Skip to main content

delta Network Overview

This document offers a comprehensive overview of the delta network and how its design impacts users and builders.

What is a domain?​

A domain is a user-facing environment for arbitrary computation whose outcomes are verifiable and can be finalized on a shared state.

Users submit signed intents; the domain executes them and presents an immediate, forward state view. From a user’s point of view, it feels like a normal Web2 app — fast interactions and instant feedback — while finalization happens seamlessly in the background.

delta network is the complete system composed of two layers:

  • the base layer, a set of validators that ensures settlement and finality (via proof verification), and
  • the execution layer, where domains operate.

Together, these layers enable verifiable computation at scale: domains operate in the execution layer, and the base layer commits results into the shared finalized state.

Domains can tune their trust model. By setting local laws, a domain chooses which properties to prove; laws are enforced by the base layer and must always be proven to reach irreversible finality. This split between execution and settlement lets arbitrarily expressive applications run as domains on delta network without sacrificing verifiability or settlement guarantees.

A domain produces state diffs whenever it executes user intents. A diff is the minimal record of how a specific account’s balances or state have changed from execution. An aggregation of multiple diffs across many intents forms a State Diff List (SDL). SDLs are the artifacts domain operators submit to the base layer, together with proofs that all global and applicable local laws were satisfied.

Actors and Interfaces​

With the core idea of a domain established, we can now turn to the actors that shape its behavior.

Users​

The end user. They initiate actions by interfacing with the domain, and they self-custody their funds.

Domain​

A domain consists of software, called a domain application, which uses the domain client and is managed by an entity called domain operator.

  • The domain application: Runs the business logic and UX of the domain.
    • It defines the UX by providing the user-facing APIs.
  • The domain client: Connects the application to the delta network:
    • it defines the local state view;
    • it executes the intents and aggregates the outcomes to SDLs;
    • it computes the corresponding proofs (usually via a third-party prover).
  • The domain operator: This refers to the unique public-key-identified entity authorized to submit SDLs and proofs to the base layer.

For a domain to start operating on delta network, its operator must declare itself as the domain operator for a specific domain by submitting a domain agreement to the base layer.


Operator model and governance

The default assumption is that a domain is centrally operated. This is where most of its practical advantages come from: fast iteration, simple coordination, and clear accountability. Security does not depend on decentralization, since correctness and settlement safety are guaranteed by cryptographic proofs of delta's global laws verified on the base layer.

That said, a domain can be operated by a distributed set of parties if desired. For example, to achieve shared governance, regulatory neutrality, or stronger liveness guarantees. However, this model is optional and typically chosen for organizational reasons rather than for technical necessity.

Domain to validator interface

A domain communicates directly with the validators via RPC, by using a fixed set of transaction types:

  • Create Domain Agreement is the transaction type that declares by public key who should be the operator for a specific domain. Once this transaction settles on the base layer, the same entity remains the operator for that domain indefinitely, or until
  • an Update Domain Agreement is submitted. That is the transaction type for changing the current agreement for a specific domain. Part of the change that can be incurred via this transaction type would be changing who the domain operator for that domain is.
  • Submit State Diff List is the transaction type for submitting the aggregated account diffs to the base layer in order to settle account balances;
  • Submit SDL Proof is the transaction type for submitting the ZK proof that the specific previously submitted state diff list (SDL) is actually respecting all global and applicable local laws.

State Model​

Having introduced the main actors, we now describe how state is represented and observed inside a domain compared to the finalized state of the system.

  • Finalized state: The shared, canonical, and irrevocable state maintained on the base layer. It includes all vaults and their holdings.
  • Domain state view: Each domain maintains its own local state view. This can update immediately when an intent is executed, prior to settlement on the base layer. This view is typically ahead of the finalized state.

Users are expected to communicate with the domain (via APIs) to find out the current holdings of their accounts. In normal operation, they interact with this view rather than with the finalized state, since it reflects the effects of their actions right away.

Vaults (Accounts)​

Each vault is registered with a specific domain. This binding prevents double-spending: without it, a single owner could attempt to spend the same holdings across multiple domains in parallel.

Moreover, we maintain a strong conceptual separation between debits and credits:

  • A user can only debit their vault (i.e. spend assets held by that vault) via the domain the vault is registered with.
  • The target of a credit can be a vault registered with any domain.

This concept will be elaborated further in the next section.

State Diff Lists Lifecycle​

At any point in time, a domain operator can choose to aggregate all locally executed user-level transactions into an SDL. The SDL is then submitted to the base layer via the corresponding transaction type. At a later step (or even at the same time), the operator will submit the corresponding proof and, once the proof is verified by the validators, the diffs contained in it will be irrevocably applied to the finalized state.

Dependencies​

Each SDL depends on other SDLs:

  • Every SDL depends on the previous SDLs from the same domain. Those constitute the internal dependencies.
  • Every SDL can optionally depend on SDLs submitted by other domains. Those constitute the external dependencies.

As a result, there is an implicit SDL dependency graph.

SDL status​

In the happy path case, an SDL can have one out of three statuses:

  1. Submitted. This means it has been submitted to the base layer (without proof yet).
  2. Proven. This means the corresponding proof has been submitted and verified.
  3. Applied. This means it has settled on the base layer.

The proven state is achieved as soon as the SDL’s proof has been accepted by the base layer; however, reaching the settled state is a bit more involved:

First, all the SDLs that it depends on, from the dependency graph, must have also reached settled status. Moreover, it should be applicable. The concept of applicability is out of scope for the current document but we can intuitively define it as "the SDL can be applied to state without resulting in any negative balances."


SDL Rejection

Every SDL that reaches the base layer has a pre-defined amount of time (generally, until the end of the next epoch) to reach the settled status. If for any reason this does not happen in time (for example, because the corresponding proof was not submitted on time), there are two direct consequences:

  1. The SDL gets removed from base layer (where it has not-settled status and therefore was not yet applied to the accounts);
  2. The domain must revert all the changes that were applied to the local domain state view by consuming intents that were aggregated in the failed SDL.

Note that, while this failure case does not carry an explicit monetary penalty for the domain operator, it does negatively impact the users whose intents did not settle, and might trigger them to move elsewhere. In other words, the domain operator's reputation is at stake.

Global and Local Laws​

As previously introduced, each intent is subject to two distinct types of cryptographic settlement constraints. We refer to these as global and local laws, respectively. The validators enforce that these laws were satisfied by verifying the corresponding proof.

Global laws​

Global laws refer to settlement constraints which are universal across all domains, and they must always be proven for every user intent. One such example is the signature check: intents with invalid signatures can never settle on the base layer.

Local laws​

Local laws refer to domain-specific rules. Using a high-level programming language, each domain defines its own set of local laws that apply to it via the domain agreement. Local laws are, in principle, known to users of a domain before interaction and serve as the formal expression of the guarantees a domain offers. It could, for example, be the case that two competing domains offer the same type of service, but one of them has stricter local laws which offers its users stronger guarantees. However, such stricter laws often come with trade-offs such as higher computational cost, slower proof generation, or reduced flexibility. Each domain must therefore balance assurance and efficiency according to its business logic and user expectations.

As a simple example of a local law, a domain might declare a per-user maximum spend over a 24-hour time window. This is a use case that often appears with fintechs that need anti-fat-finger limits, merchant caps etc.


Verification spectrum (trust trade-offs)

The configuration around local laws allows for variations on the trust assumptions between user and domain. In the minimum verification maximum trust case, the domain only proves the global laws for each user intent. For example, an order-book-based exchange may keep its matching engine unconstrained and only prove that the resulting settlements are correct via global laws. This would not offer the users any guarantees about the price at which their orders are matched.

At the opposite extreme, a domain may prove all of its business logic via local laws. For example, an AMM-based exchange can prove (via local laws) that every trade and liquidity event must follow the AMM’s published formulas exactly.

Operating a Domain​

Domains are built and operated like ordinary software systems. The developer experience at a glance:

  • Write in any language. Domain business logic is language agnostic; no DSLs.
  • Define local laws easily. Local laws are written in Rust and compiled to verifiable modules, separate from the main business logic.
  • Easy onboarding. Existing applications can be “domainized” with minimal effort by starting a domain agreement and integrating via a simple SDKs:
  • Ready to use SDKs in Rust and TypeScript (more coming).
  • Runtime flexibility. Default components for sequencing, SDL aggregation, and proof generation are provided but are also fully configurable.
  • Easily interface with the domain runtime via a domain client (part of the domain SDK).
  • Run anywhere. Deploy on AWS, GCP, on on-perm infrastructure.

Base layer connectivity​

In order to communicate with the base layer, every domain must connect to at least one validator. This connection is configured through the SDKs and is designed to require minimal setup.

Running a validator​

Running a validator is optional but offers advantages to the domains. A domain that runs its own validator can prioritize its transactions and reduce reliance on third parties, though it also assumes responsibility for uptime and infrastructure. This model suits active domains, as well as those with strict requirements for autonomy, compliance, or governance.