CIP-99 Explained: Cardano's Proof of Onboarding Standard

The newcomer gap that snapshots can't reach

Cardano airdrops tend to follow one of three patterns. Snapshot-based drops go to existing stakers or holders (governance tokens, ISPO rewards, holder bonuses). Custom claim portals let users paste an address, connect a wallet via CIP-30, and pull tokens themselves. And occasionally a project just pushes tokens to a hand-picked list of addresses, though the minUTxO rule (every output costs roughly one ada to hold) caps this in practice at the low hundreds rather than the thousands you see on other chains.

All three models work fine when you're talking to people who are already on-chain. All three miss the audience that matters most at events: people who don't have a wallet yet. You can't snapshot someone who isn't there. You can't ask them to paste an address they don't have. You can't push tokens to a wallet that doesn't exist.

CIP-99, also called Proof of Onboarding or POO, is the Cardano standard built for exactly that gap. Print a QR code, hand it out, let anyone scan it with any compatible wallet, even one they installed two minutes ago at your registration desk.

What CIP-99 is, in one sentence

CIP-99 is a Cardano standard that defines how a wallet can claim tokens from a campaign by scanning a QR code, with the wallet itself doing the heavy lifting on-chain. The shorthand name is Proof of Onboarding (POO), because the standard exists to make on-the-spot onboarding work, the use case that snapshot drops and custom claim portals can't reach.

It lives in the Cardano Improvement Proposals alongside CIP-30 (wallet connectors), CIP-25 (NFT metadata), and the rest of the ecosystem standards. Any wallet that implements CIP-99 can interact with any campaign that follows the spec. The technical deep-dive lives in our docs page; this post is the plain-English version.

What POO solves that the existing models don't

Three failure modes show up when you try to onboard new people with snapshot drops, custom portals, or hand-curated push lists. POO addresses all three.

How a claim works under CIP-99

The flow is short. Four steps, no math required:

1. The organizer creates a campaign. Pick what to distribute (ada, a token, or an NFT), how many codes, and any limits. The platform generates a set of unique codes, each encoded as a QR code that contains a web+cardano://claim/v1 URI.
2. The recipient scans the QR code with a compatible wallet. The wallet recognizes the URI scheme and knows what to do next. No app switching, no copying addresses, no manually picking a network.
3. The wallet POSTs to the campaign's faucet URL. The request includes the claim code and the recipient's stake address. The faucet checks the code is valid, builds a transaction with the correct outputs and metadata, signs it with the campaign's hot wallet, and submits it to the chain.
4. The tokens arrive on-chain. The recipient sees a balance update in their wallet seconds later. They did not type an address, did not approve a contract, did not pay a fee. They scanned a code.

The technical bits (URI format, error codes, transaction metadata under CIP-10 label 8414) are in the CIP-99 docs page. For everyone else, the flow above is the whole thing.

Why a standard matters for wallets and events

Anyone could build a custom claim system. A token issuer could host a website, ask people to paste their addresses, send tokens manually. That works. It is also a different experience for every campaign, with every issuer reinventing the same flow and every wallet learning to support each one separately.

CIP-99 makes it possible for wallets to support claim flows once and have them work everywhere. VESPR, Tokeo Pay, and Eternl all implement the standard. When you generate a CIP-99 claim code, any of those wallets handles it out of the box. As more wallets ship support, the same codes get broader reach without any work from the campaign organizer.

POO in practice: what it unlocks

Once the standard is in place, the patterns it enables span more than just airdrops:

• Event onboarding Hand a printed code to someone who just installed their first wallet. They scan, the wallet pulls in some ada or an NFT, they leave the venue holding their first on-chain asset. See our onboarding playbook for the full event flow.
• Proof-of-attendance NFTs Each scan mints a unique on-chain NFT directly into the attendee's wallet. A digital ticket stub that lives forever, not a sticker that ends up in a drawer.
• Governance and treasury distributions Token distributions to community members who actively claim, rather than to whatever addresses a snapshot script returned. Higher signal, lower noise.
• Gamified drops and scavenger hunts Hide unique codes at different spots in a venue. Each scan delivers a different reward. Five ideas live in this playbook.

For the full breakdown of what kinds of campaigns the standard supports, see campaign types.

Common questions

The short version

CIP-99 is the Cardano standard that makes pull-based token claims work. POO is what people call it in conversation. It exists because snapshot drops and custom claim portals, the two patterns Cardano leans on for token distribution, both assume the recipient is already on-chain. Events are where that assumption breaks, and POO is the standard built for the people standing in the room.

If you have a room full of people and something worth giving them, CIP-99 is the route. Build it yourself from the spec, or use a platform that already implements it.