Slice
Money

Sweeps

A sweep collects one token’s creator fees from both of its vaults into the treasury, in one transaction, and credits the recipients with what that transaction records: pump.fun’s own receipt for what it paid out, plus any fees somebody else had already collected into the token’s creator address.

When a token is swept

A scheduled job runs every few minutes. Each run first settles the sweeps it sent before, then re-reads every token’s vaults and creator address, oldest reading first. A token is swept once it holds at least 0.01 SOL between its bonding-curve vault, its PumpSwap vault and any fees waiting in its creator address. The token swept longest ago goes first, up to ten a run, so a busy token cannot take every slot. Below the minimum the fees wait: a sweep costs a network fee, and sweeping dust would spend more than it collects.

  • At most one sweep per token is ever unresolved, so a token cannot be swept twice.
  • The job holds a lease while it runs, so two runs that overlap cannot both sweep.
  • A token whose sweep fails waits before it is tried again: 2 minutes after the first failure, doubling with each one after that up to an hour, and back to normal once a sweep confirms. One token that keeps failing cannot hold up the rest.
  • The operator can pause sweeps. Fees keep accumulating in the vaults, which only pump.fun’s collect instructions can pay out of, and the first run after the pause collects all of it.
  • The treasury pays each sweep’s network fee. If it cannot, the run stops early, the fees wait in the vaults, and the operator is alerted to fund the treasury; nothing is lost.
  • If the vaults of one batch of tokens cannot be read, that batch waits for the next run and the others are swept as usual.

The transaction

One transaction per token, signed by the treasury as fee payer and by the creator key:

  1. If the creator address holds less than the rent-exempt minimum, the treasury tops it up, so the account can exist on its own: once per token before the first collect pays into it, and again only if Solana raises the minimum. Recorded as a platform cost.
  2. pump.fun’s collect instructions for both programs: the bonding-curve vault pays the creator address in SOL, and the PumpSwap vault pays it in wrapped SOL.
  3. The creator’s wrapped SOL account is closed into the treasury, which turns the wrapped SOL back into SOL.
  4. Everything the creator address holds above its rent-exempt minimum is transferred to the treasury.

When the transaction is done, the fees are in the treasury and the creator address is back to the rent-exempt minimum the sweep was built with. Trades keep paying fees while the transaction is in flight, so our collect can pick up a little more than the transfer, whose amount was fixed when the transaction was built. That remainder stays in the creator address. It was credited from the collect event already, so it is recorded as the token’s float and leaves with the next sweep without being credited again.

Crediting from the transaction

pump.fun’s programs emit an event every time they pay out creator fees: CollectCreatorFeeEvent for the bonding curve and CollectCoinCreatorFeeEvent for PumpSwap. Once a sweep confirms, the job reads those events from the confirmed transaction and credits their amounts for what our own collects moved.

A balance difference would be the wrong number for that. The same transaction moves rent, closes a token account and pays a network fee, and each of those shifts balances by amounts that are not creator fees. The event is pump.fun stating how much fee it paid out, and it can be read back from the transaction by anyone. Balances are used for one thing only: finding fees that arrived without a collect of ours.

Fees somebody else collected

Collecting is permissionless on pump.fun: anyone can trigger a collect, and it always pays the creator address, in SOL from the bonding curve or in wrapped SOL from PumpSwap. Those fees never pass through a collect of ours, so our transaction has no event for them. The sweep moves them anyway, and credits them from the same transaction’s own record: what the creator address held above the rent reserve on our books, plus its wrapped SOL, just before the transaction ran, less the float that earlier sweeps already credited. We call what remains loose fees. They are split exactly like the event amounts.

What is credited
events   = CollectCreatorFeeEvent amount + CollectCoinCreatorFeeEvent amount
loose    = creator - booked reserve + creator wrapped SOL - float   // before the tx, never below 0
total    = events + loose
credits  = split(total) by the token's shares                       // see Recipients & shares
platform = total - sum(credits)
reserve  = rent minimum the sweep was built with                    // the new booked reserve
float    = creator after the tx - reserve                           // credited, moves next sweep
rent     = reserve - booked reserve                                 // platform: a cost, or a refund below 0
costs    = network fee + rent                                       // platform, recorded separately
Whoever runs the collect, the credits of a token add up to every lamport of fee that left pump.fun’s vaults for its creator address: nothing is credited twice, and nothing collected is left out. Both halves can be checked on Solscan, the event amounts in the transaction’s logs and the loose fees in its balance changes.

Writing the credits, any burn orders for recipients on Burn, the platform’s share and the costs is one database transaction. A sweep is either credited completely or not at all.

The rent reserve

Solana requires every account to hold a minimum balance, its rent-exempt reserve: 0.00065024 SOL for an address like a token’s creator today. That reserve is the platform’s money, not a fee, and our books keep the amount they have paid for each creator address. Loose fees are measured against that booked reserve, never against Solana’s minimum of the day.

  • Funded by us. Normally the treasury tops the creator address up in its first sweep. The top-up is booked as the platform’s rent.
  • Funded by a stranger. If somebody else’s collect paid into the creator address before any sweep of ours, everything in it is fees: all of it is credited as loose, and the reserve it leaves behind is booked as the platform’s rent, exactly as if the treasury had paid it.
  • Solana changes the minimum. It has happened once already: 0.00089088 SOL became 0.00065024 SOL. Every sweep leaves a funded creator address at the minimum in force when the sweep was built and re-sets the booked reserve to it. When the minimum falls, the freed part goes to the treasury with the sweep and is booked as a rent refund to the platform. When it rises, the treasury tops the address up, or the transfer leaves part of what the address held above its reserve behind, and the platform books the difference as rent. Either way the difference is the platform’s alone: it is never credited to recipients and never taken from their loose fees or float.

Lifecycle

sweep passamounts readexpired or erroredfees stay, retried laterbelow the minimum, waitsVaultFees waitingSentSignature storedConfirmedCredits writtenFailedNothing credited
A sweep from vault to credit. If it does not land, nothing is credited and the fees are still where they were when the token is swept again.
StateMeaning
sentSigned, and its signature and last valid block height saved before sending. The signature can be looked up on Solscan from this moment
confirmedThe chain confirmed it, the events were read and the credits are written
failedIt errored on chain, or it expired: a finalized block is more than 150 blocks past its last valid block height and the chain still has no record of the signature. Either way it provably moved nothing

Saving the signature before sending is what makes retries safe. On its next run the job asks the chain about every sent sweep. Found and confirmed: credit it. Not found, a finalized block more than 150 blocks past the height after which it could land, and a search of the transaction history still empty: mark it failed and sweep again after the wait. Anything short of that: wait. At no point can a sweep be credited twice or a landed sweep be forgotten.

Checking a sweep

Every sweep is listed in the ledger and on its token’s page with its signature, the total credited and the platform’s part. Open the signature on Solscan and you will find the collect events with their amounts, the balance of that token’s creator address before and after, and the transfer to the treasury.

A sweep that lands while our database is unreachable is not lost either. Its signature was saved before it was sent, so the next run finds it confirmed on chain and credits it then. If a sweep confirms and writing its credits fails, the operator is alerted to reconcile it, and later runs keep trying to credit it.