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 of the domain client, which exposes API endpoints for important functionality including submitting SDLs and SDL proofs to the configured base layer validator, and triggering proof generation for a given SDL.

Base Layer​

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

Base 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 base layer 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.

Base Layer Transactions​

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

  • submission of SDLs and SDL Proofs to update the state on a domain's shard (called "state diff transactions")
  • base layer configurations like deployment of a new domain or validator (called "base state transactions")
  • transactions to migrate vaults between shards (called "migration transactions")

In the code, these are simply called Transactions.

Credit​

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

Debit (debit allowances)​

A signable 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).

Domain​

A user-facing, independent execution environment connected to the delta Base 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 base layer) and a domain client which handles the domain's integration with the delta base layer.

Domain Agreement​

A record stored at the base layer that registers a domain on the delta 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.

Domain Client​

The component of a domain which contains a copy of the domain's shard (including all vaults and balances), handles the creation of SDLs, coordinates proof generation, and communicates with the delta base layer. Domain operators will use the domain SDK to set up and optionally customize their client.

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 base layer.

Domain SDK​

delta's comprehensive SDK for building and running domains on the delta network. Developers can use the domain SDK to build with delta primitives, configure and run a domain client, and connect with the delta base layer.

Domain State View​

Each domain maintains its own local state view with the domain client. This view can update immediately when an end-user transaction is executed, prior to settlement on the base 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 (assume 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 State​

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 base 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.

Global Laws​

The rules of the delta network which apply across all user-level transactions in all domains. These are designed to be minimal and only restrict behavior that would break the network (e.g., a debit transaction must have a valid signature from the vault owner, and a vault balance must be more than the debited amount).

Local Laws​

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

Native Token​

delta has a native token which is used for network operations like registering a new domain, submitting SDLs and proofs, and base 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, 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 follow applicable laws. 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 laws.

Shard​

Global state on the base 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 domain SDK or domain client APIs to trigger state updates to the delta base 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 base layer to update balances on the shard and finalize the user-level transactions.

Token Holding​

Information stored in a vault that tracks non-native token balances. Token holdings store token IDs and their corresponding amounts. The vault owner can debit from these balances.

Token ID​

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

Token Laws​

Rules that are defined by the token issuer and configured in the token mint vault. Token laws are applied to all user-level transactions involving the token, across all domains. Token laws are designed specifically to enable compliance for token issuers, so they are configuration-based rather than free-form like local laws.

Token Mint​

Information stored in a vault that represents a non-native token or NFT collection on the delta network. 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.

Transaction​

A signed message to change state. As delta is 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 (and later by means of an SDL on the base layer as well). User-level transactions can be debits allowances and token mints.

In the code, these are called Verifiables.

Validator​

A node on the network 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 base layer. Through the validator RPC, clients can:

  • Submit base 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. In addition to a native token balance, vaults can store either a TokenMint or a TokenHolding.

zkVM​

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