07 — Tokenised instruments
Tokenised funds, notes and collateral with the transfer restrictions, servicing and reporting the instrument actually requires.
Tokenising an instrument is not the hard part. The hard part is that the instrument keeps its obligations: eligibility restrictions on who may hold it, corporate actions, distributions, and a register that remains authoritative when the chain and the transfer agent disagree.
We build the token, the controls that enforce eligibility at transfer time, the servicing pipeline for distributions and corporate actions, and the reconciliation that keeps the on-chain register and the legal register in agreement.
Common questions
What makes a tokenised security different from a normal token?
Enforced eligibility. A security token must refuse transfers to holders who do not meet its restrictions — jurisdiction, accreditation, sanctions status — at the moment of transfer rather than by policy afterwards. That control, and the register reconciliation behind it, is most of the engineering.
Which register is authoritative, the chain or the transfer agent?
Whichever the offering documents say, and the system must be built to match. If the legal register is authoritative, the chain is a mirror and reconciliation must be continuous with a documented resolution path. Systems that leave this ambiguous fail their first corporate action.
How are distributions handled on a tokenised fund?
By snapshotting eligible holders at a defined record time, computing entitlements off-chain against the authoritative register, and settling either on-chain or through existing payment rails. The snapshot mechanism and its treatment of in-flight transfers should be specified before launch.
Next capability
Wealth platforms
Bring us the hard part.
Forty-five minutes with the people who would actually run the build.