DALP interest-yield: continuous accrual on token balances

Steps to set the annual rate, fund the treasury, settle holder claims, and pair interest accrual with conversion using the interest-yield token feature.

The interest-yield token feature accrues interest continuously on each holder balance at an annual rate. There is no coupon calendar and nothing to declare. Use it for convertible notes, interest-bearing notes, and any instrument whose return depends on how long a position is held rather than on scheduled payment dates.

For the architecture reference, see Interest yield.

When it attaches

No system template requires this feature today; the convertible-note system template still uses fixed treasury yield. To issue an asset with interest yield, publish a custom template that lists it, together with historical balances, in its required features. Pair it with conversion for a convertible instrument, and give that conversion the Burn or Lock debt method. The platform refuses interest yield beside a MarkConverted conversion, at creation and at attachment: MarkConverted leaves the holder's balance in place, so a balance-derived payout would keep accruing on principal that is no longer active.

What you configure

In the Asset Designer details step, the wizard surfaces:

Parameter	Description
`denominationAsset`	ERC-20 token that interest pays in.
`treasury`	Address every claim draws from. The operator keeps it funded against the growing liability.
`annualRateBps`	Annual rate in basis points. `500` is 5 percent per year. Maximum `20000`.
`startDate`	When accrual begins. It cannot be in the future, and on a token that already has holders it should be the attachment time.

The rate is the only one of these that changes after deployment.

What you operate

After deployment:

Fund the treasury. A top-up transfers the denomination asset from your wallet to the treasury. When the treasury is a wallet, also approve the feature to spend the denomination asset, and raise the approval as the liability grows.
Monitor the accrued liability. The issuer position read reports what is pending as of a stated moment. Because accrual is continuous, monitor it continuously rather than on a payment calendar.
Update the rate when the terms change. The change applies from that moment forward. Interest already earned is committed first, so a rate change never rewrites the past. The rate history read lists the changes. It does not include the rate the feature started with, so pair it with the configured starting rate to cover a window that begins before the first change.
Settle claims. A holder claims their whole accrued amount at any time. The platform settles the holder, then pays from the treasury.

Servicing runs through the Platform API. See Interest yield API for the endpoints behind each step.

Pairing with conversion

On a convertible instrument, interest yield supplies the accrued interest that conversion settles into the target instrument.

Two things must line up. First, the conversion configuration has to opt in: set includeInterestInConversion. The flag is off by default, and with it off a conversion ignores accrued interest entirely. Interest keeps accruing and stays a cash claim, but it is left out of the converted amount. Leave the interest provider field empty when both features are created together; the conversion finds the one attached yield feature by itself, and the field is immutable once set.

Second, the plumbing is automatic. When the template carries both features, asset creation authorises the conversion feature as the interest consumer and, for a conversion that locks principal in an escrow account, excludes that escrow from accrual. That part needs no operator step and none is prompted. It also runs whether or not the opt-in flag is set, so authorised wiring is not proof that interest will be converted.

The consumer authorisation is write-once. It is set from the conversion configuration you supply at creation, so check the escrow address and the conversion settings before you deploy rather than after.
Interest that a conversion consumes is permanently unavailable as cash. The consumption is recorded per holder with the reason the conversion supplied.
Attaching interest yield to a token that already carries conversion does not run this wiring, and the Platform API exposes no route to set the consumer or the escrow exclusion afterwards. Plan both features into the template rather than adding interest yield later.

Operating considerations

The liability grows every second that supply is outstanding and has no natural ceiling. Treat treasury funding as a standing task, not a periodic one.
Accrual is computed on the token balance and paid in the denomination asset. The contract reconciles the precision of the two assets, so a payout is correct even when they differ.
When the two assets have different decimals, do not fund from the reported accrued and pending figures. The position reads scale the settled part correctly but not the part that has accrued since the last settlement, so they misstate the liability in whichever direction the decimals run: too high when the asset token has more decimals, too low when the denomination asset does. Neither reading is safe to treat as conservative. Reconcile against the claim events instead, and treat the reads as indicative.
An emergency pause halts accrual for every holder, not only claims. A long pause reduces the interest earned in that window, and the feature cannot compensate for it afterwards. Rate changes are also blocked while paused.
Excluding an account from accrual forfeits nothing already earned, and including it again grants no interest for the excluded window.
The denomination asset, the treasury, and the start date are fixed at creation. Plan the funding path before the asset goes live.
Removing the feature from the token does not stop accrual. Detaching only takes it out of the token's hook path; the feature keeps its clock and holders can still claim from it directly, while transfers no longer settle anyone.
There is no clean retirement while balances or unclaimed interest remain. Pausing freezes the index but also blocks claims, so it cannot drain the liability, and unpausing to release a residual restarts accrual with the hooks gone. Plan on the feature being permanent for the life of the instrument.
Do not backdate the start date on a token that already has holders. The feature keeps no record of how long each balance was held, so it pays the whole elapsed accrual on whatever balance a holder has at their first settlement. A recent buyer is overpaid and a holder who already sold gets nothing.

Troubleshooting

What you see	What to check
A holder cannot claim	Confirm the accrued amount is above zero and the feature is not paused. A holder whose interest a conversion consumed has nothing left in cash.
Claims fail while the treasury balance looks right	For a wallet treasury, the feature needs an approved allowance. Raise the approval to cover the current accrued liability.
The rate change is rejected	Rate changes are blocked while the feature is paused. Resume first, which restarts accrual, then update the rate.
Interest stopped accruing for one holder	Their accrual is closed, or the account is on the accrual exclusion list. Closing keeps the earned amount claimable but stops new interest.
The consumer authorisation cannot be changed	It is write-once by design and is set during asset creation. There is no public route to change it; the asset keeps the address it was given.
A conversion paid no interest	`includeInterestInConversion` is off. It is a creation-time setting on the conversion configuration. Leaving the interest provider unset is correct and is not a cause; an explicit provider is only for an already-deployed contract.

Interest yield