Skip to main content

Proof Lifecycle

Overview​

Every SDL must be verified against the delta global laws and any domain local laws before the contained state changes can be finalized on the delta base layer. This verification process occurs in the form of generating zero-knowledge proofs.

Proving Workflow​

Declaring Local Laws​

Local Laws are optional, and defined by the domain. A domain can implement local laws by providing the program hash when declaring their domain agreement during domain setup. When the domain generates a local law proof, validators will use the hash to confirm it was generated using the declared program.

To learn about writing local law logic, see our guide on implementing local laws.

Proofs in the Transaction Workflow​

Laws fit into the transaction lifecycle as summarized below:

Transaction submission
Users sign transaction messages and submit them to the domain.

Execution
Valid transactions are immediately applied to the domain's local balances and added to the pending state diff list (SDL). Global laws are enforced at this stage to ensure only valid transactions proceed. It is best practice to also include any local laws in domain execution logic.

Settlement
When a domain chooses to settle changes to the base layer, the SDL, transaction context, vault balances, and law programs are processed through a zkVM to generate a zero-knowledge proof. This proof and the associated SDL are sent to the base layer for validation and final application.

transaction_workflow.png

Proof Aggregation​

delta's proof program uses proof aggregation to maintain efficiency regardless of local law complexity.

Stage 1: Local Law Proof
If the domain has declared local laws, a separate proof is generated first. This proof demonstrates that all transactions in the SDL satisfied the domain's local laws.

Stage 2: Global Law Proof
The global law proof program:

  • Verifies the local law proof (if present) as part of its execution
  • Proves all transactions satisfy delta's universal rules
  • Produces a single, compact proof for the entire SDL

As a result, any number or complexity of local laws compress to the same proof size (a few hundred bytes) while remaining cryptographically secure. Validators only need to verify one proof, regardless of how many local laws a domain implements.

transaction_proving_workflow.png

How proving works in practice​

The domain SDK handles all proving operations automatically. Domain developers don't need to write proving code or manage the proof lifecycle, they only need to configure their proving setup during domain initialization and encode logic to trigger the process (as simple as a call to the domain's admin API).

The domain SDK runtime automatically:

  • Ingests signed user transactions
  • Validates signatures and applies transactions to local vault balances
  • Aggregates valid transactions into an SDL
  • Generates zero-knowledge proofs using the configured prover
  • Submits the SDL and proof to the base layer
  • Handles retries and error recovery

The global law proof program is included in the domain SDK. If local laws are defined, the runtime verifies the local law program hash matches the domain agreement and includes the local law proof in the aggregation workflow.

Choosing a proving setup​

Each domain can choose where and how proofs are generated:

  • CPU: - generates proofs locally on CPU (typically for testing and development only)
  • Remote: - connects to a custom remote prover
  • CUDA: - uses a local CUDA-enabled GPU
  • Succinct Network: - uses Succinct's prover network

All options produce identical proofs and integrate seamlessly with the SDK’s submission flow.