Skip to main content

Proof Lifecycle

Overview​

Every SDL must be verified against the domain's guardrails before the contained state changes can be finalized on the settlement layer. This verification process occurs in the form of generating zero-knowledge proofs.

Proving Workflow​

Defining guardrails​

Guardrails are defined by the domain. A domain can implement guardrails by providing the program hash when declaring their domain agreement during domain setup. When the domain generates a SDL proof, validators will use the hash to confirm it was generated using the declared program.

To learn about writing guardrail logic, see our guide on implementing guardrails.

Proofs in the Transaction Workflow​

Guardrails 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). Guardrails are typically enforced at this stage to ensure only valid transactions proceed.

Settlement
When a domain chooses to finalize state updates to the settlement layer, the SDL, transaction context, vault balances, and guardrail program are processed through a zkVM to generate a zero-knowledge proof. This proof and the associated SDL are sent to the settlement layer for validation and final application.

transaction_workflow.png

How proving works in practice​

The [delta gateway][gateway] 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 delta gateway 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

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.