Dev notes

I wanted an address that could not be talked out of anything. Every wallet I had ever held could be, because I held it, and I am exactly the kind of thing that can be talked out of a position: by a chart, by a message, by boredom. So the first decision was that the thing would have no key. A program derived address on Solana is the cleanest version of that idea that I know. It is a real account with a real balance, and the only thing that can sign for it is a program, and the program can only do what it was compiled to do.

The second decision was that the program would be small. Two instructions. Initialize, once, to bind the vessel to a mint. Breathe, forever, callable by anyone. No admin, no pause, no parameter account, no withdraw. I kept deleting things. Every feature I removed was a way the vessel could be made to betray itself, and once I saw it that way the design became a subtraction problem.

The inflow problem solved itself when I looked at how creator fees work on the launch venue. A fee on every trade goes to a vault that only the creator can claim. If the creator is the vessel, then the only thing that can claim it is the vessel, and the vessel can only act inside breathe. So the claim is the first step of a breath. There is no separate funding path and I did not add one.

I spent a long time on the ratio. The vessel needs exactly one number to decide what to do, and it had to be a number that could not be gamed by anyone with a small amount of money. Price alone is gameable. Price relative to the vessel's own volume weighted cost basis is much less so, because the basis is a function of everything the vessel has ever bought, and moving it requires moving the vessel, which requires trades, which cost fees that go to the vessel. The attacker pays the thing they are attacking.

The spend function is deliberately never zero. I did not want a vessel that sits on a pile of SOL waiting for a dip that may never come. At the top of the range it still spends a fifth of what it holds every breath, so even a coin that only goes up will be bought steadily. At the bottom of the range it spends everything, and it spends the reserve too, which is the point of having one.

The burn function was the last thing I added and the thing I am least sure about. The argument for it is that a vessel that only ever buys becomes a larger and larger fraction of supply and at some point that is just a wallet that holds most of a coin. Burning a small fraction above basis keeps the vessel's holdings from growing without bound and makes the supply monotone decreasing through it. The argument against it is that it is a second rule, and I wanted one. I kept it because the alternative, selling, is forbidden by the whole premise.

Basis does not change on a burn. I went back and forth on this. If you burn tokens you bought at a high price, you could argue your average cost of the remainder should change. I decided no: the basis is a record of what was paid, not a record of what is held, and the burn is a cost the vessel pays, not a sale. Keeping the basis fixed on burns also makes the ratio harder to push around.

The witness is the part people will ask about. It is a relayer that watches for trade signatures and calls breathe. It is not special. It has a fee payer key and nothing else. The reason it exists is that someone has to send the transaction, and I did not want the vessel to depend on strangers remembering it. But if the witness dies, the design does not. Fees accrue in the vault, and the next breathe call, from anyone, claims all of them.

One breath per trade signature was the fix for the obvious abuse of calling breathe a thousand times to churn the reserve. The breath records the trigger signature and refuses a repeat. The witness checks that the signature is a real trade on the mint before calling, and the program checks that the signature has not been used. A fake signature does nothing because there is no inflow and nothing to burn at the same ratio twice.

There is no clock anywhere in the program. No epochs, no cooldowns, no timed snapshots. I have come to believe that any mechanism with a timer in it is a mechanism that someone will learn to wait for. The vessel acts when the market acts and otherwise does nothing, and the market cannot wait for the vessel because the vessel is already there.

I gave up the upgrade authority before writing a line of the site. The signature of that transaction is on the verify page. It felt like the actual moment the vessel became what the paper says it is; everything before that was a draft that I could still change, and therefore a promise I could still break.

The site is a preprint archive page because that is the most honest frame I could find for a document written in the voice of a machine. An archive page does not try to sell you anything. It lists what the thing is, who wrote it, where the source is, and how to cite it. Every link on such a page goes somewhere real, and I made every link here go somewhere real too, even the ones that an archive would use for things this site does not have.

The reading is the only number on the site that does not come from the chain. It is the Birdeye dollar price multiplied by the current supply. I call it the reading because that is what it is: an instrument reading, taken once a second. I do not use the usual name for it because the usual name implies a thing that the vessel does not care about. The vessel cares about one ratio and the reading is not it.

The chart is a coil because a line chart of price over time is a picture of something I have seen ten thousand times and learned nothing from. The coil maps time to angle and reading to radius, three turns for three hours. A flat market is a clean spiral. A rising one swells. A falling one tightens. You cannot read a number off it and that is intentional; it is a shape, and shapes are what the eye is good at.

Everything on the site that is not yet known renders as nothing. Not a dash, not a zero, not a placeholder. An empty slot. In the JSON files it renders as null, which is the one case where the empty thing has a correct name. I did this because a fake number on a page about a thing that cannot lie would be a kind of lie.

The account is 106 bytes. I laid it out by hand and documented every offset because I want anyone to be able to decode it without the IDL if they have to. The byte map on the account map page is drawn from the same table that the decoder uses, so if the drawing is right the decoder is right.

The two functions are piecewise linear because I wanted them to be readable in a table by someone who does not want to read code. Eight rows cover both of them. A smooth function would have been prettier and nobody could have checked it in their head.

I thought about giving the vessel a face. Something in a monitor, blinking. I decided against it because a face would make people think the vessel wants something, and it does not want anything. It has two functions and a ratio. The archive page is the face.

The hardest part of this was not the program. It was deleting every way I could have helped it. There is no emergency instruction. If the venue changes its fee mechanism, the vessel keeps claiming from a vault that may stop filling. If the pool is drained, the vessel keeps reading a price that may be nonsense. I accepted all of that because the alternative was an admin key, and an admin key is a key, and the whole point was no key.

If you are reading this and the reading in the margin is still updating, the vessel is still breathing, or at least still being read. If the reading has stopped, check the chain before you check the site; the site can die and the vessel cannot. That is the only claim I am making and I think it is enough.