# RPL Staking Rework Proposal **URL:** \ **Category:** Governance\ **Created:** [11 August 2023 17:05 UTC](https://dao.rocketpool.net/t/rpl-staking-rework-proposal/2090 "2023-08-11T17:05:15Z")\ **Posts on this page:** 1\ **Showing post:** 32
**Author:** ![Patches](https://dao.rocketpool.net/user_avatar/dao.rocketpool.net/patches/32/121_2.png) [@Patches](https://dao.rocketpool.net/u/Patches)\ **Post date:** [27 October 2023 14:49 UTC](https://dao.rocketpool.net/t/rpl-staking-rework-proposal/2090/32 "2023-10-27T14:49:12Z")
# Gov Stuff I’ve generated a rewards tree using the proposed formula for target interval 15 which ended a day ago. Attached you’ll find the tree, along with a csv showing how each node’s rewards would have been different if this proposal had been enacted before interval 15. [**Click here for the rewards tree**](https://shuf.ro/rp/rp-rewards-mainnet-15.json) [**Click here for CSV summary**](https://shuf.ro/rp/rpip30interval15.csv) Once downloaded, you can search the CSV for your node id to find your personal impact. You’ll need to lowercase your node id first. For example: | node | interval15rewards | proposed | factor | delta | | --- | --- | --- | --- | --- | | 0x18845fd4aa047d6d43c934cc37aca94f85def683 | 25.0122713590862 | 21.3127893045889 | 0.852093318460127 | -3.69948205449725 | This is my node. In interval 15 I received 25 RPL of rewards. This proposal would reduce that to 85%, or 21.3 RPL, which is a difference of -3.7. On the balance, I’m in favor of measures to make inflation impel growth, so I’m leaning in favor. However, I’m sensitive to the notion that some people may feel rugged. * * * | node | interval15rewards | proposed | factor | delta | | --- | --- | --- | --- | --- | | 0x17fa597cec16ab63a7ca00fb351eb4b29ffa6f46 | 6023.22623367632 | 3373.75553590557 | 0.560124326236104 | -2649.47069777075 | | 0xca317a4eccbe0dd5832de2a7407e3c03f88b2cdd | 2142.75795001593 | 974.570809890287 | 0.454820764931962 | -1168.18714012564 | | 0x895f6558f0b02f95f48ef0d580ec885056dcccc6 | 1808.81809820746 | 778.456936814446 | 0.43036772884233 | -1030.36116139301 | | 0x7c5d0950584f961f5c1054c88a71b01207bf9cb7 | 1808.81809820746 | 778.456936814446 | 0.43036772884233 | -1030.36116139301 | | 0xacb7cfb56d6835d9e2fa3e3f273a0450468082d9 | 1808.81809820746 | 778.456936814446 | 0.43036772884233 | -1030.36116139301 | | 0x663cbbd93b5ee095ac8386c2a301eb1c47d73aa9 | 1808.81809820746 | 778.456936814446 | 0.43036772884233 | -1030.36116139301 | | 0x22ffba127f6741a619fa145516ef4d94b90f093a | 1417.00027016498 | 406.753997115619 | 0.287052871957646 | -1010.24627304936 | | 0xb8ed9ea221bf33d37360a76ddd52ba7b1e66aa5c | 1549.03842573998 | 765.819471099213 | 0.494383779236064 | -783.218954640764 | These are the biggest losers by total swing. It’s a mix of whales whose support the protocol has benefited from. They can mitigate their losses substantially by migrating to leb8s, but I would like to hear from them to understand why they haven’t already done so, and in general to get their opinions. At the top we have @thomasg followed by an anon, then patricio and marko’s nodes, and some more anons. * * * | node | interval15rewards | proposed | factor | delta | | --- | --- | --- | --- | --- | | 0x2fc184459069dc780b478f7e3c9ffd79e40842a3 | 449.767509478073 | 770.649998412312 | 1.71344079368161 | 320.882488934239 | | 0xfd0166b400ead071590f949c6760d1ccc1afc967 | 371.75691749514 | 677.058729081032 | 1.82124043216999 | 305.301811585892 | | 0xd91eecc267ff626399798040d88de62c9e70acf0 | 359.930169559552 | 655.519377559656 | 1.82124043216999 | 295.589208000104 | | 0x84ba027280cc6cc1e592a01270c5f21a494f46cb | 291.487883004815 | 530.869518016004 | 1.82124043216999 | 239.381635011189 | | 0xacfad9f0d80f74ad7e280a55ea025f4f09844b0f | 271.330533561145 | 494.158138203814 | 1.82124043216999 | 222.827604642669 | These are the five biggest winners. Unsurprisingly, they have leb8s and are closer to their borrow limits. Interestingly (for me, anyway), [**0xfd0166b400ead071590f949c6760d1ccc1afc967 - click here**](https://rocketscan.io/node/0xfd0166b400ead071590f949c6760d1ccc1afc967) reprises his role as a governance subject. See my last post about him - [**click here**](https://dao.rocketpool.net/t/rpip-4-discussion-who-should-vote/2249/40). Not that the impetus to exit to stay above 10% is a function of the rewards power curve, but I do worry this change will reinforce that behavior. 0xfd01 has exited over a third of their minipools to stay above the 10% collateral threshold, which has kept them in the “sweet spot” on the proposed curve to maximise their rewards. I wonder if there shouldn’t be a mechanism that ramps the rewards power up after 10% creating a local maximum at the collateral rate we consider to be an optimal balance between security and capacity before decaying. As it stands, with this proposal, a node operator skating by at 10.00% will be in a position we have financially defined as borderline undercollateralized, but still receiving the maximum rewards power. * * * That’s all for my ambling. # Tech Stuff - skip this. please. [**Methodology - click here**](https://github.com/jshufro/smartnode/pull/3/files) This proposal includes a `ln()`, which, obviously, is feasible. The problem comes in the standardization. Treegen is primarily a specification. Specifying integer math was fairly straight forward- you say that the integer container size is unbounded, you specify the order of operations, and everyone gets the same result. `ln()` presents more of a challenge, and will likely need to be approximated. Because floats are stored in a representation of s(2^x)\*y, a `log2()` transformation may actually be _easier_ to specify. However, for ease of implementation, I’d suggest what Val originally suggested to me when I complained about this: a LUT which approximates the desired curve. The curve is actually 3 dimensional, so the simplest LUT would be one that takes a decimal value for `staked_rpl_value_in_eth / borrowed_eth` (ie where the number of sigfigs is preordained, see below) and simply returns the weight. We can set a reasonable upper bound on the input (because nobody is likely to care about rewards growth above, say, a quotient of 20). The LUT itself will likely need to be generated not by hand but by machine and stored in a way where implementors can trivially convert it to a compile-time constant value in the language of their choice, well-optimized for interval queries. A **[interval tree - click here](https://en.wikipedia.org/wiki/Interval_tree)** comes to mind, but there’s more efficient options: We can quantize the inputs- That is, say your input to the function to 3 sigfigs is 0.789, but we quantize to 2, 0.79, and the LUT has fidelity to 2 sigfigs. In this case a simple array provides O(1) lookups, an improvement over a tree’s O(logn) complexity. And that’s all for my rambling! * * * Edit: Any of the people I called out as wanting to hear their opinions (thomas, etc), I can make myself available to do more analysis and discuss. Happy to rerun treegen for hypothetical scenarios (eg, what happens if you migrate to leb8s, or exit N minipools, etc) --- _[View the full topic](https://dao.rocketpool.net/t/rpl-staking-rework-proposal/2090)._