$BLIMP is autonomous infrastructure that routes a pump.fun token's creator fees into on-chain buybacks, then airdrops those tokens directly to holders — weighted by how long they've held.

Think of it as a perpetual-motion rewards engine bolted onto your token's fee stream. Set it up once. Every 15 minutes (or whatever interval you choose), the cranker:

• ›Claims accumulated creator fees from pump.fun's FeeSharingConfig
• ›Swaps 95% of the SOL back into your token (buy pressure)
• ›Airdrops those tokens to holders, weighted by balance × time-held
• ›Skims 5% into the $BLIMP treasury (which funds $BLIMP buybacks + burns)

Paper hands get cut at send-time. Diamond hands stack tokens every cycle. The config is permanently locked on-chain after onboarding — no one can rug it, not even us.

Who it's for

• ›Token creators who want a flywheel that pays loyalty automatically and demonstrates on-chain commitment
• ›Holders who want tokens that actually pay them for holding, not just vibes
• ›Builders who want the Anchor-free, no-custody, transparent alternative to private fee extraction

Who it's not for

• ›Teams that want to extract creator fees privately for themselves
• ›Tokens with hostile tokenomics that punish long-term holders (airdrops do the opposite)
• ›Chains other than Solana — pump.fun and the mechanism are both Solana-native

The mechanism has three pieces: pump.fun's native fee router, a dedicated wallet per project, and the cranker daemon that ties them together.

1. pump.fun's FeeSharingConfig

Every pump.fun mint can have a FeeSharingConfig PDA that permanently routes creator fees to a list of shareholders. Once the admin authority is revoked, the shareholder list is immutable — no one (not the creator, not pump.fun, not $BLIMP) can ever redirect those fees.

$BLIMP's onboarding creates this config for your mint, sets a dedicated wallet as the sole shareholder at 10000 BPS, and revokes admin. After that point, the only way fees can move is via pump.fun's distributeCreatorFees instruction — which sends them straight to that dedicated wallet.

2. Per-project HD-derived wallets

Every project gets its own Solana keypair, deterministically derived from a master seed:

We hold only the master seed (encrypted in env vars, with paper backup). Per-project keypairs are derived just-in-time for signing and zeroized after. This gives us per-project accounting, isolated failure domains, and a clean operational model for running 10+ projects at once.

3. The cranker

A long-running daemon that polls every 30 seconds. For each active project whose lastCycleAt + intervalSeconds is due, it executes a full cycle (see Anatomy of a cycle). Every stage boundary is checkpointed to Redis, so crashes, RPC timeouts, and rate limits all resume cleanly.

Two buyback paths, one abstraction

Pump.fun tokens live in two states: bonding-curve (pre-graduation) and graduated (post-graduation, on PumpSwap AMM or Raydium). The cranker auto-detects which and routes accordingly:

• ›Bonding curve: PumpSdk.buyInstructions — direct buy from the curve, cheapest path
• ›Graduated: Jupiter Ultra aggregator — best price across whatever DEX liquidity exists

From the project creator's perspective, it's transparent. You don't configure the swap path; graduation flips it automatically.

Onboarding takes about two minutes and three signatures. You connect the creator wallet, pick your config, and sign.

Prerequisites

• ›You are the creator of a pump.fun mint (i.e., the bonding curve's creator field matches your wallet)
• ›The mint does not already have a fee recipient set to someone else
• ›Your wallet has enough SOL for three tx fees (< 0.01 SOL total)

Two onboarding paths

Both land on the same on-chain state. Pick whichever you prefer:

Path A · Wallet-connect (recommended)

Visit /board, connect your wallet, paste the mint, set your config knobs, and sign three transactions in sequence. The backend verifies and activates the project automatically.

Path B · Manual (already set fee recipient on pump.fun)

If you've already configured a fee recipient via pump.fun's UI, go to /board → Manual Setup. Paste your mint and creator wallet. The UI will show you the exact BLIMP-derived wallet address that needs to match your pump.fun fee recipient. If they match, one more revokeFeeSharingAuthority signature finalizes it.

What ends up on-chain

After onboarding, the mint's FeeSharingConfig PDA has these permanent properties:

From that point on, every distributeCreatorFees call routes the vault's accumulated SOL to Wallet_N. The cranker picks it up from there on the next tick.

Cycle 0 bootstrap

Immediately after activation, the cranker runs a special cycle 0 that snapshots current holders into the tenure ledger without executing a swap or airdrop. This seeds firstHeldAt timestamps for existing holders, so they aren't penalized as "fresh buyers" on cycle 1. Without this, early holders would have zero tenure weight on the first real cycle.

One cycle = one round trip from "fees in the vault" to "tokens in holders' wallets." Eight stages, every one checkpointed, fully resumable.

Tenure weighting

The multiplier is a linear ramp from 15 minutes (1%) to 24 hours (100%). This is deliberately aggressive:

A wallet with 1M tokens held for 24 hours weighs the same as a wallet with 100M tokens held for 14 minutes. Fresh buyers get cut; long-term holders compound.

Paper-hand protection

Balances are re-verified at send time, not at snapshot time. A wallet that was eligible when the plan was built, but sold before the airdrop batch reached them, gets skipped. Their unclaimed tokens stay in the project wallet and roll into the next cycle's swap output.

LP pool auto-exclusion

Graduated tokens spend 60-90% of supply in the AMM pool PDA. If we airdropped to it naively, the pool would receive the majority of every cycle — effectively burning holder value and pumping LP invisibly. The cranker derives canonicalPumpPoolPda(mint) and excludes it from every distribution.

Token-2022 support

Every modern pump.fun mint uses Token-2022, not classic SPL. The cranker auto-detects the owning program per mint via getMintProgramId(), caches the result, and threads the correct program through every ATA derivation and transfer. Classic SPL tokens still work too — you don't configure this.

Crash recovery & idempotency

Every stage writes a checkpoint to Redis before moving to the next. Every batch writes its transaction signature to a per-cycle hash, and its index to a done-set. On restart, the cranker reads the checkpoint, skips completed batches, and resumes at the exact failure point.

There is no scenario where $BLIMP double-sends an airdrop. We've tested this against process kills, RPC rate limits, and network partitions.

Six knobs per project. Every project has its own config — nothing is shared across tokens.

System-level constants

These are set at the cranker level and apply uniformly to every project:

• ›treasurySkimBps — 500 (5% to $BLIMP treasury)
• ›priorityFeeMaxLamports — 1,000,000 (1M μlamports cap on priority fees)
• ›slippageBps — 500 (5% slippage on swaps)
• ›walletReserveLamports — 10,000,000 (0.01 SOL kept in project wallets for rent exemption + buffer)

Tuning guide

For high-frequency trading tokens

• ›intervalSeconds: 900 (15m) — fast flywheel
• ›minHoldSeconds: 900 (15m) — bias toward loyal holders even at high turnover
• ›minSweepLamports: 10M+ — avoid dust cycles that burn tx fees

For slow-cooker tokens / long-duration launches

• ›intervalSeconds: 3600 – 7200 (1-2h) — let fees accumulate, distribute in meaningful amounts
• ›minHoldSeconds: 3600+ — exclude flash buyers
• ›maxPerWalletBps: 500 – 1000 (5-10%) — cap whale capture, redistribute to the long tail

$BLIMP is custodial for at most one cycle and structurally can't redirect fees. Here's what we protect against, and what you need to trust.

Threat model

What you still need to trust

Being honest about where trust actually lives:

• ›We run the cranker honestly. The cranker executes the logic in the public repo. We could, in principle, patch it to (say) settreasurySkimBps to 100%. We don't, and you can verify cycle outputs on-chain against the code.
• ›The master seed stays secure. If it leaks, an attacker can drain any unsettled fees currently sitting in project wallets (≤ one cycle worth). They still can't redirect future fees — the FeeSharingConfig is locked.
• ›We keep the cranker running. If the cranker dies, your fees just accumulate safely in the project wallet until we start it back up. Nothing is lost. But cycles pause.

How to verify for yourself

• ›Read the FeeSharingConfig PDA for your mint. Confirm adminRevoked == true and shareholders contains exactly one entry (the BLIMP wallet) at 10000 BPS.
• ›Watch the cranker wallet + project wallet on Solscan. Every cycle leaves a trail: claim tx → skim tx → swap tx → airdrop batches.
• ›Read the source. github.com/BLIMP-FUN/blimp — it's the code that actually runs.

Quick answers. If yours isn't here, DM us on X.

What cut does $BLIMP take?

5% of each cycle's claimed fees goes to the $BLIMP treasury wallet. The remaining 95% becomes buy pressure for your token and is airdropped to holders. There are no other fees — no platform fee, no onboarding cost, no subscription.

What does the 5% treasury fund?

$BLIMP token buybacks and burns. Every project using $BLIMP feeds the treasury, which in turn supports the $BLIMP token that ties the ecosystem together. It's a shared flywheel. If you hold $BLIMP, every launch using this infra pumps you passively.

What happens to existing holders on day one?

The cycle 0 bootstrap snapshots them into the tenure ledger at activation time. They start accruing tenure immediately; by cycle 1 they're eligible (provided they meet your configured minHoldSeconds).

What if a holder sells mid-cycle?

Their balance snapshot is taken, but the paper-hand guard re-verifies at send-time. If they sold below minHoldAmount, their allocation is skipped and rolls to the next cycle. Holders who partially reduced (but are still above the threshold) get paid on their current balance.

Does this create tax obligations for holders?

We are not tax advisors. Airdrops are generally treated as ordinary income at fair market value at receipt in most jurisdictions. Consult a professional.

Can I turn $BLIMP off?

Not on-chain, no. The FeeSharingConfig is immutable. What you can do is ask us to pause cycles for your project — fees will still accumulate in the project wallet but won't be swapped or distributed. They stay there until cycles resume. This is a soft-pause, not a detach.

Can I plug multiple tokens in?

Yes. Each one gets an independent HD-derived wallet, independent config, independent tenure ledger. You can run as many as you want through the same creator wallet.

Does this still work after my token graduates?

Yes — that's actually when the flywheel matters most. Post-graduation swaps route through Jupiter Ultra. Pump.fun creator fees continue to accrue on graduated tokens via the pump_amm::transfer_creator_fees_to_pump + distributeCreatorFees two-instruction claim path.

Has $BLIMP been audited?

There's no smart contract to audit — $BLIMP has zero on-chain programs. The security surface is:

• ›pump.fun's pump_fees program (audited, used by billions of volume)
• ›SPL / Token-2022 programs (both audited)
• ›Jupiter Ultra (audited, widely used)
• ›The cranker's TypeScript (public on GitHub, tested to ~125 tests across core packages)

Can I run my own $BLIMP instance?

Yes — the repo includes a full self-hosting guide. You'll need a master seed, an Upstash Redis instance, a Solana RPC endpoint, and a small SOL balance for cranker tx fees. The code is reference-available (license TBD, likely MIT/Apache).

Where do I get help?

X: @blimp_fun. GitHub issues at BLIMP-FUN/blimp.