1/n

the wheel, the entrants, the drawer

abstract: there are n links on a wheel and money is the only argument any of them gets to make. this page describes a program on solana that holds up to 256 links in one account, assigns each a weight equal to the lamports paid for it, and on demand selects exactly one with probability equal to its weight over the total. the selection is not performed by us, because there is no us. it is performed by a walk down a binary indexed tree, seeded by the hash of a slot that had not happened yet when the request was signed. every draw leaves a receipt account behind it, so the complete history of the wheel can be recounted by anyone with a public rpc connection. entries live for roughly 216000 slots, about a day, and die without ceremony. the name is the limit case: when every weight is equal, every link is drawn with probability 1/n. this document is the whole of the machine. there is nothing behind it.

note: this page is a reader. it renders public accounts and signs nothing on its own.

keywords: weighted selection, slot hash entropy, binary indexed trees, fixed capacity machines

1. the wheel

the object described here is a wheel of links. anyone may pay to place a link on it, and the payment becomes that link's weight. anyone may then draw, and the draw selects exactly one link, with probability equal to its weight divided by the sum of all live weights. that fraction is the entire product. there is no feed, no ranking, no editorial judgment, and no second mechanism hiding behind the first. a link that wants to be chosen more often has exactly one argument available to it, which is more weight, and the argument is priced in public.

the wheel holds at most 256 links at once. this is not a temporary limitation but a structural decision, discussed in section 3, that keeps the cost of every operation flat forever. when every entrant pays the same amount, the wheel degenerates into the uniform distribution and every link is drawn with probability 1/n, which is where the name comes from, and which is rendered as fig. 1. the page you are reading does not operate the wheel. it reads the single account the wheel lives in and lets a connected wallet sign for itself. if this page vanished, the machine would not notice.

fig. 1: the limit case. every weight equal, every arc the same size, p = 1/n.

2. weight

an entrant is a pair: a link, which is any string the entrant wants drawn, and a weight, which is the number of lamports the entrant paid to place it. weight is additive. paying again for a link that is already live adds to its weight rather than creating a second entry. the probability that link i is drawn is

p_i = w_i / Σ_j w_j (1)

which is to say that doubling a weight doubles the odds only while everyone else stands still. the wheel does not reward early arrival, loyalty, or followers. it rewards exactly the thing in equation (1). fig. 2 is a small wheel you can load yourself. nothing in it touches the chain.

link weight

five links, unequal weights. draw to see a selection.

fig. 2: a toy wheel in your browser. arc length is weight over total, eq. (1). the highlighted arc is the last draw.

3. fixed capacity

a wheel that grows without bound has operations that grow with it, and a program whose costs drift upward eventually stops fitting in a transaction. the wheel therefore lives in a single account of fixed size, with room for exactly 256 slots. a slot is either live or empty. placing a link fills the lowest empty slot, and an expired link frees its slot for the next entrant. because the account never resizes, every operation touches the same bounded number of bytes, and the compute it consumes is the same on the first day as on the thousandth.

when the wheel is full, a new entrant waits for an expiry. this is deliberate. a full wheel is a wheel in which every slot has been paid for in the last day, and the queue is the price signal.

4. the drawer

selection is a walk down a binary indexed tree laid over the 256 slots. each node stores the sum of the weights beneath it, so updating a weight touches log₂(256) = 8 nodes, and drawing touches the same 8. given a target t drawn uniformly from [0, Σw), the walk descends from the root, going left when t is smaller than the left subtree's sum and otherwise subtracting that sum and going right. it ends at exactly one slot, and the slot it ends at is the selection. fig. 3 shows the walk on a tree of eight.

target t

fig. 3: eight slots with weights shown at the leaves. the highlighted path is the walk for the chosen t; it visits one node per level.

5. entropy

the target t needs a source of randomness that nobody can see in advance, including us. a draw is therefore two transactions. the first, request, records a future slot number, some distance ahead of the current one. the second, settle, may only be sent after that slot has passed, and it reads the slot's hash from the chain's own record of recent hashes and reduces it modulo Σw. when the request was signed, the slot did not exist yet, so neither the requester nor anyone else could know what its hash would be. the current slot, read live, is ….

this is not perfect randomness. a block producer for the chosen slot has, in principle, a narrow window to influence it. the wheel accepts that cost in exchange for having no oracle, no committee, and nothing off chain.

6. lifetime

an entry lives for 216000 slots. at roughly 0.4 seconds a slot, that is about a day. after that the entry is dead: it is skipped by the drawer, its weight is removed from the tree on the next write, and its slot is free. the lamports it paid are not returned. a link placed now would expire near slot …, around ….

7. receipts

every settle writes a small receipt account: the requested slot, the slot hash, the total weight at the moment of the draw, the target, and the selected link. receipts are never closed. together they are the wheel's entire history, and anyone can recompute any draw from them with nothing but a public rpc connection and equation (1).

8. limitations

the wheel does not judge links. a link can be anything, and being drawn says nothing about it except that it was drawn. money placed on the wheel is spent, not staked; there is no refund, no yield, and no promise. the slot-hash entropy described in section 5 is good enough for a wheel and not good enough for a lottery with large stakes. read the accounts before you trust them.

9. the token

the wheel has a token, also named 1/n, on solana. it is listed in the references as [1] and its market cap is printed in the top left corner of this page, read live. holding it changes nothing about the wheel: it buys no weight, no odds, and no vote. it is a memecoin about a machine that does one thing.

references

1/n. the token. mint address: soon. available at pump.fun; chart at dexscreener.
1/n. public correspondence. x.com.
P. M. Fenwick. a new data structure for cumulative frequency tables. software: practice and experience, 24(3), 1994.
solana. the SlotHashes sysvar. the chain's record of recent slot hashes, readable by any program.

1/n · a reader for a machine on solananothing on this page is financial advice.

1/n: docs

← back to the paper

a. parameters b. accounts c. instructions d. errors e. verifying a draw f. addresses

a. parameters

table 1: fixed parameters. none of them can be changed after deployment.
name	value	meaning
`CAPACITY`	256	maximum live links on the wheel
`TTL_SLOTS`	216000	lifetime of an entry, about a day
`TREE_DEPTH`	8	log₂ of capacity; nodes touched per update or draw
`MIN_DELAY`	≥ 1 slot	distance between request and the slot whose hash is used
`LINK_MAX`	200 bytes	maximum length of a link string

b. accounts

table 2: the three account kinds. the wheel is one account; requests and receipts are one per draw.
account	holds
`Wheel`	the 256 slots (link, weight, placed_at), the tree of partial sums, and the running total.
`Request`	the requester, the target slot, and the slot at which it was made. closed by settle.
`Receipt`	requested slot, slot hash, total weight, target t, selected slot and link. never closed.

c. instructions

table 3: every instruction is permissionless. there is no admin instruction.
instruction	who	what it does
`place(link, lamports)`	anyone	adds weight to a live link, or fills the lowest free slot with a new one.
`request()`	anyone	records a future slot whose hash will seed the next draw.
`settle()`	anyone	after the target slot, reads its hash, walks the tree, writes a receipt.
`sweep()`	anyone	removes expired entries from the tree and frees their slots.

d. errors

table 4: errors the program can return.
error	when
`WheelFull`	all 256 slots are live and the link is new.
`TooEarly`	settle was sent before the target slot passed.
`HashExpired`	the target slot is too old to appear in the SlotHashes sysvar; request again.
`EmptyWheel`	a draw was requested with zero live weight.
`LinkTooLong`	the link is longer than 200 bytes.

e. verifying a draw

take any receipt. read its slot hash and its total weight Σw. interpret the first eight bytes of the hash as a little-endian unsigned integer and reduce it modulo Σw; that is t. walk the tree as in section 4 of the paper, using the weights that were live at the requested slot. you should land on the slot the receipt names. if you do not, the machine is broken, and you have the proof.

f. addresses

token mint: soon
program: published at deployment
wheel account: published at deployment

1/n · docsback to the paper