Skip to main content

Glossary of delta terms

Address​

The identifier of a specific vault, determined by the vault's owner ID and the shard where the vault resides such that Address = (OwnerID, Shard).

Admin API​

The admin API is an optional feature which can be included in a fully custom-built domain to expose API endpoints for communicating with the settlement layer. This includes submitting SDLs and SDL proofs to the configured validator, and triggering proof generation for a given SDL.

Credit​

A positive change to a vault's balance. Credits do not need to be signed by the recipient vault.

Debit (debit allowances)​

A user-level transaction message used to transfer tokens from a token holding vault. A debit allowance specifies a maximum allowed debit for a given token ID and token holding vault. Once signed by the private key of the vault, up to the signed amount can be debited (based on the execution logic).

Default Guardrails​

The default guardrails are designed to be minimal and only enforce standard requirements (e.g., a debit transaction must have a valid signature from the vault owner). It is recommended all domains implement the default guardrails at a minimum, unless a highly specialized use case requires different behavior.

delta Gateway​

The component of a domain which interfaces with the delta settlement layer. This includes keeping a record of the domain's shard (including all vaults and balances), handling the creation of SDLs, coordinating SDL proof generation, and communication with the delta settlement layer. The delta gateway can be run as a docker image and integrated with almost any existing system using OpenAPI endpoints. Domain builders can optionally build a delta gateway from scratch using the domain SDK if they want nonstandard customization.

Domain​

A user-facing, independent execution environment connected to the delta settlement layer. A domain consists of an application (the actual software and business logic), a domain operator (the signer authorized to submit SDLs and proofs to the settlement layer) and a delta gateway which handles the domain's integration with the delta settlement layer.

Domain Agreement​

A record stored at the settlement layer that registers a domain on the network. The domain agreement identifies the domain by its operator and its owned shard. A valid and active domain agreement must exist before the domain operator can submit SDLs or proofs to update the shard's state on the settlement layer.

Domain Operator​

The party running the domain, represented by the owner ID of the signing key. The domain operator signs all SDLs and SDL proofs sent to the settlement layer.

Domain SDK​

delta's comprehensive SDK for building and running domains from scratch on the delta network. In many cases, domain builders will build on top of the delta gateway without using the domain SDK directly, but advanced developers can use the SDK to build with delta primitives, configure and run a custom domain gateway, and connect with the delta settlement layer.

Domain State View​

Each domain maintains its own local state view with the delta gateway. This view can update immediately when an end-user transaction is executed, prior to finalization on the settlement layer. This view is typically ahead of the finalized state for the vaults on a domain's shard.

Epoch​

The delta protocol operates on a time-based epoch system, where each epoch (approximately 1 hour) represents a period during which transactions are synchronized and ultimately accepted (i.e. applied to the system state) in all validators. At the end of each epoch, validators are guaranteed to have the same view of the system state. Changes which directly affect the network, like adding new domains or validators, are only processed between epochs.

Execution Layer​

Describes the domain layer of the delta ecosystem. All transaction execution and compute occurs on domains.

Finalized State​

The shared, irrevocable state maintained on the settlement layer. Once SDLs and their corresponding proofs are accepted by consensus and applied to the relevant vaults and shards, these changes are considered finalized and cannot be reversed.

Guardrails​

Rules that are imposed by a domain and apply to all user-level transactions which occur on that domain. Domains might use guardrails to enforce specific application logic, prove valid API connections, demonstrate compliance, or steer AI agent behavior.

Native Token​

delta has a native token which is used for network operations like registering a new domain, submitting SDLs and proofs, and settlement layer transactions. End-users will typically not need to hold a delta native token balance.

Owner ID​

An owner ID is a unique 32-byte hash digest deterministically generated from a public key (Ed25519), passkey, or multisig combination. The owner ID is used to identify a "user" (may be an end-user, token issuer, domain operator, agent, or other party) on the delta network.

Planck​

The minimal denomination for fungible tokens on the delta network.

RISC-V​

An open-source instruction set architecture (ISA) used in delta for zero-knowledge proof generation. zkVMs like SP1 and RISC Zero compile Rust programs to the RISC-V instruction set, enabling delta's SDL proofs to verify that SDLs comply with applicable guardrails. RISC-V's status as an open standard allows programs written in Rust (and other languages with RISC-V compilation targets) to be proven using established zkVM frameworks.

SDL Proof​

A RISC-V proof that a given SDL is valid, meaning all summarized user-level transactions followed the applicable guardrails.

Settlement Layer​

The network of validators that use consensus to validate proofs and SDLs sent from domains, and track global state.

Settlement Layer Migration​

The "escape hatch" mechanism which allows users to forcefully migrate their assets out of a given domain (which may be malicious, unresponsive, or censoring the user). The user can sign the migration transaction for one of their controlled vaults, and submit this message directly to a validator. It will be processed at epoch end to ensure any standard user intents can be executed by the domain before the vault is moved.

Settlement Layer Transactions​

Signed messages sent directly to a validator RPC to change the state on the settlement layer. Includes:

  • submission of SDLs and SDL Proofs to update the state on a domain's shard
  • settlement layer configurations like deployment of a new domain or validator
  • transactions to migrate vaults between shards

In the code, these are simply called Transactions.

Shard​

Global state on the settlement layer is organized into shards, where each domain owns a single shard. A shard contains vaults and balances on that domain, and domains may only debit from their owned shard (credits can be applied to external shards). This state isolation allows for domains to submit updates without requiring total global ordering.

Smart Contracts​

delta is not a smart contract system. Instead, domains are able to run any logic or program they like while using the delta Gateway APIs to trigger state updates to the delta settlement layer.

State Diff​

A change to a specific vault on a specific shard, which is created by summarizing the user-level transactions which have occurred on the domain affecting that vault.

State Diff List (SDL)​

An aggregated list of state diffs for a given domain's shard. SDLs are submitted to the settlement layer to update balances on the shard and finalize the user-level transactions.

Token Holding​

A vault that tracks token balances. Token holdings store token IDs and their corresponding amounts. The vault owner can debit from these balances. Each token holding vault has a unique signing key.

Token ID​

The unique identifier of a fungible token on the delta network. The token ID is equivalent to the vault address of the token mint vault.

Token Mint​

A vault that represents a fungible token or NFT collection. Token mints store token metadata (token ID, total minted supply, name, and symbol/ticker) rather than token balances. The vault owner can update certain metadata and issue additional tokens. Each token mint vault has a unique signing key.

Transaction​

A signed message to change state. As delta is a two-layer system, there are two layers of transactions:

User-level Transactions / User Intents​

Signed messages from end-users to domains to change state on the domain. Completed transactions are summarized into an SDL to finalize on the settlement layer. User-level transactions include debit allowances (to transfer tokens between vaults) and token mint transactions (which create/edit a token mint vault on the domain).

In the code, these are called Verifiables.

Validator​

A node on the settlement layer communicating with other validators (its peers) to keep track of the system and its state.

Validator RPC​

The gRPC-based interface exposed by validators that allows domains and applications to interact with the delta settlement layer. Through the validator RPC, clients can:

  • Submit settlement layer transactions (SDLs, proofs, domain agreements)
  • Query state (vaults, transaction status, epoch information)
  • Subscribe to network events (epoch transitions, SDL updates, vault migrations)

The domain SDK provides a BaseRpcClient that handles connection management and request/response serialization for communicating with validators.

Vault​

A data structure which exists in execution state (on shards). Vaults are identified by the owner ID of the signer and the shard of the domain where the vault is stored. A vault can be either a TokenMint or a TokenHolding.

zkTLS​

A zero-knowledge proof technique that proves the contents of a TLS (HTTPS) connection without revealing the underlying data or requiring cooperation from the server. zkTLS enables domains to verify off-chain data sources like API responses or web content.

zkVM​

A zkVM (zero-knowledge virtual machine) can run programs and generate proofs of correct execution. In delta, a zkVM is used to execute guardrail programs and generate an SDL Proof. delta primarily uses the RISC-V based zkVM SP1, with guardrail programs written in Rust and compiled to RISC-V instructions.