Skip to main content

Vaults and Ownership

Overview​

Assets on delta are held in vaults. Every end-user transaction involves at least one vault.

Vault Structure​

A vault is located by its address which consists of two components:

  • The owner ID of the signer that controls the vault
  • The shard ID of the domain where the vault is located. Since delta's architecture is designed for state isolation between domains, vaults always exist on a shard.
pub struct Address {
    /// Defines the owner of this vault.
    owner: OwnerId,

    /// Shard identifier that this vault belongs to.
    shard: Shard,
}

Vaults can only be debited (or modified, in the case of a token mint) when two conditions are met. The message must be:

  • Signed by the correct private key (which corresponds to the vault's owner ID)
  • Processed into an SDL by the correct domain (which controls the shard where the vault is located)

This binding prevents double-spending, since assets can only exist on a single shard at a time and can only be debited by the domain that controls said shard.

Credits are excluded from the above restrictions; they can be applied from any domain, allowing assets to flow across the network while maintaining security at the base layer.

Owner IDs and Signing​

An owner ID is a unique 32-byte hash digest deterministically generated from a public key (ed25519), passkey, or multisig combination. The owner ID might represent a user, token issuer, or other party on the delta network.

The delta protocol treats all signing methods identically.

  • A vault controlled by an ed25519 key looks the same as one controlled by a passkey or multisig
  • This abstraction allows new signing schemes to be supported in the future, without core protocol changes

Vault Contents​

Each vault can contain either a Token Holding which stores balances of non-native tokens, or a Token Mint which issues them.

Token Holding​

The most common type of vault is a token holdings vault. Token holdings vaults can contain any number of fungible and non-fungible tokens. These are the "typical" vaults which will generally be held by end-users and used to interact with most applications on the delta network.

token holdings data struct
pub struct TokenHoldings {
    /// A mapping from (fungible) token IDs to their respective balances in plancks.
    fungibles: HashMap<TokenId, Planck>,
    /// A mapping from NFT token ids to their respective holdings, that is, a
    /// set of collectibles in the collection issued by the given token id.
    nfts: HashMap<TokenId, nft::Holdings>,
}

Token Mint​

Token mints are data structures which represent a non-native token (both fungible and non-fungible). They store token metadata (token ID, total minted supply, name, and symbol/ticker) rather than token balances. For more detail on the inner workings of token mints, see Tokens.

Token mints exist in vaults. Only a valid signature corresponding to the vault's owner ID can manipulate a token mint, including issuing additional supply.

Vault Operations​

Vault Creation​

Creation of vaults is implicit. Whenever an owner ID receives contents for the first time on a given shard, a vault will be created at that address.

  • Crediting native tokens to a new vault address will create a generic vault, which can later hold a token holding or token mint
  • Crediting non-native tokens to a new vault address will create a token holding vault
  • Signing a mint operation for a new vault address will create a token mint vault

A vault's owner cannot be changed. Transferring ownership requires creating a new vault and moving the assets. Additionally, each owner ID can only have a single vault on each domain.

delta does not have explicit "accounts." Instead, the same owner ID can hold vaults across multiple domains, enabling builders to create multi-domain applications or wallet implementations.

Base Layer Migrations​

Since all user-level transactions occur on domains, delta provides an "escape hatch" mechanism to protect users if a domain becomes malicious, unresponsive, or censors transactions.

Users can forcefully migrate their assets out of a domain by signing a base layer migration transaction and submitting it directly to a validator. This bypasses the domain entirely, allowing users to move a vault to a different shard without requiring the domain's cooperation.