RWA architecture: the systems behind tokenised assets

The token contract is the smallest part of a real-world asset platform. A competent engineer can write and test a restricted token in a few weeks. The systems around it take far longer: the register of holders, the identity and eligibility checks, the keys that can mint and freeze, the reconciliation that proves the chain and the books agree, and the machinery for distributions and redemptions.

Our position is that an RWA platform should be designed as a record-keeping system first and a blockchain application second. The first architectural decision is which ledger is authoritative, and every other component exists to keep the remaining records consistent with it.

There are two workable models. In the first, an off-chain registry is the source of truth and the chain is a synchronised representation of it. In the second, on-chain state is the register and off-chain systems are read models built from events. Both work. What does not work is leaving the question open, because the first disputed balance will force an answer under pressure.

Our default for assets that already have a registrar, a transfer agent or a statutory register is the off-chain registry as source of truth, with the token as a mirrored, restricted instrument. It allows corrections, court-ordered transfers and recovery of lost keys without pretending the chain is immutable law. The on-chain register is the right choice when the legal structure explicitly recognises it and when holders need to settle against other contracts atomically. That decision belongs to the issuer and its legal advisers, and the architecture follows it.

An asset with eligibility rules cannot be an unrestricted ERC-20 with checks in the web application. Anyone can call the contract directly, so a rule enforced only in the interface is not enforced. Restrictions belong in the transfer path, which is the approach taken by permissioned token standards such as ERC-3643 and ERC-1400.

A typical design separates the token from an identity registry and a rules module. The token asks the rules module whether a transfer is permitted, and the module consults the allow-list and any limits that apply. Personal data stays off-chain: the chain holds a wallet address and an eligibility flag or claim reference, never identity documents.

The administrative roles on a restricted token can mint, burn, freeze and move balances. Whoever controls those keys controls the register. We design the role model before the contract: separate keys for minting, compliance actions and upgrades, held in HSMs or an MPC scheme, with multi-party approval and a time lock on anything that changes contract logic.

The trade-off is operational speed. A mint that needs three approvers will not complete in seconds, and that is acceptable for issuance. It is not acceptable for allow-list updates during onboarding, so that role is usually narrower, more automated and rate-limited. Custody of the underlying asset is a separate matter handled by a custodian, and the platform integrates with that party instead of replacing it.

Two ledgers will drift. A transaction is submitted and dropped, a reorganisation removes a block the indexer had already processed, a registry update succeeds while the matching mint fails. Reconciliation is the control that detects this, and it deserves the same engineering attention as the transfer path.

We build it as a three-way comparison: on-chain balances read at a finalised block, the off-chain registry at the same logical time, and the custodian or administrator record of the underlying asset. Breaks are classified, assigned and tracked to closure. The indexer waits for finality before treating an event as settled, and every write to the chain carries an idempotency key so that a retry cannot mint twice.

Distributions, redemptions, splits and record dates are routine in traditional registers and awkward on-chain. A distribution needs a snapshot of holders at a specific block, a calculation that handles rounding deterministically, and a payment process that can be resumed after partial failure. Pushing payments to every holder in one transaction fails once the holder count grows, so we favour a claim-based model or batched payments driven from an off-chain job with a full audit trail.

Valuation figures, reserve attestations and reference rates reach the chain through data feeds. The feed is only as trustworthy as its publisher and its signing key. We treat every feed as an external dependency with failure modes: stale values, a compromised signer, a publisher outage. Contracts check the age of a value before using it, bound how far it can move between updates, and halt the dependent function when the feed is out of tolerance.

Whether a token represents ownership, a claim on an issuer or nothing enforceable is determined by the legal wrapper, the offering documents and the applicable regulation. None of that is decided in code. Engineering can make a structure enforceable in software and auditable in operation, and it should say plainly that it does not create the underlying right. We design to requirements set by the issuer and its legal and compliance advisers, and we do not substitute for them.