CHAIN — /docs/chain/accounts

Accounts & state

ZUL uses the SVM account model unchanged: every piece of state lives in an account addressed by a 32-byte public key, owned by a program, holding lamports (of ZUL) and arbitrary data bytes.

Storage

Accounts persist in redb, an embedded ACID key-value store, as pubkey → account records. Block data and chain metadata live alongside. Writes commit atomically per block: a crash between blocks recovers cleanly to the last committed slot, and a node restart preserves state.

ACCOUNT (SVM)

Account {
  lamports:   u64       // balance in ZUL lamports (9 decimals)
  data:       Vec<u8>   // program-defined bytes
  owner:      Pubkey    // owning program
  executable: bool
  rent_epoch: u64       // present for SVM compatibility
}

Genesis accounts

Genesis mints the total ZUL supply as native lamports into three operational accounts: the faucet, an ops account, and a bridge-reserve used by deposit minting. Genesis also installs the preloaded programs (see SVM execution) and the shielded pool's vault accounts.

Token accounts

SPL Token and Token-2022 run natively, so token balances follow the standard associated-token-account layout. Bridged SOL appears on L2 as a wrapped-SOL SPL token whose mint authority is the L2 bridge — see Asset mapping.

Account history

The node serves getSignaturesForAddress from an address-to-signature index, and the indexermaintains the same mapping in Postgres for explorer account pages. An address's shielded balance appears nowhere in any of this — by design.

← PREV

Transactions

State commitment