RFC-000-019: A native REN Lending Pool

Requests For Comment | RFC
1

Name: REN Lending Pool
Category: Protocol
Status: Draft
Scope: A native Lending Pool that Node Operators can borrow REN from, and REN stakers to the pool can then earn network fees + lending rates.

Overview:
Currently, REN holders of less than 100k REN are unable to participate in node staking, therefore there’s no demand from smaller holders to hold Ren. I propose an upgrade to the protocol that allows any holder to stake their Ren into a pool that node operators can borrow from.

A native REN lending pool can allow node operators to use their locked REN as collateral to the stakers. The stakers can then earn the Ren protocol fees of the node operators that are borrowing from the pool.

A node operator can continue operating the node and maintain their price exposure to REN, while at the same time making their node a productive asset that can be used to borrow REN to then be used at any of the large lending protocols that accept REN as collateral.

Details:
A Lending Pool is created where REN holders can deposit any amount of REN.

Then the node operator borrows REN tokens from the Ren Lending Pool; The node operator can choose how much of his REN he likes to borrow against from what he has bonded in the node bonding pool and according to this percentage that is how much of his REN fees is divided among the lending pool.

This in effect could double the amount of REN staked while still maintaining the same economic incentives. Aligning both small and large holders of the REN token to continue providing security for the network.

The lending pool also carries the benefits of allowing node operators to become shared staking nodes by borrowing 50k REN from the Lending pool and only having to put up 50k REN to run the additional node.

Slashing:
A maximum threshold of 80% can be used so that the node operator has at least 20% to be used against slashing events.

Liquidations:
There should be no liquidation risk since the asset lent and borrowed is REN. In order for the node operator to get back their Bond the loan to stakers must be paid back. In the event, the node operator is not live and not earning fees the lending pool can mortgage the bond to pay back lenders of the pool.

Fees:
Governance can decide the lending rate or a utilization curve can be used similar to that of Aave and Compound.

Implementation::
A Lending Pool smart contract and logic.

The staking contract will need to upgrade the logic to prevent nodes from withdrawing their total balance if there’s a current loan open.

A MakerDao proposal to accept REN as collateral to provide a stable lending rate of DAI.

3 Likes
2

This is a fantastic win, win idea that will broaden the scope and benefit of holding less than 100K REN. As Crypto holders become more educated and sophisticated in the language of Defi, they will want to hold tokens that give them more than just capital cost speculation which is the only current benefit of holding less than 100K REN aside from utilizing non-native liquidity pools. This will increase demand for and ultimately the price of the REN token.

1 Like
3

I think this is a great proposition. It benefits new REN holders, Darknode operators, the security of the network and the $REN price stability. It would be nice if we could present this proposal to all Darknode operators via Snapshot in the short term.

1 Like
4

It’s an interesting proposal but I don’t think it could be part of the core protocol, because the network can’t autonomously run nodes itself, it has to be an individual or organization running them, so basically any REN lent out is at variable risk of slashing from the actions of whichever person/org running the node.

So it would have to be a side-service, developed and maintained by some person/group. And then the question is who would build it?

Currently there are at least two projects working on pooled darknodes as well, so this demand might get met shortly.

4 Likes
5

The idea is not for the network to run nodes autonomously but for there to be a mechanism that allows for the current node operators to use their bonded REN as collateral on the Lending Pool.

They can then raise 100k REN for example to run more nodes. This benefits everyone in the network.

6

A very simple attack vector this introduces:

Buy as much REN as you need to attack the network. Lock it up in nodes. Borrow REN against your bonded REN, and sell that REN. Attack the network with the nodes that you have running, and now you don’t even have to care about the REN you have locked up.

3 Likes
7

I agree this does increase the risk, but there can be limits to the amount a node operator can borrow. And this attack scenario can effectively be done now by shorting their locked token on a centralized exchange with leverage to increase profits even more.

8

I thought 80% max was too high for the reason that max gives (no puns intended). I could see this being safe for a lower amount like maybe 10-20% but before this moves forward, we would want some modeling done that looks into this. It also seems like some multi-node operators would also have to have some further limits because they could do this much easier given their established position. I am not saying no, I am just not convinced the safety rails are there yet. I look forward to the discussion though.

9

This is the sort of thing that the community fund ought to orchestrate.

I’ve said before that an official DNO-run REN pool would incentivize small balance holders and create a line of revenue that could finance the community fund and ultimately replace the tax on DNOs that will currently finance the CF.

Of course, we would have to consider replacing the CF tax with dilution. But if we don’t create pooling, others will. And with that also goes a lot of potential governance.

10

You can’t use the locked REN in the darknode bond contract on a centralized exchange because it isn’t transferrable. That’s exactly the defence against attackers

11

Maybe we can continue by using the community funds to commission a risk report from Gauntlet, Delphi Digital, or other good tokenomic designers in the space. I am sure there are many risk parameters that can be modeled and even new staking design ideas can be thought of.

12

You mean to say that there are already teams that will soon open pools where users with a smaller number of tokens can join and generate profits from darknodes?

13

There’s projects like https://www.renpool.io/ that plan to do this, but the fees are excessive. There are better ways to do this by putting the already bonded REN to work alongside small stakers.

14

Yes. Keep an eye out the next few days.

It’s not renpool.io i’m talking about though.

15

If a whale adversary used their bonds to collateralize a loan for more REN, it’d be easier for them to get 1/3 control.

4 Likes
16

Would using a RocketPool-like model help mitigate the attack vector, while still allowing smaller depositors to benefit from staking? For example:

  • Alice deposits e.g. 80k REN into a pool.
  • multiple other users deposit smaller amounts of REN, making a total of 100k REN.
  • Alice registers a node. Node rewards go to the pool contract. If the node is deregistered, the 100k REN goes back to the pool contract for redistribution.
  • smaller investors can withdraw their REN plus their share of fees.
  • Alice can withdraw her 80k REN plus her share of fees.
  • any shortfall due to slashing would first come out of Alice’s share, incentivising her to act honestly. If >80k REN is slashed, smaller depositors will not get their full investment back.
  • earned fees (and REN withdrawn as a result of deregistering) could be subject to an additional bonding period before becoming available for withdrawal.

Assumptions:

  • Alice can only use unbonded REN as collateral to borrow from the pool
  • borrowed REN can only be used to register nodes (i.e. it can not be transferred to arbitrary addresses)
  • Alice’s cost to attack the network is reduced by the amount she borrows from the pool (20% in the above example). Subjecting her earnings to a further bonding period could mitigate this
  • Alice receives a portion of fees earning by smaller depositors. This is a win for the smaller depositors (they would otherwise not be able to earn any fees), and a win for Alice (who earns more than she would for pooling 100k directly).

Does the fact that Alice can not sell the borrowed REN fully mitigate this attack? If the pool contract only allows borrowed REN to be used for bonding, Alice would not be able to transfer the borrowed REN to an exchange to sell.

If this model successfully mitigates the attack described by Max (and doesn’t introduce new attack vectors), it would allow for the provisional of fully decentralised pools. IMO it is imperative that any pooling solution is decentralised, otherwise we risk concentrating too much control of the network in the hands of one entity.