Skip to main content

Overview

delta separates execution from verification.

  • The settlement layer operated by the delta validator set manages state by verifying proofs and applying state changes;
  • The execution layer consists of the applications, platforms and other systems settling to delta. We refer to these as domains.

Execution​

Execution overview of a domain server connected to the delta Gateway and settlement layer

delta’s guardrail model differs from verifiable execution—instead of proving the full execution trace, applications are expected to prove a set of invariants that define the rules of their system. These rules are independent of execution, and live in a separate layer. This gives the developer full freedom in terms of defining their execution logic, while still providing verifiable guarantees.

While it is possible to write custom execution environments that connect to the delta settlement layer, we provide a default approach via what we call the delta Gateway. Using the gateway, any server can connect and settle to delta via a simple OpenAPI connector.

The delta Gateway consists of two independent modules:

  1. State provides the server with information about its users’ state, i.e. their balances;
  2. Guardrails consists of the application-defined guardrails and the corresponding prover.

Note that the domain is the entire system run by you: your backend along with your gateway.

Transaction Lifecycle​

In the following, we trace the transaction lifecycle from end user submission to final settlement:

  1. The user submits an intent to its server. This intent typically contains an amount as well as other metadata directed at the guardrails (transaction type, parameters);
  2. The server collects user intents as well as other inputs in the form of verifiable data, and runs the batch of inputs through its execution logic to get outputs in the form of an SDL (State Diff List). The SDL is the canonical format of delta.
  3. In order to settle the SDL to delta, it sends both the verifiables and the SDL to the prover. The prover computes a proof that the SDL and its corresponding inputs satisfy the guardrails, which verifies against the SDL itself (the inputs remain private).
  4. The prover submits the SDL and the proof to the settlement layer. This potentially happens async, i.e. the SDL can be submitted before the proof has been computed.
  5. The validators verify that the SDL is valid and settle it by applying its changes to state.

SDL Verification​

For an SDL to be valid, three conditions must be satisfied:

  1. Guardrail satisfaction: the SDL proof must verify;
  2. Dependencies: all prior SDLs from the same submitter have settled;
  3. Applicability: the SDL applied to state does not bring any vault balance below 0.

State Model​

delta’s state is managed on the settlement layer. In other words, state is shared across all systems forming the execution layer, and no bridging is required between them.

Vaults​

End user balances are kept in vaults, tied to a specific execution-level system. This binding prevents double-spending: without it, a single vault owner could spend the same holdings across multiple applications in parallel.

On the other hand, a vault can send assets to any other vault within delta.

In other words, there exists an asymmetry between debits (spending) and credits (receiving).