reference

how divvy works

the model

a project funds a round with ETH or an ERC-20 reward asset. the funded amount is held in an isolated vault until a distribution is activated.

a snapshot worker replays Transfer logs up to a chosen block, reconstructs balances in bigint, applies visible exclusions, and computes allocations without floating-point math.

the allocation set is committed as a standard merkle root. eligible wallets claim directly from the distributor with a proof. divvy never custodies funds.

eligibility

pro-rata by balance and minimum balance are implemented today.

time-weighted, tiered, and hybrid allocation modes are labelled coming next and are not selectable until they are genuinely implemented.

suggested exclusions (zero address, burn addresses, liquidity pools, known routers, bridges, treasury, creator wallet) are always visible and removable. nothing is silently excluded.

stock tokens and rwa

Stock Tokens are standard ERC-20 contracts. divvy reads metadata and pricing from robinhood's public read-only asset endpoints behind a typed adapter.

raw REST prices and onchain multiplier-adjusted units are never mixed: user-facing units read currentMultiplier or uiMultiplier() from the token contract.

pricing is display only. a pricing failure never alters an allocation — claims are denominated in actual token amounts.

an arbitrary ERC-20 is never labelled RWA or commodity-backed. those categories require a verified registry entry or approved configuration.

pons integration

new projects may set a divvy vault as their fee payout wallet; existing projects can deposit directly from the creator wallet.

the pons factory (0x7ed598bcef8bd9edd8c97a195c6d13f40801ec7e) is watched by a background indexer. every launched token is discovered from factory events and registered automatically.

divvy does not invent a private pons api. public metadata sits behind a replaceable typed adapter.

when creator-fee routing cannot be verified, divvy states: fee routing has not been verified for this project.

snapshot engine

every balance is read at one finalized snapshot block. a snapshot never mixes blocks, so regenerating the same snapshot always produces the same merkle root.

holder discovery uses blockscout's paginated token-holder api for address discovery only. balances come from batch balanceOf calls against the robinhood chain rpc — the chain is the source of truth, never the explorer.

a persistent holder index runs in the background: pons tokens are discovered from factory events, backfilled once, then kept current from new transfer events. once a token is indexed, creating a round against it is nearly instant.

if a synchronous snapshot exceeds its time budget, it continues as a resumable background job and the round appears on explore while it completes. the interface never spins indefinitely.

merkle commitments

allocation math is bigint end to end. totals are computed before funding, and the funded amount must exactly equal the allocation total — the contract rejects mismatches.

the tree and leaf hashes are stored server-side. claim proofs are generated on demand from stored leaves rather than pre-computed for every wallet, so the creator can continue as soon as the root is ready.

once a merkle root is set onchain it is locked. the distributor reverts on any attempt to change it.

claiming

claims are wallet-signed transactions against the distributor contract. the claimant proves inclusion with a merkle proof and the contract transfers the exact allocation from the round's vault.

expired, duplicate, and invalid-proof claims are rejected by the contract. claimed status is read from onchain events and receipts — never from a local flag.

divvy never takes custody. funds move from the funder's wallet into the round vault, and from the vault to claimants. no admin withdrawal path exists for claimant funds.

independent verification

the /verify page lets anyone paste a wallet address and a distribution id to recompute the merkle proof locally and compare it against the onchain root.

distribution detail pages link every onchain action to the blockscout explorer so funding, activation, and claims can be audited independently of the interface.

divvy reports unavailable states honestly: missing contracts read 'contracts not configured', missing indexer data reads 'not indexed yet', and missing pricing reads 'price unavailable'.

no invented data

divvy never shows sample distributions, placeholder addresses, fabricated transaction hashes, or estimated protocol statistics as if they were real.

anything you see on explore or a distribution page is either read from the chain, read from the indexer, or clearly labelled as unavailable.

write transactions are disabled until the factory and distributor addresses are configured. divvy does not substitute placeholder addresses.