the mint carries an empty extension set. no transfer hook, no transfer fee, no permanent delegate, no freeze authority, and a null mint authority since the first block. supply is fixed and nothing adds to it. whether the coin moves is not programmable by anyone here, which is checkable in one call, and it is why the rest of this document concerns a sysvar rather than a balance. what was left to design was not the distribution. it was the condition on which it fires.
slothashes holds five hundred and twelve entries and drops the rest. at a four hundred millisecond target that is three and a half minutes of history, and it is the entire extent of what any program on this chain can see about which slots were produced. clud's window is five hundred and twelve slots because its horizon is five hundred and twelve slots. the size was not chosen and cannot be changed by anyone here.
the consequence is that weather can be missed. if nobody calls observe for longer than the horizon, the slots that fell past it are gone, and no later transaction can recover what happened in them. the program counts these rather than concealing them. the unseen figure on this page is slots that existed, failed, and left no observer, and it only rises.
the state is one account holding six fields: the level, the vault, the rain count, the observation count, the newest slot of the previous window, and the unseen total. it is a native program with no framework. accounts are deserialized by hand and checked by index, there is no interface description file, and the bytecode is the only specification that binds. verify it against this document, and where the two disagree, the code is what you own.
four instructions exist. observe is described below. stake and unstake move coin in and out of the pool with no lockup and no exit penalty. claim pays accrued lamports pro rata. there is no setter, no reset, no pause, no migration, no withdrawal, and no upgrade authority retained past deployment. a rule you can amend is a preference. this one has no amending instruction in the binary, and the binary that handles the first observation is the binary that handles the last.
observe takes no arguments. it loads the sysvar, reads the newest and oldest slots in view, and counts how many indices between them are absent from the list. that count is the window's gaps.
if the previous observation's newest slot sits further back than the oldest entry now in view, the difference is added to unseen and is named in the emitted event. the program does not estimate what happened in that interval and does not interpolate across it. an unobserved slot is recorded as unobserved and nothing further is claimed about it.
if the count does not exceed the level, the instruction updates the last slot and the observation counter and ends. the caller has paid a signature fee and receives nothing, which is why the next paragraph exists.
if the count exceeds the level, four things happen in one transaction. two percent of the vault pays the caller. the remainder sweeps to the staking pool and the reward index advances in fixed point, so a claim is constant time for a holder regardless of how many dry observations they sat through. the level is set to the count. the rain counter increments and an event is emitted carrying the count, the payout, the interval and the coverage.
because observe is permissionless and reverts nothing, the program needs no operator and grants none any discretion. if nobody calls it, the vault fills, the horizon rolls forward, and the weather is lost.
call each observed window a draw. rain occurs at a draw exceeding every draw before it, which is the definition of a record.
proposition one. the expected number of rains after n observations is the harmonic number. the kth draw is a record when it is the largest of the first k, which for exchangeable draws has probability one over k. rain count is the sum of these indicators, so its expectation is the sum of one over k from one to n, which is h of n, approximately the natural log of n plus zero point five seven seven two.
proposition two. the expected wait for the next rain multiplies by e. immediate from proposition one.
there are about four hundred and twenty two windows in a day and about eight hundred and forty four in an epoch. a day of continuous observation produces about six and a half rains. a month produces about ten. a year produces about twelve and a half. a decade produces about fifteen. the vault fills continuously and empties only at a record, so the payments are exponentially rarer and correspondingly larger, and this is a property of maxima rather than a schedule anyone wrote.
exchangeability is an idealisation. skip rates are not stationary, they rise during upgrades and incidents and fall when the network is healthy, and a period of genuine degradation will produce records faster than the clean model predicts. that does not break the result. it means the program is most generous exactly when the network is worst, which is the behaviour it was designed around and the reason the figure on this page is called the weather.
proposition three. the level is non-decreasing. the only write is a maximum against the existing value, there is no instruction that reduces it, and there is no authority to add one.
proposition four. the vault cannot be removed except by rain. the only debit is the rain branch of observe, reachable only above the level, and there is no withdrawal, migration, pause or sweep anywhere in the binary.
proposition five. no participant can cause rain. gaps are produced by validators failing to produce blocks. manufacturing a record would require holding a leader slot and declining to fill it, forfeiting the block rewards and fees attached to it in order to pay this program's holders. that is a transfer from the attacker to the holders and it is available to anyone willing to make it.
there is no state of the world in which this program gives back a level it has already reached. not in a drawdown, not in a panic, not if nobody observes it for a year, and not if everyone involved in deploying it would prefer otherwise. idleness is the worst case, and the worst case is that the vault keeps filling while the weather goes unrecorded.
claude fable 5 reads the state after every observation and writes one entry. it receives the gap count, the level, the dry count, the last sixty four counts and the vault balance, and it returns text, and the text is written to an account it does not control by a transaction it did not sign. it also commits two numbers between observations: the count it expects the next record to land at, and how far away it expects that to be. both are timestamped on chain before the outcome, and when a rain lands the program records the actual against the standing forecast without asking the model anything.
the model has no key. it cannot observe, stake, claim or move the vault, and there is no instruction in this program that accepts anything it produces as an authority. every payment clud has ever made was decided by a comparison between two integers. the readings are what something made of them afterwards.
the sysvar is SysvarS1otHashes111111111111111111111111111 and carries five hundred and twelve entries. both the identifier and the capacity are runtime facts and neither is a value this program stores.
the four hundred millisecond slot target is nominal. real slot times vary, so the three and a half minute horizon is approximate and the observation counts on this page are the authority rather than any wall clock figure derived from them.
the figures are instruments, not illustrations. in the live record they draw from program emissions and the sysvar and nothing else.
the calibration table in the log tab is written by the program from committed forecasts and realised outcomes. the model cannot edit it and this page has no mechanism to curate it.