Solution
Digital asset infrastructure built around key security and reconciliation
We engineer the systems that hold and move digital assets: key management, wallet services, deposit and withdrawal pipelines, trading components and the monitoring that ties on-chain reality to internal records.
The problem space
Digital asset platforms combine the correctness demands of financial systems with a constraint traditional finance does not have: transactions on a public blockchain are generally irreversible, and control of a private key is control of the funds. A mistaken or malicious withdrawal cannot be recalled by a counterparty bank. The engineering therefore starts from key custody and transaction authorisation, and everything else is arranged around protecting them.
The second defining problem is that the blockchain is an external system the platform does not control. Nodes fall behind or disagree. Blocks are reorganised and a transaction that appeared confirmed disappears. Fees move sharply and a submitted transaction can sit unconfirmed for hours. Each network has its own account model, finality behaviour and token conventions. A platform must present a consistent internal picture to users and finance teams while absorbing all of this.
This page describes engineering only. Starone does not offer investment advice, makes no statement about the value or prospects of any asset, and makes no claim of licensing or regulatory approval. Platforms are designed to support the controls an operator needs. Which regulatory regime applies to an operator is a question for the operator and its legal counsel.
Why it is hard
Engineering challenges
Private key compromise
A key held in application memory or in a configuration store can be extracted by anyone who breaches that host, and the loss is immediate and permanent. Single-key hot wallets with broad signing rights are the usual root cause of large losses. Key material has to be isolated in hardware or split across parties, with signing governed by policy.
Chain reorganisations and finality
Crediting a deposit as soon as it appears in a block exposes the platform to a reorganisation that removes it after the user has traded or withdrawn. Finality differs by network: some are probabilistic, some have explicit finality checkpoints. Confirmation policy must be set per chain and deposits must be reversible internally until that threshold is met.
Withdrawals that stall or duplicate
A broadcast transaction may be dropped, underpriced or replaced. Resubmitting carelessly can send funds twice; mismanaging nonces on account-based chains can block every later transaction from the same address. The withdrawal pipeline needs explicit nonce management, fee-bumping rules and a guarantee that one request maps to one on-chain transfer.
On-chain and internal ledgers drifting apart
The internal ledger says what each customer owns; the chain says what the platform's addresses hold. Missed deposits, unrecorded fees and failed sweeps cause the two to diverge. Without continuous reconciliation a shortfall can exist for weeks before anyone sees it.
Node and provider reliability
A single node or RPC provider is a single point of failure and a single source of truth that may be wrong. A lagging node reports stale balances; a faulty one can report transactions that do not exist on the canonical chain. Critical reads need more than one independent source and a way to detect disagreement.
Matching engine correctness under load
An exchange must apply orders in a strict, reproducible sequence. Concurrency bugs produce trades at wrong prices or balances that go negative, and recovery after a crash must restore exactly the same order book. Throughput cannot be bought at the expense of determinism.
How we build it
Architecture
The platform separates key custody and signing from all other services, keeps an internal double-entry ledger as the record of customer ownership, and treats each blockchain as an external system observed through redundant nodes.
- 01
Key management and signing service
Private keys are generated and held in hardware security modules or split using multi-party computation, so no single machine or person holds a complete key. The signing service accepts only structured, validated requests and is reachable from a minimal set of internal callers. Operator access requires multiple approvers and is recorded.
- 02
Wallet tiers and policy engine
Funds are divided across hot, warm and cold tiers, with only the amount needed for near-term withdrawals kept online. A policy engine evaluates every signing request against rules such as amount limits, velocity limits, destination allow-lists, time locks and the number of approvals required. Policies are versioned configuration, and a change to policy goes through its own approval.
- 03
Deposit detection pipeline
Chain indexers follow each supported network through multiple nodes, extract transfers to platform addresses and track confirmations. A deposit moves through pending and confirmed states according to a per-chain confirmation policy and is credited to the internal ledger only once it meets that policy. The indexer handles reorganisations by rolling back to the fork point and reprocessing.
- 04
Withdrawal pipeline
A withdrawal request passes risk checks, is reserved in the ledger and enters a queue. A transaction builder assigns nonces or selects inputs, estimates fees and batches transfers where the network allows. After signing and broadcast the pipeline tracks the transaction to finality, applies replacement rules if it stalls and settles or releases the ledger reservation according to the outcome.
- 05
Internal ledger and exchange core
Customer balances live in an append-only double-entry ledger, independent of on-chain addresses, so internal transfers and trades settle without touching a blockchain. Where trading is in scope, a single-threaded deterministic matching engine processes a sequenced order stream held in memory, with every input journalled so the book can be rebuilt by replay. Market data and settlement are published as events.
- 06
On-chain monitoring and transaction risk
Monitoring services watch platform addresses, contract events and pending transactions for unexpected movement and alert in real time. Inbound and outbound transfers are screened through blockchain analytics providers for exposure to sanctioned or high-risk addresses, with uncertain results routed to review. Automated controls can pause withdrawals for an asset or the platform when anomalies are detected.
- 07
Treasury and reconciliation
Scheduled jobs compare ledger liabilities per asset with on-chain holdings across all tiers and report any difference. Treasury tooling handles sweeping of deposit addresses, rebalancing between tiers under approval, and fee-asset management so that withdrawals are not blocked for lack of gas. Every treasury movement is posted to the ledger and included in reconciliation.
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
What an engagement delivers
- Custody architecture and key ceremony procedures
- Signing service with policy engine and approval workflow
- Deposit and withdrawal pipelines for the agreed networks
- Internal ledger and, where in scope, matching engine
- On-chain monitoring, screening integration and alerting
- Reconciliation and treasury operations tooling
- Threat model and incident runbooks, including withdrawal halt procedures
Before you start
Decisions to make early
- HSM, MPC or multisignature custody
- Hardware security modules are well understood and suit centralised signing with strong physical controls. Multi-party computation removes the single complete key and works across chains without on-chain changes, at the cost of more complex protocols and operations. On-chain multisignature is transparent and simple to audit but is chain-specific and visible to observers. Many designs combine them by tier.
- Run your own nodes or use providers
- Node providers remove operational burden and are sensible for most networks at the start. Run your own nodes for the networks that carry the most value or volume, or where you need tracing and archive data. For critical reads, use at least two independent sources and compare their results.
- Build custody or integrate a custodian
- Integrating an established custody provider shortens delivery and transfers a share of operational risk, in exchange for fees and dependence on their roadmap and supported assets. Building in-house gives control over policy and cost at scale, and requires security engineering and operational maturity that take time to establish. The decision often follows regulatory expectations in the operator's jurisdiction.
- How many confirmations before crediting
- Set this per network from its finality model and the value at risk. Chains with deterministic finality can be credited at finalisation; probabilistic chains need a depth at which a reorganisation is economically implausible for the amount involved. Larger deposits can reasonably wait longer, and the policy should be configuration that can be tightened quickly during network instability.
FAQ
Common questions
Does Starone provide custody services or operate an exchange?
No. Starone engineers the technology. Custody and exchange operations are carried out by the client under whatever licences and approvals apply to them. We make no claim of regulatory status on our own behalf or on behalf of systems we design.
Which blockchains can be supported?
The architecture isolates each network behind a chain adapter covering address generation, transaction building, fee estimation and confirmation tracking. Account-based and UTXO-based chains both fit this model. The set of networks is agreed per engagement, since each adds integration, testing and operational work.
How is the system protected against insider threats?
By ensuring no individual can move funds alone. Signing requires policy approval from multiple parties, key shares or HSM credentials are separated across roles, administrative actions are logged immutably, and policy changes need their own quorum. Monitoring is designed to alert people outside the approving group.
Do you write and audit smart contracts?
We develop and test smart contracts where a design requires them, using established libraries, property-based testing and static analysis. For contracts that hold value we recommend an independent external audit before deployment. An audit reduces risk; it does not eliminate it.
Related
Reference architectures
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.