Most guides on this topic stop at "snapshot the holders, send the tokens." That works for a 50-wallet cap table on a quiet Sunday. It falls apart the moment your token is held across DeFi protocols, your investor base spans jurisdictions, or the gas cost of the operation eats into the distribution itself.
Distributing dividends onchain is not a single action. It is a sequence of design decisions that affect cost, compliance, and holder experience.
This guide walks through the five operational decisions an issuer has to make, in the order they need to be made, whether you are paying coupons on a tokenized bond, yield on a fund token, or stablecoin dividends on tokenized equity.
What does "distributing dividends onchain" actually mean?
The term covers three distinct flows that share the same mechanics but carry different regulatory weight.
-
The first is dividend payments to holders of tokenized shares, which are securities and inherit the full set of corporate-action obligations: announcement, record date, payment date, withholding, reporting.
-
The second is yield distribution to holders of tokenized fund shares or onchain treasury products, where the flow looks like a dividend but is structured as a profit share.
-
The third is coupon payments on tokenized debt instruments, with fixed schedules and predictable amounts.
Mechanically, all three reduce to the same problem: identify who holds the token at a given moment, calculate each holder's entitlement, and move the payment asset to them. The difference lies in the disclosure requirements, the tax treatment, and the audit trail your auditor and regulator will ask for. Treat these as inputs to your design, not afterthoughts.
A side note on terminology: a rebasing token that adjusts holder balances algorithmically is not a dividend distribution. It is a yield mechanism baked into the token contract. This guide is about distributing an external asset (typically a stablecoin) to holders of a separate token. The two should not be confused.
1. Choose your distribution model
The first real decision is the distribution model. Each option has second-order effects that show up only in production.
Snapshot vs streaming
A snapshot distribution picks a block number, reads every holder's balance at that block, and computes entitlements from it. It is simple, auditable, and matches the standard equity record-date model. It also incentivizes gaming. Sophisticated holders accumulate the token in the days before the snapshot and exit immediately after, which inflates the holder base on paper without any real commitment to the asset.
Streaming distributions accrue continuously based on a time-weighted balance. A holder who held the token for the full quarter receives more than someone who held it for three days, even if both are present at the snapshot block. Streaming aligns the dividend with actual holding behavior but requires infrastructure that can compute time-weighted balances across the full holder set, which is non-trivial when the token moves frequently.
For tokenized securities mirroring traditional equities, snapshot is usually expected. For yield-bearing instruments where alignment matters more than convention, streaming has become the default among issuers who can afford the engineering.
Push vs pull
A push distribution sends the payment asset directly to each holder's wallet. A pull distribution publishes the entitlements and lets holders claim. The difference looks cosmetic and is not.
Push fails for any holder whose tokens sit in a smart contract that cannot receive arbitrary transfers, which today includes most DeFi positions. It also scales linearly: ten thousand holders means ten thousand transactions, with gas costs that compound on top of the dividend itself. Dust amounts (sub-dollar entitlements) often cost more in gas than the value of the payment.
Pull distributions move the cost to the holder, who pays gas only when claiming. They scale to any holder count from a single onchain operation. The trade-off is the question of unclaimed funds: a non-trivial percentage of holders never claim, and the issuer needs a clear policy on what happens to the residual after a cutoff.
Pro-rata vs tiered
Pro-rata distribution, where each holder receives entitlement proportional to their balance, is the only model cleanly compatible with how regulators define a dividend. The moment you introduce tiers (a multiplier for holders who locked their tokens, a boost for long-term holders), you risk reclassifying the payment from "dividend" to "incentive," which changes the tax treatment and may require different disclosures.
Tiered models can be appropriate for utility tokens or governance designs where the legal frame already accommodates them. For tokenized securities, stick to pro-rata.
2. Solve the holder identification problem
This is where most onchain distributions break, and it is the part that "snapshot the holders" guides skip entirely.
The composability trap
The wallet that holds your token is rarely the beneficial owner. Tokens sit in AMM pools where the LP token represents a basket of assets. They sit in lending markets where the supplied position earns interest and the underlying token is fungibly mixed with other suppliers. They sit in Morpho vaults that wrap the position, in cross-chain bridges that mint a representation, in structured products that combine multiple legs.
If you airdrop the dividend to the address holding the token, you are paying the AMM contract, the lending pool, or the vault, not the actual investor. In the best case the contract redistributes the dividend to its LPs in proportion to their pool share, which dilutes your holder's entitlement. In the worst case, the funds sit in the contract permanently because nobody designed it to handle inbound stablecoin transfers.
This is the single biggest reason why onchain distributions fail in practice, and the reason most issuers eventually move from in-house scripts to dedicated infrastructure.
Reward forwarders and beneficial ownership tracing
Solving the composability trap requires logic that traces ownership through the layers of nested contracts back to the actual end holder. If the token sits in a vault that sits in another vault that sits in a smart wallet, the distribution layer needs to walk that graph at the moment of the snapshot and credit the entitlement to the address at the bottom of the chain.
Merkl handles this through reward forwarders that trace ownership through more than seven layers of nested contracts, covering the integrations most issuers care about. The point here is not to pitch a tool but to flag that this is a real engineering problem with a real cost if you build it yourself, and that the maintenance burden compounds every time a new protocol adds your token.
Exclusion lists
Treasury wallets, foundation reserves, team vesting contracts, and known exchange hot wallets should be excluded from the distribution. Forgetting this means a meaningful share of every dividend cycles back to the issuer (which creates accounting noise) or pays out to centralized exchanges that hold tokens on behalf of users without forwarding the dividend to those users.
Exclusion lists need to be reviewed before every distribution. New addresses appear over time (a new exchange listing, a new partnership wallet, a new staking contract), and missing one in a single cycle creates audit complications.
3. Set the frequency and accrual model
Quarterly distributions match traditional equity conventions and what most institutional holders expect. They are predictable, fit cleanly into accounting cycles, and produce a single tax event per quarter per holder. They are also operationally heavy: each cycle requires a snapshot, a calculation, an exclusion review, a publication, and reconciliation.
Monthly is a compromise that some yield-bearing instruments use to demonstrate consistent income without the engineering load of continuous accrual.
Continuous accrual is the model native to onchain finance. Entitlements update block by block, and holders claim whenever they want. The benefit is that holders can time their tax events, the issuer offloads timing decisions, and the user experience matches what DeFi users expect. The cost is that "the distribution date" no longer exists as a discrete event, which can complicate communications with traditional investors who expect a payment on a calendar date.
The shift toward continuous models is visible in tokenized treasury products and in onchain credit, where the underlying yield is itself continuous. Forcing it into a quarterly cadence creates more friction than it solves.
4. Account for gas and chain selection
Why L1 mainnet distributions rarely scale
A push distribution to ten thousand holders on Ethereum mainnet, at three to five dollars per ERC-20 transfer, costs thirty to fifty thousand dollars in gas before any dividend is paid. For a smaller dividend pool, the gas can exceed the distribution itself. Even on L2s where transfers are cheaper, the total cost remains linear in the number of holders.
This is why push-on-mainnet has effectively disappeared as a model for any holder base above a few hundred addresses.
Merkle-based pull distributions
The standard scaling solution is to compute entitlements offchain, build a Merkle tree of the (address, amount) pairs, and publish only the root onchain. The onchain cost becomes a single transaction regardless of holder count. Holders claim by submitting their leaf and the proof, and pay their own gas.
This is the model most distribution systems use today across DeFi and tokenized finance. The trade-off is that it requires offchain infrastructure to compute the tree, host the proofs, and serve them to holders. Issuers running this themselves typically underestimate the operational cost of keeping that infrastructure live and audited.
Multi-chain holder bases
If your token is bridged or natively deployed across several chains, the same investor may hold a position on Arbitrum, Base, and Polygon under different addresses (or the same address with different balances).
Two approaches:
-
Distribute per chain, treating each deployment as a separate holder set. Simple, but unfair to holders who split their position across chains and end up with three small dust amounts instead of one consolidated payment.
-
Aggregate ownership cross-chain, treating the holder as a single entity regardless of which chain their tokens sit on. Fairer, more complex, and requires a canonical view of total ownership that resolves bridge representations correctly.
For tokenized securities where the issuer controls deployment, aggregation is the right model. For tokens with permissionless bridging, the per-chain approach is often the only realistic option.
5. Handle KYC, tax, and regulatory reporting
When KYC is required
If the token is a security, the issuer is responsible for knowing its holders, full stop. Onchain doesn't change that. The standard pattern is to enforce KYC at the transfer level (a whitelist of approved addresses) so that by the time a distribution happens, the holder set is already verified. Distributions to unverified addresses are blocked by the token contract itself.
For utility tokens or yield products that don't fall under securities law, the position depends on the jurisdiction and on whether the distribution involves a fiat off-ramp. Stablecoin-denominated distributions to crypto wallets typically don't trigger VASP obligations on the issuer side. The moment the holder converts to fiat, those obligations land on the off-ramp provider.
The practical takeaway: KYC is a property of the token, not of the distribution. Holder eligibility and identity verification are functions of a transfer agent, not a paying agent. Confusing the two leads to over-engineering the distribution layer.
Withholding and reporting
US issuers face withholding obligations on dividends paid to non-US persons and 1099-DIV reporting for US persons, with SEC disclosure requirements layered on top for registered securities. EU issuers face DAC8 reporting and, for tokenized securities, MiCA-aligned disclosures. None of this is bypassed by being onchain. The cryptographic audit trail is a useful supplement, not a replacement.
Issuers running internal distribution scripts often discover this late, when the auditor asks for a reconciled list of holders, amounts, and tax classifications per cycle. Building that report after the fact is significantly harder than designing the distribution to produce it from the start.
Investor communications and audit trail
The transaction hash that publishes the Merkle root is a cryptographic proof that a distribution occurred and that a given holder was entitled to a given amount. It is not a substitute for the holder communications that securities regulation typically requires (notification of the dividend, of the record date, of the payment, of the tax treatment).
Plan the communications layer alongside the execution layer. The two are independent, and many issuers underestimate the second.
Putting it together: distribution as ongoing infrastructure
Looking at the full list of decisions (model, identification, frequency, gas, multi-chain, KYC, tax, communications), it becomes clear that onchain dividend distribution is not a one-off operation. It is recurring infrastructure that needs to keep working as the holder base grows, as new DeFi integrations appear, and as the regulatory perimeter tightens.
The traditional market converged on the paying agent model decades ago for the same reasons. The issuer sets the policy (who gets what, when, in which currency), and a specialized agent executes it (resolves the holder set, calculates entitlements, processes payments, produces audit reports). Computershare, Equiniti, and similar agents handle this for the bulk of listed equities globally.
Merkl reproduces this separation onchain. The issuer keeps full control over the distribution policy, including who is eligible, the calculation logic, the schedule, and the asset paid. The execution layer handles the parts that don't need to live with the issuer: composability resolution through reward forwarders, eligibility computation across chains, claim infrastructure, and the audit trail. This is what we mean when we describe Merkl as a programmable paying agent for tokenized finance: the same role TradFi paying agents play for listed securities, rebuilt for the operational realities of onchain.
The concrete consequence for issuers evaluating this: building distribution infrastructure in-house is a defensible choice for a static, single-chain, KYC-gated holder base of a few hundred addresses. Above that, the engineering and maintenance load makes the build-versus-buy question lean firmly toward buy.
FAQs
What is the cheapest way to distribute dividends onchain?
Merkle-based pull distributions on an L2 are the cheapest model at any non-trivial holder count. The issuer pays a single transaction to publish the distribution root, regardless of how many holders are entitled, and each holder pays their own gas to claim. Push distributions on L1 are typically the most expensive model and rarely justified above a few hundred holders..
Do you need KYC to pay dividends in stablecoin?
If the underlying token is a security, yes. KYC is a property of the token, enforced at the transfer level via a whitelist, not of the dividend payment itself. For non-security tokens, KYC obligations depend on the jurisdiction and typically attach to the fiat off-ramp rather than to the issuer.
How do you handle dividends for tokens held in DeFi protocols?
You need a distribution layer that traces beneficial ownership through nested smart contracts back to the end holder. Without this, the dividend is paid to the protocol contract and either trapped or redistributed at the pool level, diluting the entitlement of the actual holder. This logic is generally known as a reward forwarder.
Should dividends be distributed monthly, quarterly, or continuously?
Quarterly matches traditional equity conventions and most institutional expectations. Continuous accrual is more aligned with how onchain instruments behave and lets holders time their own tax events, but requires infrastructure that can compute time-weighted balances. The choice is more about your investor base than about the technology.
Can you distribute dividends across multiple chains at once?
Yes, with two approaches. Per-chain treats each deployment as a separate holder set: simple but creates fragmentation. Cross-chain aggregation treats the holder as a single entity across chains: fairer but requires resolving bridge representations and consolidating ownership data. The right choice depends on whether you control the chains your token is deployed on.
What happens to unclaimed dividends in a pull-based distribution?
This is a policy decision the issuer needs to make explicit before the first distribution. Common options: a claim window after which residuals return to the issuer, a permanent claim that never expires, or a redirection of unclaimed funds to a designated address. Whichever is chosen, document it in the distribution announcement and apply it consistently across cycles.