Architecture Overview
Nigo Protocol is the core protocol of BXDL, an enterprise distributed ledger product. It converts application requests into canonical ledger transactions, ensures every validator computes the same state transition and receipt, and exposes only consensus-finalized results.
BXDL adds product deployment, operations, security policy, enterprise integration, and industry solutions on top of this core.
Design principles
The architecture maintains the following principles.
- Separate consensus data from execution implementations. The ledger owns the canonical bytes of transactions and blocks, but does not own VM opcodes or business rules.
- Execute state transitions in isolated overlays. A failed execution discards its overlay; only successful results are merged into parent state.
- Keep application execution rules out of the consensus engine. Consensus nodes independently re-execute proposals through the common block pipeline and validate the result.
- Anchor chain-wide rules in consensus state. Consensus, fee, and execution profiles bind to genesis or an agreed activation height rather than arbitrary node-local options.
- Treat only finalized results as canonical ledger data. Proposals in progress remain distinct from finalized blocks.
- Build external compatibility as adapters over the core ledger. Ethereum JSON-RPC and SDK compatibility do not replace Nigo's internal state model with Ethereum's account-state model.
End-to-end flow
RPC decoding and block commit are outside the execution core. The execution core produces deterministic results for the supplied transaction and state view. The blockchain layer assembles those results into blocks, while the consensus layer validates and finalizes the same results.
Major layers
State and ledger foundations
| Module | Responsibility |
|---|---|
nigo-state-cell | StateCell, ID domain, schema/value codecs, StateStore, and execution overlays |
nigo-state-commitment | Compact Sparse Merkle Tree, canonical state root, proofs, and node-store port |
nigo-ledger | Block, transaction, receipt, and finality values plus canonical codecs and hashes |
nigo-crypto | Reusable cryptographic primitives including secp256k1, BN254, BLS12-381, P-256, and KZG |
nigo-state-cell and nigo-ledger do not depend on a VM, Spring, JDBC, or RPC. This boundary prevents consensus-visible values from becoming coupled in reverse to the execution and transport adapters that process them.
Execution and blocks
| Module | Responsibility |
|---|---|
nigo-vm | Shared EVM interpreter, gas schedules, and constrained Native validator execution mode |
nigo-core | Signature and admission revalidation, per-kind transaction execution, and fee/receipt settlement |
nigo-blockchain | TxPool, block candidates, sequential and parallel scheduling, block roots, and finalized-commit preparation |
Core enforces consensus execution rules so that identical input state and transactions produce the same StateDelta and receipt. Core has no knowledge of block worker counts, RPC DTOs, JDBC tables, or the Spring lifecycle.
The blockchain layer creates a child overlay per transaction and merges execution results in canonical transaction-index order. Even when parallel execution is enabled, the final ledger bytes and state root must match sequential execution.
Consensus and networking
| Module | Responsibility |
|---|---|
nigo-consensus | Consensus profiles, validator identity and sets, and common engine, transport, signer, and safety-store SPIs |
nigo-consensus-qbft | QBFT quorum, proposer selection, rounds, and canonical message/certificate validation |
nigo-network-p2p | Peer identity, handshake, capabilities, channel/frame handling, and secure-session boundaries |
nigo-transaction-gossip | Bounded transaction propagation, ingress, relay, deduplication, and peer-fault policy |
nigo-block-sync | Finalized snapshots, proofs, archives, catch-up, and live follow |
Consensus modules do not depend directly on Core or the VM. Proposal execution and validation live in the common blockchain pipeline; QBFT decides which proposal obtains quorum finality.
The current permissioned profile centers on a static validator set. Dynamic membership, public validator admission, and the economic security of a public network are not part of the same completion claim.
Storage, queries, and APIs
| Module | Responsibility |
|---|---|
nigo-storage-rdb | JDBC adapters for state, blocks, transactions, receipts, finality, and indexes |
nigo-observability | Backend-neutral query contracts for accounts, transactions, state, and activity |
nigo-rpc | Shared JSON-RPC registry, metadata, and exposure policy |
nigo-native-rpc | Nigo Native JSON-RPC projection |
nigo-eth-compat | Ethereum raw-transaction ingress, signature binding, nonce, and hash mapping |
nigo-eth-rpc | Ethereum JSON-RPC projection |
nigo-node | Spring Boot lifecycle and assembly of profiles, keys, transport, storage, RPC, and monitoring |
Storage implementations satisfy the state and ledger ports but do not redefine canonical transaction semantics. Memory and RDB profiles share the same execution contract, and the node selects adapters appropriate to the deployment.
Transaction execution lifecycle
A transaction with an invalid structure, signature, or protocol invariant is rejected without a receipt. In contrast, EVM REVERT, out-of-gas, or an allowed Native validator execution failure can remain in the block with a failure receipt and the defined fee transition. See the transaction model for the distinction.
State and finality
Each transaction execution produces spends and creates against the active StateCell set. The block pipeline merges these results in order, and the state-commitment layer computes the new state root.
QBFT validators check that the proposal's transactions, state root, transaction root, and receipt root match their own re-execution. A proposal is not a canonical block before it obtains a quorum certificate. Blocks, transactions, receipts, state, and indexes are persisted only after finality.
Benefits of the architectural boundaries
- Replacing a memory or RDB adapter does not change transaction semantics.
- Native RPC and Ethereum RPC can project the same finalized ledger in different forms.
- Parallel execution remains a node-local optimization; worker configuration never enters the block codec.
- A consensus profile can be replaced or revised without coupling the execution core to a particular consensus algorithm.
- Canonical bytes and execution semantics can be validated independently through test vectors and independent references.
The existence of a module or integration test does not mean an entire BXDL deployment has production approval. Feature implementation, integration validation, failure testing, and operational approval are tracked separately under assurance and support boundaries.