# Nibiru Architecture
The technical architecture of the Nibiru protocol consists of an execution engine and a consensus engine. The execution engine is where transaction execution occurs to compute new state updates, while the consensus engine validates and gossiping of blocks, ultimately adding them to the chain.
# Execution Engine
The execution engine of Nibiru is the overarching component that implements business logic and manages the "state" that makes Nibiru a state machine. This is where transactions are processed and disseminated.
This layer is essentially described by the Nibiru EVM and Wasm execution environments for smart contracts and custom "modules".
# Consensus Engine
The Nibiru Consensus Engine is responsible for block building, the gossip of blocks on the peer-to-peer (P2P) network, and management of consensus for new blocks to be added to the chain. Nibiru makes use of delegated proof of stake on CometBFT as its consensus algorithm.
# Block
A block is an ordered sequence of transactions along with a cryptographic hash that references the prior, or parent, block that came before. A block's hash is derived from the data and resulting state of executing the state transitions (transactions) it contains.
# Modules — Nibiru
| Module | Active? | Description |
|---|---|---|
| Wasm | ✔️ | Handles Wasm smart contracts. This is the interface with the Wasm VM. |
| Dev Gas | ✔️ | Implements a Smart contract gas royalties mechanism allowing builders to capture the value they create. |
| Epochs (opens new window) | ✔️ | Often in the SDK, we would like to run certain code every-so often. The purpose of epochs module is to allow other modules to set that they would like to be signaled once every period. So another module can specify it wants to execute code once a week, starting at UTC-time = x. epochs creates a generalized epoch interface to other modules so that they can easily be signalled upon such events. |
| Oracle (opens new window) | ✔️ | Handles the decentralized oracle module. |
| Common (opens new window) | ✔️ | Holds helper and utility functions to be utilized by other x/ cosmos-sdk modules. |
| Common/testutil (opens new window) | ✔️ | Helper functions for unit and integration tests. |
# Modules — Cosmos-SDK
Production-grade modules imported from the Cosmos-SDK:
| Module | Active? | Description |
|---|---|---|
| auth | ✔️ | Authentication of accounts and transactions for Cosmos SDK application. |
| authz | ✔️ | Authorization for accounts to perform actions on behalf of other accounts. |
| bank | ✔️ | Token transfer functionalities. |
| base (opens new window) | ✔️ | |
| capability | ✔️ | Object capability implementation. |
| crisis | ✔️ | Halting the blockchain under certain circumstances (e.g. if an invariant is broken). |
| crypto (opens new window) | ✔️ | |
| distribution | ✔️ | Fee distribution, and staking token provision distribution. |
| evidence | ✔️ | Evidence handling for double signing, misbehaviour, etc. |
| feegrant | ✔️ | |
| genutil (opens new window) | ✔️ | |
| gov | ✔️ | On-chain proposals and voting. |
| mint (opens new window) | ✔️ | Creation of tokens native to the chain. |
| params (opens new window) | ✔️ | Globally available parameter store. |
| slashing (opens new window) | ✔️ | Validator punishment mechanisms. |
| staking | ✔️ | Proof-of-Stake layer for public blockchains. |
| tx (opens new window) | ✔️ | |
| upgrade | ✔️ | Software upgrades handling and coordination. |
| vesting (opens new window) | ✔️ |
# Inter-Blockchain Communcation (IBC)
The IBC module has its own repository, ibc-go (opens new window).