# What is the best way to distribute payouts to tokenized asset holders? Six ways to pay tokenized asset holders compared: bank payout, push, claim, accrual, platform feature, router. The number of holders decides. --- The best way to distribute payouts to tokenized asset holders depends first on how many holders are on the register: a bank payout through a transfer agent or paying agent, an onchain push in batches, a claim contract, accrual inside the token, a distribution feature of the tokenization platform and an onchain payment router all do the job, and each one stops working well at a different register size. The second thing that separates them is who holds the money between the moment the asset earns it and the moment a holder has it. The six methods are compared below on the same nine criteria, then applied to one distribution of $50,000 across a register of seven holders. Rules on distributions of tokenized securities and on the tax treatment of the income vary by country; what follows is general information, not legal or tax advice.
3 unitsleft over after rounding in the worked example, whether the smallest unit is a cent or a millionth of a dollar
2issuer transactions for a claim distribution in the illustration, at 100 holders and at 10,000
20recipients at most on one deal routed through Shaka, which rules a router out for a holder register

Worked example and illustration detailed in the sections below; the 20-recipient limit is Shaka's own.

## Which methods can pay the holders of a tokenized asset? Six families of methods can pay the holders of a tokenized asset: an off-chain payout by bank transfer, an onchain push distribution, an onchain pull or claim distribution, automatic accrual inside the token, a distribution feature built into the tokenization platform, and an onchain payment router for a handful of beneficiaries. They differ in where the money sits before it reaches a holder and in who has to act. An off-chain payout uses the token register only as a list. A transfer agent or a paying agent reads who held what on the record date, then sends bank transfers in ordinary currency. The United States Securities and Exchange Commission describes this role for conventional securities: transfer agents record changes of ownership, maintain the issuer's security holder records and distribute dividends. A push distribution sends a stablecoin from the issuer's wallet to every holder's address, usually through a batching contract that performs many transfers in one transaction. The holder does nothing and sees the money arrive. A pull distribution, also called a claim model, works the other way round. The issuer funds a contract once and publishes each holder's entitlement, either as balances recorded at a snapshot or as a compact fingerprint of the whole list against which each holder presents a proof. Each holder then collects their own share, in their own transaction. Automatic accrual pays nothing out. The income stays in the structure and the token reflects it: either each holder's balance grows (a rebasing token) or the balance stays fixed and each token is worth more (an accumulating share class). The holder receives the return when they redeem or sell. A platform distribution feature is whichever of the mechanisms above the tokenization platform has built into its issuer tools, run against the platform's own register. An onchain payment router splits one incoming payment among a small, fixed list of parties in a single transaction. It suits the proceeds of a sale that go to a few parties, not a distribution to a register. ## How do the six payout methods compare on holders, custody of the money and effort? The six payout methods separate most clearly on three criteria: the number of holders each one suits, who holds the money before it reaches the holders, and what a holder must do to receive it. The table gives the answer for each family. | Method | Number of holders it suits | Who holds the money before holders have it | What a holder must do | | --- | --- | --- | --- | | Bank payout through a transfer agent or paying agent | Any size, where every holder has given bank details | The agent's payment account, then the banking system | Provide and maintain bank details and tax forms | | Onchain push in batches | A few to a few thousand addresses | The issuer's wallet until the batch is sent | Nothing, if the tokens sit in a wallet the holder controls | | Onchain pull or claim | Hundreds to very large registers | The claim contract, until each holder collects | Send one claim transaction per distribution and pay its network fee | | Accrual inside the token | Any size | The fund or vault; no payout is made | Nothing; redeem or sell to realise the return | | Platform distribution feature | Whatever the platform supports | Depends on the mechanism the platform uses | Usually confirm a wallet or a bank account once | | An onchain payment router | Up to the router's recipient limit, typically a handful of parties | Nobody: the payment is split as it arrives | Nothing; a recipient may sign their share beforehand | Under a pull distribution the money is out of the issuer's wallet from the first minute, yet the obligation to each holder is discharged only as claims are made, or as the terms of the offering define it. The issuer's accounts must show that difference. ## Why does a distribution need a record date and a snapshot? A distribution needs a record date because tokens change hands continuously, and the issuer must fix one moment at which the list of people entitled to the payment is read. The payment date comes later and is simply the day the money moves; whoever buys the token between the two dates does not receive that payment. Conventional securities work the same way. The Securities and Exchange Commission's investor guidance puts it in one line: you must be on the company's books as a shareholder on the record date to receive the dividend. For a token, "the books" are balances at a given block, and the snapshot is the technical act of freezing them. The basic token standard does not provide this. ERC-20, as published in the Ethereum Improvement Proposals, defines balances, transfers and approvals; it contains no function for a dividend, a distribution or a historical balance. A token that needs to answer "what did this address hold at block N" must either add a snapshot mechanism to the contract or have the register rebuilt off-chain from the transfer history. OpenZeppelin's contract library documents such an extension and states its purpose plainly: computing dividends from a snapshot prevents the same balance being counted in several accounts, which is what would happen if someone received a payment, moved the tokens to a second address and was read again. A push that reads live balances while its batches are still going out can pay the same tokens twice, or miss them. A claim contract must point at one fixed block for every holder. Even a bank payout needs the cut-off, because the agent's file is prepared before the payment day. Accrual inside the token is the one method with no record date. Since the return is in the value or the balance of the token itself, whoever holds the token holds the accrued income, and a buyer pays for it in the price. | Method | How the record date is fixed | Tokens held in a marketplace or custody contract | Unclaimed amounts | | --- | --- | --- | --- | | Bank payout through a transfer agent or paying agent | The agent extracts the register at the record date | The agent pays the beneficial owner if the operator supplies the list behind its address | Returned transfers are held by the agent under local unclaimed property rules | | Onchain push in batches | Balances read at a snapshot block, then sent to those addresses | The stablecoin lands at the contract address; the operator must pass it on | None in principle, but money sent to a contract that cannot forward it is stuck | | Onchain pull or claim | The snapshot block, or the list fingerprint, written into the claim contract | The contract can collect only if it was built to call the claim | They stay in the contract until a deadline set in the terms | | Accrual inside the token | No record date | The accrual follows the token; a rebasing balance may be misread by a contract that does not expect it | None | | Platform distribution feature | The platform's register at the cut-off it sets | Handled if the marketplace or custodian is integrated with the platform | Follows the platform's terms | | An onchain payment router | Not applicable: the parties and their shares are fixed in the deal | Not applicable: recipients are named parties, not token balances | None: every share is paid in the same transaction | ## What happens to tokens held in a marketplace or custody contract on the record date? Tokens listed on a marketplace, pledged as collateral or kept with a custodian usually sit at an address that belongs to a contract or to an omnibus account, and that address is what the register shows on the record date. The payment therefore goes to the operator's address unless the distribution was designed to look through it. Two situations come up. The first is an omnibus custody account: one address holds the tokens of many clients. Paying that address is correct only if the custodian then allocates the money to its clients from its own books. The issuer needs that arrangement in writing before the first distribution. The second is a marketplace or lending contract with no function to receive and forward a distribution. A stablecoin pushed to it arrives and may stay there, because the contract was written to handle the asset token, not income paid on it. A claim distribution has the mirror problem: the entitlement belongs to the contract's address, and a contract can only claim if its code includes that call. In both cases the depositor is the economic owner and the register says otherwise. The issuer can announce record dates ahead so that holders can withdraw; the snapshot rule can exclude a published list of contract addresses and reallocate their balances to the depositors the operator reports; or the token can be restricted so that it may only move to addresses the platform has approved, which keeps unknown contracts off the register altogether. Accrual inside the token avoids the question for accumulating shares, since value follows the token wherever it sits. A rebasing token is less forgiving: a contract that recorded a deposit of 1,000 tokens and does not expect the balance to change may not credit the growth to the depositor. ## How is each holder's amount rounded, and where does the remainder go? Each holder's amount is the distribution multiplied by the holder's tokens and divided by the tokens outstanding, rounded down to the smallest unit of the payment currency, and the units lost to rounding form a remainder that the terms must assign to someone. Rounding down for everyone is the only rule that can never pay out more than the amount available. The smallest unit is a cent for a bank transfer. For a stablecoin it is set by the token's decimals, commonly six, which makes the unit one millionth of a dollar. A finer unit shrinks the remainder in money terms but does not remove it: with seven holders, up to six units can be left over whatever the unit is. Accumulating shares follow the same rule. ERC-4626, the Ethereum standard for tokenized vaults, describes shares as a claim on a fraction of the vault's underlying holdings and requires the conversion between shares and assets to round down, in favour of the vault and therefore of the remaining holders. Three treatments of the remainder are common, and a distribution policy should name one of them: - carry it forward and add it to the next distribution; - leave it in the distributing account or contract as a balance of the vehicle; - allocate it by a fixed rule, such as one unit each to the largest fractional parts until it is used up. The amounts are trivial; the rule is written down so that a reviewer comparing the amount declared with the amounts paid finds the difference explained. ## What does a $50,000 distribution to seven holders look like, worked through? On a $50,000 distribution over 900,000 tokens held at seven addresses, each token earns $0.0555 recurring, the seven rounded amounts add up to three units less than $50,000, and that three-unit remainder is the same count whether the payment is made in cents or in millionths of a dollar. This is a worked example with invented holders; every amount is computed pro rata and rounded down. The register on the record date holds five individual wallets, one custodian's omnibus address and one marketplace contract where a holder has listed tokens for sale. | Holder on the record date | Tokens (share of 900,000) | Bank payout, rounded to the cent | Stablecoin payout, six decimals | | --- | --- | --- | --- | | Wallet A | 250,000 (27.7778%) | $13,888.88 | 13,888.888888 | | Wallet B | 180,000 (20.0000%) | $10,000.00 | 10,000.000000 | | Custodian's omnibus address | 150,000 (16.6667%) | $8,333.33 | 8,333.333333 | | Marketplace contract | 120,000 (13.3333%) | $6,666.66 | 6,666.666666 | | Wallet E | 110,000 (12.2222%) | $6,111.11 | 6,111.111111 | | Wallet F | 55,000 (6.1111%) | $3,055.55 | 3,055.555555 | | Wallet G | 35,000 (3.8889%) | $1,944.44 | 1,944.444444 | | **Total paid** | **900,000 (100%)** | **$49,999.97** | **49,999.999997** | | **Remainder** | | **$0.03** | **0.000003** | Only Wallet B, with exactly one fifth of the supply, receives an amount that needed no rounding. Each method then requires the following for this same job. With a bank payout, the agent sends up to seven transfers from its payment account, needs bank details for seven payees, and must first ask the custodian and the marketplace operator who stands behind their two addresses. Holders are paid when their bank credits them, which for a holder abroad may be days after the payment date. The agent keeps $0.03. With a push, the issuer approves one batch transaction carrying seven stablecoin transfers and pays one network fee. Five wallets are paid the moment the transaction confirms. The other two transfers, 8,333.333333 and 6,666.666666, land at the custodian and at the marketplace contract, and the holders behind them are paid only when those operators pass the money on. With a claim model, the issuer makes two transactions: one to publish the entitlements and one to fund the contract with $50,000. Seven claims are then needed, each paid for by the claimant. If the marketplace contract cannot claim, 6,666.666666 sits in the claim contract until the deadline in the terms. With accrual, no payment is made. The $50,000 stays in the vehicle and each token is worth about $0.0556 more; a holder of 55,000 tokens is roughly $3,055.56 better off without receiving anything, and realises it on redemption or sale. A platform feature runs one of the mechanisms above against the platform's own register. A payment router is not the instrument for this job: seven recipients would fit under a 20-recipient limit, but a router pays parties named in a deal, not whoever holds tokens at a given block. ## How does each method handle tax withholding, cost as the register grows, and proof of payment? Only the bank payout through an appointed agent and some platform features handle tax withholding and reporting as part of the payment; every onchain method leaves that work to the issuer, done before the money moves. Cost grows with each holder for a bank payout and a push, hardly at all on the issuer's side for a claim model, and not at all for accrual. | Method | Tax withholding and reporting | Cost as holders grow | Proof produced | | --- | --- | --- | --- | | Bank payout through a transfer agent or paying agent | Normally part of the agent's service | A fee per payment; cross-border transfers cost more | The agent's payment file and bank confirmations | | Onchain push in batches | Not handled; the issuer must deduct before sending and report separately | Network fees rise with every address; several batches on a large register | One public transaction per batch listing every transfer | | Onchain pull or claim | Not handled; entitlements must be published net of any deduction | Nearly flat for the issuer; each holder pays for their own claim | The published entitlement list plus one transaction per claim | | Accrual inside the token | No payment to withhold on; whether accrued income is taxable varies by country | No distribution cost | The published value per token or the balance change | | Platform distribution feature | Sometimes offered; check what is included | The platform's fee schedule | The platform's report, plus onchain records if it pays onchain | | An onchain payment router | Not handled | Not relevant beyond its recipient limit | One transaction showing every party's share | The chart below illustrates the cost row for the two onchain payout methods. It assumes a batch of 200 transfers per transaction, a figure chosen for the illustration; the real batch size depends on the network and the token.
Issuer transactions needed as the register growsIllustration: push batches of 200 transfers; claim model with one publication and one funding transaction
Push in batchesPull or claim
100 holders 1 2 1,000 holders 5 2 10,000 holders 50 2

Counts issuer transactions only. Under the claim model each holder also sends one claim transaction and pays its network fee, so the total work is moved to the holders, not removed.

A holder whose share is smaller than the network fee for claiming it will leave it, and those small shares become the unclaimed balance. Letting entitlements from several periods accumulate, so that one claim collects them all, reduces that effect. On tax, the difficulty is that a public address says nothing about the tax residence of the person behind it. An issuer that must withhold needs the holder's identity and tax status linked to the address before the record date, then publishes or pushes net amounts and keeps the calculation. Whether a distribution on a given token is a dividend, interest, rent or a return of capital, and what must be withheld and reported on it, is set by the securities and tax law of the countries involved and by the offering documents. ## What happens to payouts that nobody collects? Uncollected payouts exist under every method that requires the holder to do something or to be reachable: a bank transfer that bounces, a claim never made, or a stablecoin pushed to an address nobody controls any longer. The money still belongs to the holder until the law or the terms of the offering say otherwise, so the issuer needs a written rule before the first distribution. Under a bank payout, a returned transfer goes back to the agent, who tries to contact the holder and eventually applies the unclaimed property rules of the relevant jurisdiction; in many countries dormant amounts must be reported and handed to a public authority after a set period. Under a claim model, the unclaimed balance is visible to everyone: it is what remains in the contract. The terms usually set a claim window, after which the issuer may take the balance back and hold it for late claimants off-chain. Under a push, nothing is formally unclaimed. A transfer to a lost wallet or to a contract that cannot forward it is recorded as paid and cannot be recalled. ## Where does an onchain payment router fit, and where does it not? An onchain payment router fits one situation around a tokenized asset: a single incoming payment, such as the price paid by the buyer of the asset, that must be shared among a small number of named parties. A router does not fit the distribution to a register of token holders, because its recipients and their percentages are fixed when the deal is created, while a register changes with every trade. Shaka is one such router. It routes the total of a deal and pays every party their share at the same moment, in one transaction, without ever holding the funds. Each party's share is set as a percentage of the deal and can be signed by that party before the payer pays, which costs the parties nothing. The payer pays once, through a payment link. Destinations are fixed and signed before the payment, so the money cannot be redirected at the last minute, and the payment is final; every party can see that the others were paid, and the record stays available onchain. A deal has at most 20 recipients. That limit settles the question for a register. A property token with 400 holders cannot be paid through a 20-recipient router, and splitting the register into twenty deals would recreate, by hand, what a batch push or a claim contract does by design. A router takes no snapshot and keeps no money for a late claimant; it is not an escrow service and not a transfer agent. Where it does apply is one step upstream. Take the sale of the same asset for $2,400,000, an illustrative figure, with five parties entitled to the price: the vehicle that holds the asset for the token holders at 88%, the asset manager at 4%, the broker at 3%, the originator at 3% and legal counsel at 2%. One payment from the buyer becomes five payments in the same transaction: $2,112,000, $96,000, $72,000, $72,000 and $48,000, which add up to $2,400,000. The vehicle's $2,112,000 is then distributed to the seven holders of the earlier register by one of the other methods, at $2.3466 recurring per token, with a remainder of two millionths of a dollar at six decimals. ## How do you choose a payout method for your register? Choose by the number of holders first, then by whether holders are known and reachable, then by whether the asset pays income out or reinvests it. The situations below cover most tokenized assets. - A few dozen identified holders who gave bank details, in a security where withholding applies: a bank payout through an appointed agent keeps payment, withholding and reporting in one place, at a cost per payment that is tolerable at that size. - Up to a few thousand holders in self-held wallets, paid monthly or quarterly: a push in batches asks nothing of them, provided the policy deals with contract addresses and the issuer accepts paying the network fees. - Thousands of holders or more, or many small holdings: a claim model keeps the issuer's cost nearly flat. Plan the claim deadline, let entitlements accumulate across periods, and expect an unclaimed balance. - A fund whose investors want growth and not cash, or a token widely held inside other contracts: an accumulating share class removes the distribution altogether. Confirm with a tax adviser how accrued income is treated for your holders. - A token issued on a platform that offers distributions: use the feature if it covers your record date rule, your deductions and your marketplaces, and ask which mechanism it runs underneath, because that determines who holds the money in between. - A one-off payment to be shared among up to 20 named parties, such as a sale price: an onchain payment router pays them all in one transaction. The holders' portion still needs one of the methods above.