01
Five chains had five definitions of finality
Ethereum, BNB Chain, Tron, Polygon and Solana do not expose equivalent block, slot or confirmation behaviour. Settlement policy needed to be chain-specific and visible to the merchant.
Selected work
Client engagement
Sagapay
A payment gateway engineered so no operator can read a signing key.
A five-chain gateway launched in 2024, with per-invoice deposit addresses, key parts held in separate datastores, settlement to merchant wallets and explicit handling for chain reorganisation and notification failure.
- Client
- Sagapay
- Sector
- Payments infrastructure
- Engagement
- Platform, blockchain and security engineering
- Period
- Launched 2024
The problem
What the client needed to solve
A multi-chain payment gateway has to create addresses, observe payments, sign transactions and pay network fees, but exposing complete signing keys to employees or support systems would create an unacceptable operational risk.
Sagapay also needed funds to settle to each merchant’s wallet, reliable confirmation across five chains, and notification behaviour that would survive chain reorganisations and merchant-system outages.
Why it was difficult
Constraints inside the problem
These operating and governance conditions determined what a credible solution had to achieve.
02
The platform had to sign without exposing a key
A policy prohibiting access was insufficient. Complete key material could not exist in a console, export, support tool or any datastore an operator could read.
03
Confirmed did not always mean irreversible
A chain reorganisation can invalidate an included transaction. Payment state had to remain reversible until the configured depth was reached, with reversal events communicated as explicitly as confirmations.
04
Merchant systems could be unavailable
A successful chain transaction could not be lost because a merchant endpoint timed out. Notifications needed signatures, idempotency and durable retry behaviour.
The solution
What Root Digit built
Root Digit built a five-chain payment gateway with a unique deposit address for every invoice, signing-key parts stored in separate datastores and settlement sweeps to the merchant wallet.
Chain-specific watchers determine payment state, while signed idempotent webhooks, durable retry and explicit reorganisation handling keep the merchant’s application aligned with the blockchain record. No operator-facing system exposes a complete signing key.
How we did it
Engineering the solution
The workstreams below show how the solution was designed, built and controlled.
01
Split-key generation and signing
Each invoice receives a unique deposit address. Its signing key is generated inside the platform and immediately divided into parts stored separately. Parts are reassembled only in process memory for the signing operation and are not surfaced through operational tooling.
- Per-invoice addresses
- Separate key-part stores
- Transient in-memory assembly
- No operator export path
02
Chain-specific confirmation watchers
Dedicated watchers track mempool entry, inclusion, depth and reversals under a policy appropriate to each supported chain. Merchants can select the depth at which an invoice is treated as settled.
- Ethereum ERC-20
- BNB Chain BEP-20
- Tron TRC-20
- Polygon and Solana
03
Settlement and gas operations
Once the payment satisfies policy, the platform signs a sweep from the invoice address to the merchant wallet and pays the network gas required to execute it. Funds do not remain as gateway float.
- Merchant-wallet destination
- Network fee management
- Sweep-state reconciliation
- Transaction audit trail
04
Reliable merchant notifications
Settlement and reversal events are signed and sent with idempotency keys. Exponential backoff and durable retries ensure a recovering merchant endpoint receives the same event without creating a duplicate business action.
- Signed payloads
- Idempotency keys
- Exponential backoff
- Acknowledgement tracking
05
Exception policy
Underpayments, overpayments, dust and chain reorganisations are represented as explicit payment states. That keeps ordinary exceptions out of manual reconciliation and makes merchant behaviour predictable.
- Underpayment
- Overpayment
- Dust policy
- Reorganisation state
System design
Architecture and controls
01
Payment state machine
Invoice, observed, included, confirmed, swept, reversed and notified states are persisted separately so chain status and merchant notification cannot be mistaken for the same event.
02
Signing boundary
Key parts cross their storage boundaries only inside the signing path, exist together only transiently and never appear through administrative or support surfaces.
03
Merchant boundary
Funds settle to the merchant wallet. Signed webhooks communicate the platform’s observed state, while idempotency protects the merchant application from duplicate processing.
Transaction record
From invoice to merchant wallet
The gateway observes and signs the movement. It does not use a pooled merchant balance as the destination.
01
Invoice created
The merchant requests an amount, asset, chain and confirmation policy.
02
Deposit address issued
The platform creates a unique address and splits the associated signing key across separate datastores.
03
Payment observed
A chain-specific watcher records mempool, inclusion and confirmation state.
04
Funds swept
Key parts are assembled transiently in memory to sign the sweep to the merchant wallet; the platform pays network gas.
05
Merchant notified
A signed, idempotent webhook is retried until the merchant acknowledges it.
Source
Customer wallet
Controlled path
Invoice address · signed sweep
Destination
Merchant wallet
Delivery sequence
How the programme progressed
Phase 01
Payment and risk model
Invoice lifecycle, chain support, confirmation policies, key boundaries and merchant settlement responsibilities.
Phase 02
Core platform
Address generation, split-key signing, chain watchers, invoice state and merchant-wallet sweeps.
Phase 03
Integration reliability
Signed webhooks, idempotency, retry, reorganisation handling and exception policy.
Phase 04
Launch and chain expansion
Operating controls, merchant integration guidance and production support across five chains for the 2024 launch.
Outcomes and evidence
What the solution achieved
These are product and architecture facts from the Sagapay delivery record. “Zero operators” describes the designed access path: it is not a claim that the gateway never handles key material or a regulatory characterisation of custody.
- 0%
- gateway transaction fee
- 5
- supported chains
- Zero
- operators able to read a complete key
- 2024
- production launch
Commercial model recorded for the launched platform.
Ethereum, BNB Chain, Tron, Polygon and Solana.
An architectural property of the split-key operating path.
Year the platform launched.
Engagement conclusion
The gateway’s security position comes from making complete key material unavailable to operators, not from asking operators not to access it. The same precision extends to settlement, confirmation, reversal and merchant notification.
Start a conversation