Articles Β· Staking
What is withheld from those who leave is not handed to the remaining stakers at once β it is paid out evenly, and that payout has a window. It feels as though several exits in a row should chain their windows together. The contract does it differently, and the difference explains why the pool's yield moves in sawtooth steps.
5 October 2026 Β· verified at publication
The window is counted from each exit separately and never exceeds seven days. Three large exits in a row do not give twenty-one days: each one resets the window and counts seven afresh from itself. The windows do not form a chain β they overlap.
The orange ticks are the moments of the exits, the blue rectangles are the distribution windows, and the figure inside each one is its length in days. Three exits in the first two days close the payout on the ninth day, not the twenty-first. Nor can the end fall any later in principle: every window runs exactly seven days from its own exit.
The staking pool has a single source of income β the fee withheld from those who leave. When a staker takes the position back, the contract keeps 10% of the whole of it in the pool, accrued earnings included. You can verify this in the source itself: the undistributedFees counter increases in exactly one place, inside the unstake function.
But what is withheld is not paid out at once. It lands in the "pot" of undistributed fees and flows out of it evenly, at a constant rewardRate measured in RNBW per second. While it flows, the share price rises β that is, the addition reaches everyone in the pool, in proportion to the size of their position. Nobody receives new shares: every existing one simply becomes worth more.
So the yield on staking depends not on how many people joined, but on how many left. Inflows push it down: the same stream of coins is split across a larger pool. Outflows push it up, and twice over β the pool shrinks, and a tenth of whoever left is added to it.
A new fee is not simply added to the old one. The contract recalculates the speed at which everything will now drain and picks one of three branches. The choice comes down to a single comparison: is the new speed higher than the current one or not.
No payout is running β the previous window has already expired
The speed equals the pot divided by seven days. Everything starts from a clean slate.
window β exactly 7 days
Pot Γ· 7 days is not less than the current speed β a large exit
The speed goes up, and the window is reset and counted afresh from this very second.
window β exactly 7 days
Pot Γ· 7 days is less than the current speed β a small exit
The speed does not change, the drip is the same. It simply has to drip for longer: what is left of the window plus the addition divided by the speed.
window β less than 7 days
This is why the ceiling holds without exceptions. In two branches the window equals seven days by definition. In the third it is shorter than seven β otherwise the speed would have risen and the second branch would have fired. There is no fourth option in the code.
The guard against lowering the speed is deliberate and is spelled out in the contract with the words rewardRate can only stay flat or increase. Without it, anyone could leave in penny-sized portions and drag everyone else's yield down with every exit.
Three cases on one scale. Orange shows how much RNBW is sitting in the pot: it is topped up in a jump on an exit and drains evenly downward. The slope of the line is the distribution speed β the steeper it is, the faster the fees reach the stakers.
A β an exit while no payout is running. 100,000 RNBW withheld into an empty pot, so the rate is 14,286 a day. By the seventh day nothing is left.
C β a large exit in the middle of a payout. On the third day another 100,000 is withheld. The slope got steeper, the speed rose to 22,449 a day, the window reset β and the end slid to the tenth day.
D β three large exits in a row. The end falls on the ninth day, not the twenty-first. What did grow is the speed: from 14,286 to 37,026 RNBW a day, a payout 2.6 times faster.
Case C is where the eye is fooled. The payout really will finish later than the original seven days β on the tenth. But that is not "a window ten days long": from the exit on the third day to the end is exactly seven. The window did not stretch, it was moved.
The third branch looks inconspicuous, yet it is the one that fires almost every time: over the whole history, the exits large enough to raise the speed number in the single digits. Let us look at it close up β on the general chart everything that matters happens at a scale you cannot see there.
Inset β is magnified 28 times vertically, inset β‘ 15 times in time. The dashed line in both shows how things would have gone without the top-up.
The main thing is visible in inset β : the line before the step and after it are parallel. The speed did not change, the drip stayed the same β only the level in the pot went up. That is why the term is extended by exactly as long as the drip needs to carry the addition out: 1,000 Γ· 14,286 a day = 1 hour 41 minutes. You can see it in inset β‘.
The end of the payout slid from 7.00 to 7.07 days, and from the exit itself to the end there are 4.07 left β almost three days short of the ceiling. But that three-day margin is a property of this example, not of the branch: it came from the exit landing in the middle of the window and being tiny.
Then the same third branch will stretch the payout by almost seven days. Its margin depends not only on the size of the addition but on how much of the window was left: the extension equals what remains of the window plus the addition divided by the speed.
The vertical axis is the length of the window from the exit, in days. Each orange line stands for one size of fee. Point B is the case from the previous section: an exit on the third day with an addition of 1,000. The top right point is an exit on day 6.9 with an addition of 95,000.
The lines are parallel and all of them run into the blue ceiling. The later the exit, the less is left to drain β but the more the addition weighs against that remainder. A large addition at the end of the window comes almost right up to seven days: on an exit at day 6.9 with 95,000 withheld, 0.10 plus 6.65 leaves 6.75 days, and that is still the "term is extended" branch.
| Withheld | In the pot | Window, d | End, d | Branch |
|---|---|---|---|---|
| 1,000 | 2,429 | 0.17 | 7.07 | term extended |
| 25,000 | 26,429 | 1.85 | 8.75 | term extended |
| 50,000 | 51,429 | 3.60 | 10.50 | term extended |
| 95,000 | 96,429 | 6.75 | 13.65 | term extended |
| 98,571 | 100,000 | 7.00 | 13.90 | term extended |
| 100,000 | 101,429 | 7.00 | 13.90 | speed rose |
Look at the last two rows β that is the border between the branches. A fee of 98,571 RNBW still falls into "term extended", while 100,000 already raises the speed. And both give the same thing: exactly seven days. There is no jump between them, the border is smooth β the "term extended" branch approaches seven days from below, the "speed rose" branch sits on them. That is why the ceiling holds without exceptions.
The calendar length of the payout, on the other hand, is not bounded by anything. In the "End" column, a fee of 95,000 puts it at 13.90 days β almost a fortnight. The seven-day ceiling bounds the window from each separate exit, not the overall term. Exits that land near the end of a window can push it out indefinitely, and with a live stream of exits the payout simply never stops β which is what actually happens: the pot does not run dry.
Everything described here follows directly from the _addFees function in the staking contract 0x288ea8Bcb51d53aD361D786EFa904C401904aF70. The source is published and verified, and you can read it in the explorer.
The contract assigns dripEndTime = block.timestamp + dripDuration, where dripDuration equals 604800 seconds β exactly seven days from the current second. The previous window simply ceases to exist.
Here it is dripEndTime = block.timestamp + undistributedFees / rewardRate. The condition for entering this branch itself guarantees that the quotient is smaller than dripDuration β otherwise the previous branch would have fired.
The pot balance and the speed are read from the contract with the calls undistributedFees() and rewardRate(). Both of them, together with the history of every exit and a note on which branch fired for each, are on the Staking page.
The figures in the examples in this article were obtained by replaying _syncPool and _addFees step by step from a zero state, rather than taken from the site β so that they could not be fitted to the conclusion.