Treating chain integration as reconciliation, not as an RPC call

Context

The Algorai Admin platform was the operational surface for configuring products, monitoring positions and reconciling on-chain state. Everything the admin did had to be reflected on chain; everything the chain reported had to come back into our own store.

Problem

The obvious approach — wrap the SDK and call it whenever you need a balance — works in a demo and fails in production. A trader expects a balance, an order, a position and a history to be there, correct, straight away. None of those are ours. The balance lives on the chain, the venue is someone else’s contract, and settlement happens on the chain’s schedule, not the screen’s.

Constraints

• The chain is the source of truth and our database is a copy, never the other way round.
• Data arrives late, from several places, and can change after we have displayed it.
• Bridged networks (Ethereum, Solana, Polygon) can rewrite history under a transaction, which Algorand’s own consensus does not do.
• The two must not drift apart quietly. Drift nobody notices turns into a support ticket about someone’s money.

Decision

Treat the integration as a synchronisation problem with a reconciliation step that runs on its own, written in Go against the official Algorand SDK — not as a thin wrapper called on demand. Our database is a view of what is on the chain, and anything it claims has to be re-derivable from the chain.

Alternatives

Trade-offs

Reconciliation costs time and code. Reading straight through to the chain is simpler and faster when everything works, and everything works most of the time — which is exactly what makes the failure expensive. It is rare, it is silent, and it is about money.

Outcome

Admin and treasury operations ran against reconciled state rather than against whatever the last RPC call happened to return.