RWA Tokenization

Definition

RWA tokenization is the issuance of a token that represents a legally enforceable claim on an asset that exists outside the chain — a building, a bond, a bar of gold, an invoice. The token is not the asset. It is a register entry whose authority comes from the legal structure beneath it, and its usefulness depends entirely on that structure being real, enforceable in a named jurisdiction, and matched by a register somebody is accountable for.

What it solves

1. Ownership records that disagree with each otherMost private assets are recorded in a spreadsheet, a transfer agent’s system and a lawyer’s file, and reconciling them is somebody’s quarterly job. A single register that every movement writes to removes the reconciliation rather than automating it.
2. Settlement that takes days and handsA private transfer typically means a signed instrument, a manual eligibility check and a wire. When eligibility is data and the register is one system, the check is instantaneous and the movement is recorded the moment it is confirmed.
3. Minimums that exclude most of the marketDivisibility is a property of the register, not of the asset. A building does not become more liquid because it is tokenized, but a claim on it can be denominated in units small enough for an investor who could never have written the whole cheque.

How it works

1. The asset is structured before anything is issuedA legal vehicle holds the asset, and the token represents a claim against that vehicle. Without it the token is a promise from whoever happens to control the wallet.
2. Eligibility is written down as policyWho may hold the instrument becomes a rule set over investor attributes — classification, jurisdiction, verification status — evaluated identically for every subscription and every transfer.
3. The offering takes money against a referenceSubscriptions are checked against the offering terms first, then against the compliance policy, and only then is a payment reference issued.
4. Units are issued to the registerAllocation decides who gets what; issuance puts the units on the register and records the movement that created them.
5. The asset is serviced for its whole lifeIncome is distributed to holders of record, corporate actions adjust the register, and redemption retires units against a payment.

Architecture

Five subsystems and one transaction boundary. A compliance engine that evaluates policy as data; an offering engine that holds the book; a double-entry ledger where investor money is a liability until it settles; an ownership register rebuilt from confirmed movements; and a payment rail that matches money by reference. The point of putting them in one transaction is that a status can never disagree with the entries behind it — a payment marked settled and the ledger rows recording that settlement commit together or not at all.

Tokenization lifecycle

1. StructureAsset defined, legal vehicle recorded, parties appointed, data room assembled.
2. ConfigureToken standard chosen from what the instrument is, supply and transfer restrictions set.
3. OfferTerms published, subscriptions accepted, eligibility evaluated per investor.
4. Allocate and issueThe book is scaled if oversubscribed, units are issued, proceeds released to the issuer.
5. ServiceDistributions, corporate actions, valuations and reporting for the life of the asset.
6. RetireRedemption, maturity or wind-down burns the units against a final payment.

Supported token model

Permissioned token with on-chain transfer restrictions. A plain fungible token has no concept of who may hold it, so for a restricted security it is not a missing feature but the wrong instrument. The standard is selected from the instrument’s own properties — whether it is fungible, whether it is fractionalised, whether a transfer depends on who the recipient is.

Asset requirements

What must be true before this can responsibly be tokenized at all.

• A legal owner of record, and documentation proving it.
• A vehicle that can issue a claim, or a jurisdiction where a direct claim is enforceable.
• A valuation methodology somebody will sign, with a stated frequency.
• Custody arrangements for anything physical, with an independent party where the asset is bearer-like.
• A servicing plan: who calculates income, who pays it, and out of which account.

Compliance considerations

• Eligibility is denied by default. A workspace with no published policy admits nobody, because eligibility must come from a rule saying so rather than from no rule objecting.
• An absent fact never satisfies a rule — not knowing whether a verification is valid is not the same as knowing it is.
• Every decision is snapshotted with the policy version that produced it, so “why was this allowed” is answerable under the rules in force at the time.
• Jurisdiction packs constrain who may be offered what, and an unreviewed pack cannot back a published policy.

Investor workflow

• Complete identity verification appropriate to the instrument and jurisdiction.
• Review the offering terms, the data room and the risk disclosures.
• Subscribe for an amount; the platform checks terms, then eligibility, then issues a payment reference.
• Send funds quoting the reference — the reference is the only thing that matches money to a subscription.
• Receive an allocation, which may be scaled back if the book is oversubscribed, with any difference returned.
• Hold, receive distributions, and redeem or transfer where the instrument permits it.

Issuer workflow

• Define the asset and its legal structure, and appoint the parties.
• Assemble the data room and have the documents approved.
• Configure the token and have the contract plan reviewed.
• Publish a compliance policy — a second authoriser signs the exact rule set.
• Open the offering, monitor the book, and run allocation.
• Issue units, release proceeds, and service the asset for its life.

Payments

Money is matched to a subscription by a checksummed reference and by nothing else — not the amount, not the date, not the counterparty name. Unidentified credits post to a suspense account where they stay visible until somebody clears them. Investor money is carried as a liability from the moment it arrives until an allocation settles, because until then it belongs to the investor.

Lifecycle servicing

Distributions pay holders of record, rebuilt from confirmed movements as at the record date rather than from today’s register. Corporate actions that change unit counts are planned, previewed and re-checked against the register at the moment they execute. Redemptions burn units and recognise what the holder is owed in one transaction.

Secondary transfer

Transfers between investors run the same two gates as issuance: the transfer rules the token contract enforces, and the compliance policy asked about the recipient. Someone who could not have subscribed cannot be transferred into either, or the transfer becomes the route around the policy. Lockups and freezes both stop a transfer.

Risks

Named plainly. An instrument whose risks are only in a footnote has been mis-sold before it has been issued.

1. The legal claim is the whole productIf the vehicle is unenforceable, or the asset is not owned as documented, the token represents nothing. No amount of cryptography repairs a defective claim.
2. Tokenization does not create liquidityA secondary market requires buyers. Divisibility and transferability are necessary and nowhere near sufficient, and an instrument marketed as liquid that is not is a mis-sale.
3. Valuation is an opinion with a date on itFor anything not exchange-traded, the price is a methodology and a signature. Stale or optimistic marks are the most common way investors are harmed.
4. Custody concentrates riskFor physical assets the custodian is a single point of failure, and proof of reserve attests to what an attestor saw, not to what is there now.
5. Regulatory treatment varies and changesThe same instrument may be a security in one jurisdiction and not in another, and a policy that was correct at issuance may not stay correct.

How we support it

• An asset definition engine covering 67 asset classes, each with its own template, recommended token standard and readiness requirements.
• A compliance engine where rules are reviewable data over a closed vocabulary, never evaluated as code.
• A double-entry ledger where every movement that touches money posts in the same transaction as the state change that caused it.
• An ownership register that can be rebuilt from its own movement history and checked against it.
• Maker-checker on every irreversible action, with the approval bound to a hash of exactly what was approved.

Questions

Next steps

Bring an instrument you are actually considering. Structuring something real is the only way to judge whether the model fits.