Abstract
Fans already launch coins named after the people, games and communities they love. The creator fees from those coins go to whoever pressed the button. strikr redirects them. Each coin's creator on pump.fun is a vault dedicated to that coin. A ledger assigns 90% of everything the vault collects to the accounts the coin is made out to, and those owners claim by publishing a short code bound to their payout wallet. The launcher never controls the fees, the split can't change after launch, and a payout is never sent twice, even when the network fails mid-flight.
1. The problem
On pump.fun, a coin's creator earns a fee on every trade. When a fan launches a coin "for" a streamer, the streamer earns nothing, and the fan may be earning from someone else's name. The obvious fix, asking launchers to forward fees, relies on trust, and the people the coins are named after usually don't know the coins exist.
We want three things at once: anyone can launch for anyone; only the named owner can collect; and the owner can claim years later, from any platform, without having done anything in advance.
2. Design goals
- Launcher-neutral. The launcher signs and pays for the launch but never holds authority over fees.
- Identity by permanent id. Recipients are pinned to the platform's immutable id where one exists, not a handle that can be renamed or recycled.
- Claim without accounts. No sign-up, no OAuth grant. Proving control of the account is enough.
- Exactly-once payouts. No payout is sent twice, and none is lost.
- Platform-agnostic. New platforms plug in behind a single interface.
3. Mechanism
3.1 Creating a coin
The server generates a fresh mint keypair and derives the coin's vault address (3.2). It builds pump.fun's create_v2 instruction, with an optional first buy, setting creator to the vault and user to the launcher. The mint signs on the server, and the launcher's wallet adds the final signature and pays. The creator is passed as data, not a signer, so the vault never needs to sign or hold SOL to be created. Because the mint's signature covers the whole message, the launcher can't alter the creator without invalidating the transaction.
Once the transaction lands, the server reads the coin's bonding curve and checks its creator equals the expected vault before listing it.
3.2 Vault derivation
seed = HMAC-SHA256(master_seed, "vouch:vault:v1:" || mint)
vault = Ed25519 keypair from seed[0..32]Nothing per coin is stored. Any server holding the master seed can re-derive any vault to sign payouts, and no one without it can.
3.3 Fee accrual
pump.fun pays creator fees into a creator vault keyed by the creator address, on the bonding curve and on PumpSwap after graduation. Newer curves can also hold fees in a bucket on the curve itself. A payout first sweeps any such bucket into the creator vault, then collects from both programs into the coin's vault wallet in one transaction.
3.4 The ledger
For each coin we keep what is owed to every recipient and to the platform. The vault must always hold:
vault_balance = rent_reserve + platform_owed + Σ recipient_owedAnything above that is new fees. Each payout computes the surplus and splits it: recipients receive surplus × 90% × share, rounded down, and the rounding dust goes to the platform. Because the ledger is reconciled against the real balance rather than against expected amounts, fees that arrive by any path are always credited exactly once.
3.5 Paying out
Verified recipients with at least 0.001 SOL owed, and the platform share, are paid by plain system transfers from the vault in a single transaction. The transaction is signed before it is sent, so its signature is known in advance and recorded with every line before broadcast.
3.6 Exactly once
Before doing anything else, a payout run checks every earlier transfer for that coin that isn't marked final:
- Confirmed: apply it to the ledger (idempotent: it applies once).
- Failed, or its blockhash expired without landing: mark it failed. Nothing moved, so nothing changes.
- Still unknown: put the coin on hold and stop.
A coin is processed under a database lock, so two runs never race. Together these guarantee a payout can't be sent again while an earlier one might still land.
4. Identity and verification
4.1 Permanent ids
At launch every recipient is resolved through the platform's API to a permanent identifier: GitHub's numeric user id, X and Twitch user ids, YouTube channel ids, Reddit's t2_ ids, Farcaster fids, Roblox universe ids, Discord guild ids. Handles are kept only for display. Where a platform has no permanent id (some reviewed platforms, websites and Minecraft servers), the normalised handle or domain is the identity.
4.2 Wallet-bound codes
code = "strikr-" || hex(HMAC-SHA256(claim_secret,
platform | permanent_id | payout_wallet | utc_day))[0..20]The claimant publishes the code where only the account owner can write. The server recomputes the code from the claimed wallet for today and yesterday, reads the platform once, and looks for the exact token. Copying a published code is useless: a different wallet produces a different code. Codes are single-use, and the bindings they create can be replaced only by verifying again.
4.3 Human review
Some platforms offer no dependable way for a server to read a profile. For those, the claim enters a review queue where a person confirms the code is on the account. Coins can be made out to such accounts only after they have verified, so the payout wallet exists before any fees do.
5. Trust model
Plainly: the server derives vault keys, so the operator could technically move unclaimed fees. The launch itself is non-custodial; payouts are custodial until they're sent. We publish every payout on-chain so anyone can audit vault balances against the ledger shown on each coin page.
| Threat | Mitigation |
|---|---|
| Launcher redirects fees | The launcher is never the creator, and the creator is checked on-chain before a coin is listed. |
| Someone claims another person's account | The code must appear on the account itself, read directly from the platform by permanent id. |
| Someone copies a public code | Codes are bound to one payout wallet. A copy pays the original wallet or nothing. |
| Handle renamed or recycled | Coins follow permanent ids. A new owner of an old handle has a different id. |
| Double payout after a network failure | Signatures are recorded before sending, settled before any new payout, and coins hold while results are unknown. |
| Server-side request forgery through pasted links | Only https, private and internal addresses blocked on every redirect, fixed hosts for platform APIs, response size capped. |
| Account takeover of the recipient | Out of our control. Whoever controls the account can claim. Owners should secure their accounts. |
| Operator compromise | Master seeds live only in server secrets. Payout history is public, and future versions move vaults on-chain (8). |
6. Economics
90% of creator fees go to recipients and 10% to strikr. The platform share pays for API access, review staff, hosting, and the Solana network fees on every payout, including the one-off rent reserve each vault needs.
Launching costs the launcher pump.fun's account rent and network fees, plus any first buy. The launcher earns nothing from fees. Their upside, if any, is the tokens they buy, exactly like any other trader.
7. Limitations
- Unclaimed fees are held by vaults whose keys the server derives (5).
- Verification depends on platform APIs. When a platform changes or rate-limits its API, claims there may pause.
- Reviewed platforms depend on human judgement and take longer.
- Fees exist only while people trade. Most coins stop trading quickly.
- pump.fun controls its programs and fee rates and can change them.
8. Roadmap
- On-chain vaults. Replace server-derived vaults with program-owned accounts that release funds only against a verified claim, removing operator custody.
- Native social fees. pump.fun now offers social fee accounts for some platforms. Where available, route those recipients' shares there directly.
- Login claims. Optional one-tap claims through platform sign-in where the platform allows it.
- More platforms. Each new provider is one module behind the same interface.
Disclaimer
This paper describes software, not an investment. Coins launched with strikr are speculative and most lose all their value. Nothing here is financial, legal or tax advice. See the risk disclosure and terms.