# Income features

Source: https://docs.settlemint.com/docs/concepts/modeling-assets/token-features/income
Reference for the token features that pay holders: dividend yield, interest yield, fixed treasury yield, maturity redemption and the distribution waterfall.

Four token features pay holders income or principal from a treasury, and a fifth, the distribution waterfall, splits one pool across share classes. Dividend yield pays an amount per share that the issuer declares, interest yield accrues a rate over time, fixed treasury yield pays a fixed coupon each period, and maturity redemption pays face value once after maturity. The distribution waterfall decides no per-holder amount: it splits one pool across share classes, and each class's dividend yield pays from its own part.

A [token feature](https://docs.settlemint.com/docs/concepts/modeling-assets/token-features) is a module attached to one token. An account with the token's governance role attaches, detaches and configures it after issuance where the feature allows it, and each entry names any other role an action needs. The DALP Library is the catalogue of [instrument templates](https://docs.settlemint.com/docs/concepts/modeling-assets/instrument-templates) that ship with the platform, and each entry says which of them include the feature.

## Dividend yield [#dividend-yield]

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](https://docs.settlemint.com/docs/concepts/modeling-assets/token-features/balances-and-holds#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.

| Parameter | Description |
| --- | --- |
| Dividend denomination asset | The [denomination asset](https://docs.settlemint.com/docs/concepts/modeling-assets/denomination-asset) that pays dividends. It cannot be the token itself or a registered fee-on-transfer or rebasing token. |
| Dividend treasury | The account that pays holders, or the distribution waterfall for a share-class instrument. A wallet treasury must approve the feature to spend. A vault contract pays itself. |
| Default claim deadline (days) | How many days holders have to claim when a declaration names no deadline, counted from the payment date, or from the declaration if that is later. At least 1. The default is 90. |

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. A retry within the 24-hour idempotency window returns the first declaration and does not extend that window. While the first submission is still in flight, the retry joins it without a second eligibility check. If the first submission failed before signing, the retry runs the full eligibility check again and 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 or with `POST /api/v2/tokens/{assetId}/features/dividend-yield/dividends/{dividendId}/top-ups`. The Console shows Fund dividend only to the governance role. A holder with a verified identity claims, or an account with the custodian role claims on a holder's behalf, and either way the payout goes to the holder's wallet. An account with the emergency role pauses and resumes claims from the "Claims" row on the token's Features tab. The claim deadline is soft: a holder can still claim after it until governance reclaims the dividend. Once the deadline has passed, the Console marks the dividend Expired and offers the reclaim to the governance role as "Release unclaimed". The Platform API offers it as `POST /api/v2/tokens/{assetId}/features/dividend-yield/dividends/{dividendId}/reclaim`. A reclaim closes the dividend and releases the feature's liability, after which the row reads Released. It moves no tokens, because the treasury never lost them. Governance can also extend a payable dividend's claim deadline once, by an on-chain call that neither the Console nor the Platform API offers. [Corporate Action](https://docs.settlemint.com/docs/concepts/issuing-and-markets/corporate-action) explains why a snapshot cannot be replaced, and [Corporate actions](https://docs.settlemint.com/docs/console/asset-management/manage/corporate-actions) covers the screens.

For example, 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.

## Interest yield [#interest-yield]

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. Each settlement rounds the interest down to the smallest unit of the denomination asset and carries the fraction to the holder's next settlement, so how often a holder is settled does not change what the holder earns. Holders pull with a claim that pays the whole accrued amount. The feature never holds the money, and it requires [historical balances](https://docs.settlemint.com/docs/concepts/modeling-assets/token-features/balances-and-holds#historical-balances). The DALP Library includes it on two templates, Money Market Fund and Syndicated Loan. A wallet that identity recovery marked lost cannot claim. The Platform API pays what it is owed to its replacement wallet through the token's `recovered-wallet-claims` route.

| Parameter | Description |
| --- | --- |
| Interest denomination asset | The token that pays interest. It cannot be the token itself or a registered fee-on-transfer or rebasing token. |
| Interest treasury | The account that pays holders. |
| Annual interest rate (BPS) | The yearly rate in basis points, 1 to 20,000. 100 basis points equal 1%. |
| Interest start date | When accrual starts. Zero means now. It must be now or in the past. |
| Accrual model | "Continuous" accrues each second over a 365-day year. "ACT/360 daily snapshot" credits each completed UTC day on a 360-day year, and the start date must then be an exact UTC midnight. |

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 with a wallet verification and no role on the token. Funding from an account other than the treasury transfers the denomination asset to the treasury. When the treasury itself signs, funding raises the treasury's allowance to the feature by the amount instead, because the treasury already holds the asset. An account with the emergency role pauses and resumes the feature from the "Accrual" row on the token's Features tab. A pause stops accrual, claims, and rate changes. Governance excludes an account from accrual and includes it again from the "Excluded from accrual" list on the same tab. A conversion that includes interest reads and closes accrual through this feature.

For example, 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.

## Fixed treasury yield [#fixed-treasury-yield]

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. A period becomes claimable in the first second after its end time, not in the block at the end time itself. 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 nine templates, among them Corporate Bond, Green Bond, Sovereign Bond, and Certificate of Deposit. A wallet that identity recovery marked lost cannot claim. The Platform API pays what it is owed to its replacement wallet through the token's `recovered-wallet-claims` route.

| Parameter | Description |
| --- | --- |
| Yield denomination asset | The token that pays the coupon. |
| Basis per unit | The face value of one whole token in the denomination asset. The issuance form takes a decimal. The "Set yield schedule" sheet and the Platform API take base units. |
| Yield treasury | The account that pays holders. A wallet treasury must approve the feature to spend. |
| Yield start date | When the schedule starts. It must be in the future at creation. |
| Yield end date | When the schedule ends. It must be after the start date. Issuance and an attach both refuse an end date after the maturity date of the token's maturity redemption. |
| Annual yield rate (BPS) | The yield per year in basis points, which DALP converts to the rate paid each period. 1 to 20,000, at issuance and when the feature is attached afterward. |
| Payment interval | Hourly, daily, weekly, monthly (30 days), quarterly (90 days), semi-annual (180 days), or yearly. |

The Console's issuance form and its "Set yield schedule" action for this feature take the rate per year. An asset on the standalone yield schedule 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, and the EVM contract keeps the fraction. A feature attached before DALP kept the fraction keeps paying whole basis points. 500 basis points a year paid every semi-annual (180-day) period pays 246.575 basis points each period, and paid daily it pays 1.37 basis points each day. Within those limits, the Console refuses a rate only when the schedule cannot pay it: the end date must be after the start date, and the interval and the rate must be positive. The Platform API converts the same way when the request sets `rateBasis` to `annual`. A request that leaves `rateBasis` out takes the basis its template states, and the DALP Library's fixed-income templates state `annual`. When neither the request nor the template states one, 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 246.575 basis points and the 5-day period pays 5/180 of that, 6.85 basis points, so the year pays 500 in total. A per-period rate sent through the Platform API 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](https://docs.settlemint.com/docs/api-reference/errors)).

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 Platform API refuses, before anything is queued, a top-up from a wallet that holds less of the denomination asset than the amount ([DALP-14501](https://docs.settlemint.com/docs/api-reference/errors)) and a top-up from the treasury's own wallet, whose transfer to itself cannot change what the treasury covers ([DALP-14502](https://docs.settlemint.com/docs/api-reference/errors)). That wallet approves the allowance instead. It also refuses a claim the treasury cannot pay: its balance, or for a wallet treasury its allowance to the feature, is below what the holder is owed ([DALP-14503](https://docs.settlemint.com/docs/api-reference/errors)). The refusal names the amount owed and the treasury, not the treasury's balance. When the organisation does not share redemption funding with holders and the caller does not manage the token, the refusal names neither. When more than 104 periods are owed, so one claim settles only part of them, or the index has not priced the owed periods yet, the API refuses the claim only if the treasury cannot pay any of it, and the refusal names no amount. 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](https://docs.settlemint.com/docs/api-reference/errors)). Select historical balances before fixed treasury yield in the template's Features step.

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 246.575 basis points. The notional is 10,000.00 and the coupon is about 246.58 for each 180-day period, which scales to 5.00% over a 365-day year.

The second generation adds a write-once authorised consumer for the conversion integration and an account exclusion list of at most eight accounts. The consumer has no Console or API entry. Governance excludes and includes accounts from the "Excluded from accrual" list on the Features tab, which shows how many of the eight slots are used. An account included again keeps its slot. The Console shows no generation badge. See [Yield and maturity](https://docs.settlemint.com/docs/console/asset-management/manage/yield-maturity) for the screens.

## Maturity redemption [#maturity-redemption]

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 resets the matured state, and the post-maturity block lasts while the feature stays attached. After maturity, every mint reverts with `TransferBlockedAfterMaturity` ([DALP-1092](https://docs.settlemint.com/docs/api-reference/errors)), 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, or an account with the custodian role redeems on a holder's behalf. Either way the feature burns that holder's tokens and pays face value on the amount burned to the holder's wallet. [Corporate Action](https://docs.settlemint.com/docs/concepts/issuing-and-markets/corporate-action) explains why maturity cannot be undone. The DALP Library includes it on 14 templates, among them Corporate Bond, Green Bond, Sovereign Bond, Commercial Paper, and Treasury Bill.

| Parameter | Description |
| --- | --- |
| Maturity date | When the token can mature. It must be in the future. |
| Denomination asset | The token that pays the redemption. It cannot be the token itself. |
| Face value | The payout for one whole token in the denomination asset. The issuance form takes a decimal and scales it by the asset's decimals. It must be greater than 0: the form refuses 0, and the Platform API answers 0 with `TOKEN_CREATE_FEATURE_CONFIG_INVALID` before anything is signed. |
| Redemption treasury | The account that pays redemptions. A wallet treasury must approve the feature to spend. |

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. The Platform API refuses a top-up from a wallet that holds less of the denomination asset than the amount ([DALP-14504](https://docs.settlemint.com/docs/api-reference/errors)) and a top-up from the treasury's own wallet ([DALP-14505](https://docs.settlemint.com/docs/api-reference/errors)). Before anything is queued, it refuses a redemption that a wallet treasury's allowance cannot pay ([DALP-9481](https://docs.settlemint.com/docs/api-reference/errors)) or that the treasury's balance cannot pay ([DALP-14506](https://docs.settlemint.com/docs/api-reference/errors)). Each refusal names the treasury, the amount the redemption needs, and the treasury's allowance or balance. When the organisation does not share redemption funding with holders and the caller neither manages the token nor is its treasury, both answer as not available right now ([DALP-12373](https://docs.settlemint.com/docs/api-reference/errors)) without the treasury's figures. A holder with an available balance redeems, and an account with the custodian role can redeem on a holder's behalf, for up to 100 holders in one call. 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. A token with this feature is valued from its face value times the price of its denomination asset and carries no price feed of its own: a template that requires the feature creates the token without one, and attaching the feature later removes the token's own feed after the attach is queued. See [Yield and maturity](https://docs.settlemint.com/docs/console/asset-management/manage/yield-maturity) for the screens.

For example, 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.

## Distribution waterfall [#distribution-waterfall]

A share-class instrument pays several classes from one cash pool. The waterfall decides how much each class's leg gets, by rank, and each class's dividend yield pays holders from its own leg. Each class's dividend yield uses the waterfall as its treasury, so it can draw only its own leg. The waterfall attaches to the controlling class token. It holds the cash and keeps, for each distribution, what each class's leg still holds, and for each class how much capital it 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 into legs and binds each class's dividend to its leg. Money leaves through two functions. A class's dividend yield calls `payoutFor`, with the dividend's number, when a holder claims. `release` returns what a closed leg still holds to the wallet that funded it. A class's leg is 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](https://docs.settlemint.com/docs/concepts/issuing-and-markets/corporate-action#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, the template pair that issues a controlling and an economic class. It runs on EVM only.

The Console shows each parameter under its name and a sentence on what to enter, for example "Contribution basis", the capital the class paid in. The structure editor on the instrument structures tab uses the same names when it links one class's field to another.

| Parameter | Description |
| --- | --- |
| `denominationAsset` | The token the pool is paid in. Every class's dividend yield must use the same asset. |
| `ownClass` | The class row that belongs to the token holding the waterfall. |
| `classTerms` | One row for each share class, 2 to 8 rows. |
| `classTerms` `role` | A unique name for the class, such as `controlling` or `economic`. |
| `classTerms` `token` | The class token. A class that does not exist yet is bound during issuance. Its dividend yield must use the waterfall as its treasury. |
| `classTerms` `contributionBasis` | The capital the class paid in. Enter a decimal in the payment asset, above zero. The platform scales it by that asset's decimals, not by 18. |
| `classTerms` `ordinaryRank` | 1 to 255. In ordinary mode, the lowest rank is paid first. |
| `priorities` | Zero to 64 rows. Each row ranks the classes for one kind of event. |
| `priorities` `determinationKind` | A text label for the event, such as `sponsor-event`. It must be unique and must match the claim's text exactly, including case. |
| `priorities` `ranks` | One tier for each class, 1 to 255. Tier 1 recovers capital first. Every class needs a tier in every row. |

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 its tiers. The class and row terms cannot change after the waterfall is deployed, because no function edits a class or a row. Two settings per class and priority row can change, each until the first distribution is funded under that row. An account with the governance role turns netting on or off with `setDistributionNetting`, and sets a wind-down premium with `setDistributionPremium`: an amount in the payment asset that the class is owed once under that row, on top of its capital. The premium is an on-chain call only. The Console and the Platform API do not offer it. The distribution waterfall card on the token page shows the netting setting of each class under each priority row and whether the row is locked, and a governance account changes it there or through the Platform API (`v2/token/setDistributionNetting`). A waterfall that was upgraded after distributions were funded can fold those distributions into its running totals with `syncAllocations`, from the same card or through `v2/token/syncAllocations`. Any account can run it, and it changes no split.

After issuance, an account with the governance role funds a distribution through a coordinated distribution, which also needs [maker-checker](https://docs.settlemint.com/docs/concepts/custody-and-signing/maker-checker) approval while the Corporate actions row under Approvals in the organisation settings is on. The issuance run binds each class to its token, and `fund` is rejected until every class is bound. A class left unbound can be bound afterward only by an on-chain `bindClass` call from the governance role. The Console and the Platform API do not offer it. 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, and then any premium set for the class under that row. With netting on for the row and the class, a class's unreturned capital 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 what each class is still owed in capital and premium, and each class's share pays its capital before its premium. 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 the leg its dividend was bound to when the distribution was funded, so one distribution never spends another distribution's unclaimed money. The waterfall rejects a caller that is not that class's current dividend yield (`UnauthorizedClass`), a dividend that no funded distribution bound (`UnboundDividend`), a payout above the leg (`InsufficientAllocation`), a payout in another asset (`PayoutAssetMismatch`), and a plain `payout` call that names no dividend (`ReferenceRequired`).

An account with the governance role releases a leg back to the funding wallet once the leg is closed: it has no dividend, its dividend was cancelled, or its dividend is paid, including after governance reclaimed the unclaimed rest. A leg is released once, an empty leg is refused, and every release is refused while the waterfall holds less than it owes across all distributions. A leg whose dividend was never declared, or was cancelled, also gives back the capital it counted as returned. The Console offers Release in the Class money panel of a coordinated distribution's record, and the Platform API offers the same operation on the corporate action's leg.

In this example, 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.

| Case | Pool | Controlling | Economic | How it works out |
| --- | --- | --- | --- | --- |
| Ordinary | 10,000,000 | 9,000,000 | 1,000,000 | Equal ranks, so the pool splits 9:1 by contribution basis. |
| Priority, shortfall | 8,000,000 | 7,000,000 | 1,000,000 | Economic recovers its 1,000,000 first. Controlling takes the remaining 7,000,000. |
| Priority, upside | 12,000,000 | 10,800,000 | 1,200,000 | Capital of 1,000,000 and 9,000,000 comes first. The residual 2,000,000 splits 9:1. |
| Second priority after the shortfall | 5,000,000 | 4,700,000 | 300,000 | A later pool: economic has its 1,000,000 back, and controlling is still due 2,000,000 of its 9,000,000. That 2,000,000 comes first, and the residual 3,000,000 splits 9:1. |

Netting changes what a class is due. Take two classes with a basis of 350,000,000 each and equal ordinary ranks. 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.

[Figure] Priority mode fills capital buckets in tier order, then splits the residual. A pool of 12,000,000 enters priority mode. Tier 1 is the economic class's capital of 1,000,000, and it fills first. Tier 2 is the controlling class's capital of 9,000,000, and it fills next. The residual of 2,000,000 follows the ordinary rule and splits 9 to 1 by contribution basis. The result is 10,800,000 for the controlling class and 1,200,000 for the economic class. With a pool of 8,000,000 the pool runs out inside tier 2, and the controlling class receives 7,000,000. Labels: Priority mode, pool of 12,000,000; Pool; 12,000,000; Tier 1; Economic capital; 1,000,000; Tier 2; Controlling capital; 9,000,000; Residual; 2,000,000; Ordinary rule, 9:1; Legs: controlling 10,800,000, economic 1,200,000; With a pool of 8,000,000 the pool runs out inside tier 2.

Each tier fills before the next one starts, and whatever is left after the last tier follows the ordinary rule.

Three points cause 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 the platform raises no error for it. 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, so any issuer the trusted-issuer registry accepts for that claim can switch a distribution into priority mode.

The runbook is [Corporate actions](https://docs.settlemint.com/docs/console/asset-management/manage/corporate-actions), which covers creating, previewing, approving, and confirming a coordinated distribution.