Skip to main content
Request a demo
Tokenization

Token Standards

Which token standard an instrument needs, decided by what the instrument is rather than by what is fashionable.

Standards, ordered by control over a transferFour token standards as rungs, from one where anyone may hold up to one where a transfer can be refused by the contract itself.ERC-20anyone may holdERC-1155batched, still openERC-4626a vault around oneERC-3643a transfer can be refused

Definition

A token standard is the interface a token exposes: how balances are held, how transfers happen, and — critically for regulated instruments — whether a transfer can be refused. Choosing one is a design decision about the instrument, not a technology preference.

What it solves

  1. Standards chosen by imitationThe most common failure is picking the standard the last project used. A restricted security on a standard with no concept of eligibility is not a shortcut; it is the wrong instrument.
  2. Restrictions bolted on afterwardsTransfer restrictions added in a wrapper can be bypassed by interacting with the token directly.
  3. Unexplained recommendationsAn issuer signing off a token design needs the reasoning, the alternatives considered and the warnings — not a single name.

How it works

  1. Describe the instrumentIs it fungible? Is it fractionalised? Does a transfer depend on who the recipient is?
  2. The engine recommendsThose three properties largely determine the answer, and the recommendation carries its reasoning.
  3. Alternatives are shownWith the trade-off each one makes, so the decision is reviewable.
  4. Warnings are explicitIncluding the case where a chosen standard cannot express a restriction the instrument requires.

Architecture

A pure recommendation function over the instrument’s properties, and a contract suite — identity registry, compliance module, token and factory — that enforces the resulting rules on chain. The off-chain mirror of those rules uses the same reason codes as the contract, so the platform can explain a refusal in the words the chain would use.

How the platform is arrangedFour stages — asset, compliance, offering and register — connected left to right, all enclosed by a single transaction boundary that rests on a double-entry ledger.AssetStructured and documentedCompliancePolicy in forceOfferingA book that is derivedRegisterHolders of recordOne transaction boundaryA movement and the entries behind it commit together, or neither doesDouble-entry ledgerEvery movement, both sides, in minor unitsBalanced at COMMIT
Four stages inside one transaction boundary, on one ledger. A register that disagrees with the cash is not a state the software can reach.

Tokenization lifecycle

  1. ConfigureStandard, decimals, supply model and restrictions recorded against the asset.
  2. ReviewThe plan is checked before deployment, including the administrator model.
  3. DeployIdentity registry, compliance module and token wired together in one transaction.
  4. OperateEligibility enforced on every transfer for the life of the instrument.

Supported token model

ERC-3643 and equivalents for restricted securities; plain fungible standards only for genuinely unrestricted instruments. A plain fungible token has no concept of who may hold it. For a security that is not a missing feature to work around — it is evidence that the instrument and the standard do not match.

Asset requirements

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

  • A decision on fungibility that reflects the instrument, not the convenience of the register.
  • A stated position on whether transfers require recipient eligibility.
  • A decimals choice consistent with the smallest unit the instrument can be held in.
  • An administrator model — who can freeze, force-transfer or recover — disclosed to investors.

Compliance considerations

  • On-chain eligibility means the contract refuses a non-compliant transfer regardless of what any interface allows.
  • The reason a transfer was refused is legible, and the platform reports it in the same vocabulary the contract uses.
  • Concentration limits apply to secondary transfers only: a cap below 100% is unsatisfiable at primary issuance, because the first holder minted to necessarily holds everything.
A compliance policy as ordered rulesRules are evaluated in sequence and the first match decides. A subject matching no rule is denied, and a fact the platform does not know never satisfies a rule.Subjectan investor's facts#1Screening hit is openreject#2Country in the blocked listreject#3Professional or institutional, verifiedallowMatched no ruledenyFirst matchdecides. A laterallow cannot undoan earlier reject.Eligibility comesfrom a rule saying so.
Rules are data, evaluated in sequence, and the first match decides. A subject matching nothing is denied — eligibility comes from a rule saying so, never from no rule objecting.

Investor workflow

  • Be registered as an eligible holder before any units can reach you.
  • Hold and transfer within the restrictions the contract enforces.
  • Understand the administrator model, because it defines what can be done to your position.

Issuer workflow

  • Describe the instrument honestly and take the recommendation.
  • Review the alternatives and the warnings.
  • Have the contract plan approved before deployment.
  • Operate within the model you disclosed.

Payments

Standards govern the register, not the money. Payment and settlement sit alongside, in the ledger.

The payment railMoney is matched to a subscription by its reference and no other attribute, then screened and settled. Provider adapters for card and crypto rails are not built, and are drawn as an absent component.ReferencechecksummedFunds arrivebank or custodyReconcilereference or nothingScreenAMLSettlesecond authoriserSuspense (2900)unidentified, and visibleNo reference matchProvider adaptersCard, local rail, stablecoinNot built — the registry ships empty
A reference is the only thing that matches money to a payment. Everything else is an exception for a person, and unidentified credits post to suspense where they stay visible.

Lifecycle servicing

Corporate actions that change unit counts are executed as proportional mints and burns, which is what a token contract actually does on a split — so the register can still rebuild issued supply from its own movement history afterwards.

How a distribution is splitA funded pool is divided among holders of record as at the record date using largest-remainder allocation, then withholding is deducted from each holder's gross rather than from the pool.Funded poolone exact amountRegister as atthe record dateRebuilt from confirmedmovements, not today’sbalancesNet to the holderWithheld, from that holder’s grossThe lines sum to exactly what was fundedLargest-remainder allocation, so no minor unit is created or lost. Rounding each slice independently leaves the issuer a few units out every cycle.There is no per-jurisdiction withholding matrix in this build — one rate is entered per run.
Holders of record as at the record date, split by largest remainder so the lines sum exactly, with withholding taken from each holder’s gross rather than off the top of the pool.

Secondary transfer

The standard is what makes a secondary transfer safe: eligibility, lockups, freezes and concentration are enforced by the contract rather than trusted to whoever built the interface.

The transfer gateA transfer request passes through eight compliance checks. Any single failure refuses the transfer; the same gate is evaluated off-chain and on-chain.Senderholds unitscanTransfer( )Sender holds the unitsNeither party frozenLockup expiredRecipient eligible under policyJurisdiction permittedInvestor type permittedHolding limit not breachedSanctions screening clearRecipientunits move, or none doOne implementation. The Solidity module and the register evaluate the same rules.
One implementation of the gate, not two. The function the register calls is the same one that mirrors the Solidity compliance module check for check, so an off-chain gate and an on-chain gate cannot drift.

Risks

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

  1. ImmutabilityThere is no upgrade mechanism here, deliberately: an upgradeable securities token lets the issuer rewrite the rules under holders after they have subscribed. The cost is that a defect cannot be patched in place.
  2. Administrator powerFreeze, forced transfer and recovery are real capabilities. They are necessary for regulated instruments and they must be disclosed.
  3. Key managementA compromised deployer or agent key is a severe event, and is on the threat model as not fully mitigated.
  4. Standard mismatchAn instrument on the wrong standard may be unable to enforce a restriction it is legally required to enforce.

How we support it

  • A recommendation engine that will not fall back to a plain fungible standard for a restricted security, with a test asserting it.
  • A Solidity suite — identity registry, compliance module, token, factory — with an execution test suite running against a real EVM.
  • An off-chain mirror of the transfer rules whose reason ordering is checked against the Solidity enum, so the interface never explains a refusal with the wrong reason.

Questions

Which standard do you recommend?

Whichever the instrument requires. For a restricted security that means a permissioned standard with on-chain eligibility; for a genuinely unrestricted utility instrument a plain fungible standard may be right.

Can the token be upgraded later?

No. That is a deliberate choice — an upgradeable securities token lets the issuer change the rules after investors have committed.

Who can freeze or move my tokens?

Whoever the administrator model names, and that model is disclosed before you subscribe. If it is not disclosed, that is itself the answer to a different question.

Next steps

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

Request Enterprise DemoAll tokenization topics