# What a stake actually records: the row, the weight and the accumulator > Canonical: https://blazephoenix.xyz/learn/what-a-stake-records > License: CC BY 4.0 (attribution + link) · © 2026 BlazePhoenix > Updated: 2026-08-13 A stake is one written row — amount, lock end, a multiplier fixed by lock length from 1.02x at 90 days to 2.75x at 7 years, and an accumulator checkpoint — and your reward is your weight's share of a fixed budget, a fraction that falls whenever anyone else stakes or locks longer. All arithmetic rounds down with no round-up operation anywhere, so the sum of payouts can never exceed what the contract holds. Staking is usually explained by what it feels like: you lock tokens, and rewards appear. That description is useless for deciding anything, because it does not tell you where the rewards come from, what determines your share of them, or what happens if everyone does the same thing. So this article does the opposite. It shows what is actually written down when you stake, and derives everything else from that. ## The row When you stake, the contract writes one record. It holds your address, the amount you locked, the moment the lock ends, a multiplier fixed by how long you chose, and a checkpoint of a running counter that the next section explains. Note what is not in the row: any promised rate, any yield figure, and any amount owed to you. Nothing in the record says the protocol will pay you a percentage. Your reward is computed from your share of a budget, and your share is computed from that row against everyone else's. The lock end is a timestamp, and the rules that key off it are in the contract. Read them there before committing tokens, rather than from any article, including this one. ## The multiplier, and why it is the whole design The lock length you choose fixes a multiplier, and the range runs from 90 days to 7 years: ``` 90 days 1.02x 1 year 1.10x 2 years 1.25x 4 years 1.70x 7 years 2.75x ``` Your weight is your amount multiplied by that number, and weight — not amount — is what determines your share. Work an example with two people: ``` A stakes 10,000 for 90 days: 10,000 x 1.02 = 10,200 B stakes 5,000 for 7 years: 5,000 x 2.75 = 13,750 ------ total weight 23,950 A share: 10,200 / 23,950 = 42.5887% B share: 13,750 / 23,950 = 57.4113% ``` B staked half as many tokens as A and holds the larger share. Nothing was granted to B for loyalty; the multiplier is the price paid for accepting a lock that lasts twenty-eight times longer, and it is exactly the illiquidity that is being compensated. Read the consequence in the other direction, because it is the one that affects you. Your share is a fraction with everyone else in the denominator. It falls whenever anyone stakes, and it falls whenever anyone lengthens a lock, without anything happening to your own row. A staking page showing you a rate is showing you a snapshot of that denominator, not a property of your stake. ## The rounding rule, in numbers Suppose a period distributes 1,000,000 tokens between A and B in the shares above. The exact amounts are: ``` A: 1,000,000 x 10,200 / 23,950 = 425,887.265... B: 1,000,000 x 13,750 / 23,950 = 574,112.734... ``` Chain arithmetic has no fractions, so both numbers are truncated — the protocol rounds down everywhere and has no round-up operation at all. A receives 425,887 and B receives 574,112, which add to 999,999. One unit stays in the contract. That single leftover unit is the whole point of the rule. Rounding in the user's favour would mean the sum of the payouts could exceed the amount available, and a contract that can promise more than it holds is a contract that will eventually fail to pay someone. Rounding down means the residue always accumulates on the contract's side. The cost of that choice is that you are always paid slightly less than the exact fraction, by less than one indivisible unit. ## The accumulator: how payouts are computed without a loop There is a practical problem hidden here. If ten thousand people are staked, the contract cannot walk through ten thousand rows every time it needs to update rewards — the work would grow without limit and eventually no transaction could afford to complete. The solution is a single running counter: the total rewards paid per unit of weight, since the beginning. Call it the accumulator. When you stake, the row records the value the accumulator had at that moment. Your reward at any later time is: ``` reward = your weight x (accumulator now - accumulator at your checkpoint) ``` Put numbers on it. Your weight is 10,200. The accumulator stood at 0.02 when you staked and stands at 0.05 now. Your reward is 10,200 x (0.05 - 0.02) = 10,200 x 0.03 = 306 tokens. Two properties fall out of this and both are worth understanding. Your payout depends only on your own row and one shared number, so the work is the same whether there are ten stakers or ten million. And rewards that accrued before you staked are unreachable to you by construction — not by a rule someone wrote, but because the difference of the two accumulator values simply does not include them. A single accumulator would blur different kinds of payment together. This protocol keeps two separate ones, so that emission rewards and interest are never funded out of each other; the article on the dual accumulator takes that apart. ## The second row: debt A stake can also be borrowed against, and this adds a second record: how much you owe. The rule is that your debt may not exceed 50% of your net equity, where equity is your stake minus what you already owe. That phrasing hides the actual ceiling, so derive it. Write S for your stake and D for your debt. The condition is D <= 0.5 x (S - D). Multiply out: D <= 0.5S - 0.5D, so 1.5D <= 0.5S, so: ``` D <= S / 3 with S = 30,000: D <= 10,000 equity = 30,000 - 10,000 = 20,000 and 10,000 is exactly 50% of 20,000 (check) ``` So a "50% loan-to-value" rule is a ceiling of one third, not one half, and the difference is not a technicality — it is the difference between borrowing 15,000 and 10,000 against the same 30,000. Anyone quoting the 50% without deriving the third has not read the condition. Liquidation happens when debt reaches 95% of the stake. Compare the two lines: you may open a position at 33.33% and you are liquidated at 95%, so the debt has to grow to about 0.95 / 0.3333 = 2.85 times its opening size, relative to the same stake, before that line is reached. That distance is the margin the design gives you, and it is a number you can check rather than a reassurance. ## What has not been verified The trading contracts carry machine-checked proofs: two symbolic specifications must pass before any change can be merged, static analysis fails the build on any high-severity finding, and a size guard is set tighter than the chain's own limit. A third specification times out rather than completing, and a specification that times out proves nothing — it is listed here because leaving it out would make the other two sound like more than they are. The staking contract has neither. No prover and no static analyser run against it in the pipeline today. Seven findings have been disclosed in the staking contract and one in the router, with three external researchers involved and one of the seven found internally. That is a stronger signal than a clean record would be, because it means people looked and reported. But it also means the phrase "solvency-enforced" is one this project does not use about staking, and if you read it anywhere about this protocol, it is wrong. **Verify it yourself:** Read your own row: on a block explorer, open the staking contract at 0x3f60C7aa0c36a78D200405feBE143d2Cf3fA0c77, choose the Read tab, and look up your address. Multiply your amount by the multiplier for your lock length and compare it with the weight the contract stores. Related: https://blazephoenix.xyz/learn/the-halving-schedule · https://blazephoenix.xyz/learn/what-is-staking · https://blazephoenix.xyz/learn/the-dual-accumulator · https://blazephoenix.xyz/learn/reading-the-staking-screen · https://blazephoenix.xyz/learn/oracle-free-lending