Token features

Fifteen token features add behavior to a token, such as paying a coupon, charging a fee, or converting a loan into equity. This page is their catalog: one entry per feature, stating what it does, the parameters and units that decide it, and who operates it after issuance. Reach for it when you already know a feature by name, perhaps because it sits on an instrument template or in a token's "Token Features" section. It does not teach the template workflow: Instrument templates covers that, and composable tokenA Composable Token lets an issuer bring a new regulated instrument to market by configuring facts, features, and rules, not new contract code.Read the concept explains why a token's behavior is built from features. The Platform API manages the same features programmatically.

An instrument template is a set of token features with their defaults, plus metadata fields and a compliance policy. A feature reaches a token in one of two ways. You select it on the template's "Features" step, and issuing from that template installs it. Or, after issuance, an account that holds the governance role attaches, detaches, rotates, or updates it. A token holds an ordered list of at most 32 features and runs them in list order: the template's order at issuance, and the end of the list for a feature attached later. The platform never sorts the list.

The Console attaches only hold, voting power, and fixed treasury yield after issuance, and it detaches only permit. The Platform API attaches twelve of the fifteen features. Conversion, historical balances, and the distribution waterfall reach a token only through a template at issuance. Each entry below names the actions that exist after issuance and the role each one needs. Parameter names follow the Issue new asset form. The template's "Features" step shows some parameters under their identifiers instead, such as discountBps, so the tables give the identifier where the two differ. The four fee features, fixed treasury yield, conversion, and the conversion minter have a second generation, and their entries say how it differs. The Console shows no generation badge.

Choose the feature by what it doesCopy Anchor Link

Group the fifteen features by the job they do, then pick the one in that row that matches your requirement.

Within the income row, the choice is how the amount is decided. Dividend yield pays an amount per share that the issuer declares each time, fixed from balances on a record date. Interest yield pays a rate that accrues on balances as time passes. Fixed treasury yield pays a fixed coupon for each period, on the balance held at the end of that period. Maturity redemption pays face value once, after maturity, in exchange for the token. The distribution waterfall decides no amount. It splits one pool across the share classes of an instrument, and each class's dividend yield then pays from its own part.

Within the fee row, the choice is who pays and what moves. One 100-token transfer shows the four behaviors side by side. The example uses a 2.5% (250 basis points) transaction fee, a flat external fee of 2.5 units of a second token, and a 1% yearly AUM fee that is collected separately.

The next table shows what each feature needs before it works, what it cannot sit beside, and where it runs. A feature that needs a token before issuance makes the template show "Prerequisite setup needed" on Issue new asset until the tenant has that token. The Features step enforces the dependencies and the conflict as you toggle: "Select Historical Balances first." and "Conflicts with Transaction Fee Accounting." are the messages it shows.

AUM feeCopy Anchor Link

Accrues an annual management fee on the token's time-weighted average supply and mints it to the fee recipient when someone collects it. It never touches a transfer, a mint, or a burn. It dilutes holders instead: every holder's share of supply shrinks by the amount minted, and the recipient gains it. The accrued fee is the average supply since the last collection, multiplied by the yearly rate and the elapsed time, divided by 365 days, and rounded down. Choose it for a fund-style fee that must not change any holder's balance or any transfer. The DALP Library includes it on five templates: Mutual Fund, ETF, Money Market Fund, Private Equity Fund, and Commercial Real Estate.

After issuance, an account with the governance role sets the rate, sets the recipient, and freezes both. Changing the rate first settles the fees accrued so far at the old rate, when the old rate and the accrued amount are both above zero. Changing the recipient settles nothing, so earlier accruals go to the new recipient at the next collection. A freeze locks the rate and the recipient and cannot be undone. Any account can collect, because the accrual fixes both the amount and the recipient. Collection continues after a freeze. The how-to Fee administration covers the screens.

With a constant supply of 1,000,000 tokens and a 1% rate, a full year accrues 10,000 tokens. The supply becomes 1,010,000, and a holder of 100,000 tokens falls from 10% to 9.901% of supply. The next period starts from 1,010,000. When the supply changes during the period, the average decides the fee. A supply of 1,000,000 tokens for 180 days and 1,500,000 tokens for the next 185 days averages 1,253,424.66 tokens, so the fee is about 12,534.25 tokens, not the 15,000 that the closing supply would give. A fee that rounds down to zero does not reset the window, so the accrual keeps growing until it produces a whole base unit.

In the second generation, the fee mint is a booked movement. A transaction fee on the same token does not split it, transaction fee accounting does not record it, and an external transaction fee is not charged on it. Compliance and identity checks still apply to the recipient. On Canton, the admin collects against a balance snapshot of one account in whole days, and the schedule has no freeze.

ConversionCopy Anchor Link

Turns a holder's balance of a loan or convertible token into newly minted target tokens at a price that a trigger sets. Governance publishes a trigger that holds a round price per target token, and a holder converts against it. The custodian can also force a conversion for a holder. The effective price is the round price less the discount, rounded down, and limited to the price cap when one is set. The converted principal, plus accrued interest when interest converts, divides by that price to give the target amount, rounded down to the target token's decimals. The loan side then reduces its exposure with the debt method, and the target token's conversion minter mints the result. The call is atomic: a failed mint reverts the principal reduction. Choose it for convertible notes, SAFEs, and warrants. The DALP Library includes it on four templates: Carbon Credit, Convertible Note, SAFE, and Warrant.

All fourteen settings are fixed at issuance. The Issue new asset form shows the first six rows of the table, with the target token first. The other settings take their defaults, and you set them in the template's feature settings or through the Platform API.

The debt method decides what happens to the loan tokens. Burn destroys the converted principal. Lock moves it to the escrow account, which then holds it. MarkConverted moves nothing: the holder keeps the loan tokens, but converted tokens can no longer be transferred or burned, and "convert all" converts only the unconverted balance. No Library template pins Lock or MarkConverted. MarkConverted also blocks attaching interest yield or fixed treasury yield later, and it rejects a partial conversion while a forward-coupon yield feature is attached.

After issuance, governance publishes and disables triggers and changes the conversion window. The window is the only term that changes after issuance, and the Platform API updates it through the feature name conversion-minter. Any other change needs a rotate. A holder converts the holder's own balance and, when interest converts, the holder's accrued interest. A full conversion that would close accrual while convertible interest remains first needs the interest drained. The custodian role can force a conversion. On Canton, conversion is a fixed-rate exchange that the holder starts, with no trigger, discount, cap, or window.

A holder with 100,000 loan tokens, all with 18 decimals, converts against a trigger with a round price of 2.50. The discount is 20%, the cap is 1.80, accrued interest is 3,000, and interest converts. The discounted price is 2.00, so the cap lowers the effective price to 1.80. The value is 100,000 plus 3,000, which gives 103,000. The holder receives 103,000 divided by 1.80, which is 57,222.22 target tokens. Without the cap the holder would receive 51,500, and without interest 55,555.56. The loan token is valued one for one in the denomination asset, so a loan token that is not worth one unit converts as if it were.

A conversion that rounds to zero target tokens is rejected, so a decimal mismatch cannot burn principal for nothing. The conversion feature has a second generation that retires the principal as a booked movement, so a transaction fee or an external fee on the loan token takes no part of the principal. Both generations share one configuration. The composable token concept explains how the loan and target tokens pair, and the corporate action "conversion" in Corporate actions runs it for a bond.

Conversion minterCopy Anchor Link

Sits on the target token and mints there only for the conversion features on its allow-list. A call from any other address is rejected. Each conversion has a unique identifier, and the minter marks it used before it mints, so a replay fails on the loan side and on the target side. It records the recipient, the amount, the loan token, the converter, and the trigger for each issuance. Choose it on any token that other instruments convert into. The DALP Library includes it on two templates: Carbon Credit and Convertible Target Equity. Neither lists a converter.

After issuance, governance adds and removes converters. The Console action "Add Authorized Converter" takes the conversion feature's address on the loan token. A wallet or other contract that is not a conversion feature is rejected. Detaching the minter while a conversion is live leaves every conversion on that pair reverting. The second generation mints as a booked movement, so a fee on the target token takes no part of the issued tokens. The minter has no Canton counterpart: a Canton conversion mints through the target registry's own mint path.

Distribution waterfallCopy Anchor Link

Holds one pool of cash and splits it into one leg for each share class, by rank. Each class's dividend yield uses the waterfall as its treasury and draws only on its own leg, so a class can never spend another class's money. The waterfall attaches to the controlling class token. It holds the cash and keeps two counters for each class: what the class may still draw, and how much capital the class has had back. It does not own or move the share tokens, and it restricts no transfer. Money enters through fund, which splits the pool and raises the counters. Money leaves through payout, which a class's dividend yield calls when a holder claims. A class never receives a lump sum. Its leg is always paid out as per-share dividends to its holders. The operator action that drives it is the coordinated distribution, and Paying several share classes from one pool explains why the design works this way. The DALP Library includes the waterfall on one template, Controlling Class Share, which belongs to the Dual-Class Share Structure. It runs on EVM only.

The Console shows these parameters under their identifiers. The structure editor on the instrument structures tab shows them as words, for example "Contribution basis".

In the Dual-Class Share Structure, the issuer enters the payment asset and, for each class, the contribution basis and the ordinary rank. Both ordinary ranks default to 1, so an ordinary distribution splits by contribution basis. The Library seeds one sponsor-event priority row that puts the economic class (Class B) at tier 1 and the controlling class (Class A) at tier 2, and the issuer cannot change it. The class and row terms cannot change after the waterfall is deployed, because no function edits a class or a row. One setting can change: an account with the governance role can turn on netting for a class under a priority row with setDistributionNetting, until the first distribution is funded under that row. No Console action sets it.

After issuance, an account with the governance role funds a distribution through a coordinated distribution, which also needs a second person's approval unless the organization turned that approval off. The issuance run binds each class to its token, and fund is rejected until every class is bound. No Console action binds a class afterward. The factory also registers the waterfall as a contract with an identity and adds it to the compliance bypass list, so a payment token that refuses unregistered recipients still accepts the pool. The bypass covers receiving only, and every payout to a holder is still checked.

The waterfall works in one of two modes, and the mode decides who gets the pool.

Ordinary mode applies when the operator names no determination kind, and also when the named kind has no valid claim. The whole pool goes to the classes with the lowest ordinary rank, split pro rata by contribution basis. A class at a higher rank gets nothing. Equal ranks share the income, and distinct ranks are winner-take-all.

Priority mode applies when the operator names a configured kind and the controlling token's identity holds a valid issuerEventDetermination claim of that kind from a trusted issuer. Tiers run in ascending order. Each tier is due the unreturned capital of its classes, which is the contribution basis less the capital the class has already had back. With netting on for the row and the class, it is the contribution basis less every leg the class has been allocated, ordinary distributions included, and never below zero. A tier fills completely before the next one starts. A shortfall inside a tier splits pro rata by unreturned capital. Whatever is left after the last tier follows the ordinary rule.

A kind with no configured row, and a claim that is missing, revoked, from an issuer that is not trusted, or of another kind, all fall back to ordinary mode without an error. A trusted claim whose data cannot be decoded is rejected. Legs always add up to the pool. Shares round down, and the remainder goes to the last class of the group. quote previews the split without moving money. fund computes the split again and reverts with SplitChanged before it takes any money if the result differs from what the operator approved. A class's dividend yield can draw only its own leg: the waterfall rejects a caller that is not that class's current dividend yield (UnauthorizedClass), a payout above the leg (InsufficientAllocation), and a payout in another asset (PayoutAssetMismatch).

The numbers below come from the contract tests. The controlling class has a contribution basis of 9,000,000, ordinary rank 1, and tier 2 in the sponsor-event row. The economic class has a basis of 1,000,000, ordinary rank 1, and tier 1.

Netting changes what a class is due. In the contract tests both classes have a basis of 350,000,000 and equal ordinary ranks, and an ordinary distribution of 200,000,000 gives each class 100,000,000. A priority distribution of 500,000,000 then pays the economic class 250,000,000 and the controlling class 250,000,000 when netting is on for the economic class. With netting off, the economic class is still due its full 350,000,000, and the controlling class receives the remaining 150,000,000.

Three sharp edges decide most mistakes with this feature.

Distinct ordinary ranks are winner-take-all. A junior class at a higher ordinary rank receives no ongoing income, and nothing reports the loss. With three classes, A (basis 6,000,000, rank 2), B (basis 3,000,000, rank 1), and C (basis 1,000,000, rank 1), a pool of 10,000,000 gives A nothing, B 7,500,000, and C 2,500,000. Give classes equal ordinary ranks to share income, and use priority tiers to return junior capital.

The contribution basis does two jobs. It is the split ratio in ordinary mode and the principal balance in priority mode. Enter the cash the class paid in, never its net asset value.

The two orderings are independent. The ordinary rank orders income, and the ranks of a priority row order capital return. A class can share income equally and still come second for capital, as the controlling class does above. The platform checks that a determination claim comes from a trusted issuer. It does not check who that issuer is beyond that registration.

The runbook is Corporate actions, which covers creating, previewing, approving, and confirming a coordinated distribution.

Dividend yieldCopy Anchor Link

Pays a cash dividend that the issuer declares, with an amount per share. After the record date, governance records one holder snapshot. The platform reads each holder's balance on that date from historical balances, works out each holder's amount, and fixes the full list of entitlements in a Merkle tree, a compact fingerprint that lets each holder prove their own entry. Holders then pull their claim: the feature pays it from the treasury and never holds the money itself. Declaring a dividend and recording the snapshot move no money. A claim reverts when the treasury is short. Choose it for equity-like instruments where the issuer decides each payout. The DALP Library includes it on nine templates: Controlling Class Share, Economic Class Share, Common Equity, ETF, Mutual Fund, Preferred Equity, Private Equity Fund, Commercial Real Estate, and Sukuk Ijara.

All three settings are fixed at issuance. The feature has no setter for the treasury, so the only way to change one is to detach the feature and attach a new one, which is refused while declared dividends are still unclaimed.

For each dividend, the issuer enters the amount per share, the ex-date, the record date, the payment date, and optionally a claim deadline. The dates run in order, and the claim deadline must be in the future. A record date in the past is allowed when historical balances cover it. Without a claim deadline, the platform sets the later of the payment date and today, plus the default days. An identical declaration retried with the same idempotency key keeps the deadline derived for the first accepted write. Rejoining an accepted declaration does not extend the 24-hour idempotency window. When the first submission is still in flight, the retry rejoins it and the platform does not check eligibility again. When the first submission already failed before signing, the retry runs the full current eligibility check before it submits again, and it still keeps the original deadline.

After issuance, an account with the governance role declares a dividend, records its snapshot once the record date has passed, and cancels a dividend before its snapshot exists. Anyone can fund the treasury with a plain transfer. A holder with a verified identity claims. Governance can also extend a claim deadline once and reclaim unclaimed entries after the deadline, and the Console offers neither. The claim deadline is soft: a holder can still claim after it until governance reclaims. Reclaiming releases the feature's liability and closes the dividend. It moves no tokens, because the treasury never lost them. Corporate Action explains why a snapshot cannot be replaced, and Corporate actions covers the screens.

A token has 18 decimals, and the denomination asset has 6. The amount per share is 0.40, and a holder had 250 tokens on the record date, so the holder's entitlement is 100.00 units of the denomination asset. With 1,000,000 tokens in supply, the declaration estimates 400,000.00 of funding. The snapshot replaces that estimate with the exact sum of the rounded-down entitlements, so the requirement is the estimate or slightly less.

On Canton, the admin opens a distribution for each period with an amount per unit and a claim deadline. A holder presents an attested balance snapshot from the record date, and the claim mints the amount in the same instrument. The deadline is enforced.

External transaction feeCopy Anchor Link

Charges a fixed fee for each mint, burn, or transfer, pulled in a second token. The token amount moves in full, and the fee does not depend on the amount. The payer is the account that receives a mint, or the sender of a transfer or a burn. The feature pulls the fee from the payer to the fee recipient with an ERC-20 transfer, so the payer must hold the fee token and must have approved the feature contract to spend it. A payer without balance or allowance makes the whole token operation revert. The fee recipient is not exempt: when the recipient pays, it pays itself and still needs the allowance. Custodian forced updates, zero-value operations, and a fee token of zero charge nothing. The DALP Library includes it on one template, Asset-Backed Token.

The three fee amounts use different units in two places. At issuance, the form takes base units of the fee token. After issuance, the "Set external fee amounts" sheet takes decimal units and scales them by the fee token's decimals. A zero fee token means the feature collects nothing. It does not mean the native currency.

After issuance, an account with the governance role sets the amounts, the recipient, and the token, and freezes them. A freeze locks the amounts, the recipient, and the token, and cannot be undone. Collection continues after a freeze. Payers approve the feature, not the recipient. With a fee of 2,500,000 base units of a 6-decimal fee token, a 100-token transfer costs the sender 100 tokens plus 2.5 fee tokens, and a 200-token transfer costs the same 2.5. A mint of 100 tokens charges the account that receives the mint, even when the issuer submits it. A redemption is charged at the burn fee.

In the second generation, a booked movement such as an AUM fee mint is not charged. On Canton, the fee is a flat amount in a different instrument, charged to the sender on top of the transfer from funding the sender presents. It applies to transfers only and has no freeze. See Fee administration for the neighboring fee screens.

Fixed treasury yieldCopy Anchor Link

Pays a fixed coupon for each period, on the balance a holder owns at the end of that period, from a treasury. The schedule runs from a start date to an end date and is cut into periods of one interval each. For each completed period, the holder's coupon is the balance at the period end, multiplied by the basis per unit, multiplied by the rate, divided by 10,000. The holder who owns the tokens at the period end gets the whole coupon, whatever they held earlier in the period. Transfers carry no accrual. Holders pull with a claim that settles every completed period, at most 104 periods in one call. The feature has no pause. The DALP Library includes it on eight templates, among them Corporate Bond, Green Bond, Sovereign Bond, and Certificate of Deposit.

The Console's issuance form and its "Set yield schedule" action for this feature take the rate per year. An asset on the older standalone yield schedule still takes its rate per period in that schedule's sheet. DALP converts it to the rate paid each period, the annual rate times the interval's share of a 365-day year, rounded to the nearest whole basis point. 500 basis points a year paid every semi-annual (180-day) period pays 247 basis points each period. When rounding would move the yearly yield by more than 1%, or leave nothing to pay, the Console refuses the rate and names the nearest annual rate the interval pays accurately. 500 basis points a year cannot be paid daily, because a day carries 1.37 basis points, and 368 is the nearest annual rate that can. The Platform API converts the same way when the request sets rateBasis to annual. Without it, the API pays rate every period unchanged. The DALP Library's fixed-income templates pre-fill a semi-annual, quarterly, or yearly interval, and Corporate Bond pre-fills 500 basis points a year. Yearly means 365 days.

When the span is not a whole number of intervals, the last period is shorter, and the contract pays it the rate prorated to its length. A semi-annual schedule over 365 days has three periods, of 180, 180, and 5 days. At 500 basis points a year, each 180-day period pays 247 basis points and the 5-day period pays 5/180 of that, 6.9 basis points, so the year pays 500.9 in total. A rate the Platform API sends per period, without rateBasis set to annual, is prorated in the short period the same way. A feature attached before DALP prorated the short period keeps paying it the full rate. A claim that needs more than 104 periods takes several calls. A shared budget caps each period at the yield on the total supply at its end. A holder's coupon is capped by what the other holders' claims left, and an empty budget advances the holder's position with a zero payout. A claim with nothing to pay reverts with NoYieldAvailable (DALP-4243).

After issuance, governance sets the treasury, which is the only setting that changes. Anyone can fund the treasury, and a holder claims. The treasury wallet itself approves the allowance. The Console's "Set yield schedule" action attaches the feature to an asset that has none, with its first schedule. Changing the rate, the dates, or the interval needs a detach and a new attach, which starts a new schedule. A token that has the feature needs historical balances too. The contract requires it and attaching reverts without it (DALP-1071), but the template's Features step does not enforce it.

A holder owns 10 tokens at the end of a period. The basis per unit is 1,000.00 of a 6-decimal denomination asset, and the annual rate is 500 over a 360-day schedule of two semi-annual periods, so each period pays 247 basis points. The notional is 10,000.00 and the coupon is 247.00 for each 180-day period, which is 5.01% a year after rounding to whole basis points.

The second generation adds a write-once authorized consumer for the conversion integration and an account exclusion list of at most eight accounts. Neither has a Console or API entry. The Console shows no generation badge. On Canton, the admin opens a distribution for each period against an attested balance snapshot, and the payout moves from the treasury account's holdings. See Yield and maturity for the screens.

Historical balancesCopy Anchor Link

Records every account's balance and the total supply after each mint, burn, or transfer, so any past time can be queried. The token calls the feature once for each operation with the legs that executed. The feature sums each account's net change and writes one checkpoint per touched account, plus one for total supply when it changed. Checkpoints are keyed by timestamp, and several writes in one block keep the last. balanceOfAt and totalSupplyAt return the latest checkpoint at or before the time you ask for, and a future time is rejected. Dividend yield, interest yield, and the distribution waterfall read it for record-date balances, and fixed treasury yield needs it too. Choose it on any token that pays dividends or interest. The DALP Library includes it on all 33 system templates. Ledger Data explains why a point-in-time record matters.

The feature has no parameters and no role after issuance. It cannot be detached while dividend yield, interest yield, or the distribution waterfall is attached. The attach API does not offer it, so it arrives through a template.

The feature records the time it started. A token has 1,000 units on day 0, and the feature starts on day 10. The standard totalSupplyAt query for day 5 returns 0, because no checkpoint exists at or before day 5. The strict variant rejects the same query with QueryBeforeEnabled. A query for day 12 with no activity since returns 1,000.

While the feature is detached it records nothing, so a lookup for that period returns the last checkpoint written before the detach. Fixed treasury yield does not declare the dependency in the platform registry, so the platform does not block detaching historical balances while a yield schedule runs. Do not detach it from a token that has one. On Canton, an admin writes balance snapshots and attests lookups on request. Total supply history is not available.

HoldCopy Anchor Link

Lets an authorized venue reserve units in the holder's wallet without moving them. The units stay where they are, but the holder can no longer spend them: a transfer or burn above the available balance is rejected with AmountExceedsAvailable. The available balance is the balance, less the units the custodian froze, less the units held. Releasing a hold is not a transfer and leaves no trace. A venue can also deliver reserved units to a recipient through the token's full compliance path. Each reserver touches only its own reservations. A hold can have a lifetime in seconds or never expire, and an expired hold stops counting at once. Choose it for any token that trades on a venue. The DALP Library includes it on 31 templates, all except Controlling Class Share and Economic Class Share, and it comes first in their feature list.

The feature has no attach parameters. It starts with an empty reserver list and does nothing until governance authorizes a venue.

After issuance, an account with the governance role authorizes and removes venues, at most 32 at a time. The Console action is "Authorize a venue", and it always sets the hold to never expire. The Platform API accepts a lifetime. Removing a venue makes all its reservations stop counting at once. Anyone can clear an expired hold. A forced custody update, such as a custodian forced transfer, passes the check by design, and mints never touch held units.

A holder has 1,000 units. The custodian froze 100, and a venue holds 300. The available balance is 600, so a transfer of 700 reverts with AmountExceedsAvailable, and so does a new reservation of 700. A custodian forced transfer of 700 succeeds and can leave the holder below the held total, and the available balance then reads 0.

The feature belongs first in the token's list, so a fee or rewrite feature cannot consume units that the hold already committed. The DALP Library puts it first, and a feature attached later goes to the end of the list. The Console can attach it with "Attach the hold feature". It runs on EVM only. Trading Venue explains who holds assets while an order is working, and Venue operations covers the screens.

Interest yieldCopy Anchor Link

Pays simple interest on holder balances, from a treasury. The interest does not compound. A global index grows with the rate and with elapsed time, and each holder's interest is the balance times the growth of the index since the holder's last settlement. The feature settles a holder at every balance change, so the holder who held the balance during the interval receives it, and a transfer moves the accrual with the balance. Holders pull with a claim that pays the whole accrued amount. The feature never holds the money, and it requires historical balances. The DALP Library includes it on two templates, Money Market Fund and Syndicated Loan.

After issuance, an account with the governance role updates the rate, from 1 to 20,000 on the Console sheet "Update interest rate". Interest accrued so far settles at the old rate first. The treasury, the denomination asset, the start date, and the accrual model are fixed. A holder claims, and anyone can fund the treasury. An emergency pause stops accrual, claims, and rate changes, and the Console has no control for it. A conversion that includes interest reads and closes accrual through this feature.

A holder owns 1,000 tokens at a 5% yearly rate, in a 6-decimal denomination asset. Over 30 days with the continuous model, the interest is 4.109589. With ACT/360 over 30 completed days, it is 4.166666. Over 365 days, the continuous model pays exactly 50.000000 and ACT/360 pays 50.694444, because 365 days count against a 360-day year. On Canton, the admin opens a distribution for each period and holders claim against an attested balance snapshot, with the amount minted in the instrument.

Maturity redemptionCopy Anchor Link

Redeems tokens at face value after maturity. Before maturity nothing changes for transfers. Governance matures the token at or after the maturity date, and the treasury must then hold face value times the supply, or the call is rejected. The emergency role can mature it earlier, strictly before the date, with no funding check, so redemptions can open on an underfunded treasury and run first come, first served. Neither path can be undone. After maturity, every mint reverts with TransferBlockedAfterMaturity (DALP-1092), even a custodian-forced mint or a fee mint, and regular transfers revert the same way. Burns pass, and so do custodian forced transfers. Each holder then redeems on their own: the feature burns the holder's tokens and pays face value on the amount actually burned. Corporate Action explains why maturity is a one-way door. The DALP Library includes it on 13 templates, among them Corporate Bond, Green Bond, Sovereign Bond, Commercial Paper, and Treasury Bill.

After issuance, governance matures the token and sets the treasury, which can change only before maturity. The emergency role matures it early. Anyone can fund the treasury, and the treasury wallet itself approves the allowance. A holder with an available balance redeems. The maturity date, the denomination asset, and the face value are fixed. Redemption can be partial and repeated, and total payouts are capped at face value times the supply recorded at maturity. A transaction fee with a burn fee reduces the payout to the net burned amount. See Yield and maturity for the screens.

A holder redeems 2.5 tokens, with a face value of 1,000.00 per token in a 6-decimal asset, and receives 2,500.00. Before the token can mature, a supply of 1,000,000 tokens needs 1,000,000,000.00 in the treasury. When an early maturity opens an underfunded treasury, a redemption that needs more than the balance reverts with InsufficientTreasuryBalance and the burn rolls back. On Canton, redemption burns whole holdings the holder lists, and the post-maturity transfer block is not part of the feature: a compliance module must enforce it.

PermitCopy Anchor Link

Lets a holder approve a spender with an off-chain signature instead of an approve transaction, following EIP-2612. Anyone can submit the signed permit. The feature checks the deadline, consumes the owner's nonce first, verifies the signature, and sets the allowance on the token. The standard form accepts signatures from ordinary wallets. A second form checks signatures through EIP-1271, so a smart wallet can sign. The signature is bound to the token's name at deployment. A second submission of the same signature fails, because the nonce has moved. The feature restricts no token operation. Choose it when a spender, such as an exchange or a payment contract, should not need a separate approve transaction. The DALP Library includes it on 31 templates, all except Controlling Class Share and Carbon Credit.

The feature has no parameters. On the platform, a holder's wallet signs a permit through the Platform API, and an account with the custodian role relays it. After issuance, governance attaches and detaches it, and the Console offers detach only, behind a typed confirmation. It cannot be rotated. Detaching it resets the nonces, and unsubmitted permits stop working. A permit with a passed deadline is rejected with ERC2612ExpiredSignature. It runs on EVM only. Smart Wallet covers the signing side.

Transaction feeCopy Anchor Link

Takes a fee as a percentage of each mint, burn, or transfer and splits the operation into a net leg and a fee leg to the recipient. The percentage applies to the amount, rounded down, and the amount the user asked to move is always the total. A transfer of V sends V less the fee to the receiver, and the fee from the sender to the recipient. A mint of V mints V less the fee to the target and the fee to the recipient. A burn of V sends the fee from the holder to the recipient and burns the rest. The fee is not dilutive: supply changes only by the mint or burn the user asked for. No fee applies to a zero-value operation, to an operation that involves the fee recipient, to a custodian forced update, to a fee that rounds down to zero, or to a booked movement such as an AUM fee mint. With a rate of 10,000 basis points, the whole amount goes to the recipient. The DALP Library includes it on one template, Mutual Fund.

After issuance, an account with the governance role sets all three rates together, sets the recipient, and freezes the rates. A freeze locks the rates only and cannot be undone. Setting the recipient still works after a freeze, and the change applies to the next operation. The fee leg runs the full pipeline, so an ineligible recipient blocks the whole operation, not only its fee. Fee administration covers the screens.

A transfer of 100 tokens with a 250 basis point fee gives the receiver 97.5 and the recipient 2.5, and the sender pays 100. A mint of 100 at 100 basis points gives the target 99 and the recipient 1, and supply rises by 100. A burn of 100 at 100 basis points costs the holder 100, pays the recipient 1, and lowers supply by 99. Rounding favors the holder: 33.333333 tokens at 150 basis points on a 6-decimal token is 33,333,333 base units, the fee is 499,999, and the net is 32,833,334. An amount of 99 base units at 100 basis points has a fee of 0 and passes through unsplit.

In the second generation, a forced or booked movement emits no fee event. The first generation emitted an event even though it took no fee. Transaction fee cannot sit beside transaction fee accounting. On Canton, the schedule has a percentage and an optional flat part, applies to transfers only, and the receiver gets the net.

Transaction fee accountingCopy Anchor Link

Applies the same percentage math as the transaction fee and records the result without collecting anything. On each mint, burn, or transfer, it computes the fee on the gross amount, adds it to a running total, and emits a fee event. Balances, supply, and transfers are untouched, and the recipient receives nothing on chain. Use it for off-chain invoicing and reporting. The DALP Library includes it on two templates, ETF and Asset-Backed Token. It cannot sit beside the transaction fee, because the two would account for the same transfer.

After issuance, an account with the governance role sets the rates and the recipient, freezes both, sets a per-account fee exemption, and reconciles. Reconcile reads the running total, sets it to zero, and emits a record. It moves no tokens and distributes nothing, because the actual collection happens off chain. A second reconcile with a zero total is rejected with NoFeesToReconcile (DALP-1070). Reconcile and the exemption work after a freeze. An exempt account is skipped when it is on either side of an operation. The exemption exists in this feature only. A redemption accrues once at the burn rate.

A transfer of 100 tokens at 250 basis points records a fee of 2.5, and the receiver still gets all 100. After a reconcile of 1, the total reads 0, and no balance changes. The second generation skips booked movements, so an AUM fee mint no longer inflates the total. On Canton, the matching template is a running total of fees that actually settled, with no tracking-only mode, no reconcile, and no exemption.

Voting powerCopy Anchor Link

Turns balances into voting units with their own checkpoints. A holder's units equal the balance, but the units carry weight only for the address the holder delegates to. A holder who has not delegated has no votes. The Console action "Activate voting power" delegates to the holder's own wallet. On every mint, burn, and transfer, the feature moves units between delegates and writes checkpoints, so getPastVotes and getPastTotalSupply answer for a past time. Delegation moves weight, not tokens. The token's governance addon reads the feature as its source of vote weight. The DALP Library includes it on eight templates: Commercial Real Estate, Common Equity, Convertible Target Equity, Economic Class Share, Employee Equity Award, Mutual Fund, Private Equity Fund, and Tokenized Art.

The feature has no parameters. After issuance, a holder delegates, or delegates by signature. The Platform API requires the delegating wallet to have an activated identity registration. Governance attaches, detaches, and rotates the feature, and the Governance wizard offers an inline attach when the token lacks it. A detach or rotate is blocked while the token's governor has pending, active, or queued proposals.

Alice holds 600 tokens and Bob holds 400. Alice has activated her voting power, and Bob has not. A vote with record date T reads 600 votes for Alice and 0 for Bob. The total supply at T is 1,000, so the delegated weight is 600 of 1,000. If Bob delegates after T, his weight counts only for votes with a later record date. On Canton, a holder attests the balance snapshot for a vote window, and delegation is not available. See Governance for the screens.

When an operation is rejectedCopy Anchor Link

A rejection comes from one of three places: the template, the attach and detach API, or the token itself while it runs. A rejection reflects the rule and the state at that moment, so repeating the same call fails again until the condition changes.

The template's "Features" step blocks a feature that misses a dependency or conflicts with another one. Publishing checks both again, and issuing a token with the conflicting pair is rejected with DALP-0605.

An attach, detach, or rotate through the Platform API can be rejected for these reasons.

At run time, a token or a feature reverts with an error that names the rule. These are the ones you meet most often.

TroubleshootingCopy Anchor Link

A feature card says Select X first or Conflicts with X

The Features step shows "Select Historical Balances first." when a feature needs another one, and "Conflicts with Transaction Fee Accounting." for the one conflicting pair. Enable the named feature first. Turning a feature off also turns off every feature that depends on it, so the confirmation can remove more than the card you clicked.

A template shows Prerequisite setup needed

Seven features need a token that already exists in the tenant: external transaction fee, maturity redemption, fixed treasury yield, dividend yield, interest yield, the distribution waterfall, and conversion. Any token satisfies the check, and conversion also needs a target token that has the conversion minter. Open the template's detail panel and create a token, or register an existing one for a payment or fee token, then return to Issue new asset.

A coupon pays more than expected

The contract pays its stored rate once for each payment period. A schedule created through the Platform API without rateBasis set to annual stores the rate as given, so 500 basis points with a daily interval pays 5% of face value every day. Also check the schedule length: with a per-period rate, a span that is not a whole number of intervals ends with a shorter period that still pays a full coupon. Fix the rate and the dates by detaching the feature and attaching a new schedule.

A transfer fails after maturity

After maturity every mint and every regular transfer reverts with TransferBlockedAfterMaturity, and nothing reverses maturity. Burns pass, so holders redeem. A custodian can still run a forced transfer. The fix is to redeem, not to retry the transfer.

A transfer fails on held units

A venue has reserved some of the holder's units, so the transfer is above the available balance and reverts with AmountExceedsAvailable. Units the custodian froze count the same way. Cancel the resting order on the venue to release the hold, or transfer no more than the available balance.

A waterfall class receives nothing

Check four causes. First, distinct ordinary ranks are winner-take-all, so a class at a higher rank gets nothing in ordinary mode. Second, the pool may not reach the class: the preview shows "Not reached". Third, a class with a leg but no supply on the record date, or a per-share rate that rounds to zero, gets no dividend, and its leg stays in the waterfall. Fourth, fund reverts with ClassNotBound until every class has a token.

An operation reverts on the fee token's allowance

An external transaction fee pulls the fee from the payer with an ERC-20 transfer, so the payer needs fee-token balance and an allowance for the feature contract. The payer is the account that receives a mint, or the sender of a transfer or a burn. The fee recipient is not exempt, so it needs the allowance when it pays.

A detached feature leaves a gap in its history

Historical balances records nothing while it is detached. A lookup for that period returns the last checkpoint written before the detach, so a dividend with a record date in the gap reads stale balances. The platform blocks the detach while dividend yield, interest yield, or the distribution waterfall is attached. Fixed treasury yield also needs the feature, but the platform does not list that dependency, so do not detach historical balances from a token that has a yield schedule.

Frequently asked questionsCopy Anchor Link