Name: Time based burn (and thus total) fee Category: Protocol Status: Draft Scope: Make the burn fee dependent on duration of time between mint and burn
Overview:
The idea is to make the burn fee dependent on the time between mint and burn of the same address interacting with RenVM. Several time-windows could be established with different associated burn fees. The burn fee could even be allowed to be negative in case of very high velocity mints and burns. This proposal would allow to differentiate between interactions with RenVM that are assumed to be for different use-cases. On the one-hand, arbitrage like use-cases are encouraged via lower total fees. Use cases where RenBTC is locked in protocols (staking, LPing) for a long time could potentially be disincentivized this way.
Example:
An address does a mint of 100 RenBTC and pays the 0.25% fee. If the same address does a burn in size up to 100RenBTC within 1hour the burn fee is -0.1%. Hence the total fee paid is 0.15%. If the burn happens within 1 day the burn fee is 0% (total fee is 0.25%). And so forth, any number of differentiating time windows could be possible. The last threshold is fixed and therefore the maximum total fee is known to the user beforehand.
Necessary next steps:
Determine suitable time-windows and associated burn fees
Potentially adjust mint fee based on the above
Investigate technical feasibility
Pro:
Potential to incentivize higher velocity mints and burns. Such transactions increase volume without increasing TVL
Maximum total fee is known to the user beforehand
Not artificially reducing demand by increasing the total fee
Con:
More difficult to implement than current method because measurement of time between mint and burn is needed
RenVM to potentially have negative burn fees might increase attack vectors
A problem with having a time-based fee is that it is impossible to increase the fee for a user based on how long they have held e.g. renBTC, because a user could always transfer to a fresh address before burning. And there is no way to tell whether a renBTC transfer is done to skirt the fee, or if it is a trade or withdrawal from a DeFi application.
It would be possible to give a rebate to addresses that have minted recently, but there are nicer solutions than taking a larger fee upfront and then giving it back, by simply having lower fees for use-cases where an asset will be quickly minted and burned. This could be done with contract-specific fees, which is something that is being considered by the team.
This is a great idea, things that I brought up in RFC-000-002: Multi-Variable Fee Control. To remain competitive we need to have as much flexibility available to the network in terms of fee management. This will allow us to maximize volume and income through the network.
oooh interesting with contract specific fees !!
This literally addresses the concerns of @FanaticalFishing
Good stuff, only have one question:
How would you prevent these contracts with rebates to not starting to pool other users and eventually just centralize the flow of mints/burns into large players?
Thanks for the reply @MaxRoszko. Indeed the idea was to only rebate if the same address does the mint and burn within a specified time window. So a 100 btc mint gives the same address the right to a burn rebate up to that same amount. The same rule could alleviate the concern of @Sabobi.
It’s not necessarily needed to increase the fee upfront, this would actually be a separate discussion I think. If the current fees are kept as-is but only rebates are introduced for short duration transactions then that would not disincentivize anything compared to the current setup.
I also like the idea of having contract-specific fees, this would allow to distinguish between more factors than just time between mint and burn. Possible downside is that the overall fee structure might become a bit less transparent, but I guess that wouldn’t be a problem if for each individual user it is clear what they are paying at the moment of interacting with the contract.
I agree that contract-specific fees would be a big step. It will make low and high fees possible depending on the use case and offers a bridge to unite those that want low fees (for high velocity applications) with those that want higher fees (because they don’t believe in the predicted velocity).
There are different designs around that, one would be having contract-specific fees for contracts where for instance minting and burning are tied in the same transaction, e.g. a native DEX where someone trades native BTC for USDC, so BTC gets minted, and then burned back to the trader on the other side in one go. We don’t need to have a 0.25% minting fee there, it could be 0.1% in total for the mint and burn (and of course something like a 0confirmation integration is necessary for that use-case). So someone could not abuse this by minting renBTC using that contract instead of the regular bridge, and then withdraw their renBTC.
Governance would have control over the fees for these kinds of contracts as well.
In scenarios like this, is the Ren Team responsible for negotiating the terms and length of these contracts and then presenting them to the community to vote on? How might this situation be managed in the future.
I like how the thoughts are developing around this. Agree if you have contracts where the mint and burn happen in one go it should work. It is actually quite good approach to give second layer applications a chance to establish themsleves without worrying about algorithmic fee changes in future. Looking forward to hear more in future, thanks!
I do like this idea as I think it is important that we formulate strategies whereby different use cases are charged differently, to encourage arbitrage, dex integrations etc.
I’m not sure I quite follow the reasoning of your logic Max though. They would only receive a reduced burn fee if they minted and then burnt from the same address. If the user transfers to a fresh address, well thats on him and he has to pay a higher fee.
You also say there is no way to tell whether a renBTC transfer is done to skirt the fee - but I don’t see how that is possible. Only thing I could see is you mint, and you know that someone else wants to burn. So you mint your 100btc. He transfers you his 100 renbtc. You then burn them for him and collectively you have paid lower fees. But I don’t see an issue with that as long as there is a mint to match against the burn (thus fulfilling our desired outcome of high velocity trades with no increase to TVL)
I also think that new ideas / fee structures have a tendency to be shot down straight away whereas I think instead there should be a push from the team to consider and discus them more fully.
I’m saying the idea to linearly increase the burning fee depending on how long an address has held renBTC doesn’t work, because they could move the renBTC to a fresh address and start over with a burn fee at 10 bps.
I thought what was being proposed is that we have a set burn fee that everyone pays. However if you transfer into, and back from the same address within certain time criterias, then you receive a discount.
So there is no issue if someone moves their renBTC to another address, they would simply pay the usual burn fee and forfeit the reduced fee had they burnt back from the same address
If I understand you correctly there is a risk of centralized flows in the long run. You will eventually get services that act is mint/burn “stations” people go to for a discounted rate as they simply batch txs on both sides. Even with the argument that people wouldn’t cause it would require trust in that party is invalid since smart contracts could do the job for a minor fee (eg. 1bps) and thus always fall under the regular fee tier.
This situation would be difficult to achieve if mint/burn discount only applies to same txs instructions to avoid gaming the system.
Another option would be to “whitelist” certain addresses that community (nodes) can vote to add/remove, with the argument that nodes act in best interest of the network it should stabilize at optimized results and not just whitelist any entity.