Where it runs
Single-tenant in your own cloud account, in the region you choose, Singapore included. There is no shared multi-tenant platform holding other clients' registers next to yours.
Singapore · MAS · Project Guardian
Technology for tokenised capital markets products in Singapore
In November 2025 MAS replaced its digital token offerings guide with the Guide on the Tokenisation of Capital Markets Products. A tokenised share, bond or fund unit is regulated as what it is, and the Guide sets out what an issuer should tell investors about the technology underneath. This page takes that list, and the Project Guardian frameworks fund managers work from, and maps each item to what Tokenistry Core does — gaps included.
The Guide's principle is same activity, same risk, same regulatory outcome. Dealing, fund management, custody, operating a market and giving financial advice need the licence they always needed. The token changes how those activities are carried out, not whether they are regulated.
One paragraph matters when choosing a technology supplier. Under paragraph 4.6, a person who can control access to a token or execute transactions involving it — even through one of several keys, or a shard of one — may be treated as having control of it, which is custody. Tokenistry holds no key that can authorise a transaction in an investor's token. In an operated deployment, the accounts Tokenistry runs pay network fees and cannot sign a transfer of anyone's holdings.
First: which register is authoritative
The Guardian Funds Framework describes three forms a tokenised fund's share register can take, and Project Guardian's report on operationalising tokenised funds names four models within them. The Guide asks the same question from the investor's side: where there is more than one record, disclose which one is definitive.
| Model | Where the authoritative register sits | What Core does |
|---|---|---|
| Model 1 Digital Mirror |
Off chain, usually with the fund administrator. The on-chain copy serves internal purposes and is not authoritative. | Mints, burns and transfers follow the register you already keep, and the Ownership Engine reports where the on-chain copy has drifted from it. |
| Model 2 Digital Twin |
On chain for a distributor's nominee clients or a tokenised feeder fund; the underlying fund's register stays off chain. | The on-chain register for the nominee holdings or the feeder fund, with eligibility enforced per investor and positions reported per investor. |
| Model 3 Digital Native |
On chain only. Subscriptions, redemptions and transfers happen on the ledger itself. | The register is derived from confirmed chain state, lot by lot, with positions per investor across all of their wallets. |
For a VCC with a native on-chain register, the same report flags two points counsel will want settled: keeping the register open for inspection at the registered office (VCC Act, s. 66(9)), and whether an on-chain instruction is a proper instrument of transfer (s. 40(3)).
The Guide's disclosure illustrations, item by item
Paragraph 3.7 lists examples of what may be material to disclose about a tokenised product. They are illustrative, not exhaustive, and the disclosure is the issuer's. The right-hand column is what you would be describing with Core underneath, not wording for your offering documents.
| Disclosure | What the Guide asks about | What Core gives you to describe |
|---|---|---|
| Type of DLT and security | The type of DLT, public or private, permissioned or permissionless, and network and application security, including identity and access management. | EVM chains, public or permissioned, chosen per deployment. Single-tenant in your cloud account: each service has its own database role and credentials, secrets come from your secret manager, and outbound access is limited to the RPC and custody endpoints you configure. |
| Smart contracts and governance | How smart contracts are used and governed, including whether they were audited before deployment. | ERC-20 tokens implementing ERC-7943, behind an upgrade beacon whose upgrades need their own role. No external audit has been completed yet, and today that line of a disclosure would have to say so. |
| Minting, issuing, transferring, redeeming, burning | The processes and controls around each. | Each is a role-gated contract function. Issuance and redemption run as durable operations with idempotency and confirmation tracking, eligibility is checked inside every transfer, and every authority operation is recorded with the parameters it signed. |
| Key intermediaries | Who sets up and operates the DLT network, and their roles. | The network, the node or RPC provider and the custodian are yours to name. Tokenistry is the software supplier, and in an operated deployment also runs the services. |
| How ownership is recorded | Whether records are on or off chain, how transfers happen, when they are final, and which record is definitive if there are several. | Set by the register model above. Positions are derived only from confirmed chain state, and the confirmation depth that counts as final is a per-network setting you can state. |
| Rights to amend or override records | Whether the issuer or anyone else can amend or override on-chain records, and in what circumstances. | Freezing an exact amount, forced transfer and forced burn are separate roles. You disclose who holds each and when it is used, and every use leaves an on-chain event. There is no pause function. |
| Custody of the tokens | Whether investors hold directly, the issuer safeguards, or a third-party custodian does, and how private keys are managed. | Investors hold in their own allow-listed wallets or through a custodian; Tokenistry holds none of their keys. The issuer's authority keys stay in its own custody workspace, behind one signing interface. |
| Technology and cyber risks | Malfunction of the network or smart contracts, security breaches, and risks of public permissionless chains such as forks and 51% attacks. | Indexing handles chain reorganisations, and failed submissions, degraded RPC endpoints and crashed workers are recovered from rather than lost. Forks and attacks on the network remain properties of the chain you choose, to disclose as such. |
| Third-party service providers | Arrangements with providers of DLT infrastructure or tokenisation services, and what happens if they fail. | Tokenistry is one of those providers. A licensed deployment keeps running in your account without us, with source escrow and exit provisions available. An operated deployment puts us in the operating path, and that belongs in the disclosure. |
| Lost or stolen keys | The loss or theft of private keys used to access the tokens, and the effect on investors. | A holder's lost wallet can be replaced by a forced transfer, on terms you set and disclose. The authority key matters most, which is why it stays in your own custody workspace. |
Source: MAS, Guide on the Tokenisation of Capital Markets Products, 14 November 2025, paragraphs 3.7 and 4.5–4.6.
The Guardian token taxonomy, Levels 1 and 2
The Guardian Funds Framework sets minimum token functions in four levels. Levels 1 and 2 describe the token itself: the base standard, and certification and compliance. This is how the Core token measures against them.
| Minimum functionality | Core |
|---|---|
| Level 1 · Issuance, redemption, mint and burn | Yes |
| Level 1 · Holder transfers, and approvals for holders and operators | Yes — standard ERC-20 transfer and approval |
| Level 1 · Holding of a holder, and holders of a token | Yes — balances on chain, and holders per token from the Ownership Engine |
| Level 1 · Event logging; name, symbol and supply | Yes |
| Level 1 · Multi-signature arrangements | Yes, per role — a role can be held by a multi-signature address |
| Level 1 · Link the token to metadata with URIs | No — the token has no metadata or terms link today |
| Level 2 · Whitelisting of wallet addresses | Yes — separate send and receive permissions, checked inside every transfer by the Eligibility Engine registry |
| Level 2 · Transaction approval, rejection and status tracking | Yes — a transfer can be checked before it is attempted, is refused with a specific error, and operations are tracked through confirmation |
| Level 2 · Freeze and force transfer (burn) | Yes |
| Level 2 · Issuer access rights and control | Yes — one role per function, with compliance administration on its own key |
| Level 2 · Holder onboarding and verification | Partly — your KYC provider's result becomes on-chain permission; verifying identity stays with the provider |
| Level 2 · Digital identity identifiers | No — identity stays in your systems and is mapped to wallets off chain |
| Level 2 · Visibility of confidential data | Partly — no personal data goes on chain, but balances on a public network are visible to anyone |
| Level 2 · Cross-jurisdictional compliance rules | Partly — expressed as permission pools; the rules themselves are yours |
Sources: MAS Project Guardian, Guardian Funds Framework (November 2024), and Operationalising Tokenised Funds (November 2025).
What an MAS-regulated firm's risk team will ask
A financial institution stays responsible for the technology it relies on. MAS's Technology Risk Management Guidelines already say so, and in March 2026 MAS consulted on Guidelines on Third-Party Risk Management that would extend outsourcing-style expectations to every third-party service. The answers that carry weight are about control.
Who holds the keys and the data
Your custody workspace holds the keys and your databases hold the data. In a licensed deployment Tokenistry has no access to either.
What happens if we stop
The deployment keeps running in your account. Source escrow and documented exit provisions are available where continuity has to be evidenced.
What diligence will find
Contract source open to your reviewers, and no external contract audit completed yet. Better heard here than discovered in a review.
Who this is for
| Firm | Typical starting point | What matters most |
|---|---|---|
| Fund managers | A Digital Native VCC fund, or a tokenised feeder into an existing fund | Eligibility per investor, positions across wallets, a register you can state is definitive |
| Banks & securities firms | Tokenised notes or structured products on infrastructure they run | Single-tenant deployment, keys in their own custody, a disclosure they can write precisely |
| Distributors | A Digital Twin nominee register for clients' holdings | Holdings per client under one nominee, allow-listed wallets |
| Trustees & custodians | Oversight of on-chain activity in the funds they serve | A reconciliation against chain state from a service that holds no key |
Outside Tokenistry, plainly
- capital markets services licences
- prospectus & disclosure drafting
- KYC & AML checks
- fund administration & NAV
- stablecoin or cash settlement
- legal opinions on the register
Tokenistry is a software supplier. It does not deal in capital markets products, manage funds, operate a market, give financial advice, or hold anyone's tokens.
How it is delivered
Licensed, for institutions
Single-tenant in your own cloud account, in a Singapore region if you choose, with your database and your keys. See for institutions.
Operated, for issuers
We run the stack; you hold the authority key in your own custody workspace. See for issuers.
Questions
What is the MAS Guide on the Tokenisation of Capital Markets Products?
MAS guidance issued on 14 November 2025, replacing the Guide on Digital Token Offerings. It explains how the Securities and Futures Act and the Financial Advisers Act apply to tokenised capital markets products, from issuance and offering to trading, settlement and custody, on the principle of same activity, same risk, same regulatory outcome. It includes disclosure illustrations and case studies.
Does a technology provider need a MAS licence?
MAS looks at the substance of what a firm does: dealing, fund management, custody, operating a market or giving financial advice. Tokenistry does none of those. It supplies software, and holds no key that could authorise a transaction in an investor's token. Whether your own arrangement needs a licence is for your counsel.
Does holding the freeze or forced-transfer role count as control of investors' tokens?
It is the right question to ask. Paragraph 4.6 of the Guide treats the ability to execute transactions involving a token, even through one of several keys, as control for custody purposes. In a Core deployment those roles sit with the issuer or manager, not with Tokenistry; what holding them means for the issuer's own licensing is a question for counsel.
Which tokenised fund model should we use: Digital Mirror, Digital Twin or Digital Native?
Project Guardian's report ties the choice to the manager's readiness, investors' appetite and legal clarity. A Digital Mirror keeps the existing register authoritative, a Digital Twin adds an on-chain register for a distributor's clients or a feeder fund, and a Digital Native fund keeps its register only on chain. Core supports each, and the model decides which record you disclose as definitive.
Can a VCC keep its register of members on a blockchain?
Electronic records have legal effect under the Electronic Transactions Act, but the Operationalising Tokenised Funds report notes open points: keeping the register open for inspection at the registered office, and whether an on-chain instruction is a proper instrument of transfer. Those are for counsel. The technology side is a register derived from chain state that can be read out for inspection at any time.
Is the token ERC-3643?
No. It implements ERC-7943, with allow-listing, freezing and forced transfer. The Guardian taxonomy cites ERC-3643 and ERC-1400 as reference standards for its compliance level rather than as requirements. The practical difference is that Core keeps identity off chain instead of in an on-chain identity registry.
Are the smart contracts audited?
Not yet by an external firm. The Guide lists whether a smart contract audit was conducted before deployment as something to disclose, so ask where ours stands before you rely on the contracts.
Can a tokenised product run on a public blockchain?
Yes, or on a permissioned one; both are EVM networks to Core. The Guide expects the type of network and its specific risks, such as forks, to be disclosed. On a public network, permissioning lives in the token's smart contracts, which is what the Eligibility Engine provides; a permissioned network adds its own at the ledger level.
Does Core handle stablecoin or cash settlement?
No. Core executes the unit side, minting, burning and transferring tokens, when your dealing process instructs it. Cash legs, including settlement in stablecoins or tokenised deposits, run in the systems and with the providers you already use.
Where is it hosted?
In a licensed deployment, single-tenant in your own cloud account, in the region you choose, Singapore included, with your database and your keys. That keeps the questions a third-party risk review asks, about data location, access and exit, answerable from your side.
Related
Tokenising a fund or a note in Singapore?
Tell us the product, the register model and the network you have in mind. We will go through the Guide's disclosure items with you and say which ones Core answers and which stay with you.
Discuss a tokenised product