Transaction Lifecycle

This document traces the complete journey of a debit allowance (the most common user-level transaction) through the delta network, from the end-user's device through a domain and onto the base layer where it becomes finalized state.

Overview

A user-level transaction on delta passes through several distinct phases:

1. Signing — The user signs their intent client-side
2. Submission — The signed message reaches the domain
3. Execution — The domain processes the intent and updates local state
4. Aggregation — Multiple intents are batched into an SDL
5. Proving — A zero-knowledge proof is generated
6. Settlement — Validators verify the proof and finalize state

Each phase serves a specific purpose, and together they enable delta's unique combination of instant user experience and cryptographic finality.

Phase 1: Signing the Intent

The lifecycle begins when an end-user decides to transfer tokens from their vault.

The user interacts with an application — this could be a dedicated wallet, a domain's custom interface, or any client that integrates with delta. Using a client-side library (such as the TypeScript signing SDK), the application constructs a debit allowance message containing:

• The recipient vault's address
• The maximum amount(s) to be debited per token type
• A nonce to prevent replay attacks
• The shard this domain operates on

The user then signs this message using their vault's associated method (ed25519 keys, passkeys, or multisig). The result is a signed verifiable: a self-contained message that proves the vault owner authorized the transfer.

Phase 2: Submission to the Domain

The signed verifiable now needs to reach the domain for processing. How domains receive user-level transactions depends entirely on the their implementation; delta places no constraints on that. For example, they might expose HTTP APIs, WebSockets, gRPC services, or other interfaces. Some domains might accept intents directly from users; others might require intents to pass through additional validation layers first.

Phase 3: Domain Execution

Once a domain receives a signed verifiable, the real processing begins. This phase showcases one of delta's key design principles: domains have complete freedom over execution.

Unrestricted Computation

The domain can run any code before, during, or after processing an intent. For example:

• Run a matching engine for an exchange
• Execute complex business logic for a payment system
• Validate intents against external data sources
• Apply machine learning models
• Interface with traditional databases and services

There are no blockchain-specific constraints. The domain can be written in any programming language, run on any infrastructure, and implement any architecture.

From Intent to State Diff

The domain's execution must ultimately produce a mapping from the user's signed intent to concrete state diffs.

For a simple transfer, the domain just produces state diffs that debit exactly the amount of the allowance and credit the same amount to the recipient. For more complex examples like an exchange, a user might sign an intent to sell up to a certain amount of tokens. But, the domain is allowed to produce state diffs debiting a smaller amount. Possibly based on the matching engine's output.

Domains also control the ordering of intents i.e. sequencing. They might process intents first-come-first-served, or implement priority mechanisms. This affects which intents succeed when there are conflicts, giving domains significant power.

Instant Local State Update

After execution, the domain applies the resulting state diffs to its local state view which updates balances of vaults on that shard immediately. This instant feedback is possible because the domain trusts its own execution, even though the base layer hasn't yet confirmed the changes. However, it only applies to vaults on the same shard.

The user-level transaction is now stored in the domain's pending queue, awaiting aggregation into an SDL.

Phase 4: SDL Aggregation

Rather than submitting each user-level transaction individually, domains batch multiple intents into a State Diff List (SDL).

The domain operator decides when to create an SDL. This could be on a timer (every few seconds), when a threshold of pending intents is reached, or based on any other criteria.

When an SDL is created, the domain:

1. Collects all pending state diffs since the last SDL
2. Aggregates them into a single list per affected vault
3. Signs the SDL with the domain operator's key
4. Submits it as a base layer transaction to a validator via RPC

The SDL captures the net effect of all included intents. If a vault was debited twice and credited once during the batch period, the SDL contains only the final net change for that vault.

Phase 5: Proof Generation

After submitting the SDL, the domain triggers proof generation. The proof demonstrates that all user-level transactions in the SDL followed the applicable global laws and any local laws defined by the domain. For details on what gets proven, see the list of global laws.

The domain is responsible for generating the proof — either locally or by outsourcing to an external proving service.

Proof Submission

Once generated, the proof is submitted to validators as a separate base layer transaction. The SDL and its proof can be submitted together or separately.

Phase 6: Validator Processing and Finalization

SDL Reception

When validators receive an SDL submission, they:

• Verify the SDL is signed by a valid domain operator
• Check that the domain has an active domain agreement
• Register the SDL with a status of "unproven"
• Track its dependencies on other SDLs

At this point, the SDL exists on the base layer in "submitted" status, but it hasn't affected any balances.

Proof Verification

When the corresponding proof arrives, validators verify it cryptographically. The verification is efficient — validators don't re-execute the user-level transactions, they simply check that the proof is valid for the claimed SDL.

If verification succeeds, the SDL's status changes to "proven." However, it may not be immediately applied if it depends on other SDLs that haven't been proven yet.

State Application

Once an SDL is "fully proven" i.e. all its dependencies are also proven, validators apply the state diffs to the finalized state and set the SDL status to "applied".

For each state diff in the SDL:

• Vault balances are updated according to the debits and credits
• The changes are committed to persistent storage
• The global state is updated across all validators

Finality

After application, the state changes are final and irreversible. The user-level transaction has completed its journey from intent to settled reality.

Validators broadcast SDL status updates, allowing domains to track when their submissions reach finality. Domains can use this information to provide users with confirmation that their intents have settled.