Merkle airdrops

A Merkle airdrop commits many allocations to one SHA3-256 root while keeping only the root and claim state on chain. Recipients use a portable manifest to reproduce and submit their own proofs.

Create a campaign

1. Verify the standard Fungible Asset and creator balance.
2. Add unique recipient allocations.
3. Set the claim start, claim end, and later creator-reclaim time.
4. Review the generated root, total funding, and campaign seed.
5. Sign the fully funded creation transaction.
6. Download and publish the generated JSON claim manifest.

The manifest records chain ID 6, package address, campaign object, asset, allocation indices, amounts, leaves, proofs, root, schedule, and creation transaction. Treat it as a public distribution artifact; recipients need it to claim independently.

Claim an allocation

The recipient loads the manifest. Trust Stack rebuilds the tree locally and rejects any changed field that no longer reproduces the campaign root or allocation. It then reads live campaign and claim state. Only the leaf recipient can sign, during the claim window, and each index can be claimed once.

Recovery

After the separate reclaim timestamp, anyone may trigger recovery, but the contract can return the unclaimed remainder only to the immutable creator address. Trigger authority is not recipient authority.

Proof binding

Each leaf binds the campaign, token metadata, allocation index, recipient, amount, and a Trust Stack domain separator. This prevents reusing a valid proof across another campaign, asset, wallet, or allocation. Proof depth is capped at 64.