Interest Yield

Interest Yield lets a DALP asset accrue interest continuously on each holder balance at an annual rate. There is no period calendar and no declaration step. Interest grows with time held, and each holder pulls the accrued amount by claiming it in the denomination asset from a treasury.

The claims and identity model defines identity, claim topics, and trusted issuers. Interest Yield does not decide investor eligibility. It accrues on balances that already exist on the asset.

On configurable tokens, the app and API submit one operator request to create and attach this capability. The setup specifies the denomination asset, the treasury, the annual rate in basis points, and the start date. DALP queues deployment first. When that step settles, DALP attaches the predicted address to the token. The capability appears in token reads after indexing catches up.

Interest Yield is the yield side of a convertible instrument. When the asset also uses Conversion, the accrued interest of a holder can be converted into the target instrument instead of paid as cash.

Operating model

Accrual is continuous and index-based. Every mint, burn, or transfer settles the accounts it touches, which commits the interest earned up to that moment before the balance changes. A rate update or a pause applies from the moment it happens, so past accrual is never repriced.

Distribution is pull-based. The feature calculates the accrued amount, but the holder must submit the claim transaction.

Interface

The rate and the start date are set when the feature is deployed. The start date must not be in the future, so accrual begins at that moment or immediately. On a token that already has holders, start at attachment time; see Change impact for why a backdated start misprices existing positions. Afterwards, governance changes the rate only. The annual rate is expressed in basis points and cannot exceed 20,000 basis points.

The table below lists the runtime capabilities.

The accrued amount of a holder, the annual rate, the rate history, the aggregate accrued liability, and the holder position are available as read-only queries.

Business impact

The issuer keeps the money. The feature never holds the denomination asset. Every claim pays straight from the configured treasury, so the treasury balance is the funding position for the whole accrued liability.

The liability grows every second that supply is held. Unlike a period schedule, there is no interval at which the obligation steps up, so treasury monitoring must be continuous rather than calendar-driven.

Accrual is computed on the token balance and paid in the denomination asset. The contract reconciles the decimals of the two assets, so an asset token and a payment asset with different precision are supported and the payout is correct. The reporting reads do not apply that reconciliation to the part of the accrual that is not yet settled, so on a mixed-decimal asset they misstate the liability in whichever direction the decimals run; reconcile from claim events rather than from the position reads.

A rate change is forward-looking. Interest earned under the old rate is committed before the new rate applies, so a rate update never rewrites what a holder has already earned.

Risks and abuse cases

If the treasury denomination balance falls below the accrued liability, late claimants find the treasury short. The liability has no natural ceiling while supply is outstanding, so monitor it continuously.

When the treasury is a wallet, the feature pulls the payout with an ERC-20 transfer from that wallet. The treasury must approve enough allowance for the feature, or every claim fails while the balance still looks correct. A treasury that implements the vault payout interface uses its own payout path and needs no wallet approval.

A vault treasury moves the access decision into the treasury contract. The feature calls the vault's payout function and the vault decides who may make it call. A custom implementation that does not restrict the caller to the configured yield feature can be drained by anyone who calls it directly, and a funded balance is no evidence that it is safe. The DALPAsset token itself implements the payout interface and rejects any caller that is not a feature registered on it; prefer it, or review the caller check of a custom vault before you enable claims.

The consumer authorization is write-once. An address set by mistake cannot be replaced, and the conversion path of that asset stays bound to it. Verify the address before submitting.

An account excluded from accrual earns nothing while excluded, and re-including it grants no interest for the excluded window. An exclusion applied to the wrong address therefore costs that holder real interest for the period, even though governance can correct the flag afterwards.

A pause stops accrual for every holder. A long pause reduces the interest earned in that window and cannot be compensated by the feature itself.

Controls and guardrails

Deployment input checks

DALP validates the addresses in the feature deployment input before queuing the transactions. The remaining rules below belong to the contract: on token creation the platform applies them too, but a later attachment queues the request and fails at deployment instead. Supply these values in your request:

• denominationAsset must be a non-zero EVM address.
• treasury must be a non-zero EVM address. On token creation, a request that omits it uses the requesting wallet. On a later attachment, it is required.
• annualRateBps must be greater than zero and not more than 20,000 basis points.
• startDate is required on token creation, and it must not be in the future. On a later attachment, omit it so accrual starts at attachment time.
• Historical Balances must be selected in the same feature set.

Failure modes and edge cases

A claim is rejected when the accrued amount is zero, when the feature is paused, or when the schedule is not configured. A holder whose whole accrued amount was consumed by a conversion has nothing left to claim in cash.

A rate update is rejected while the feature is paused. Unpause first, which resumes accrual, then update the rate.

Interest that a conversion consumes is permanently unavailable as cash. The consumption is recorded per holder with the reason supplied by the conversion, which is the audit trail for that decision.

Closing accrual stops future interest for that holder but leaves the already earned amount claimable. Closing is idempotent, so a repeated call is safe.

The conversion provider prices accrued interest for the current block only. A quote for a past or future moment is rejected, because continuous accrual keeps no history that can reprice an earlier boundary.

An accrual exclusion and an accrual close both remove the balance of that account from accrual. The aggregate liability reported between two settlements can lag the live position slightly, and it lags in the conservative direction.

Auditability and operational signals

• InterestYieldFeatureConfigured(token, denominationAsset, treasury, annualRateBps, startTimestamp) is emitted once when the feature is configured.
• ScheduleSet(annualRateBps, startTimestamp, globalIndex) is emitted when accrual starts.
• RateUpdated(oldRate, newRate, globalIndex) is emitted per rate change and is the source for the rate history query. The query carries changes only, so pair it with the configured starting rate from ScheduleSet to cover a window that begins before the first change.
• InterestClaimed(holder, amount, globalIndex) is emitted per claim and is the primary signal for treasury drawdown tracking.
• InterestAccountSettled(account, accrued, userIndex) is emitted when a balance change commits the accrued interest of an account.
• PauseStatusChanged(paused, globalIndex, lastUpdateAt) is emitted on pause and on resume. Off-chain accrual previews must stop at a pause and restart at the resume moment.
• InterestConsumed(holder, amountWad, reason, consumedAt) is emitted when a conversion uses accrued interest instead of cash.
• AccrualClosed(holder, closedAt) is emitted when accrual stops for a holder.
• AuthorizedConsumerSet(consumer) and AccrualExclusionSet(account, excluded) record the two governance settings that change who accrues and who may consume.
• Monitor the aggregate accrued liability against the treasury denomination balance. The issuer statistics query reports the aggregate position, and the holder position query reports what one holder can claim.

Dependencies

Historical Balances is required in the feature set alongside Interest Yield. The platform declares this dependency and rejects a template that selects Interest Yield without it. The requirement is a feature-set rule, not a contract one: unlike Dividend Yield, the interest contract resolves no snapshot provider and accrues from live balances, so Historical Balances is there for the reporting and reconciliation views rather than for the accrual itself.

The denomination asset is the ERC-20 asset paid as interest, such as a stablecoin or another approved payment asset. The treasury is the address that funds every claim. When the treasury is a wallet, it must approve the feature to spend the payout asset. When the treasury implements the vault payout interface, the feature calls that interface instead. The payout mode is resolved once when the feature is configured.

Conversion is optional. When the asset converts, Interest Yield acts as the interest provider for the conversion. The conversion must set includeInterestInConversion; that flag is off by default, and while it is off the conversion settles principal only and accrued interest stays a cash claim. The provider itself needs no naming when the token carries one yield feature, because the conversion discovers it. An explicit provider names an already-deployed contract, and the value is immutable once set.

Two combinations are refused before deployment. A conversion beside both Interest Yield and Fixed Treasury Yield cannot resolve which provider to use. A conversion using the MarkConverted debt method cannot carry either yield feature, because MarkConverted leaves the holder's balance in place and a balance-derived payout would keep accruing on principal that is no longer active. Use the Burn or Lock debt method with Interest Yield.

Compatibility and ordering notes

• supportsRewriting = false. The feature does not rewrite transfers.
• The feature does not restrict mint, burn, transfer, or redeem operations. It settles the accounts a transfer touches so the accrual stays exact across balance changes.
• Place it after any rewriting feature so that settlement sees post-fee balances.
• It is designed to pair with Conversion for convertible instruments. Asset creation authorizes the conversion feature as the consumer and excludes a lock-method escrow account from accrual, so neither is an operator step. Whether interest is actually converted is a separate conversion setting.
• It is incompatible with a Conversion that uses the MarkConverted debt method, and with a Conversion that also carries Fixed Treasury Yield. Both are refused at design time rather than at run time.
• It can run beside Dividend Yield on the same asset. The two liabilities are separate, so plan the treasury funding for the total.

Change impact

Attaching the feature after launch starts accrual from the configured start date. A start date in the future is rejected.

Do not backdate the start date on a token that already has holders. The feature keeps no history of how long each balance was held. It applies the whole elapsed accrual to the balance a holder has when their account is first settled, so a recent buyer is paid interest for a period they did not hold the position, and a holder who sold before attachment is paid nothing. On an existing token, start accrual at attachment time.

The rate is the only schedule value that changes after deployment, and it changes forward only. The denomination asset, the treasury, and the start date are fixed at configuration time.

Removing the feature from the token does not stop accrual. Detaching takes it out of the token's hook path and nothing more: the feature contract keeps its state and its clock, its index keeps advancing with time, and holders can still claim by calling it directly. Worse, transfers no longer settle anyone, so balances that move after detachment are never accounted for and what the feature computes drifts away from what holders actually held.

There is no clean way to retire the feature while holders still have balances or unclaimed interest. Pausing freezes the index, but it also blocks claims, so it cannot be used to drain the liability: interest accrues again between a holder's last claim and the pause, that residual is then unclaimable, and unpausing to release it restarts accrual with the transfer hooks already gone. Detaching settles nothing either way.

Treat the feature as permanent for the life of the instrument. Detaching is only harmless once no balances and no unclaimed interest remain, which is a property of the instrument winding down rather than a shutdown procedure you can run on the feature. Plan the wind-down into the instrument, not into a later detachment.

See also

• Token Features Catalog - return to the full feature catalog and the yield comparison
• Conversion - the convertible instrument pair that consumes accrued interest
• Historical Balances - required dependency
• Dividend Yield - declared distribution alternative
• Fixed Treasury Yield - period-based coupon alternative
• Token lifecycle API operations - endpoint summary for deploying and operating token features