Trust Stack Docs
Products

Merkle airdrops

Publish a fully funded claim campaign with portable proofs, exact costs, and recovery rules.

A Merkle airdrop commits many wallet allocations to one SHA3-256 root while storing only the root, campaign state, and claimed indexes on-chain. Recipients use a public manifest to reproduce their allocation proofs and claim directly.

Airdrop creation workspace showing token funding, allocation input, and campaign schedule

When to use it

Use an airdrop when:

  • recipients should choose when to claim;
  • the creator does not want to submit a transfer for every wallet;
  • the distribution needs a defined claim window and later unclaimed-fund recovery; or
  • recipients or auditors need portable allocation proofs.

Use multi-send for immediate transfers to no more than 100 wallets in one atomic transaction.

Before you start

Prepare the token metadata address, unique recipient allocations, complete funding balance, claim start, claim end, and a later reclaim timestamp. The campaign creator also needs SUPRA for creation gas. Every claimant needs a copy of the exact generated manifest and enough SUPRA for claim gas.

The manifest is operationally essential. The on-chain root alone does not contain enough data for a recipient to reconstruct a proof.

Create a campaign

  1. Open Create airdrop.
  2. Enter and verify the standard Fungible Asset and creator balance.
  3. Add unique recipient addresses and positive amounts.
  4. Set the future claim start, claim end, and later creator-reclaim time.
  5. Review the generated root, allocation total, campaign seed, and schedule.
  6. Sign the fully funded creation transaction.
  7. Wait for the matching campaign-created event.
  8. Download the generated JSON manifest and publish it at a durable public location.
  9. Share the manifest hash through an independent channel so recipients can detect replacement.

The manifest records chain ID 6, package address, campaign object, asset, indexes, recipients, amounts, leaves, proofs, root, schedule, and creation transaction.

Practical example

A community allocates 100,000 EXR:

RecipientAllocation
Alice20,000 EXR
Bob30,000 EXR
Carol50,000 EXR

The creator deposits the complete 100,000 EXR when creating the campaign. Alice can claim only her 20,000 EXR, using Alice's manifest proof and Alice's signer. Bob cannot reuse Alice's proof, and a second claim for Alice's index is rejected. After the reclaim timestamp, any unclaimed remainder can only return to the immutable creator address.

Fees and costs

ActionTrust Stack protocol feeWho paysOther cost
Create campaignNoneNobodyCreator supplies full allocation and pays network gas
Claim allocationNoneRecipientRecipient pays network gas
Recover unclaimed balanceNoneTriggering signerSupra network gas
Build or verify manifestNoneNobodyHosting or distribution cost, if any, is external

Trust Stack does not deduct a percentage from the campaign or claims. The contract returns the exact leaf amount to a successful claimant. Network gas is determined by Supra and is separate from protocol fees. See Fee governance.

Claim an allocation

Airdrop claim workspace for loading and locally verifying a manifest

  1. Open Manage airdrop.
  2. Load the exact campaign manifest.
  3. Let the dApp rebuild the tree and confirm that the proof reproduces the live root.
  4. Connect the wallet named in the allocation.
  5. Confirm the campaign, asset, index, amount, claim window, and current unclaimed state.
  6. Sign the claim and wait for the matching claim event.
  7. Confirm the index is marked claimed and the recipient balance increased by the exact allocation.

Only the leaf recipient can sign, only during the claim window, and each allocation index can be claimed once.

Recovery after the campaign

The reclaim time is deliberately later than the claim end. After it is reached, anyone may submit the recovery transaction, but the contract sends the unclaimed balance only to the immutable creator. Triggering recovery does not let the caller choose a recipient.

Proof binding and limits

Every leaf binds the domain separator, campaign, token metadata, allocation index, recipient, and amount. This prevents valid proofs from being replayed across another campaign, token, wallet, or allocation. Proof depth is capped at 64.

Common problems

  • Manifest unavailable: the root cannot reconstruct missing proofs; contact the campaign creator.
  • Manifest changed: reject it if the rebuilt root or independently shared hash differs.
  • Wrong wallet: only the allocation recipient can sign.
  • Claim window closed: claiming is no longer possible after the end timestamp.
  • Already claimed: inspect the index and original transaction before assuming an application error.
  • Creator cannot recover yet: the separate reclaim timestamp has not arrived.

Publish the manifest durably

Store the exact manifest in a durable public location and preserve its hash independently. Trust Stack verifies integrity, but content addressing and an on-chain root do not guarantee that an operator will keep the file available.

On this page