Shaft

What a keeper stakes, and what a report has to survive to be paid

Reporting a yield figure into this program is work someone can be punished for: a keeper posts a bond the program can take, and the authority can take it. The half that pays a report which stands up is on chain, and its terms are read off the account that holds them rather than written here. Whether it has ever paid anyone is a separate question, and the lifetime figures below are the answer. What the chain does not decide is whether a report was true, and that is stated at the foot of this page rather than left out of it.

Where the reward is right now

Bond and slashing deployedReward instructions deployedReward policy on chain

The reward ledger exists on chain and the figures below are read out of it rather than written here. There is no setter for any of them: they were fixed in the transaction that created the account, and changing one is a program upgrade.

Share a surviving report earns: 0.05%
Challenge window: 7 days
Bond required per unit vouched: 10,000 : 1
Paid to reporters, lifetime: 0
Burned, lifetime: 0

The last two are internal accounting units rather than an asset amount. They are here because a mechanism that has never paid and a mechanism that has are different things, and a figure that started at zero is the only way to tell them apart from outside.

Choose a wallet

No Solana wallet is reachable from this browser. Phantom, Solflare and Backpack all announce themselves to a page through the same standard this control reads. Install one and reload, and it appears here on its own.

Vouch for what this seam earned

seam 1

The figure you post stands for 7 days. It earns 0.05% of the amount it vouched for if it is still standing at the end, and the bond behind it is what the program takes if it is not.

Realised, not yet vouched: reading
Your bond: connect a wallet
Bond this would take: enter an amount

Amount to vouch for, in BTC

Connect a wallet to vouch.

Already on chain

Deployed

Being able to punish a bad report is not a plan here. These three are in the program running on mainnet now, and the reward is built on top of them rather than beside them.

bond_keeperA keeper posts $LODZ the program can take. Reporting without a bond is not possible; the account that records the stake is the same one the reward will later check.
slash_keeperThe authority takes a bonded keeper's stake. This is the instruction the challenge window is built on -- a challenge is not a new mechanism, it is this one, called in time.
unbond_keeperA keeper withdraws their stake and stops being able to report.

What the upgrade added

Deployed 2026-08-22

Three instructions and three new accounts. The upgrade changed no existing account and no existing instruction: every account the vault already held decodes byte for byte the same afterwards, which is what makes it an addition rather than a migration.

Deployed is where this stops being a statement about code and starts being one about state. The first of the three has to run before either of the others can, and the panel at the top of this page is what says whether it has, because it reads the account rather than this sentence.

initialize_reward_ledgerFixes the reward policy once: the share a surviving report earns, how long it must stand, and the collateral ratio a vouch requires. There is no setter, so changing any of them later is a program upgrade.
open_attestationA bonded keeper vouches for realized yield the chain has already received. The vouch cannot exceed what that seam actually realized and has not already been vouched for, and it requires a bond proportional to its size.
claim_attestation_rewardAfter the window has passed with the bond unslashed and still standing, the keeper claims a share of the redemption fees that have physically accumulated. Two independent caps decide whether that is possible at all.

How a report earns

1Post a bond the program can takeA keeper stakes $LODZ before it can report anything. The stake required to vouch is proportional to the size of what is being vouched for, so covering more work means risking more.
2Vouch for yield the chain already receivedA vouch cannot exceed what that seam actually realized and has not already been vouched for. It is bounded by tokens the program watched arrive, not by a figure anyone typed, so a reward can never be paid against yield that did not happen.
3Stand through the challenge windowThe challenge is not a new mechanism. It is the authority calling the slash instruction that is already deployed, within the window. A report that is slashed earns nothing and loses the bond; a report that is not is claimable when the window has passed.
4Claim a share of the fees, with the bond still standingThe bond is checked again at the moment of payment, not only when the vouch was made. That is what stops a keeper vouching, pulling their stake, and then claiming: the stake has to be there when the reward pays.

What a reward can never reach

A payment out of a vault holding other people’s deposits is the shape of the thing that goes wrong most often, so it is bounded twice and both bounds have to hold.

Every deposit and every queued ticket is reserved first: Before a reward moves, the program requires the vault to still hold the full value of every live share and every redemption already in the queue, as though all of them were paid out of that one asset at once. Only what is above that line can be touched. The figures come from reading the vault balance and the queues at that moment rather than from a running total kept somewhere.
Nothing beyond the fees actually collected: Separately, the lifetime total paid out can never exceed the redemption fees the program has recorded. That is what makes a reward a share of a fee rather than a share of the deposits: with no fees collected there is nothing to pay, and the claim fails instead of finding the money somewhere else.

Both new instructions also stop while the vault is paused. That is the opposite of the redemption claim, which deliberately ignores a pause because stranding somebody’s settled principal is the thing a pause must never be able to do. A keeper reward is not settled principal, so it can wait -- and pausing is therefore also a way to freeze a report that is being argued about after its window has closed.

What the chain does not guarantee

A report earns its reward by surviving the window without being slashed, and the only party who can slash it is the authority. The authority is the challenger.

That does not make this trustless and it is not offered as though it did. An inattentive authority can let a bad report mature into a payment. A malicious one can slash an honest keeper and take the bond. Neither is prevented by anything described above.

What the chain does guarantee is narrower, and it is worth having on its own terms: no reward is paid without a bond that was posted, slashable, and still standing when the payment was made; no vouch can exceed the yield the program actually received; and no payment can cross the reserve that covers every deposit and every queued ticket, or exceed the fees that were actually collected. Those are bounds on the money. The judgement about whether a report was true is not one of them.

There is one keeper today and it is the operator, so the same party reports, challenges and would be paid. That is worth knowing before any of the above reads as a check on anybody.

Advancing

What a keeper stakes, and what a report has to survive to be paid

How a report earns

1Post a bond the program can takeA keeper stakes $LODZ before it can report anything. The stake required to vouch is proportional to the size of what is being vouched for, so covering more work means risking more.

2Vouch for yield the chain already receivedA vouch cannot exceed what that seam actually realized and has not already been vouched for. It is bounded by tokens the program watched arrive, not by a figure anyone typed, so a reward can never be paid against yield that did not happen.

3Stand through the challenge windowThe challenge is not a new mechanism. It is the authority calling the slash instruction that is already deployed, within the window. A report that is slashed earns nothing and loses the bond; a report that is not is claimable when the window has passed.

4Claim a share of the fees, with the bond still standingThe bond is checked again at the moment of payment, not only when the vouch was made. That is what stops a keeper vouching, pulling their stake, and then claiming: the stake has to be there when the reward pays.

What a reward can never reach

A payment out of a vault holding other people’s deposits is the shape of the thing that goes wrong most often, so it is bounded twice and both bounds have to hold.

Every deposit and every queued ticket is reserved first

Before a reward moves, the program requires the vault to still hold the full value of every live share and every redemption already in the queue, as though all of them were paid out of that one asset at once. Only what is above that line can be touched. The figures come from reading the vault balance and the queues at that moment rather than from a running total kept somewhere.

Nothing beyond the fees actually collected

Separately, the lifetime total paid out can never exceed the redemption fees the program has recorded. That is what makes a reward a share of a fee rather than a share of the deposits: with no fees collected there is nothing to pay, and the claim fails instead of finding the money somewhere else.

What the chain does not guarantee

A report earns its reward by surviving the window without being slashed, and the only party who can slash it is the authority. The authority is the challenger.

There is one keeper today and it is the operator, so the same party reports, challenges and would be paid. That is worth knowing before any of the above reads as a check on anybody.