Token Standards

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.

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.

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.

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.

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.

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

Next steps

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