delta Transactions
Overview​
delta has multiple transaction types that operate across its two-layer architecture. Understanding these transactions requires distinguishing between who signs the message, where it's processed, and what state it affects.
All transactions in delta are wrapped in a signed message container, which consists of a payload (the transaction data) and a signature. This abstraction allows the same signature verification logic to work across all transaction types, while the effects vary based on the sender, recipient, and payload content.
Transaction Categories​
Transactions on delta are organized into two categories: user-level transactions (which are processed by domains) and settlement layer transactions (which are processed by the validator set).
User-Level Transactions​
User-level transactions are signed by vault owners and submitted to domains. They include end-user actions like transferring tokens or minting new assets. These transactions:
- Are signed by the vault owner (using passkey, Ed25519 private key, or multisig combination)
- Get submitted to a domain client and applied to the domain's local state view immediately
- Are bundled into an SDL and verified through a zk proof before being finalized to the settlement layer
- Latency for final settlement is determined by the domain where the transactions occur
For more detail on user-level transactions, see token operations.
Settlement Layer Transactions​
Settlement layer transactions are submitted to delta validators, and affect either finalized state (vaults and their balances on the settlement layer) or the network core configuration (validator set or domain agreements). These transactions:
- Get submitted to a settlement layer validator RPC
- Are finalized by the correct consensus mechanism ("fast path" or epoch end state transition) depending on the operation.
Transaction Summary Tables​
Below is a complete reference of all transaction types in the delta protocol.
User-Level Transactions​
| Transaction | Purpose | Signed By | Submitted To | Finalization |
|---|---|---|---|---|
| debitAllowance | Transfer tokens up to a signed amount from one vault to another | Vault owner | Domain client | Domain dependent |
| Create Token Mint (Fungible) | Issue a new fungible token with the given parameters (including initial supply and recipient vaults) | Vault owner | Domain client | Domain dependent |
| Create Token Mint (NFT) | Issue a new NFT collection with the given parameters (including initial tokens and recipient vaults) | Vault owner | Domain client | Domain dependent |
| Increase Supply | Issue additional supply of an existing token to the given recipient vaults | Vault owner | Domain client | Domain dependent |
Settlement Layer Transactions​
| Transaction | Purpose | Signed By | Submitted To | Finalization |
|---|---|---|---|---|
| Submit SDL | Propose state updates | Domain client | Validator | Fast path consensus |
| Submit Proof | Submit cryptographic proof of state updates | Domain client | Validator | Fast path consensuss |
| Submit Domain Agreement | Register a new domain with the given owner and shard | Domain operator | Validator | Epoch end state transition |
| Update Domain Agreement | Update an existing domain agreement (includes updating guardrail program) | Domain operator | Validator | Epoch end state transition |
| Declare Validator | Add validator to consensus set | Validator operator | Validator | Epoch end state transition |
| Settlement Layer Migration | Forcefully migrate a vault from one domain to another | Vault owner | Validator | Epoch end state transition |
Implementation Notes​
In the delta codebase, signed user-level transactions are referred to as verifiables because they represent operations that will be verified through the proving system.