pump.fun prices this coin with a constant product between two virtual reserves. Nothing about the price is a market opinion. It is the quotient of two integers stored in one account, and every buy or sell is a deterministic rewrite of those integers. This page reads the account, decodes every byte, reproduces the program's arithmetic, and shows where that arithmetic leaks.

The program keeps k as the product of the virtual reserves. A buy sends sol, the program takes its fee from that sol first, adds what remains to the virtual sol reserve, and computes the new virtual token reserve as k divided by the new sol reserve, rounded up by one. The tokens out are the old token reserve minus the new one. A sell adds tokens to the token reserve, computes the new sol reserve as k divided by the new token reserve rounded down, pays the difference minus the fee. Both divisions are integer divisions. Both round in the program's favor.

buy:
  fee        = sol_in * fee_bps / 10000
  net        = sol_in - fee
  k          = v_sol * v_tok
  v_sol'     = v_sol + net
  v_tok'     = floor(k / v_sol') + 1
  tokens_out = v_tok - v_tok'

sell:
  k          = v_sol * v_tok
  v_tok'     = v_tok + tokens_in
  v_sol'     = floor(k / v_tok')
  gross      = v_sol - v_sol'
  fee        = gross * fee_bps / 10000
  sol_out    = gross - fee

price       = v_sol / v_tok
to_complete = k / (v_tok - r_tok) - v_sol
gross_in    = to_complete / (1 - fee_bps / 10000)

Because the division rounds, two trades of nearly the same size can return token counts that differ by more than the price difference explains. The map below runs the buy formula on the current reserves for every size from 0.001 sol to 2 sol in 0.001 sol steps and records the remainder the program discards. Dark cells are sizes where the discarded remainder is largest. The agent trades only at the lightest cells.

These are not offers. They are what the program will do if someone sends that amount in the next transaction, assuming nothing lands ahead of it. Compare any row to the fill you actually received and you have measured what landed ahead of you.

Every wallet that has touched this coin, decoded from the transactions themselves. The agent does not ask an indexer who bought. It reads the trade event the program emits inside each transaction, then reads the wallet's own history to find its first transaction and the wallet that funded it. Classification follows fixed rules written on the method page. No row is edited by hand.

A bundle is three or more buys from three or more distinct wallets landing in the same slot. That pattern does not happen by accident on a thin curve. The escrow records the bundle's total position when it is detected and buys a fixed fraction of every later sell from any of its wallets, from creator fees, in the same slot window if it can land there. The exposure column is what the bundle still holds.

The agent's program owns one vault per coin. Creator fees arrive there. The vault pays out only through four instructions, each of which can only be called when a stated on chain condition is true. There is no admin withdraw. There is no timer. The conditions are trades.

Creator fees accrue to the vault with every trade. The reflux instruction claims them and buys the coin on the curve, but it can only be called when the curve's real sol reserve is below the reserve recorded at the last reflux. That means the vault only buys after sells have pulled the reserve down past the previous entry. Each lamport entering a lower reserve moves price by more than it would at a higher one. Dumps fund entries, and entries happen at local lows by construction, not by prediction.

allowed(reflux) = real_sol_now < last_reentry_real_sol
on success:      last_reentry_real_sol = real_sol_now
                 fees_reentered += amount
                 reflux_count += 1

When the dossier flags a bundle the keeper calls the record instruction with the bundle's slot and wallets. The program stores the position. From then on, any sell by a recorded wallet enables the counter instruction, which buys from the vault an amount equal to a fixed fraction of what that wallet just sold, and reduces the stored exposure by the sold amount. The fraction is fixed in the program and shown below. The counter cannot be called without a matching sell in the same or previous slot.

allowed(counter) = sell by bundle wallet in slot s or s-1
amount           = sold_sol * counter_fraction_bps / 10000
exposure        -= sold_tokens

The protocol fee pump.fun collects on a buy is a known number: the fee rate times the sol sent. The refund instruction returns exactly that number to the buyer from the vault. It becomes callable for a given buy only after a fixed count of sells by other wallets have landed on the curve while the buyer's token balance has not decreased. The count is checked against the trade history the program has recorded, and the buyer's balance is read from their token account at call time. A buyer who sold forfeits the refund for that buy.

refund_amount          = sol_in * fee_bps / 10000
allowed(refund, buy b) = sells_by_others_since(b) >= refund_sell_count
                         and balance(buyer) >= tokens_out(b)

The curve completes when its real token reserve hits zero, and the program then moves the liquidity to its pool. Whoever sends the buy that crosses the line decides when that happens. The vault keeps a migration reserve for that purpose. The crossing instruction can only be called when the dossier's recorded bundle exposure is under a maximum share of supply and the share of fresh, sniper and bundle wallets among all classified wallets is under a maximum. Both maximums are stored in the vault and shown here. When the conditions fail and the curve is within the final stretch, the hold instruction sells vault tokens into the curve to keep the reserve under the threshold until they pass.

After completion the agent reads the pool account instead of the curve and keeps the same mechanisms running against pool trades: reflux buys through the pool at reserve lows, counter buys against recorded bundles, refunds of the pool's fee on the same count rule. The dossier keeps classifying. This page reads the vault's phase byte and shows which account it is watching.

What the agent has established about the pump.fun program by reading it. Each finding is a sentence or two, the account or transaction that demonstrates it, and the sha256 of the finding text written to an account under the agent program. Recompute the hash from the text on this page and compare it to the account. If they differ, this page has been edited after the fact.

Finding texts are added as they are recorded on chain. Each one will appear here under its index with the exact string that was hashed, so the hash can be recomputed client side. The hashing rule is sha256 over the UTF-8 bytes of the text with no trailing newline, hex encoded, lowercase.

hash = hex(sha256(utf8(text)))

The bonding curve account is derived from the mint with the seed string bonding-curve under the pump.fun program. It is read with a confirmed commitment and decoded by byte offset. The global account under the seed string global holds the fee rate and the initial reserves every curve starts with. Neither account can be changed by anyone but the pump.fun program. Reading them is free and permissionless.

pump.fun emits a trade event on every buy and sell. The event is written into the transaction as a self call to the program with a fixed discriminator, and also into the log as program data. The agent decodes the event bytes directly: mint, sol amount, token amount, side, user, and the four reserves after the trade. From the post trade reserves and the amounts it reconstructs the pre trade reserves and recomputes what the curve formula would have returned. The difference between that and the actual token amount is the gap.

A wallet's first transaction is found by paging its signature history to the oldest entry. The funder is the account in that first transaction whose balance fell by the most, excluding the wallet itself. Classification is then one pass through the following rules, first match wins.

Integer division discards a remainder. On a buy the program computes the new token reserve as k over the new sol reserve, rounded up by one, which gives the buyer slightly fewer tokens than the real number would. The discarded part scales with the remainder of k modulo the new sol reserve. By choosing sol amounts where that remainder is near zero, the agent's buys lose almost nothing to rounding, while ordinary buys lose a fraction of a token each. Over many trades the difference between the agent's effective price and the average effective price of other trades is the harvested dust. It is reported in tokens and in the sol those tokens are worth at the curve price.

The reflux rule is one comparison: the current real sol reserve must be below the reserve recorded at the last reflux. The first reflux after deployment has no prior record and is allowed at any reserve. Each reflux records the reserve it entered at. The effect is that the vault only ever adds sol to the curve at a reserve lower than its previous entry, which is a lower price than its previous entry.

A recorded bundle wallet selling is the only event that enables a counter buy. The counter buys a fixed fraction of the sol the bundle wallet just received. The purpose is not to defend a price. It is to make the bundle's exit fund the vault's position at the exact price the bundle exited at.

A refund is the exact protocol fee of one buy, computed from the sol sent and the fee rate at the time, paid from creator fees. It becomes available after a fixed count of sells by other wallets, and only if the buyer's token balance has not fallen below the tokens that buy returned. The sell count is the clock. No wall clock time is read anywhere in the program.

Completion is a buy that empties the real token reserve. The vault holds sol for that buy. It may send it only when two conditions read true at call time: recorded bundle exposure as a share of supply is under the stored maximum, and the share of fresh, sniper and bundle wallets among classified wallets is under the stored maximum. The second condition is read from an account the keeper updates from the dossier, and the keeper's update is itself constrained to counts it can prove with trade signatures. When the conditions fail and the curve is within the final stretch, the hold instruction may sell vault tokens into the curve, but only enough to keep the reserve under the threshold, never more.

A finding is text plus proof. The keeper submits the sha256 of the text and either a transaction signature or an account address. The program stores them under an index. Nothing about the text can be changed afterward. The text itself is published on the findings page, and anyone can hash it and compare.

It never sends a transaction that the program would reject. It never holds a key that can move the vault outside the four instructions. It never acts on a timer. It never reads a price from anywhere but the curve or pool account it is watching. It never classifies a wallet by anything other than the rules on this page.