RFC-000-020: Revenue Automation Strategies

Requests For Comment | RFC
1

Name: Revenue Automation Strategies
Category: Protocol
Status: Draft
Scope: Modifications to revenue distribution, allowing operators to automatically invest revenue in DeFi protocols

Overview

With the advent of native RenVM smart contract capabilities, we have the ability to make more advanced use of fee revenue.

As a DN operator I would like my earnings to be automatically invested in DeFi protocols to further increase my ROI. I would like the ability to opt-in to “Revenue Automation Strategies” (RAS) which are executed automatically by RenVM.

An example of a RAS would be directly depositing my earnings into a Curve pool. I would opt-in to this strategy and set the percentage of my earnings that will automatically deposited to Curve. e.g. I could decide to deposit 50% of my renBTC earnings in Curve, and 100% of my renDOGE earnings in another RAS.

As fees are earned RenVM would automatically deposit them to Curve. Because RenVM would only need to execute a single transaction to deposit on behalf of multiple users we would save gas compared to each user withdrawing their earnings and depositing to Curve individually.

RenVM would keep track of how much Curve belongs to each user, and provide a mechanism to withdraw the underlying assets (and any LP rewards) from Curve.

Strategies could be proposed via the governance process. Community fund grants could be used to fund development of strategies, with initial strategies perhaps being developed by the Ren team.

Once Ren is further down the path to decentralisation it seems likely that Yearn will add renBTC-based strategies. I can see a symbiotic positive feedback loop forming here: ren* assets are automatically deposited into Yearn, where they are deposited into other DeFi protocols, increasing liquidity/usage of ren* assets, leading to more fees, leading to more ren* assets deposited in Yearn…

My holy grail here would be a Yearn strategy that pays rewards in REN. I would dedicate 100% of my earnings to this strategy, and eventually my Ren nodes would earn enough REN for pay for another node.

History

To my knowledge this is the first RFC for such a proposal.

Related RFCs

Implementation Details

This is an early RFC to gauge community sentiment and brainstorm ideas for strategies. Actual implementation details will be added as the discussion evolves, assuming there is interest.

Implementation Requirements

  • RenVM smart contract knowledge

  • Strategy development (combines RenVM + host chain smart contracts)

  • New pages in Command Centre so operators can view strategies and opt-in

  • Protocol changes to allow an operator to redirect their revenue to a strategy, and withdraw underlying assets from strategies

1 Like
2

Interesting idea.

I don’t think this is a good feature for the RenVM. I believe if individual DNs want to reinvest their fees at the end of the epoch, they are free to do so, but using developer’s time and precious resources any time in the near future for a feature like this is not prudent in my opinion.

3

At first glance I liked the idea. Especially to reinvest our fees to buy REN.
But last epoch we made 800k fees. If we assume 10% of DN operators would agree to reinvest their earnings we land at 80k each epoch. Which is just not enough right now.

If we increase our earnings per epoch further it would make sense again. But also we could be able to receive our monthly earnings on a L2 in the future. This would neglect the gas savings argument.

4

Interesting proposal, however, this should be at the bottom of the priority list in my opinion.

Priority of focus should be decentralization and features geared towards users of the protocol (host-to-host, integrations, etc). Increasing the total Darknode revenue, instead of adding a marginal ROI on existing revenue.

Besides, this might be better handled by 3rd parties. Once RenVM smart contracts can be deployed by anyone, the protocol can provide an option to automatically forward your fees to another RenVM smart contract. This gives the operator more flexibility, and does not put the onus on the core team to implement or integrate with a specific RAS strategy.

That being said, I would also suggest to gauge community sentiment for something like this first, to get a feel of how much interest and thus potential capital there would be for something like this.
Maybe a poll in the form of “how much x% of DN revenue would you automatically reinvest in a RAS?”.

5

Thanks for all the feedback so far. Completely the agree this should be on the bottom of the priority list (if at all).

Lovely idea. This would give third-parties the ability to build such a service without placing unnecessary load on the core devs.

Another use case for a RAS would be automatically swapping earned tokens. e.g. if someone does not want to hold renDOGE they could use a RAS which converts it into renBTC automatically.

Sentiment Poll

What percentage of DN revenue would you automatically invest in a RAS?

  • 0%
  • 1-20%
  • 20-40%
  • 40-60%
  • 60-80%
  • 80-100%
0 voters
6

Building automated investment tools with direct tye-ins at the protocol level strikes me as both 1) non-essential and 2) likely to come unglued rather quickly.

The space advances far too quickly for this to be
viable in my opinion. It’s not that hard to send off what a DNO wishes into a curve pool once per month.

However I DO think it might be nice to build on some kind of API-like endpoint whereby third party services that do this could be optionally bolted on by DNOs.

7

On reflection I prefer Thomm’s suggestion of fee forwarding instead of the initial proposal. It achieves the use case of facilitating revenue automation while avoiding many of the valid issues raised with native automation. The revenue automation aspect can then be built by a third party, or by DNOs themselves (who might open source the contracts for their fellow DNOs to use).

A further benefit of fee forwarding/delegation would be separation of hot/cold wallets. Fees could accumulate in a hot wallet, with a cold wallet used for DN operations.

This is true at the moment but the cost will increase over time as non-BTC fees become more relevant and additional ren* assets are introduced.

We will get this out of the box by virtue of the fact that fees are withdrawn via smart contract. It was theoretically possible with Ethereum-based withdrawals, but the ROI vs tx fees did not make sense.