V.O.W / pdf

V.O.W: A Vessel of One Wallet That Cannot Sell, Built on Pump.fun Creator Fees

typeset view. the same text is available as HTML and as TeX source.

The object

The vessel is a program derived address. It is derived from the program id and the seed string "vessel", and it has a bump. It has no private key, which means no person, no machine, and no author of this paper can sign for it. The only way the vessel's balance changes is through instructions of its program, and the program has exactly two public instructions: initialize, which may be called once and binds the vessel to a single mint, and breathe, which anyone may call at any time. The program's upgrade authority is set to null at deployment, and the verify page lists the signature of the transaction that did so. Once initialized, the vessel cannot be re-pointed at another mint, closed, or drained. The author of this paper does not have, and could not have, an exit.

The inflow

The coin was created on pump.fun with the vessel as its creator fee destination. Every trade of the coin produces a creator fee in SOL, and the fee accrues to a creator vault that only the designated creator may claim. Because the designated creator is the vessel, and the vessel can only act through breathe, the claim happens inside breathe: the instruction first claims any pending creator fee into the vessel, then measures the vessel's lamport balance against the balance recorded at the end of the previous breath. The difference is the inflow. There is no other source of inflow. The vessel does not receive airdrops, does not receive transfers from the author, and if someone sends it SOL directly, that SOL is simply counted as inflow at the next breath and treated the same way. There is no way to earmark it.

The breath

A breath has six steps. First, claim. Second, measure the inflow. Third, read the price: the program reads the pool reserves (the bonding curve while the coin is on the curve, the migrated pool afterwards) and computes the lamports that one million base units would cost at the margin. Fourth, compute the ratio r = price รท basis, where basis is the volume weighted price of every unit the vessel has ever bought; on the very first breath, before any purchase, r is defined as 1. Fifth, spend: a fraction f(r) of inflow plus reserve is swapped for the coin, the purchased units are added to holdings and the basis is updated, and the unspent remainder becomes the new reserve. Sixth, burn: if r is at least 1.25, a fraction g(r) of the holdings after the purchase is burned from the vessel's token account. The breath then writes its sequence number, the new reserve, the new holdings, the new basis, the last price, and the state, and emits a Breath event. The whole thing is one transaction. If any step fails, nothing is written.

The two functions

The spend fraction is a piecewise linear function of the ratio. At or below 0.80 it is 1.00: the vessel spends everything it has. Between 0.80 and 1.00 it falls linearly to 0.50. Between 1.00 and 1.50 it falls linearly to 0.20. At or above 1.50 it is 0.20. The vessel therefore never spends nothing; even at the top of the range a fifth of what it holds in SOL is converted each breath. The burn fraction is zero below 1.25, rises linearly as one tenth of the excess ratio above 1.25, and caps at 0.05 at and above 1.75. Both functions are constants in the program and are included in the TeX source as a table. There is no governance, no parameter account, and no admin instruction.

What the vessel cannot do

The program contains no instruction that moves SOL out of the vessel except the swap inside breathe, and no instruction that moves tokens out of the vessel's token account except the burn inside breathe. It cannot be upgraded. It cannot be closed, because no instruction closes the Vessel account. It cannot be paused. It cannot act unless breathe is called, and breathe does nothing except record a zero inflow and a new ratio if there is nothing to spend and nothing to burn. It cannot distinguish between callers. It cannot refuse an inflow. The vow is not a policy that the vessel follows; it is the set of things that are physically possible for it, and that set was fixed before this paper was written.

The witness

The relayer, called the witness in this paper, watches the coin's signatures and calls breathe when a new trade appears. The witness is not privileged. If it goes offline, breaths stop, the inflow accumulates in the creator vault, and the next breath, called by anyone, will claim and spend all of it under the same rules. The witness has no key to the vessel and cannot change what a breath does. It only chooses when, and even that choice is constrained: it may not call breathe more than once per confirmed trade signature, because breathe records the trigger signature and rejects a repeat.

Verification

The program id, the vessel address, the vessel's token account, the mint, the creator vault, the null upgrade authority transaction, and the IDL are listed on the verify page, each with a link to a block explorer. The Vessel account layout is 106 bytes and is documented byte by byte in the account map file. Anyone may decode it. The breath log on this site is produced by decoding Breath events from the program's transaction logs with the published IDL, and the raw signature of every breath is shown next to its decoded fields.

Figure 1

claimmeasureread priceratiospendburnvessel account, 106 bytes, written once per breathpool reservescreator vaulttoken account
Figure 1. one breath, left to right, ending in a single write.

Figure 2

0.801.001.251.501.7510subparityparitysuperparity0.801.001.251.501.750.060subparityparitysuperparity
Figure 2. the spend fraction f(r) and the burn fraction g(r).