A Solana Token-2022 transfer hook that turns a token launch into an infection game:
You can only buy from the pool if you already hold the token. To get your first tokens, an existing holder has to send you some — you have to get infected before you can buy.
- Peer-to-peer transfers are always allowed (that's how the infection spreads)
- Selling back into the pool is always allowed (you can always exit)
- The creator (patient zero) is whitelisted and can buy from zero
- Program ID:
2hdbA2wNSqCDg3RLSd4Gm1TTzbBAHCvhnrrKR8bqR7xk - Anchor 0.31 / Rust · built on the SPL Transfer Hook Interface
Token-2022 calls the hook's Execute on every transfer. The logic:
let dst = destination.owner; let src = source.owner;
if whitelist.contains(dst) -> allow // creator / patient zero, etc.
if dst is a pool-vault authority -> allow // selling into the pool / migration
if src is a pool-vault authority -> // this is a BUY from the pool…
require (destination.amount - amount) > 0 // …only if buyer was already infected
else InfectionError::NotInfected
otherwise -> allow // peer-to-peer transfer = infection spreads
destination.amount is the post-credit balance, so destination.amount - amount is the buyer's
balance before the buy. If it's zero, they've never been infected and the buy reverts.
Pool-vault detection is by owner: the DBC and DAMM v1/v2 pool vaults are owned by known
authority PDAs (FhVo3m… / HLnpSz… / CuVzw6…), so "tokens leaving a pool" = a buy, and "tokens
entering a pool" = a sell.
Meteora's DBC auto-revokes the transfer hook the moment the bonding curve completes (it nulls
the mint's transfer-hook program + authority in process_swap.rs so the token can migrate to DAMM
v2). Once that happens, the infection rule is gone forever. So for a persistent infection game, the
token must never graduate — set the migration market cap absurdly high (e.g. millions of SOL)
so the curve effectively never fills.
| Instruction | Who | Purpose |
|---|---|---|
initialize_extra_account_meta_list(creator) |
anyone (pays) | Creates the mint's ExtraAccountMetaList + HookConfig PDAs and whitelists creator. Run once per mint, after the mint exists, before the first trade. |
add_to_whitelist(address) |
config authority | Exempt another wallet (can buy without being infected). |
remove_from_whitelist(address) |
config authority | Remove an exemption. |
transfer_hook(amount) |
Token-2022 (CPI) | The Execute entrypoint enforcing the rule. |
Full flow tested against the live DBC 0.2.0 program: create config + pool with the hook → init → creator buys (0 balance, whitelisted) ✓ → fresh wallet buy rejected (NotInfected) ✓ → creator sends it tokens (peer transfer) ✓ → it buys ✓ → it infects another wallet, which can then buy ✓ → a never-infected wallet rejected ✓.
anchor build
solana program deploy target/deploy/infection_hook.so \
--program-id target/deploy/infection_hook-keypair.json \
--url <rpc> --keypair <deployer.json> --upgrade-authority <deployer.json>MIT — see LICENSE.