Reference Architecture
IllustrativeDigital Asset Infrastructure
The off-chain infrastructure behind a digital asset product: blockchain nodes, wallet services, secure key management, indexing, transaction monitoring and an API gateway.
The problem
Consider a business that needs to hold, send and receive digital assets on one or more public blockchains on behalf of its users or its own treasury. It must generate deposit addresses, detect incoming transfers, sign outgoing transactions and present accurate balances and history through its own applications.
A blockchain is an unusual dependency. Transactions are irreversible, confirmation is probabilistic until finality, blocks can be reorganised, fees fluctuate and a leaked private key cannot be rotated out of harm's way after the fact. The infrastructure around the chain has to supply the safety, auditability and operational control that the chain itself does not.
Requirements the design must meet
- Private keys must never exist in plaintext in application memory, logs, backups or on an operator's machine.
- Every outgoing transaction must pass policy checks, and high-value transfers must require approval from more than one person.
- Balances must be derived from finalised chain data and must be corrected automatically after a chain reorganisation.
- Loss of a single node or RPC provider must not stop deposits from being detected or withdrawals from being broadcast.
- Transactions must be screened and monitored, with a complete audit trail of who requested, approved and signed each one.
- Adding support for another EVM-compatible chain must be a configuration and testing exercise, not a rewrite.
The design
Components
Applications & APIs
- Client applications
- API gateway
- Partner APIs
- Operations console
Wallets & Transactions
- Address management
- Transaction builder
- Nonce and fee control
- Policy engine
Key Management
Keys never leave the signing boundary
- HSM
- MPC signing
- Approval quorum
- Key rotation
Node / RPC Layer
- Full nodes
- RPC providers
- Failover routing
- Mempool access
Indexing & Analytics
Chain data is provisional until it is final
- Block ingestion
- Event decoding
- Reorg handling
- Query APIs
Monitoring & Compliance
- Transaction monitoring
- Address screening
- Audit trail
- Alerting
API gateway
A single authenticated entry point serves internal applications and partner integrations. It enforces rate limits, request signing and idempotency keys on anything that moves value. Withdrawal endpoints are separated from read endpoints so they can carry stricter controls and their own quotas.
Wallet service
The wallet service derives deposit addresses from hierarchical deterministic keys, maps them to accounts and tracks which addresses the platform controls. It separates hot wallets that serve day-to-day withdrawals from warm and cold tiers that hold reserves. Sweeps and rebalancing between tiers are explicit, policy-governed operations.
Transaction service and policy engine
This service builds transactions, manages nonces, estimates fees and handles replacement when a transaction is stuck. Before anything is signed, a policy engine evaluates limits, velocity rules, destination allowlists and approval requirements. The service tracks each transaction through submission, inclusion and finality as an explicit state machine.
Secure key management
Signing happens inside a hardware security module or through multi-party computation, where key shares are held by separate parties and the full key is never assembled. The signing boundary accepts only requests that carry a valid policy decision and the required approvals. Key ceremonies, backup and recovery are documented procedures that are rehearsed.
Blockchain node and RPC layer
The platform reads from and broadcasts to the chain through a pool of self-operated full nodes and external RPC providers. A routing layer checks node health and block height, fails over automatically and compares responses across sources for critical reads. Broadcasting through more than one path reduces the chance that a transaction is silently dropped.
Indexer
An indexer ingests blocks, decodes transfers and contract events, and writes them to a relational store keyed by block number and hash. Data is marked provisional until the block reaches the configured finality depth, and reorganisations are handled by rolling back and replaying affected blocks. The application reads balances and history from this store, not from live RPC calls.
Transaction monitoring and screening
Incoming and outgoing transfers are screened against address risk data and checked against behavioural rules such as structuring or unusual velocity. Alerts open cases for review, and a flagged withdrawal is held before signing instead of being investigated afterwards. The component is designed to support an organisation's compliance obligations; it does not replace them.
Observability and audit
Dashboards track node lag, indexer lag, pending transaction age, fee spend and hot wallet balances against thresholds. Every request, policy decision, approval and signature is written to an append-only audit log. A periodic job reconciles the internal ledger against on-chain balances and raises any difference.
Trade-offs
Design decisions
| Decision | Why |
|---|---|
| MPC or HSM signing instead of keys held by the application | Keeping keys in application configuration is simple and fast, and it makes any server compromise a total loss. Hardware or multi-party signing adds latency, cost and operational ceremony, which is the correct price for removing the single point at which a key can be stolen. |
| A tiered wallet structure with a small hot balance | Holding all funds in a hot wallet makes withdrawals instant and maximises exposure. Keeping only working liquidity hot limits what an attacker or a software fault can reach, at the cost of rebalancing operations and the occasional delayed withdrawal when the hot tier runs low. |
| Self-operated nodes combined with external RPC providers | Relying on one provider is cheap and creates a dependency that can rate-limit, lag or go offline. Running nodes is a real operational burden, so the design uses both: owned nodes for independence and verification, providers for burst capacity and geographic reach. |
| A dedicated indexer instead of querying the chain on demand | Live RPC queries cannot answer questions such as an account's full history efficiently, and they expose users to unfinalised data. An indexer is another system to build and keep in sync, and it is what makes balances fast, consistent and correct after a reorganisation. |
| Credit deposits only at a configured finality depth | Crediting on first confirmation feels faster and risks crediting a transfer that is later reorganised away. Waiting for finality delays availability by a chain-dependent interval, which is communicated to the user as a pending state. |
Intended outcomes
- Private keys that are never exposed to application code or operators
- Outgoing transfers that cannot bypass policy and approval controls
- Balances that stay consistent with the chain, including after reorganisations
- A complete record of who requested, approved and signed each transaction
What the design is built to achieve. Illustrative, not measured results from a client project.
Representative technologies
- Go
- TypeScript
- Node.js
- PostgreSQL
- Kafka
- Redis
- Ethereum / EVM
- HSM / MPC signing
- Kubernetes
- Terraform
- OpenTelemetry
Have a system that needs to work in production?
Tell us what you are building. An engineer will read it and reply within two working days.