Typhon stores, orders, and executes transactions on Anoma blockchains. It is intended as a replacement for Tendermint. We have a brief overview presentation of some of the features of Typhon here..

Typhon can be broken down into (roughly) 3 layers:

  • a mempool, which stores received transactions
  • a consensus, which orders transactions stored by the mempool, and
  • an execution engine, which executes the transactions on the state machine.

We expect each Anoma participant (validator) will run processes in all three layers. layer diagram Above, we use "client" to refer to matchmakers, ferveo, or anyone else who generates transactions to be ordered. The "critical path" is shown in thicker arrows, with other crucial messages shown in narrower arrows.


Validators receive transactions from clients, store them, and make them available for the execution engine to read. The mempool protocol, which is based on Narwhal also produces a DAG of headers, which reference batches of transactions (via hash), and prove that those transactions are available for the execution engine. These headers are ultimately what the consensus decides on, in order to establish a total order of transactions. Read more here.


Our consensus is based on Heterogeneous Paxos. Validators choose a totally ordered sequence of headers from the mempool DAG. This establishes a total order of transactions for the execution engine to execute. Read more here.

Execution Engine

Given a total order of transactions, the execution engine updates and stores the "current" state of the virtual machine, using as much concurrency as possible. Proofs from the execution engine allow light clients to read the current state. When the execution engine has finished with a transaction, it communicates to the mempool that the transaction can be garbage-collected from storage. Read more here.