Overview
Wallet Node
Wallet Node is infrastructure for organizations that operate institutional wallets, such as exchanges, custodians, and financial platforms. It divides the transaction lifecycle into four layers: Validate, Execute, Observe, and Reconcile. Each layer provides the APIs and data it needs. Key custody and signing stay in the systems you have built. You can build a wallet service by integrating Wallet Node, without running nodes or building an indexer.
| Scope | Owner |
|---|---|
| Check pre-signing execution results · identify counterparty addresses | Wallet Node (Validate) |
| Key custody · transaction signing | Customer - existing MPC · HSM · KMS or key management vendor |
| Transaction execution · status tracking · deposit detection | Wallet Node (Execute · Observe) |
| Balances · transaction history · valuation reconciliation | Wallet Node (Reconcile) |
| Ledger · ERP · closing | Customer - existing accounting system |
Wallet Node Layers
Wallet Node divides the transaction lifecycle into four layers and provides the functions each layer needs. Each transaction is processed in the order Validate → Sign → Execute → Observe → Reconcile. Signing (Sign) is handled by the customer. Wallet Node supports the other four stages with the RPC API and Data API.
1. Validate (Pre-signing Verification)
Validate checks whether a transaction is valid before signing. Your wallet backend sends the transaction contents and the counterparty address. Wallet Node then executes the transaction against the latest block state and returns the execution result, asset changes, fees, and counterparty information.
Before signing, you can check whether the transaction will succeed, which assets and amounts move, and who the counterparty is. Filtering out transactions that would fail reduces wasted fees and operational losses.
| Category | API | Purpose |
|---|---|---|
| Simulation | eth_simulateV1 · eth_call | Executes a transaction without sending it to check the result, revert reason, and balance changes |
| Preflight | eth_estimateGas · eth_feeHistory · Get Gas Price | Estimates the gas limit and fees |
| Preflight | Get Token Allowance | Checks whether the token allowance is sufficient |
| Identity | Is Contract · eth_getCode | Determines whether the counterparty address is a contract |
| Identity | getAccountLabels · inferContract (coming soon) | Checks the entity and category labels of the counterparty address and the contract type |
2. Sign (Transaction Signing)
Key custody and transaction signing run in the systems you have built. Nodit does not access keys or the signing process. Wallet Node resumes at the point where it receives the signed transaction.
3. Execute (Submission)
When you submit a signed transaction, Wallet Node broadcasts it to the network and observes the pending period before it is included in a block. Your wallet backend stores the returned transaction hash as the tracking reference.
Execute submits a pre-validated transaction to the network. You build the transaction with the correct nonce, sign it, and submit it. You can then query the Mempool to check its state before block inclusion. If a transaction stays pending for a long time, you can resubmit it as a replacement transaction with a higher fee.
| Category | API | Purpose |
|---|---|---|
| Broadcast | eth_sendRawTransaction | Submits a signed transaction and returns the transaction hash |
| Nonce | eth_getTransactionCount · Get Next Nonce by Account | Retrieves the next nonce |
| Mempool | nodit_pendingTransactions · eth_subscribe (newPendingTransactions) · eth_newPendingTransactionFilter | Observes the pending period between submission and block inclusion through subscription or polling |
| Recovery | eth_sendRawTransaction | Resubmits a transaction that has been pending for a long time or was rejected as a replacement transaction with a higher fee |
| Recovery | eth_getTransactionByHash · eth_getTransactionReceipt | Checks whether the original or the replacement transaction was included in a block |
4. Observe (Tracking and Finality)
After a transaction is included in a block, you check the execution result with the receipt and compare it with the finalized block to determine finality.
Observe tracks whether a submitted transaction was processed and included in a block. With the transaction hash, you can check block inclusion and execution success, and determine whether the including block has reached the point where it can no longer be reverted. You can also detect deposits and withdrawals for registered addresses in real time with Webhook, and receive a correction message when a block reorganization (reorg) changes the result.
| Category | API | Purpose |
|---|---|---|
| Status | eth_getTransactionReceipt · Get Transactions by Hashes | Checks block inclusion and execution success (status) |
| Status | nodit_minedTransactions · debug_traceTransaction | Subscribes to transactions included in blocks and traces the execution path of failed transactions |
| Finality | eth_getBlockByNumber · Get Block by Hash or Number | Calculates the confirmation depth and whether the irreversible point has been reached |
| Activity | Get Transactions by Account(s) · Get Token Transfers by Account(s) | Retrieves the transaction and token transfer history of an address to detect deposits |
| Activity | Get Internal Transactions by Account(s) | Retrieves asset movements that occur inside contracts |
| Alerts | Webhook (ADDRESS_ACTIVITY · TOKEN_TRANSFER) · eth_subscribe · eth_getLogs | Detects deposits, withdrawals, and token transfers for an address through push, subscription, or polling |
| Alerts | Webhook (LOG) · Address Set | Notifies on contract event logs and manages monitored addresses as a set |
| Reorgs | Webhook (reorgCorrectionEnabled) · eth_getBlockByNumber · eth_getBlockByHash | Receives correction messages for messages invalidated by a reorg, or detects reorgs by comparing block hashes again |
5. Reconcile (Reconciliation and Evidence)
Your wallet backend retrieves balances, balance changes, and valuations to reconcile them with the internal ledger and ERP, and retains the evidence data required for audits.
Reconcile retrieves balances, balance changes, valuation prices, and activity statistics by address and reconciles them with the internal ledger. It provides the evidence data you need to re-verify past transactions and asset movements during closing and external audits.
| Category | API | Purpose |
|---|---|---|
| Portfolio | Get Native Balance by Account · Get Tokens Owned by Account | Retrieves the assets held by each address |
| Portfolio | eth_getBalance · Get Token Balance Changes by Account | Retrieves the balance at a reference point and the balance change history |
| Valuation | Get Token Prices by Contracts · Get Native Token Price (coming soon) | Retrieves token prices to convert balances into valuations |
| Statistics | Get Account Stats | Aggregates the number of transactions and transfers and the number of asset types held by an address |
| Evidence | eth_getProof · eth_getTransactionReceipt · debug_traceTransaction | Combines transactions, asset movements, and original proof data into audit evidence |
The Necessity of a Wallet Node
In institutional wallet operations, nodes underpin the service together with transaction execution and ledger management. If a node goes down, the wallet service, including deposit detection and withdrawal processing, can stop. If an institution runs its own nodes, it needs a dedicated operations team for the following tasks, separate from wallet development.
- Client management: Version upgrades of open-source node clients and hard fork handling
- Sync monitoring: Continuously checking that nodes keep up with the latest block, and resyncing when they fall behind
- Incident response: Traffic switching, recovery, and root cause analysis when a node fails
- Capacity management: Scaling for continuously growing chain data and archive storage
- Chain expansion: Repeating the above tasks for each chain whenever supported chains increase
The burden of node operations delays the launch and expansion of wallet services. Wallet Node takes over node operations. The Nodit infrastructure that runs Wallet Node has been verified for enterprise-grade operational stability through SOC 2 certification and operates under the following framework.
- Availability: Provides a 99.9% SLA, and Dedicated Cluster guarantees 99.9% or higher by contract
- Sync and incident response: Smart load balancing that accounts for node sync state, automatic failover, and cluster-based monitoring
- Security and auditing: Access control based on IP/Domain Allowlist and RBAC, and an audit framework based on Request Logs
- Operational continuity: 24/7 monitoring, real-time operational status on the Status page, and a dedicated operations team channel
Institutions can integrate through the API instead of building node infrastructure, and focus on developing wallet logic for validation, execution, tracking, and reconciliation. You can find the operating framework and onboarding process in Quickstart for Enterprise.
Operational Assurance
Assure is the operations layer that keeps the four layers running reliably. It applies across the entire flow rather than to a specific stage of the transaction flow. It provides the operational standards that institutions need for infrastructure reviews and contracts, such as SLA, throughput, and incident response.
| Item | Details |
|---|---|
| Dedicated infrastructure | Configured as a dedicated cluster for the institution, with no resources shared with other customers |
| Guaranteed throughput | Throughput per institution (RPS · CU) is specified in the contract |
| Region · access path | Provides a Korea region, and access paths can be restricted with dedicated lines, IPSec VPN, and IP allowlists |
| Sync-based routing | Nodes that fall behind the latest block are removed from traffic before they return stale balances or nonces |
| Automatic failover | Automatically switches to healthy nodes when a node fails |
| Block lag disclosure | Node sync lag is exposed through an API so institutional monitoring can cross-check it |
| SLA · 24×7 operations | Availability and incident response standards are contracted as an SLA, with 24-hour operations |
| Usage · request logs | Request-level logs and usage support root cause analysis and audit response. You can find how to query them in Request Logs |
| Data retention | Data is queryable from the genesis block, and the retention period is specified in the contract |
Assure's operational standards apply to the entire Nodit infrastructure, not just Wallet Node. SLA figures and contract terms are finalized per institution during onboarding consultation. You can find the operating model and scope of guarantees in Assure.