Paying your investors is a core operational job, and on-chain it can be accurate, fast, and provable - if you set it up right. Running distributions means calculating each holder's pro-rata share, applying the waterfall if the deal has one, and paying out in a way that scales and leaves an auditable trail. The main design choice is push versus claim. Here is how to run distributions that holders trust and you can reconcile.

Step 1: Calculate each holder's share

Start from a clean snapshot of who holds how much at the distribution record date. Because ownership is on-chain, you can read balances directly - no manual cap table to reconcile - and compute each holder's pro-rata share.

Apply the waterfall first if the deal has one: costs, debt, and preferred returns before common holders. Get the calculation right before any money moves.

Step 2: Choose push vs claim

Two models exist. Push sends each holder their share directly - simplest for investors, but gas costs scale with the number of holders and you pay them. Claim lets holders withdraw their share - cheaper for you at scale, and common via a merkle-proof distribution where holders claim against a published root.

For a small holder base, push is clean. For many holders, a claim-based merkle distribution is far more efficient. Pick based on your investor count and who bears the gas.

Step 3: Execute and verify

Fund the distribution in the payout asset (usually a stablecoin), run it, and verify: totals reconcile, each holder's amount matches their share, and the transactions succeeded. On-chain, this is all checkable.

Handle edge cases deliberately - holders who changed wallets, unclaimed amounts, rounding. Decide the policy up front rather than improvising mid-distribution.

Step 4: Record and communicate

Keep records of each distribution - record date, amounts, recipients, transaction hashes - for compliance and accounting. Then tell investors it happened and how to claim if claim-based.

Transparency here builds the trust that brings repeat investors. The investor sees this from the other side in how investors claim their returns - design your flow to match their expectations.

The mechanics in practice

Put numbers on the push-versus-claim choice. A push to 50 holders is a handful of transfers - trivial. A push to 5,000 is thousands of on-chain transfers, and at even a few cents of gas each plus failed-transfer handling, the cost and operational risk climb fast. That is why large distributions use the Merkle-claim pattern: you publish one Merkle root summarising every holder's entitlement (Uniswap's open-source MerkleDistributor is the reference implementation), and each holder claims against it, paying their own gas. For small, one-off payouts, a batching tool like Disperse is enough.

Settle in a stablecoin - USDC is the usual choice - so holders receive a stable amount, not a volatile token. Take the ownership snapshot from on-chain transfer events (a subgraph makes this clean) at a defined record date, and freeze it before you compute shares.

Two practitioner details matter. First, tax: depending on structure and investor type you may owe 1099 or K-1 reporting and sometimes withholding, so capture the data at distribution time, not at year-end. Second, decide an unclaimed-funds policy up front - a claim window, then a sweep back to treasury - because some holders never claim, and improvising that later erodes trust. And always reconcile the on-chain total against your treasury outflow before you call a distribution done.

Where to go next

• Next: go-to-market for a compliant offering.
• The investor's side: how investors claim their returns.
• Glossary: distribution waterfall.

Sources: token-standard specifications; platform documentation, as of 2026.