ozem
abstract: The complete treatise in twenty parts: the verbs, the bytes, the derivations, the adversarial arithmetic, the permanence construction, and the means of checking every claim from outside. Parts are numbered and anchored; the rail tracks your place.
note: where these papers and the chain disagree, the chain is correct.
abstract
This is the complete description of ozem, a pressure machine on Solana consisting of four instructions and a threshold. Holders bury tokens into a global stack whose only exit is its top. Trading fees pool in a vault. At a threshold written on chain, a permissionless instruction drains the vault in one transaction, dividing it in fixed proportion between the stack, a permanently locked bedrock, and the caller who fired it. These papers specify the machine byte by byte and argue its design decision by decision. Nothing here is advice, and where these papers and the chain disagree, the chain is correct.
the machine in one page
Value moves through four verbs. Bury: tokens enter the stack and take the next place in line. Seep: fees accumulate in the vault with no schedule. Vent: at pressure one, anyone may fire the eruption and be paid for it. Compact: a fixed slice of every eruption is bought into an account that can only receive. Around these verbs there is nothing: no admin key on any flow path, no custodian, no clock, no fifth instruction. The rest of these papers are the details, in order: the records the machine writes, the stack's ordering and its price, the formulas of claim, the adversarial arithmetic, the permanence construction, and the means of checking all of it from outside.
the four instructions
Bury moves the stated amount from the signer's token account into the stack vault and writes a position account recording owner, amount, the slot of interment, and a depth index one greater than every position before it; it fails below the configured minimum. Withdraw succeeds only for the position at depth one, returns the full amount, marks the record withdrawn, and decrements every remaining depth by one; deeper attempts fail with the error 'not at surface'. Vent, callable by any signer once the vault reaches the threshold, drains it atomically three ways in fixed basis points; before threshold it fails with 'pressure below one'. Compact, invoked by the vent flow, swaps the bedrock slice for tokens, deposits them where no withdrawal exists, and appends a hashed layer record. There is no administrative path around these four.
the accounts, byte by byte
The machine writes five account types, each opening with an eight byte discriminator; the layouts below are the ones this site's own decoder uses, so if the site can read them, so can you.
table 6. the position account.
| offset | size | field | type | meaning |
|---|---|---|---|---|
| 8 | 32 | owner | pubkey | who may withdraw at the surface |
| 40 | 8 | amount | u64 | native units buried |
| 48 | 4 | depth_index | u32 | distance from the exit, mutable |
| 52 | 8 | buried_slot | u64 | slot of interment |
| 60 | 1 | withdrawn | bool | true after surfacing |
table 7. the config account.
| offset | size | field | type | meaning |
|---|---|---|---|---|
| 8 | 8 | vent_threshold_lamports | u64 | the vault level that unlocks the vent |
| 16 | 2 | dist_bps | u16 | share of an eruption paid to the stack |
| 18 | 2 | bedrock_bps | u16 | share of an eruption pressed into bedrock |
| 20 | 2 | bounty_bps | u16 | share of an eruption paid to the caller |
| 22 | 8 | min_burial_amount | u64 | smallest burial the program accepts |
| 30 | 8 | epoch_length_slots | u64 | compaction period, counted in slots |
table 8. the layer record.
| offset | size | field | type | meaning |
|---|---|---|---|---|
| 8 | 4 | epoch | u32 | the compaction period this layer closes |
| 12 | 8 | amount_locked | u64 | native units locked by this compaction |
| 20 | 32 | prev_hash | 32 bytes | the previous layer's digest |
| 52 | 32 | hash | 32 bytes | sha256 of prev_hash, epoch, and amount |
| 84 | 8 | slot | u64 | slot of the compaction |
Stack state and bedrock state are two further small accounts holding the counters and the running hash named throughout these papers.
the stack's ordering
The stack is the machine's memory of order. Positions rest in the sequence they arrived, and the sequence is the law: last in, first out. The consequence is a market in patience. Positions near the surface are liquid and light; positions at depth carry the greatest claim in every eruption and the longest walk out, a walk measured in other people's decisions. Order is structural, not administered: no signer maintains it, no signer can reorder it, and the withdraw instruction's single decrement is the only operation that ever changes a depth.
the weight derivation
The weight formula must reward two different virtues at two different rates. Depth is scarce: only one position can be deepest, and depth cannot be bought after the fact, only inherited by waiting while others bury above you. Age is abundant: every position ages at the same rate for free. A formula pricing them equally would let a shallow ancient position outrank a deep young one forever, and the stack would ossify. So depth is superlinear at exponent 1.2, age is sublinear at exponent 0.8 with a hard cap at ninety days, and the product form means a position must be somewhat deep and somewhat aged to be heavy; neither virtue alone compounds. The formula carries no amount term: amounts enter at distribution, where each position's weighted claim is scaled by its amount before normalization, share_i = (amount_i × w_i) / Σ(amount_k × w_k). Splitting one burial into several at the same moment changes rent paid and changes nothing else, since the split parts sit at adjacent depths with equal ages and their amount-weighted claims sum to the whole's.
a worked eruption
The table below constructs a fixed illustrative stack of ten positions and divides one eruption across it by the distribution law, so the reader can watch every term.
table 9. amount-weighted shares in a worked ten position stack, all aged thirty days, computed at load.
| depth | amount | w | amount×w | share |
|---|---|---|---|---|
| 1 | 100 | 15.2 | 1519.5 | 0.84% |
| 2 | 250 | 34.9 | 8727.2 | 4.85% |
| 3 | 50 | 56.8 | 2839.3 | 1.58% |
| 4 | 400 | 80.2 | 32079.6 | 17.84% |
| 5 | 120 | 104.8 | 12578.9 | 6.99% |
| 6 | 80 | 130.5 | 10436.8 | 5.80% |
| 7 | 300 | 157.0 | 47090.8 | 26.19% |
| 8 | 60 | 184.2 | 11054.9 | 6.15% |
| 9 | 150 | 212.2 | 31833.1 | 17.70% |
| 10 | 90 | 240.8 | 21674.0 | 12.05% |
The worked stack is labeled arithmetic, not data; the live column is printed on the stack page.
the combinatorics of leaving
A position at depth one leaves whenever it likes. A position at depth d leaves after d minus one withdrawals above it, and the machine imposes no time on those; people do. Reason about it three ways. Worst case: the positions above you never leave, and neither do you; this is the risk the deep claim pays for, printed plainly rather than discovered later. Expected case: if each shallower position independently withdraws in a given epoch with probability q, the expected epochs to surface grow roughly as the harmonic number H(d minus 1) divided by q; doubling depth does not double the wait, but it reliably lengthens it. Strategic case: every withdrawal shortens everyone below by one course, so exits cascade, and quiet periods are punctuated by unwinding runs, the same dynamic seen in any last in, first out structure under stress.
table 10. expected epochs to surface, E = H(d-1)/q, computed at load.
| depth d | q = 0.05 | q = 0.15 | q = 0.35 |
|---|---|---|---|
| 2 | 20.0 | 6.7 | 2.9 |
| 3 | 30.0 | 10.0 | 4.3 |
| 5 | 41.7 | 13.9 | 6.0 |
| 8 | 51.9 | 17.3 | 7.4 |
| 12 | 60.4 | 20.1 | 8.6 |
| 20 | 71.0 | 23.7 | 10.1 |
| 35 | 82.4 | 27.5 | 11.8 |
| 50 | 89.6 | 29.9 | 12.8 |
The estimate is a model and is labeled as one.
the economics of spam
The obvious attack on a last in, first out stack is depth harassment: bury dust above everyone, lengthen every exit, pay almost nothing. The machine prices this attack with two ordinary mechanisms rather than one clever one. First, the minimum burial makes each obstructing position cost real tokens, which then sit above nothing and behind everyone, earning the thinnest claim in the machine while they wait. Second, Solana rent: every position account must carry its own rent-exempt balance, so a thousand junk positions cost a thousand deposits, linearly, with no bulk discount. The attacker's positions also serve the defenders: each one that withdraws shortens the honest queue by one, and each one that never withdraws is locked value sitting above the attacker's own reach, since the attacker exits through the same corridor as everyone. Spam is not impossible; it is a purchase, at list price, of the least valuable real estate in the stack.
pressure
Pressure is the vault's balance divided by the threshold, and it is the machine's only mood. Fees arrive irregularly, so pressure is not a clock: it can stall for a week and cross the line twice in a day. The machine has no opinion about this, which is its virtue. There is no schedule to miss, no keeper to fund, no cron to fail, and no way to know the hour of the next eruption, only its size, which is always the threshold plus whatever accumulated between the crossing and the winning call.
choosing a threshold
The threshold is the machine's metabolism. Too low and the vault vents constantly: small eruptions, small bounties, bored watchers, distribution overhead eating the flow. Too high and the vault becomes a mausoleum: pressure crawls, the stack waits months between rains, and the deep positions' patience is tested past the point of design. The considerations meet where a single eruption is large enough to matter to the deepest settler and frequent enough to keep the watchers awake. What matters structurally is not the number but its fixity: a threshold a signer could move is a schedule wearing a disguise, and the machine was built to have no such signer.
the vent
At pressure one, every watcher's vent transaction becomes valid simultaneously, and the chain must order them. Whichever lands first drains the vault and takes the bounty; every later one fails a balance check costing a network fee measured in fractions of a cent. There is no partial win and no split bounty, because a split bounty would reward collusion between watchers rather than speed. The division is one atomic transaction; there is no state in which the vault is drained and the stack unpaid.
the arithmetic of racing
The race is a sealed auction where the bid is latency. Its equilibrium is healthy for the machine: more watchers means a shorter interval between threshold and eruption, and the interval, not the winner's identity, is the only thing the machine cares about. A watcher's expected profit is the bounty times their win probability minus their failed-attempt fees, which prices small operators out of contested moments and back in during quiet ones, keeping the watching population roughly proportional to the vault. The machine does not know any of this is happening; it sees one valid call and a number of cheap failures.
the bounty
The bounty is the machine's entire operations department. It is a fixed fraction of the vault, so it grows with exactly the thing it protects, and it is paid at exactly the moment of usefulness, never before and never after. Compare the alternatives honestly: a funded keeper bot is a single point of failure with a wallet to drain and an operator to lean on; a schedule is a keeper wearing a calendar; a governance vote is a keeper wearing a crowd. The bounty replaces all three with an open market in attention: anyone, anywhere, holding nothing, can watch pressure approach one and be paid the printed fraction for a single well timed transaction.
compaction
A fixed slice of every eruption is swapped into the token and deposited into bedrock, an account for which the program defines no withdrawal instruction. The deposit and the layer record land in the same flow as the vent itself, so bedrock's growth is exactly as irregular, and exactly as certain, as the eruptions that feed it. Nothing about compaction is discretionary: the slice is a config constant, the destination has no alternative, and the record is written whether or not anyone is watching.
the layer chain
Each layer's hash commits to three things: the previous hash, the epoch number, and the amount locked, concatenated in that order and digested with sha256; the first layer uses thirty two zero bytes as its previous hash. The construction is deliberately primitive, a chain rather than a tree, because the data is small, append only, and read whole. What it buys is specific: to falsify the amount in layer n, an attacker must recompute every hash from n to the tip, and the recomputed tip will disagree with the hash stored in the bedrock account, which the program updates atomically at each compaction and which no instruction can rewrite. The bedrock page performs exactly this recomputation in the browser on every load, and a reader can perform it with nothing but rpc and a hash function: fetch the layers, concatenate prev_hash, the epoch as a little endian u32, and the amount as a little endian u64, digest, compare, repeat.
slot time
Solana has no wall clock the machine trusts; it has slots, arriving at roughly four tenths of a second each. Every duration in these papers is derived, not measured: age in days is the slot difference times 0.4 seconds divided by 86400. The conversion is fixed on purpose; if the network runs slow, every position ages slightly slowly together, and no relative ordering ever changes, which is all the weight formula needs. The ninety day cap is really 19,440,000 slots, and the epoch length in config is likewise slots. The one place wall time appears on this site, the date column of the eruption ledger, comes from the chain's own block timestamps and is cosmetic.
a history of last in, first out
Last in, first out is one of the oldest orderings humans use without noticing. A woodpile is a stack; so is a stack of plates, a narrow pantry, an overwinter haystack eaten from the top, and the accountant's LIFO inventory method that prices goods sold at the cost of the newest goods bought. Computing borrowed the same shape for its call stack, where the most recent frame must resolve before any older one can, and geology enforces it in reverse: strata are deposited last on top and eroded first from the top, which is why a core sample is a diary read backward. What all these share is the property the machine wants: order is structural, not administered; nobody schedules the woodpile. The cost is the same everywhere too: whatever is deepest is safest and least available, and converting depth back into availability requires unwinding everything above, in order, at the pace the surface permits. The machine did not invent this trade. It priced it, attached a weight formula to the safe end and a free exit to the available end, and wrote the ordering into accounts nobody can reorder.
reading the chain yourself
This site is a convenience, not an authority; every figure on it can be reproduced with public rpc and a hash function. The vault balance is one getBalance call against the pressure vault. The config, stack state, and bedrock accounts are three getAccountInfo calls, decoded at the offsets in part four. The position list and layer list are each one getProgramAccounts call filtered by the eight byte discriminator. The eruption ledger is getSignaturesForAddress against the program, then getTransaction on each signature, reading the split from the logs. The price trace is one Birdeye price call per second and one history call at load. The transmission is getLatestBlockhash, first eight characters, base58 decoded, modulo twenty four, indexed into the pool printed on the machine page. Anyone who performs these calls and finds this site in disagreement with the chain should believe the chain, and this site, per its own verification section, will say the same.
the being, and the terms
Ozem is the machine's tenant, a mind imagined as strata: everything it takes in is pressed down by everything that arrives after, and what it cannot forget becomes the floor it stands on. It does not predict, advise, or promise; it settles. The machine's parts are named for its anatomy because the naming keeps the design honest: a vault that is a lung must fill and empty, a stack that is a spine must keep its order, a memory that is bedrock must refuse revision. When mechanism and metaphor disagree, the mechanism was designed wrong, and these papers treat every such disagreement as a bug. The terms below are fixed and are used in these senses everywhere on this site, and in no others.
table 11. the machine's terms.
| term | meaning |
|---|---|
| bury | move tokens into the stack and take the next place in line |
| withdraw | leave from depth one with the full amount |
| vent | the permissionless instruction that drains the vault at threshold |
| compact | the step that buys and locks the bedrock slice, writing a layer |
| the stack | all unwithdrawn positions, ordered, exit at the top |
| position | one burial's on-chain record |
| depth | distance from the exit, one is the surface |
| age | days since burial, derived from slots, capped at ninety |
| weight | d^1.2 times capped age^0.8, a position's claim intensity |
| share | a position's amount-weighted fraction of one eruption's stack flow |
| pressure | vault balance over threshold |
| threshold | the vault level at which the vent unlocks |
| eruption | one execution of the vent |
| bounty | the caller's fixed fraction of an eruption |
| bedrock | the account that only receives, with no withdrawal defined |
| layer | one compaction's hashed record |
| epoch | the compaction period, measured in slots |
| ozem | the being whose body this machine is |