Tokenised money market funds

One investor lifecycle, traditional or tokenised.

SMART-TA and SmartChain are designed to deliver tokenised money market fund operations as a single administered lifecycle. The same investor register, dealing controls, NAV, cash and compliance discipline that govern a conventional MMF, extended with a dedicated execution and evidence layer for on-chain settlement. Both register models are supported, so the fund decides whether the authoritative record of ownership sits off-chain or on-chain.

Tokenised MMF solution
TA
SMART-TA Authoritative transfer-agent register, dealing, NAV, cash and compliance
SC
SmartChain Token execution, chain observation and reconciliation evidence
Token standards in scope
ERC-3643 DS Protocol Permissioned ERC-20 ERC-1400 family
Register models
Off-chain authoritative On-chain authoritative
SmartChain is designed as a standard-agnostic execution layer, so the token standard is a configuration choice per fund or share class, not a platform rebuild.

Full investor lifecycle

Eight stages in sequence, six functions running underneath them.

A tokenised MMF holding moves through eight stages in sequence, from onboarding to fund closure. A further six functions run continuously alongside every one of those stages rather than occupying a place in the sequence.

01
Investor onboarding & identity verification

Eligibility is decided and evidenced off-chain, then represented on-chain in whatever form the fund's chosen token standard provides.

  • The decision is made once, off-chain. SMART-TA captures investor identity, KYC/AML evidence, suitability and jurisdictional eligibility, and holds the resulting approval as the record every later stage depends on.
  • The chain receives a representation, not the judgement. What is written on-chain is a claim that eligibility exists, in the form the token standard supports, rather than the underlying evidence itself.
  • Nothing downstream can begin without it. No wallet association, issuance or transfer is possible for an investor who does not hold a current approval.
02
Wallet association, custody & key management

An approved investor is linked to one or more wallet addresses, which are screened and then enforced by the on-chain compliance layer.

  • Three parties, three distinct roles. SMART-TA holds the investor-to-wallet approval record, SmartChain writes that approval to the on-chain register, and the deployed compliance contract enforces it independently at each subsequent transfer.
  • Association is a controlled event. Adding or removing a wallet is an approved instruction with its own audit trail, not a self-service action by the holder.
  • Custody arrangements vary by investor. The model accommodates self-custody and third-party custody without changing where the eligibility decision sits.
03
Subscription (primary market)

A subscription instruction is captured, validated and priced against a struck NAV, with issuance following the approval rather than leading it.

  • Validation precedes pricing. Dealing cut-offs, current eligibility and fund-level controls are checked before the instruction reaches an allocation, so an ineligible order never acquires a price.
  • Issuance is triggered, never originated. Once the instruction is approved and settlement confirmed, SmartChain triggers the corresponding token issuance against that approved instruction. It does not issue independently.
  • The register and the chain are aligned by construction. The position exists on the register because an approved instruction created it, and on-chain because that same instruction was executed.
04
NAV determination & on-chain publication

Valuation and transfer agency remain separate functions, and publishing a NAV on-chain does not change which of them owns it.

  • Fund accounting strikes, transfer agency applies. The NAV is struck and approved through the fund's valuation cycle; the transfer agency function applies it to investor-level allocations.
  • Cash flows complete the loop. Net shareholder cash flows pass back to fund accounting, settle against the fund's books and feed the next valuation point.
  • On-chain publication is delivery, not authorship. Where a share class calls for on-chain NAV visibility, the approved figure is delivered to the chain in a form the token standard can consume, without changing who calculated or approved it.
05
Redemption (primary market)

Redemption follows the same validation, approval and NAV path as subscription, but carries what subscription does not: the fund's liquidity management tools.

  • Liquidity tools are designed in, not exceptional. Redemption fees, gates and suspensions are the fund's planned response to stress. Each depends on a queue with a defined ordering rule so requests can be pro-rated fairly.
  • Sequencing protects the fund. Once the instruction is approved and the applicable strike determined, the token leg is burned before cash is released, so fund cash never leaves ahead of a final token leg.
  • On-chain settlement changes the construction. Where redemption settles in an on-chain settlement asset, both legs are on-chain and the correct design is a single atomic operation rather than a sequence.
06
Secondary transfer & collateral use

This is the one stage where the token can move without the fund being asked first. An eligible holder can transfer to another eligible wallet, or pledge the token as collateral, without per-transaction approval.

  • Enforcement is autonomous, eligibility is not. The token's on-chain compliance logic evaluates each transfer independently: both sides must hold valid eligibility, fund-level rules such as jurisdiction limits, holding caps and lockups are applied, and a failing transfer reverts.
  • SMART-TA is out of the path but not out of the picture. It is not in the per-transfer authorisation path, yet it remains the source of the identity and eligibility data those rules depend on, and it observes and reconciles the resulting position changes.
  • Collateral treatment depends on the arrangement. A full title transfer moves the holder of record, while a security interest typically leaves the holder in place with the interest recorded against the position.
  • The register model shapes what a counterparty relies on. Under an on-chain authoritative register the token is legally determinative at the moment of reliance. Under an off-chain authoritative register the legal record sits in SMART-TA, and the fund publishes a precedence rule and reconciliation cadence so the relationship between the two is defined rather than assumed.
07
Yield & income distribution

Income is calculated and approved through the same accrual and distribution process used for conventional share classes, then applied to holder positions.

  • Distribution or accumulation is a product decision. Income can be distributed by issuing additional tokens or accumulated by letting unit value rise, and the two carry different tax consequences for the holder.
  • The conventional answer still applies. An accumulating and a distributing class can sit on a single register, implemented as partitions within the token where the standard supports it, so the holder rather than the platform chooses.
  • Accrual is daily and time-apportioned. Income is prorated by elapsed time on transfer and redemption, so a holder is paid for the exact period held.
  • Income can be reconstructable from the chain. Where a share class calls for it, each income event is recorded on-chain against the dealing point and the rate it derives from, rather than being inferable only from a change in unit price.
08
Corporate actions, wind-down & closure

Structural fund events, including share-class amendments, mergers, wind-down and closure, are decided by the fund's governing body and manager, not by the transfer agent.

  • Record and execute, rather than decide. SMART-TA records and evidences those decisions and executes the resulting register changes; SmartChain reflects the outcome on-chain once it is legally final rather than initiating it.
  • Most events stay off-chain. These remain legal processes with the register updated to reflect the result, not on-chain transactions in their own right.
  • One narrow category is different. Changes to the token's own structural identity, such as its name, symbol or linked identity contract, have a direct on-chain counterpart, and that permission is held at a higher trust tier than day-to-day administrative functions.
  • Wind-down is phased, not instantaneous. New subscription is disabled first, income and redemption rights are maintained through a defined transition period, and primary redemption closes only at the end of it, with a terminal-state plan covering the token, the registry and the records afterwards.

Running continuously, not as a ninth step

Six functions that operate across every stage above.

These carry a disproportionate share of the operational cost and the regulatory exposure in a tokenised MMF, precisely because they don't fit into a pipeline view of the lifecycle.

Ongoing monitoring & re-screening

Approved wallets and investor identities are re-screened on an ongoing basis against sanctions and eligibility data, not only at onboarding.

Freezes, forced transfers & corrections

Administrative override capabilities such as freezing a wallet, forcing a transfer or correcting an error sit under the same approval and audit discipline as any other instruction, rather than being exercised unilaterally on-chain.

Reconciliation & register authority

Under an off-chain authoritative register, SMART-TA and the chain are reconciled continuously against a published precedence rule, so a discrepancy is caught and resolved through an auditable corrective workflow rather than a silent adjustment. Under an on-chain authoritative register there is no competing record, and the same process instead assures the completeness of the indexed off-chain copy.

Multi-chain register management

Where a share class is deployed across more than one network, SmartChain is designed to keep a single governed register behind it, rather than treating each network as its own source of truth.

Tax, reporting & investor statements

Income reporting, cross-border information exchange, withholding and investor statements remain SMART-TA obligations, unchanged by tokenisation.

Operational resilience & failure modes

Recovery paths, exception handling and failure modes are designed for across both the SMART-TA and SmartChain layers, not assumed away.

Division of responsibility

One platform, two clearly separated layers.

SMART-TA and SmartChain each own a distinct part of the tokenised MMF lifecycle, so responsibility for every decision and every on-chain action is unambiguous.

TA

SMART-TA

Transfer agency data estate & processing platform

SMART-TA owns the transfer agency data estate, the processing platform and the dealing decisions taken on them, for traditional and tokenised share classes alike. It applies an approved NAV to investor-level allocations rather than striking it, and records and executes fund-level decisions rather than making them. Its scope is the same under either register model; what changes is only which copy of the ownership mapping is legally authoritative.

  • Holder records, KYC/AML case files and eligibility
  • Dealing, orders and allocation decisions
  • Application of approved NAV to investor allocations
  • Shareholder cash flows and reconciliation
  • Compliance rules and approval workflow
  • Corporate action register changes, recorded and evidenced
  • Reporting and audit evidence
SC

SmartChain

Token execution & evidence layer

SmartChain translates approved instructions into token actions, observes the chain for confirmation, and maintains the indexed off-chain copy of on-chain state that the platform queries against. It does not make business decisions on its own.

  • Token action submission for approved instructions
  • Standard-agnostic execution across supported token models
  • Chain event observation, indexing and finality tracking
  • Indexed off-chain copy of the ownership mapping
  • Wallet, identity and eligibility enforcement on-chain

Deployment model

Two decisions, made independently.

A fund moving to tokenised operations is really making two separate choices, and they are often treated as one. The first is where legal authority for ownership sits. The second is how much of the transfer agency function executes on-chain. SMART-TA and SmartChain are designed so a fund can answer each without the other being decided for it.

The word "register" covers three things, and each is settled differently.

Separating them is what allows the two decisions to be taken independently rather than as a single all-or-nothing move.

Decision one The ownership mapping

Who holds how many units, and the eligibility state that gates a transfer. This is what the register authority choice decides.

Decision two The processing platform

Capture, validation, allocation, accrual, settlement matching and the operational workflow. How much of this executes on-chain is a separate choice.

Largely off-chain throughout The data estate

Holder records, dealing history, verification case files, correspondence, statements and reporting archives. Constrained by law and volume rather than by design.

Decision one: where legal authority for ownership sits

Digital twin

Off-chain authoritative register

The conventional register remains the legal record, and the token represents a position held in SMART-TA. Ownership changes when that record is updated.

  • SMART-TA holds the authoritative ownership mapping
  • SmartChain maintains the token representation and its evidence
  • Published precedence rule and defined reconciliation cadence
  • Documented exception and correction process
Authority: SMART-TA
Native tokenised

On-chain authoritative register

The ledger is the legal record of holdings, with no second authoritative register behind it, and the token is legally determinative at the moment a counterparty relies on it.

  • The token ledger holds the authoritative ownership mapping
  • SMART-TA runs the data estate and the operational workflow
  • Register-correction capability retained by the manager
  • Specified read-and-evidence path for depositary and auditor
Authority: token ledger

Decision two: how much of the function executes on-chain

Execution bridge

Approved instructions are executed on-chain and eligibility is enforced at transfer. The operational path runs off-chain, with the ledger acting as a settlement and evidence venue.

Distributed processing

Deterministic functions move to contracts: accrual and time-apportionment, lockups and holding caps, redemption queue ordering and pro-ration, fee calculation. Order capture opens to APIs and investor-facing applications.

Contract-native operations

Smart contracts, APIs and applications carry the majority of the operational path, with off-chain systems retained for the functions below. The furthest position the architecture is designed to reach.

What does not move, and why

These constraints are legal and practical rather than architectural, so they apply at every position on the spectrum. Naming them is what makes the rest of the boundary a genuine choice.

Personal data and the document estate

Verification documents, correspondence and case files carry personal data that sits badly with an immutable ledger and gains nothing from being on it. The chain holds attestations and references; the evidence itself stays off-chain.

Discretionary judgement and correction

AML adjudication, suitability, complaints, and the death, divorce, fraud and court-order cases require an accountable decision-maker. The manager must also retain practical ability to bring the register into line with the legally correct position, which sets a floor on how autonomous the contracts can be.

Inputs the chain cannot originate

NAV from fund accounting, sanctions and screening data, tax status. A contract can consume these and act on them, but it cannot produce them, and the path by which they arrive is an off-chain trust point wherever it is placed.

The choice is the fund's, not the platform's Both decisions run on the same modules, the same workflow and the same controls, and neither constrains the other. A fund can hold an off-chain authoritative register while running much of its processing on-chain, or hold an on-chain authoritative register with a deliberately conventional operational path.

Phased adoption route

For managers moving an existing register, a staged route is available.

A fund launching directly on an on-chain authoritative register adopts that model from the outset and does not pass through these stages. This route exists for managers with an established off-chain register who want to introduce tokenisation incrementally, and it ends at the point where the two models meet. The architecture does not change between stages; what changes is which record the fund formally designates as authoritative, under its own legal and operational governance.

1 Digital twin

SMART-TA authoritative, chain mirrored

SMART-TA remains the authoritative register. SmartChain projects a token representation and execution evidence alongside it, giving a verifiable digital record without changing where legal ownership sits.

Authority: SMART-TA
2 Verified register

Continuous reconciliation, independently verifiable

SMART-TA and SmartChain are continuously reconciled, so the on-chain record can be relied on for position verification and reporting alongside the transfer-agent register, without either side operating unchecked.

Authority: SMART-TA, chain verified
3 Native tokenised register

Token ledger as the legal ownership record

Where a fund's legal documentation designates the token ledger as the official ownership record, the fund is operating the on-chain authoritative model described above, reached by transition rather than at launch. SMART-TA retains the data estate, processing platform and operational layer around it.

Authority: token ledger
No platform migration required Movement between stages is a change of operational and legal designation, not a change of software. Every stage on this route, and both register models, are designed to run on the same platform.

Token standard coverage

Built for the standard the fund needs, not the other way round.

SmartChain's execution layer is designed to integrate with multiple permissioned token models, so the choice of standard can be driven by the fund's legal structure and target market, not by a platform constraint.

01

ERC-3643

A permissioned token standard built around on-chain identity, where eligibility is verified against a registered identity before any transfer is allowed to complete.

  • On-chain identity verification
  • Rule enforcement at transfer
  • Established institutional adoption
02

DS Protocol

A compliance-embedded security-token model, where transfer and eligibility rules are enforced as part of the token standard itself.

  • Embedded compliance logic
  • Registered security-token pattern
  • Suited to regulated securities issuance
03

Permissioned ERC-20

A whitelisted extension of the standard fungible-token model, with transfer eligibility enforced through an external permissioning layer.

  • Broad wallet and tooling compatibility
  • External eligibility and transfer control
  • Lower integration overhead for counterparties
04

ERC-1400 family

A modular security-token standard family combining partitioned balances, document referencing and configurable transfer restrictions.

  • Partitioned holdings support
  • Configurable transfer restrictions
  • Document and metadata referencing

Why this matters

One platform for traditional and tokenised MMF operations.

Unified operations

No parallel platform to run

Traditional and tokenised MMF share classes are designed to be administered through the same investor register, dealing and NAV engine, rather than a separate system for each.

Governed evidence

Reconciliation is built into the foundation

SMART-TA and SmartChain are designed to reconcile continuously, so the audit and control evidence a tokenised fund needs is a by-product of normal operation rather than a separate exercise.

Standard flexibility

Choose the token model per fund

ERC-3643, DS Protocol, permissioned ERC-20 and ERC-1400 family token standards are treated as configuration choices, not separate builds.

Register model choice

The fund decides where authority sits

An off-chain or on-chain authoritative register are both supported on the same platform, adopted at launch or reached by staged transition, without re-platforming.

Traditional and tokenised money market funds, administered on one platform with one set of controls.