Skip to main content
Request a demo
Financial assets

Bond Tokenization

Debt paying a periodic coupon to holders of record, with accrual, day-count and maturity handled as first-class lifecycle events.

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

Bond tokenization issues a debt instrument as a permissioned token: a fixed principal, a coupon on a schedule, and a maturity date at which principal is repaid and the units retire. The register determines who receives each coupon, and it does so as at a record date rather than as at the moment somebody runs the payment.

What it solves

  1. Coupon administrationPaying a coupon across a holder base by hand is a reconciliation every period. Computed from the register, it either sums exactly to the pool or refuses.
  2. Record-date disputesWho was entitled on the record date is a question a manual register answers slowly and sometimes wrongly.
  3. Minimum denominationsTraditional bond minimums exclude smaller investors; the denomination becomes an issuance decision.

How it works

  1. Terms are fixed at issuancePrincipal, coupon rate, frequency, day-count convention and maturity.
  2. Units are issued against subscription proceedsThe issuer receives the proceeds; holders receive units.
  3. Coupons pay holders of recordOn each payment date the register is rebuilt as at the record date and the pool is split across it exactly.
  4. Maturity retires the instrumentPrincipal is repaid, units are burned, and the register closes.

Architecture

A distribution engine that reconstructs holders of record from confirmed movements as at a date and splits the pool by the largest-remainder method so the lines sum to exactly what was funded. Withholding is applied per holder against their gross entitlement rather than taken off the top of the pool.

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. StructureIssuer, terms, security or ranking, and governing law.
  2. IssueOffering, allocation, issuance, proceeds to the issuer.
  3. Coupon periodsRecord date, computation, declaration, payment — repeated for the life of the bond.
  4. MaturityFinal coupon and principal repayment; units retired.

Supported token model

Permissioned fungible token. Bonds of the same series are interchangeable, so units are fungible. Transfer restrictions and holder eligibility require an on-chain compliance check.

Asset requirements

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

  • An issuer with the capacity to borrow and a documented obligation to repay.
  • A defined coupon schedule with an explicit day-count convention.
  • A paying agent or an equivalent operational owner of each payment.
  • Ranking and security clearly documented, including what happens on default.

Compliance considerations

  • Prospectus or exemption analysis per jurisdiction of offer.
  • Withholding tax treatment per holder jurisdiction, which is a reviewed data set rather than a lookup to guess at.
  • Transfer restrictions consistent with the exemption relied upon.
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

  • Verify, review the terms, subscribe and fund.
  • Hold and receive coupons on schedule.
  • Transfer where permitted, subject to eligibility.
  • Receive principal at maturity as the units retire.

Issuer workflow

  • Document the instrument and its ranking.
  • Configure the token, the coupon schedule and the withholding basis.
  • Issue and take proceeds.
  • Run each coupon: record date, compute, have it approved, fund the pool, pay each holder.
  • Repay principal and retire the units at maturity.

Payments

A declared coupon recognises two liabilities at once — the net owed to holders and the tax withheld and owed onward to an authority — funded from the issuer. Holders are then paid one line at a time, because that is how payments actually fail, and a single movement for the whole run would either block everybody on one bounced transfer or falsely record them all as paid.

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

The coupon cycle is the instrument’s life. Each run is computed against the record-date register, approved as a specific list of people and amounts, declared on the ledger and then paid per holder.

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

Transfers between coupon dates carry no accrued-interest mechanism unless the terms create one; most tokenized issues transfer cum-coupon and let the record date decide. That choice must be disclosed, because it determines who is paid.

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. Credit riskThe issuer may not pay. Tokenization changes the register, not the covenant.
  2. Withholding complexityGetting withholding wrong creates a liability for the issuer and an unexpected shortfall for the holder.
  3. Record-date ambiguityIf the record date and the transfer rules disagree, two parties will both believe they are entitled.
  4. Default handlingWhat happens on a missed coupon must be documented before it happens, not negotiated after.

How we support it

  • Distributions computed from the register as at the record date, so later buyers are not paid and earlier sellers are.
  • Exact allocation: the lines sum to the pool with no residual, tested against registers with irregular weights.
  • Withholding recognised as its own liability, so a balance that never clears is visible rather than buried.

Questions

Can coupons be paid in a stablecoin?

Where the terms and the jurisdiction permit it. The receiving account is always an explicit choice, because a stablecoin payment recorded against a bank account balances and describes something that did not happen.

What happens if a holder cannot be paid?

That line stays unpaid and visible while the others complete. Paying is per holder precisely so one failure does not stall or falsify the rest.

Is accrued interest handled on transfer?

Only if the terms create it. Most tokenized issues rely on the record date instead, and that must be disclosed.

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