Architecture
The Wallet Node architecture processes requests and delivers data between the customer's wallet system and the blockchain. Customers keep running key custody, signing, and the ledger in their existing systems, while Wallet Node handles node access, data indexing, and event delivery. This page describes the overall structure, the role of each component, the order in which requests and data are processed, and the division of responsibilities between the customer and Nodit.
System Overview
Wallet Node sits between the customer's systems (Institution) and the blockchains (Blockchains). The customer Backend sends requests to Wallet Node's HyperNode and Data API, and receives events through Webhook. Wallet Node synchronizes with the blockchains through the Node Pool, and provides the data collected by the Indexer through the Data API and Webhook.
In the diagram, the left side is the customer's systems, the center is Wallet Node, and the right side is the blockchains. Dots represent actual data movement. Green indicates requests, blue indicates responses, and orange indicates continuously flowing data. Validate, Execute, Observe, and Reconcile at the top are the four layers supported across Wallet Node, and Assure at the bottom is the operational assurance that applies to all of Wallet Node.
Components
The Wallet Node architecture divides into components operated by the customer and components operated by Nodit. Customer components use your existing systems as they are, and Nodit builds and operates the Wallet Node components.
Customer Components
| Component | Role |
|---|---|
| Frontend | The operations console and user app. It passes user actions, such as withdrawal requests and approvals, to the Backend |
| Backend | The wallet server. It builds transaction requests, applies approval policies, and connects Wallet Node with the key management system |
| Key Mgmt | A key management system based on MPC, HSM, or KMS. It stores keys and signs transactions. Customers build it themselves or use an external key management vendor |
| Ledger DB | The database that stores the ledger, ERP, and audit records. It is reconciled against the on-chain data retrieved from Wallet Node |
Wallet Node Components
| Component | Role |
|---|---|
| HyperNode | The node abstraction layer in front of the Node Pool. It receives RPC API and WebSocket requests and forwards them to the best node based on each node's synchronization status. If a node fails, it switches automatically to a healthy node |
| Node Pool | A group of nodes synchronized with the blockchain network. It broadcasts signed transactions to the network and receives new block and transaction data |
| Indexer | Collects and verifies block data from the Node Pool, then indexes it by the configured conditions, such as accounts, tokens, and transactions |
| Indexed Data | The database that stores the data organized by the Indexer. The Data API and Webhook operate on this data |
| Data API | Provides Indexed Data as a REST API. You can query aggregated data that is hard to retrieve with the RPC API, such as balances, token holdings, and transaction history |
| Webhook | Sends deposit, withdrawal, and token transfer events for registered addresses to the customer's Callback URL. If a block reorganization (reorg) changes the result, it sends a correction message |
| Assure | The operational standard that applies to all of Wallet Node, including dedicated infrastructure, automatic failover, SLA, and request logs. See Assure for details |
Request and Data Flow
Requests and data in Wallet Node are processed through four paths: RPC requests and Data API requests sent by the customer, ingestion of data arriving from the blockchain, and Webhook events generated from the ingested data.
| Path | Processing order |
|---|---|
| RPC request | Backend → HyperNode → Node Pool → Blockchains → Node Pool → HyperNode → Backend |
| Data API request | Backend → Data API → Indexed Data → Data API → Backend |
| Data ingestion | Blockchains → Node Pool → Indexer → Indexed Data |
| Event delivery | Indexed Data → Webhook → Backend |
A single transaction passes through these paths in the following order. For the API call order per layer, see the sequence diagram in Overview.
- Validate: The Backend sends the transaction contents to HyperNode and requests simulation and fee estimation. HyperNode forwards the request to a node that follows the latest block. You check whether the counterparty address is a contract with the Data API.
- Sign: The Backend requests a signature from Key Mgmt based on the validation result and approval policy. This step is handled entirely within the customer's systems, and Wallet Node is not involved.
- Execute: The Backend submits the signed transaction to HyperNode. The Node Pool broadcasts the transaction to the network, and the Backend stores the returned transaction hash as the tracking reference.
- Observe: When the transaction is included in a block, the Node Pool receives the block data and the Indexer reflects it in Indexed Data. Webhook sends events for registered addresses to the Backend, and the Backend retrieves the receipt and finalized block to determine finality.
- Reconcile: The Backend retrieves balances, balance changes, and transaction history with the Data API and reconciles them against the records in Ledger DB.
Responsibilities and Trust Boundary
The trust boundary of Wallet Node is the signing stage. The customer manages keys, signing, approval policies, and the ledger, and Nodit manages node operations, data indexing, and event delivery. Nodit does not access the customer's keys or signing process, and receives only signed transactions and query requests.
| Area | Managed and verified by the customer | Managed and verified by Nodit |
|---|---|---|
| Keys and signing | Key generation, custody, and signing; key management vendor selection | Not involved |
| Approval policy | Approval workflows, limits, and dual control | Provides the simulation, fee, and counterparty information needed for decisions |
| Transaction execution | Transaction construction and nonce management policy | Broadcast, pending observation, and node synchronization management |
| Finality decision | Decides the finality criteria (block depth, finalized) | Provides the receipt, finalized block, and reorg correction messages |
| Data integrity | Cross-checks data freshness (block lag) and verifies proof data | Verifies indexed data, publishes block lag figures, and provides proof data (eth_getProof) |
| Ledger and accounting | Journal entries, chart of accounts, and closing policy; Ledger DB operations | Provides the on-chain evidence data needed for reconciliation |
| Access control | API Key custody and management of call origins | Provides IP/Domain Allowlist and request logs |
| Operations | Operation and monitoring of integrated systems | Node operations, automatic failover, SLA, and 24×7 monitoring |