RFC-000-011: Continuous Fee Bond

Requests For Comment | RFC
1

Name : Continuous Fee Bond
Category : Protocol
Status : Draft
Overview : In order to retain a pure 1:1 BTC to renBTC wrapping solution, perhaps a way we can solve this is by requiring through the smart contract a bond, to be placed in escrow, could be in ETH, could be in renBTC upfront, that would be subject to the continuous fee in the event TVL is approaching a critical state.

Overview

As some are more concerned than others about maintaining a true 1:1, a workaround solution might be to just require a refundable bond, upfront when wrapping, this bond would be subject to continuous fees, until depleted. Sizing the bond would become a question for another RFC if this concept is embraced as a solution.

Description

Pros:

Customers understand upfront that to leave wrapped assets in RenVM is not a free process, that there is a clear price that might be forgone in the name of security, while able to maintain 1:1. Whenever they decide to BURN back.

Having some leverage to incentivize the necessary market behavior is a pro if the bond was larger enough to motivate and was clear to customers that it was being drained. Bond would be returned in full, assuming that there are no continuous fees in play.

Cons:

Additional cost burdens that are not being used by competition give us a disadvantage as a network.

Bonds might increase TVL further unless held in a separate contract of some kind.

The bond pool might be difficult for people who have acquired their renBTC by other means such as in DEX or trading, instead of by bridging, in theory, someone put up a Bond, and that might be tied directly to that amount, but for pass-through purposes, this might be an issue.

I don’t see a problem with not maintaining a 1:1, but this has been voiced frequently in the forums, and perhaps it’s time to discuss it since, TVL has not been in check for multiple Epochs at this point.

Implementation

Adding to the complexity of the RenBridge and Smart Contract required when the initial wrapping takes place to escrow the bond and return the bond when BURNing.

2

Thanks for the post. A few questions:

  • Who is putting up the bond?
  • How is the bond amount calculated? Which oracle?
  • How is a critical state determined for the TVL vs. TVB?
  • Why is this better than increasing the fee to mint?
  • How would this work with current integrations like Curve and other upcoming ones?
3

  1. I would think the customer who is utilizing the bridge would be the one to put up the bond.

  2. Bond would have to be calculated based on a rate that the network feels is appropriate for a customer who could very well stick around too long, perhaps this rate is dynamically tied to the current TVL ratio. As we get further out of balance, the bond requirement could increase.

  3. I would think if we are accelerating past the 1/3 critical security level is when I think these bonds would need to kick in. We currently exist at a level that should be considered if we were on our own fully decentralized undesirable. I am trying to open up the conversation and see if this strategy could be a viable solution. Understanding what is considered untenable by the network would be a place to start.

  4. I am not sure if it is, certainly part of the conversation. It has been mentioned else we are looking for high volume low TVL, so in this case, it might permit more volume than just constantly jacking the MINT fee up to the point where users don’t want to bridge with renVM. The solution of charging customers that are overstaying their welcome on the network does make sense, but at the same time, having users that are using DEFI products is largely part of why they want to use RenVM in the first place, and many of these solutions especially for BTC are liquidity providing in exchange for yield, as long as we are earning income off them at a rate that still is tenable for them to stay, but increases the value of REN to the point where the ratio is maintained I see this as an acceptable outcome as well, but markets would need to cooperate and act rationally to value REN in this way, which we are still detached from our income.

  5. It may not work with integrators unless perhaps as an integrator we request them to bond based on a daily average of their volume, in the name of security. They could afford it, and if their constant flow and locked renBTC is important to them, they might just pay it.

4

Thanks for sharing the idea!

First impression reaction - creative workaround, but it increases complexity and decreases seamless UX. It just adds an extra step/requirement for a user to prepare for in order to interact with RenVM. I personally think we should be removing barriers (0conf to reduce conf time) rather than adding hurdles (requiring collateral to use RenVM)… not to mention the use of bandwidth of technical resources in order to make something like this.

2 Likes
5

Too much friction for the user

2 Likes
6

Thanks for posting this is an interesting idea. However there are few reason why I don’t think this would be beneficial.

Firstly I think this would deter users mainly on an added complexity especially if you were to use a different token to bond there would be a extra transactions to go in and out and that would increase transaction fees. Then you need to send your eth to one address and your bitcoin to another. It is already stressful enough having complete custody of your own assets and having to send them elsewhere adding in another transaction to send would lead to more human errors. So it would have to be the underlying asset they are already sending as an extra percentage taken out. I don’t think people will like this. I actually think the current continuous fee system or raising/lowering the mint and burn fees is a better solution than the extra complexities this would pose.

Secondly because of REN being an interoperability protocol being able to move freely between chains as quickly as possible is of upmost importance so adding in extra transactions is going to slow this down causing more friction to the system. Also add more transaction fees as stated above whether by RENVM internally or by the user.

Thirdly how does the bond work if one switches renbtc to wbtc. Do I lose the bond? But that bond was my deposit for the renbtc that I put in the system. I don’t really see a fair way of how the bonds can work unless you keep the asset but then people might feel tied to Renbtc because of their bond. The only way I really see this working is there to be a much higher fee on depositing renbtc and a percentage of that fee goes in to a continuous fee pool that also gets given back out to people burning renbtc.

example that could possibly work
So say we take a 1% mint fee;
0.25% goes to darknode operators
0.75% goes to continuous fee pool

If we need to we turn on the continuous fee that starts draining a percentage of that pool same as how the continuous fee works.

on burning
0.1% goes to darknode operators
0.75% fee is given to the burner as a rebate from continous pool

If the continuous fee is turned on the pool will shrink whilst the rebate remains the same percentage the value of the rebate would be reduced. Above is just an idea really. I actually think raising fees so high to accommodate this might price us out of the market. I also think this would be confusing to users. Would the continous fee pool be big enough to deter people out of the system. Probably not so the fee might need to be even higher than suggested.

3 Likes
7

What are is the bond trying to incentivize or decentivize? Users that mint renBTC and don’t burn it within the same week, month?

I think this adds unnecessary complexity. The continuous fee idea, like a vault maintenance fee, is an interesting one, I don’t think forcing the users to put up a bond is the way to go.

8

The more i think about it the more i like this proposal i sometimes just have to work through the logic in my own head first. Heres how id do it:
Upfront the btc wrapper pays 0.3%. No burn fee. If they return the btc in a year they get between 0.01 and 0.2% rebated in terms of btc.
Thus fee is still 0.3% but also a stronger push to not hold renbtc

2 Likes
9

I had a look through the ren wiki and following section was interesting:

image
image932Ă—317 56.9 KB

If I understand correctly the plan in the future is to use continuous fees to incentivize burns when TVL is much higher than TVB. when the difference is small mint and burn fee adjustments will be done.

This sounds reasonable, I would’ve loved to see ideas of maybe even doing negative fees on burn side. so people actually get paid to burn, that would be interesting.

Anyway seems like the ideas are there but focus for now is to give current economic tests some time to present reliable data, so we just need to be a bit patient i guess.

2 Likes
10

There’s also some techniques we’re exploring to be able to resolve the TVL > TVB situation without needing to rely on continuous fees.

8 Likes
11

I really appreciate this approach Loongy. When you first put the concept to the community there was a fair amount of push back (and no doubt from within the team as well). So you’ve gone back to the drawing board to look at finding alternative solutions. Can’t wait to hear all about them!