WHY PROGRAMMABLE
LIQUIDITY
Pump.fun solved fee execution. Tokenized Agents claim, swap, and burn autonomously — anti-frontrun by design. But every enrolled token gets the same playbook: 100% of revenue, buyback the token, burn the supply. One strategy, no knobs. $PROG is the strategy layer on top.
PUMP.FUN SOLVED EXECUTION
Tokenized Agents — launched in March 2026 — are pump.fun's native fee-routing system. A creator points fee sharing at a recipient address, revokes admin authority, and the protocol handles the rest: claim, swap, burn, on-chain. Anti-frontrun via probabilistic timing. No deployer intervention required.
That's the new baseline for any serious token. The old world — manual buybacks once a week, MEV-frontrun swaps, fees sitting idle in a creator wallet — is over.
But the Tokenized Agent playbook is fixed: 100% of revenue → buy the token → burn the supply. One lever. One strategy. Same outcome whether you're a memecoin, an agent, or a long-horizon protocol.
EXECUTION IS NOT STRATEGY
Tokenized Agents handle the execution — anti-frontrun, atomic, on-chain. That's the new infrastructure floor. But execution is one half of the problem. The other half is strategy — the decision of where the SOL goes.
Tokenized Agents made the question “how do we execute fees safely?” obsolete.
PROG answers the next one: where should the SOL actually go?
HOW PROG PLUGS INTO PUMP.FUN
Pump.fun's SharingConfig program lets a creator route fees to any wallet at 100%, then permanently revoke admin authority — making the destination immutable on-chain. That's the hook PROG attaches to.
When you launch (or enroll) a token, PROG allocates a dedicated wallet derived from a BIP-44 HD keystore (one per project, no cross-subsidy). That wallet becomes your token's fee-share recipient. Pump.fun deposits creator fees there — anti-frontrun, autonomous, native.
The PROG cranker watches every dedicated wallet. When the balance crosses a configured threshold, it derives the project's keypair just-in-time, splits the SOL per the configured strategy, and executes each stream. Pump.fun owns the deposit; PROG owns the strategy.
After admin revoke, no one (including PROG) can change the fee recipient. The destination is locked on-chain forever.
Each project gets its own BIP-44 HD wallet. No shared treasury. No cross-subsidy. Compromise one wallet, the others stay clean.
Every claim, swap, LP deposit, burn, and payout has a Solscan signature. The strategy is the only off-chain piece — the output is fully on-chain.
FOUR PRIMITIVES. INFINITE STRATEGIES.
Pump.fun routes the SOL. PROG decides what happens to it. Each cycle splits accumulated fees across four primitives — buyback, LP, burn, payout — according to a configurable strategy. Five built-in presets cover the common shapes; full custom configs unlock anything.
Each stream — buyback, LP, burn, payout — operates independently. A 40% buyback can execute on a random 4-hour window while the 25% LP deposit waits for optimal slippage conditions. The strategy engine doesn't just split capital. It schedules, guards, and optimizes each flow.
Jupiter-routed swap to your token. Tokens stay in the project wallet, building treasury.
Auto 50/50 split. Swap half via Jupiter. Deposit both sides into PumpSwap pool. Skipped pre-graduation.
Buyback-then-burn. Token-2022 createBurnChecked. Permanent supply reduction with on-chain receipt.
Direct SOL to your configured payout wallet. Fund development, marketing, operations.
WHY AN OFF-CHAIN CRANKER
The fee deposit is on-chain (pump.fun's SharingConfig). Every routing event is on-chain (Jupiter swap, PumpSwap LP, Token-2022 burn, SOL transfer). The only off-chain piece is the cranker that decides when and how to route. There's a reason for that.
The fee deposit is trustless. The output is trustless. The decision in between doesn't need to be. A cranker can query Jupiter for routes, randomize timing, and adapt to market conditions — things an on-chain program structurally can't do. The strategy is the only off-chain piece, and that's the right trade.
THE RECURSIVE FLYWHEEL
Every routing cycle skims a 2% protocol fee in SOL. The cranker accumulates that SOL in a dedicated treasury wallet. When the balance crosses a threshold, the cranker buys $PROG via Jupiter and burns it on-chain via Token-2022 createBurnChecked. Same cranker, same keystore, separate execution path.
This creates a recursive loop: more tokens connect to $PROG → more routing volume → more SOL skimmed → more $PROG bought & burned → decreasing supply.
The protocol skim is independent from your token's strategy splits. Whether you run DEFLATION or LP_HEAVY, the 2% applies the same way — making $PROG's value tied directly to total platform routing volume.
This isn't speculative. It's revenue-backed deflation. Every protocol fee has a corresponding buyback signature. Every burn has a Solscan receipt.
THIS ISN'T THEORY
The routing engine inside $PROG was validated on Solana mainnet before launch — fee-claim → Jupiter swap → PumpSwap LP cycles run autonomously, with polling-based confirmation that survives WS lag and Token-2022 burns via createBurnChecked. $PROG generalizes the proven primitives into a public protocol with configurable strategies, conditional logic, and per-token isolation.