RocketPool Pawn Stars

Two-sided Lock Box and Withdrawal Account (WA) Splitter

Person R: Has RPL and wants to stake it to earn RPL rewards. They do not want to run a minipool themselves or lack the 16 ETH to afford to do so. They believe that the value of RPL will rise with respect to ETH. They are willing to commit that RPL to a stake that they can not withdraw from for a long (ideally multi-year) period of time.

Node Operator (NO E): Has ETH and wants to run minipools to earn additional ETH rewards (including tips and MEV) but does not want to take exposure to RPL.

Both Person R and NO E want a completely trustless and veritable method to stake their respective asses collectively using the RP protocol.

Benefits:

  • Completely trustless on-chain solution.
  • Requires communication between the parties to set the initial terms and to extend the length of the agreement.
  • Agreement has a contract expiration to repay the RPL loan without the need to share ETH2 signing keys.
  • NO E does not need to take any exposure to RPL.
  • Person R can add more RPL to a node independently after the contract is executed and still be guaranteed its return albeit without a guarantee of the exit date on the principal.

Cons:

  • One RP contract feature toe the Merkle Tree claims is needed (see pink box below). knoshua.eth caught this.
  • Two smart contracts (Lockbox and Splitter) need to be written.
  • Gas costs are incurred to deploy the two contracts.
  • NO E can not mix personal and lockbox minipools on the same node wallet but can run lockbox minipools on combined VC clients if slashing protections are in place.
  • ETH deposed for pawning in the lockbox is unslaked earning zero rewards leading to a lost opportunity costs for NO E. However even at 100% pawn value ratio the 15% node commission on 16 regular ETH makes up for this. This equates to earning 1/3 the node commission or (5%). This still is better than solo operating a solution and requires NO E to take no exposure to RPL.

Dependency: In the new Merkle Tree claims reward :
require(msg.sender == _nodeAddress || msg.sender == withdrawalAddress,“Not owner”);`
Meaning can Person R via the splitter smart contract (RPL Withdrawal Address) send a transaction that would process the claim for Node operator E. (The claim of course goes to the Withdrawal address specified by NO E and the transaction gas was paid by Person R.)

Step 1: NO E installs RP; creates a wallet; NO E provides Person R with the node wallet address.

Step 2: Person R deploys a non-upgradable lockbox smart contact. No funds are deposited for lending at this point. Person R provides NO E this lockbox contract address and person R’s payment wallet address.

lockbox smart contract:
Variables:
status (open, active or closed)
pawnedETH : some negotiated value of ETH that would be held as colleterial (pawned) to ensure that the RPL loaned is returned. (1.6 ETH) This can be the market price of the ETH lent, but really should some value that represents the potential earn of the RPL over a period of time and the amount of assurance that NO E would not abandon the node before forming a minipool and thus fail to repay the RPL loan. In other words this is the amount of leverage that Person R wants to ensuring that NO A exits at the agreed upon time.
timer: date in future (1/1/2027)
rplLoanAmount (160 RPL)
BorrowerAddress (NO E’s node wallet address)

Pseduocode:
Person R deposits RPL equal to the amount rplLoanAmount.
If NO E deposits ETH equal to pawnedETH this will 1) Set lockbox status to active and 2) perform stakeRPLFor(address _nodeAddress, uint256 _amount) where address is the NO E node wallet address.
If the timer date is reached Person R can claim all pawnedETH in the lockbox and close the lockbox status.
If the status is open Person R can withdraw RPL and close lockbox (e.g. the deal fell through).
Person R can reset the timer to a date later than the current timer date. (e.g., Person R and NO agree to keep the deal going and the timeout is extended by Person R).
If RPL equal to or greater than rplLoaned is returned to the lockbox then NO E can withdraw the pawnedETH and close the lockbox status.

Step 3: NO E deploys non-upgradable splitter contact to an address; sets and locks the RP node withdraw address (WA) to the splitter contract. Note: All minipools on this node will be using this splitter WA so NO E should NOT mix personal minipools with this lockbox model.

Splitter smart contract:
Variables:
rplWaletAddresss (Person R’s wallet)
ethWalletAddress (NO E’s wallet and the contract owner address)
LockBox contract address

Pseudocode:
RPL can only be sent to the RPL wallet address
ETH can only be sent to the NO E wallet address (owner address).
Person R and NO E can call claim() thru this spiller contract that will process the node RPL claim. Note: NO E can do it from the node wallet address already.
Either Person R or NO E (or any person) can call process() that distributes token balances.
When process() is called: If the RPL amount in splitter >= lockbox borrow RPL it will send that amount to the lockbox and mark the lockbox closed. Any excess RPL greater than the loaned RPL amount will be sent to the rplWaletAddresss; If not then all RPL goes to rplWaletAddresss (This is to close out the lockbox once the minipool has been exited from eth2 validating).

Step 4: Person R verifies that the node wallet is reistered with RP; That the WA is set to splitter and that RPL wallet address in the splitter is set to the Person R’s rplWalletAddress. Person R funds the lockbox with RPL equal to the lend amount. (green lines)

Step 5: Node operator A deposits ETH in to the splitter and can call borrowRPL(). This action sets the contract status to active and calls StakeRPLFor(NO E walletAddress). Even if NO E decides to not validate and after waiting for the RPL cooldown decides to remove the RPL any attempt to abscond with the RPL the funds will be returned to the node’s WA. The WA was already set and locked to the spitter contract and thus the RPL will be returned to Person R.

It is possible for NO A to call borrowRPL() (but NO E never formed a minipool. In this case the RPL staked but not active with a minipool can be abandoned by NO E in situ. In this case Person R would have to wait for the lockbox timer to activate. At which time Person R can obtained the pawnedETH as restitution.

Normal Node Operating: Node operator validates and RPL rewards are claimed (by either NO E or Person R) and all RPL rewards are sent to the splitter. Either party can call process() and the spiltter will send the coin balances to the respective parties. (purple lines)

All MEV and tips will go the distributor or smoothing set by NO E. But those contracts may continue to use the withdrawal address set by thee NO. Thus there needs to be a way to return ETH to the NO E.

Minipool Exits: All funds are distributed back to the WA (splitter). Since the RPL balance at exit (hopefully) exceeds the lockbox borrowedRPL amount. Either party can call process() and the spillter will send the coin balances to the respective parties. (red lines)

Slashing or Abandonment: In the event of a penalty that eats in to the RPL stake the NO would need to purchase RPL and deposit it manually in to the lockbox to free the ETH deposit. If NO E fails to do this, Person R can withdraw the E deposit or once the timer ends. The later if more advantageous to Person R as any RPL not auctioned by the RP protocol will be distributed by the Splitter. Person R is made whole by recovering the entire lockbox ETH deposit so any additional distribution from the spitter is icing on the cake.

Refusing to exit NO E: If NO E fails to exit Person R can claim the ETH in the contract once the timer has been reached. Person R still earns the RPL rewards and will be given all RPL when the minipool exits. This pressures NO E to either renegotiate with Person R to extend the timer or exit the minipools in time to reimburse the lockbox or risk forfeiting their ETH deposit to Person A.

10 Likes

This is a wonderful idea. We need to encourage more node operators, and this should support that goal. Further, it increases the potential investors in RPL. The technical solution seems sound, but I don’t have the technical expertise that Ken and several others do.

Thanks for this, Ken! I can tell a lot of work went into it.

To add to my earlier comment, we’ve been discussing this within the EV Mavericks discord (DAO name TBD, ManeNetDao potentially). We’d like to use DAO funds to support RP and decentralized staking. We love the idea of operating a node, but that’s challenging for DAOs. Being able to provide a pool of RPL via our multisig seems like a fantastic option. I suspect there are other DAOs in this position.

1 Like

For what it’s worth, this proposal has my full support!

I think this proposal is good for RPL token holders in the short term, but detrimental to the RPL network compared to status quo.

From a system perspective RPL token rewards (inflation) should incentivize actions within the system that increase its overall value. Inflation is basically a way to redistribute network share. It makes sense to redistribute network share only if it increases the overall value of the network and not if it is only value transfer from one set of actors to others.

Let me be concrete and address the problem statement this proposal is solving for:

I would question here if NO who does not want / have exposure to is alligned enough / at all with rocketPool, maybe I am missing something, but it seems they have no stake in the system, which may / may not be problematic. His incentive allingment with rocket pool is strictly worse, could be neutral / positive for the system as a whole if it brings enough validators on board, still I would be cautious.
The question here to ask is, how many more validators can it bring on board? Is it worth the deterioration in the incentive alignment?

This actor seems like a much more problematic from system perspective. There is a constant(k) number of RPL tokens that is distributed to all node operators every block. If barriers of entry for passive RPL holders to earn validating rewards drop drastically(which seems this proposal is ment to do), many will enter the game and start to earn validating rewards, actually for just holding the token. They effectively dilute the active rpl validators (actors that seems to need to be incentivized most). This effect can really be massive, since most RPL is currenly not staked.
Simple napkin math:
at the time of writing 77% of RPL is not staked, if 20% is rented out, it would amount to ~15% of overall token supply, which is ~50% of RPL currently being staked. Effectively cutting the rewards for active staking validators by one third.

To put it concisely, it moves value from active rpl validators to passive RPL holders.

There is also a second order effect concerning rpl price. Since passive RPL holders now have less incentive to either be active in the network, or sell the token(since they are not getting diluted), there is both less sell pressure on RPL & becoming active validator, which increases the price of RPL but also increases barriers of entry for new active rpl validators who are not yet rpl holders. This would seem detrimental to long term system health.

Also, It might be true that this may bring more validators into rpl network, but seems like it goes directly against the tokenomics design.

This trade off might be worth it, but we should be aware of the tradeoff in the first place and first evaluate this tradeoff thoroughly…