Engineering Scenario
IllustrativeRWA Tokenisation Platform
An engineering scenario for representing real-world assets as permissioned tokens, with an off-chain registry of record, enforced transfer controls and continuous reconciliation.
The problem
Consider an issuer that wants to represent an off-chain asset, such as a fund unit, a debt instrument or a share in a physical asset, as a token on a public blockchain. The intent is to make issuance, transfer and servicing programmable while keeping the legal and regulatory framework that already governs the asset.
The token is a representation, and the legal claim lives elsewhere. If the on-chain record and the off-chain registry disagree, or if a token reaches a holder who is not eligible to own it, the platform has failed at its main job. Most of the engineering is therefore about keeping two records consistent and making transfer rules impossible to bypass. This scenario describes engineering only and is not legal, financial or investment guidance.
Requirements the design must meet
- Only wallets belonging to verified, eligible holders must be able to receive or hold the token, and this must be enforced by the contract itself.
- The off-chain registry must remain the record of ownership and must be reconciled against chain state continuously.
- The issuer must be able to perform controlled administrative actions, such as pausing transfers or recovering tokens from a lost wallet, under multi-party approval.
- Issuance, distributions and redemption must be traceable from the off-chain instruction to the on-chain transaction and back.
- Personal data must stay off-chain, with only the minimum necessary references recorded on the ledger.
- Contract logic must be upgradeable under governance, without changing token balances or holder addresses.
The design
Components
Off-chain
- 01
Asset onboarding
Legal structure and documents
- 02
Investor KYC
Identity and eligibility checks
- 03
Asset registry
Record of ownership and rights
- 04
Reconciliation
Registry matched to chain state
- 05
Reporting
Statements, audit and disclosures
On-chain
- 01
Token issuance
Mint against the registered asset
- 02
Allowlist
Only verified wallets can hold
- 03
Transfer controls
Rules enforced in the contract
- 04
Settlement
Atomic transfer against payment
- 05
Lifecycle events
Distributions, redemption and burn
Asset onboarding and registry
The registry records each asset, its terms, its supporting documents and the mapping to its token contract. It also holds the register of holders and their positions, and is the system that auditors and administrators consult. Document hashes can be anchored on-chain to evidence that a record has not changed.
Investor onboarding and eligibility
Investors complete identity verification and eligibility checks through an integrated KYC provider, and the result is stored off-chain. A verified investor registers one or more wallet addresses, proving control by signing a challenge. Eligibility can expire or be revoked, and those changes flow through to the on-chain allowlist.
Permissioned token contracts
The token follows the ERC-20 interface and adds transfer restrictions in the style of permissioned token standards such as ERC-3643. Every transfer calls a compliance module that checks sender and receiver against the identity registry and any applicable rules. Administrative functions such as pause, forced transfer and recovery exist, are role-restricted and emit events.
Issuance and lifecycle service
This service turns approved off-chain instructions into on-chain transactions: minting on subscription, burning on redemption and recording distributions. Each instruction carries an identifier that is stored with the resulting transaction hash, so the two can always be joined. Operations are idempotent, so a retried instruction cannot mint twice.
Settlement
Where payment is made on-chain in a tokenised currency, transfer of the asset and transfer of payment are executed atomically in one transaction. Where payment is made through banking rails, the asset leg is released only after the payment is confirmed off-chain. The design supports both, because the available settlement asset varies by market.
Custody and key management
Issuer and administrator keys are held in HSM or MPC-based signing infrastructure, with privileged contract roles assigned to multi-signature accounts. No single person can mint, pause or upgrade. Investors may hold tokens in their own wallets or with a custodian, and the platform treats both as registered addresses.
Indexing and reconciliation
An indexer follows the token contracts and builds an on-chain view of balances and transfers at finality. A reconciliation job compares that view with the registry and raises a break for any difference, which is investigated before the next reporting cycle. This is the control that detects errors in either record.
Reporting and audit
Holders receive statements generated from the reconciled record. Administrators and auditors can trace any position to the instructions and transactions that produced it. Reporting outputs are structured to support an issuer's disclosure obligations, which remain the responsibility of the issuer and its advisers.
Trade-offs
Design decisions
| Decision | Why |
|---|---|
| Transfer restrictions enforced on-chain, in the token contract | An unrestricted token with checks performed only in the application is easier to build and integrates with more wallets and venues. It also allows a holder to transfer to any address directly on-chain. Enforcing eligibility in the contract narrows where the token can move, which is the point. |
| The off-chain registry as the record of ownership | Treating the chain as the sole record is conceptually clean and leaves no remedy for lost keys, court orders or operational errors. Keeping the registry authoritative, with the token as its synchronised representation, adds a reconciliation burden and matches how ownership of such assets is generally established. |
| An EVM-compatible public chain instead of a private ledger | A private ledger gives control over participants and fees and limits interoperability with existing wallets, custodians and tooling. A public EVM chain offers that ecosystem and mature audit tooling, at the cost of public transaction visibility and variable fees, which is why personal data is kept off-chain. |
| Upgradeable contracts behind a governed proxy | Immutable contracts offer the strongest guarantee to holders and cannot be corrected if rules or regulation change. A proxy pattern keeps balances intact through upgrades and introduces upgrade risk, which is mitigated with multi-signature control, a time delay and independent audit of each new implementation. |
| Personal data kept entirely off-chain | Recording identity attributes on-chain would simplify some checks and would make that data permanent and public. The contract therefore stores only addresses and eligibility flags, and the link between an address and a person stays in the off-chain system where it can be protected and deleted. |
Intended outcomes
- Tokens that can only be held by wallets belonging to verified, eligible holders
- An on-chain record and an off-chain registry that are continuously checked against each other
- Administrative actions that require more than one approver and leave a public trace
- Positions that can be traced from instruction to transaction to statement
What the design is built to achieve. Illustrative, not measured results from a client project.
Representative technologies
- Solidity
- Ethereum / EVM
- ERC-20 / ERC-3643
- TypeScript
- Node.js
- Go
- PostgreSQL
- Kafka
- HSM / MPC signing
- Kubernetes
- Terraform
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.