Cerberus Protocol is a reusable, proof-based distribution and access-control primitive for Solana.
It allows an organizer to commit to a fixed set of eligible wallets off-chain, publish a single Merkle root on-chain, and let users prove their eligibility and claim exactly once — without storing the full whitelist on-chain.
Cerberus Protocol is not just an airdrop contract. It can be used for:
- Token airdrops
- Whitelists
- NFT mint access
- DAO voting eligibility
- Any permissioned on-chain action
Eligibility is discovered off-chain, but enforced on-chain.
- The organizer computes a Merkle root from a whitelist.
- The smart contract stores only the root.
- Users obtain a Merkle proof off-chain.
- The contract verifies the proof and allows a one-time claim.
Cerberus Protocol has three components:
[ Backend (off-chain) ] ---> [ Smart Contract ] <--- [ Frontend ]
(proofs) (verification) (UX)
- Backend prepares and serves Merkle proofs
- Smart Contract verifies proofs and enforces rules
- Frontend connects wallets and submits transactions
This is the flow for a team launching an airdrop.
The organizer creates a CSV / JSON file:
[
{ "wallet": "WALLET_1", "amount": 100 },
{ "wallet": "WALLET_2", "amount": 50 }
]This file is never uploaded on-chain.
The organizer runs a script that:
- Hashes each entry:
hash(wallet + amount) - Builds a Merkle tree
- Outputs:
- Merkle root
- Proof + index for each wallet
The organizer deploys the MerkleGate program and initializes it with:
- Merkle root
- Bitmap size (number of eligible users)
After this step:
- The eligibility set is locked
- The organizer cannot change who is eligible
The organizer mints tokens and transfers them to a vault controlled by the program.
This is the exact experience for an end user.
The frontend prompts the user to connect their wallet.
The frontend now knows the user’s public key.
The frontend calls the backend:
GET /proof?wallet=<USER_WALLET>
- If the wallet is in the whitelist:
- Backend returns
{ proof, index, amount }
- Backend returns
- If not:
- Backend returns
not eligible
- Backend returns
The backend does not enforce rules — it only serves data.
- Eligible → “You can claim X tokens”
- Not eligible → “You are not eligible”
This is how users know their eligibility.
The frontend builds a transaction calling:
claim(proof, index, amount)
The user signs and submits it.
The Cerberus Protocol program:
- Recomputes the leaf from user data
- Verifies the Merkle proof against the stored root
- Checks the bitmap (not already claimed)
- Marks the index as claimed
- Executes the action (token transfer / CPI)
MerkleDistributor
- Authority
- One or more Merkle roots
- Bitmap account reference
ClaimBitmap
- Bitset tracking which indices have claimed
Each index can be claimed only once.
initialize_distributor– set root(s) and bitmapclaim– verify proof, mark claim, execute actionadd_root(optional) – add new eligibility setsupdate_authority(optional)
- Generate proofs
- Serve proofs
- Go offline
- Fake eligibility
- Increase claim amounts
- Allow double claims
All enforcement happens on-chain.
- No on-chain whitelist storage
- Proof-based verification
- One-time claim enforced via bitmap
- Backend is untrusted
- Frontend is untrusted
- Gas efficient
- Scales to large airdrops
- Reusable across use cases
- Production-proven pattern
Cerberus Protocol is a permission engine, not just an airdrop.
Cerberus Protocol lets organizers commit to eligibility off-chain and lets users prove eligibility on-chain — exactly once.
MIT