# Execution system

Namada chain is running on the Anoma ledger. Namada is set out to initially only leverage a selected subset of Anoma's features and e.g. Anoma Intent gossiper and Matchmaker systems will not be supported. The main component specified on this page is the Tendermint-based Anoma ledger with a WASM-based transaction and validity predicate system, that powers many other components of Namada (such as IBC, PoS and MASP integrations).

## Anoma Ledger

The Anoma ledger is built on top of Tendermint's ABCI interface with a slight deviation from the ABCI convention, that is in Anoma, the transactions are currently not being executed in ABCI DeliverTx method, but rather in the EndBlock method. The reason for this is DKG and ABCI++ integration in Anoma, which has not yet been fully finished and hence is out-of-scope for Namada.

The Anoma ledger features an account-based system (with UTXO employed inside it in certain integrations, such as MASP) where each account has a unique address and a dynamic key-value storage sub-space. Every account in Anoma is associated with exactly one validity predicate. Fungible tokens are accounts, whose rules are governed by its validity predicate. Many of the ledger integrations are themselves just special Anoma accounts too (e.g. PoS, IBC and MASP).

Interaction with the Namada ledger are made possible via Anoma transactions (note transaction whitelist). Please refer to the protocol section that specifies the transaction execution model. In short, in Anoma transactions are allowed to perform arbitrary modification to storage of any account, but the transaction will be accepted only if all the validity predicates that were triggered by the transaction accept it. That is, the accounts whose storage sub-spaces were touched by the transaction and/or an account that was explicitly elected by the transaction as the verifier will all have their validity predicates verifying the transaction. A transaction can add any number of additional verifiers, but of course cannot remove the ones determined by the protocol. For example, a transparent fungible token transfer would typically trigger 3 validity predicates - those of the token, source and target addresses.

## Transaction and validity predicate whitelist

While Anoma ledger aims to be a fully programmable ledger, for Namada only a selected subset of provided validity predicates and transactions will be permitted through pre-defined whitelists configured for the Namada network.