What is ADAPT

ADAPT — A Decentralized Application Programming Toolkit — is a framework for building distributed data fabrics that act as private, verifiable backends for internet applications. You use it to build end-to-end decentralised systems in which neither the operator nor any single device has unilateral access to the data being processed.

ADAPT is for software that handles data where the security requirements are high but the throughput requirements are modest: cryptographic keys, identity documents, regulated personal data, multi-party workflows. It is not a high-performance query engine. It is a way to let mutually-distrusting parties run shared business logic over shared data without giving any of them custody of the plaintext.

At the platform level ADAPT provides:

  • Software attestation — code running anywhere in the network can prove which code is running.
  • Peer-to-peer data sharing — nodes exchange transactions over an end-to-end-encrypted message protocol without depending on any trusted server.
  • Secure inter-organisational workflows — separate organisations can compose distributed packets where each side only sees the slice of the data its role allows.

You can use ADAPT for any kind of distributed secure application — multi-device authentication, decentralised identity, zero-trust data services — or you can drop it into an existing SaaS stack to harden the parts that handle the most sensitive data.

Anatomy of an ADAPT system

ADAPT consists of:

  • A compiler for the MUFL language, a special-purpose programming language for data manipulation with strong external isolation.
  • An execution environment (the C++ evaluator) responsible for data storage, encryption, and interpreting compiled MUFL code.

The execution environment is built around three concepts:

A deeper look at how these pieces fit together — and why the architecture has the shape it does — lives in Architecture.

ADAPT Packets

A packet is a smart, self-governing data store. It holds application data alongside the business logic that controls every read and write of that data. The data could be anything the application needs to protect — credentials, identity records, permissions, an event history.

A packet is the tight binding of data to its logic. The code inside the packet is the only thing that ever touches its data; outside code talks to the packet by submitting requests through the packet’s explicit transaction interface. If the interface does not declare a way to read a field, that field is unreadable from outside, full stop.

See Packets in the ADAPT data model for the data-model detail.

ADAPT Nodes

A node is a small request-response server that hosts one or more packets, controls access to them, and speaks the ADAPT messaging protocol to other nodes. Nodes run anywhere: in a browser, on a phone, on a Linux server, inside an AWS Nitro Enclave.

Each node is responsible for:

  • Hosting its packets and protecting them from unauthorised access.
  • Receiving incoming messages from other nodes and dispatching them to the right packet.
  • Persisting packets and transaction logs to backup storage so state survives restarts.
  • For front-end nodes, brokering between the user (clicks, keystrokes, UI state) and the packets the application embeds.

Today’s shipping node forms include:

  • AWS Nitro Enclaves backend nodes.
  • Linux server nodes.
  • Node.js-embedded backend nodes.
  • Browser-embedded front-end nodes.

Nodes can be deployed by the operator as part of a DevOps process, or materialise automatically on user devices when a user installs the application.

ADAPT Transactions

A transaction is a single message handed to a node and dispatched to a packet. It carries input data. If it succeeds, it may produce a new packet state and an output message — possibly a request to invoke a transaction on another packet, which the node forwards on the sender’s behalf.

Transactions are the entire input/output surface of a packet. They are written in MUFL, which is also how the packet describes the rest of its business logic. Every data access inside a node passes through a declared transaction; there is no other path.

Where to go next