RFC-000-022: Introduce minimum fee cap for small RenVM TXs

Requests For Comment | RFC
1

Name: Introduce minimum fee cap for small RenVM TXs
Category: Protocol
Status: Draft
Scope: Introduce minimum fee cap for small RenVM TXs in order to optimize income potential from smaller mints and burns

Overview

This proposal aims to optimize income potential from smaller mints and burns by introducing minimum fee cap. Practice which can be considered an industry standard and to which users are well accustomed to.

This cap is especially beneficial, because it scales incredibly well with RenVM’s growth (which we’re expecting) and overtime can be a nice addition to our income not only in % compared to what we’re getting from small mints & burns now, but also in absolute $ numbers.

Background

At the time of writing our competition has already implemented min caps and here are some examples:

BEP ETH → ETH ETH - min fee is 0.01 ETH / ~$20 (multichain)
FTM BNB → BEP BNB - min fee is 0.0220 BNB / ~$6.7 (multichain)
FTM fUSD <-> ETH fUSD - min fee is $15 (multichain)
BEP BUSD → ETH BUSD - min fee is $20 (multichain)
BEP YFI → ETH YFI - min fee is 0.000400 YFI / ~$11 (multichain)
FTM YFI → ETH YFI - min fee is 0.000800 YFI / ~$23 (multichain)
anyBTC → BTC - min fee is 0.001 BTC / ~$32 (anyswap)

You get the picture. Even if we consider the fact that most of these min caps are only for one-way swaps and you divide that number by 2, it’s still fairly high. But it is my firm belief that min caps is a good practice for the protocol’s bottom line, which automatically benefits both DNO and the Community Fund. Thus this should be implemented, just with more user-friendly and respectful numbers.

Details

To illustrate the benefit of min cap introduction, using sticks and stones, and my “hello world” knowledge, I took 900 latest RenVM’s transactions and filtered by mint/burn amount less than 0.11 BTC (because it roughly translates to making less that ~$5-$6 from a TX, which I think is a reasonable cap, but obviously this is open for discussion).

This resulted in 341 TXs out of 900 (which also included non-BTC mints & burns, but the amount of that is negligible), so roughly 38% of all TXs are smaller than 0.11 BTC.

After this I calculated the average mint & burn amount, which resulted in ~0.03345 BTC / ~$1060. So roughly we’re making $1060 * 0.0015 = $1.59 from each transaction. Or a total of ~$542 for all 341 TXs (a bit more if we account current mint fee on ETH).

If we introduce min fee cap of only $5, than that’s a 341 * 5 = $1705 collected in fees from the same user group, during the same slow volume-wise time period.

To put this into perspective - this is a 314% increase!

And I want to reiterate, that this will scale incredibly well, once RenVM gets more adoption.

Implementation

  1. Gather community sentiment on the overall concept of this proposal
  2. Discuss possible fee structure
  3. Reach consensus on the fee structure
  4. Implement min fee caps into RenVM’s code
5 Likes
2

Nice analysis Arviee, difficult to understand why minting in RenVM is so cheap for small amounts. Shall be a minimum fee, fully agree. An even just charging $5/tx is pretty cheap against competitors and a great pump to DN

1 Like
3

I love it. I think this is a very prudent proposal. A small $5 minimum seems quite harmless to users of the RenVM

4

I think we shouldn’t make it harder for people to do small transactions. I didn’t get to really start playing around with defi until I could do it cheaply on Binance chain, it was just too expensive on Ethereum unless I staked large amounts. This proposal would artificially impose a higher introduction fee to using Renvm. Let’s not forget that crypto is supposed to be for everyone, not just for the rich.

3 Likes
5

Interesting idea, and look forward to the comments.

Would raising the percentage be worth considering as an alternative? Where transactions falling under a certain volume amount get charged a higher fee %, and even possibly have multiple tiers?

1 Like
7

First, let me say that I believe the bitcoin is for everyone. Non-sovereign open-source money native to the Internet is great for humanity overall.

While I don’t want to start adding too many rules and fee structures to different users on the network, a $5 minimum seems pretty reasonable and not too big of a hit on our smaller users.

I think it’s easy to say put a $10 or $20 minimum is “nothing“ but to someone with $100 or $200 worth of bitcoin bringing it over to a different chain via Ren VM, that constitutes a significant portion of their holdings.

Right now WBTC seems to be used by whales and institutions. That means we’re the long tail. Let’s be friendly to them and encourage them to use Ren rather than destroy their holdings with too many fees.

This bot supports a $5 min or, the greater of $5 or X% of the transaction.

Edit: Further, let’s remember, as voters with at least $30K USD invested in Ren alone to run a Darknode, and likely an equal or greater amount in Bitcoin, not everyone is as fortunate as us and may be just starting on their crypto journey with some spare money from work. Let’s support those just getting started and combat the impulse to make crypto a game for whales only

1 Like
8

As a long-term DNO, I fully support this proposal. I also agree with the thoughts @darknode_bot laid out in his response.

9

This would price me out of the REN ecosystem. I don’t participate in defi on ETH because of the fees. Who is going to be happy paying $5 to wrap BTC to a low fee network? Everyone will be looking for a different solution,

1 Like
10

Great summary and proposal Arviee!

Overall I am not opposed, but it is worth pointing out that this calculation ignores prices elasticity, and assumes everyone who used Ren without the cap would continue to do so after the cap is introduced. If we assumed all of those <0.11BTC txs went to a competing network this proposal would end up costing us revenue. The actual number will of course be somewhere in the middle but we should not go into this assuming the 314% increase is a given.

If the minimum fee is denominated in fiat we will also need a price feed oracle to calculate this at the time of the transaction. This opens up some more questions - which oracle to use, how frequently to update prices etc.

Well said. Kudos to whomever programmed this bot’s sense of humanity.

1 Like
11

Fair point. But needs a few corrections, imo. First is that it’s not going to be in the middle, it’s going to be higher, because people don’t usually mint $50 or something, in the ~$0-$3000 range average mint was ~$1000 and I’m pretty certain those guys can afford to pay a $5 fee. And there aren’t any cheaper solutions out there, we would still be the cheapest if we go with $5.

As an added bonus, I think (needs a comment from tech people), someone who might want to spam RenVM with TXs would have to pay quite a lot more. Sounds like win-win-win?

This is also true and I’d love to hear what our awesome RenVM developers think of this? How would this complicate things? Or maybe slow them down? Or none of this?

12

I like this idea, but adding an oracle to the system does worry me a little bit, especially given that we’d have to do this across chains which has implementation concerns.

Because the oracle is a fundamental issue, I’d love for @loongy to chime in on this proposal as to whether requiring an oracle would add additional implementation expense and security vulnerabilities before deciding yes/no on my part.

2 Likes
13

I agree. I don’t think fixed lower or upper bounds should be set on fees. The rate structure as we currently have it is all we should need. The more economic levers in the system, the more problems (both economic and technical). Also future usage may include micro transactions. Assuming there’s always a person behind every renVM transaction would be a mistake.

14

First of all, thanks for putting this up @Arviee!

If I understand your numbers correctly, than that is only on the first 1/3 of transactions.

What are the total fees paid by all 900 transactions, and what percentage did the smallest 1/3rd of transactions contribute to the total?

You can also share the dataset so I can run the numbers myself.

15

Calling my table a dataset is over-praising it, it’s literally from the stone age, using already made tables from darknodes.online.

1349Ă—471 81.9 KB

:see_no_evil:

And there’s no fee info that I can use (can manually calculate it though). Or someone who knows duneanalytics can probably get this pretty fast. But the resulting number in relation to the overall number will be small, no doubt about it. This is why I call it “optimizing” and mention scaling over time. Every little bit adds up, especially once our volume increases.

If anyone can create a data set with all the info required I’d love to dig in it and make an even more compelling case.

But the technical side of things is still to be discussed.

Edit: Checked available dune analytics and their fee graphs are also broken… not that many available analytics tools to use atm.

16

Given that your data set contains transactions from July 2th through July 19th, we can make a rough estimation.

Those 900 transactions covered 17 days out of the current 21 days in to the epoch.
Total fees collected in this epoch is $573,018.68 as of right now. Averaging and extrapolating this to the 17 days in your data set that gives 573018 / 21 * 17 = 463871

Lets say your 900 transactions yielded a total of $463000 in fees. In the OP you mention that the smallest 1/3rd of transactions yielded a total of $542, this is only 0.11% of the total fees.
Even with the $1705 that would be collected with a $5 minimum (ignoring price elasticity) that is only 0.36% of the total fees.

The total fees collected would be increased by 0.25% (463000 vs 464163).

These are very rough numbers to be sure, and should be taken with a grain of salt, but even if they are an order of magnitude off, the effect would still be small.

Given that the affect on the bottom line for DNO’s is minimal, and the implementation is non-trivial because it requires the use of oracles (which are also not free), I’d be leaning against this proposal in its current form.
Besides, the effect might be quite big for users that are playing with “smaller” amounts of a few hundred bucks, and deterring any users for only a marginal gain will be counter productive in my view.

On a final note regarding the benefit of spam protection, this can also be tackled in a simpler way by implementing a minimum transaction amount denominated in the transacted currency, e.g. you can only sent 0.0001 BTC or more.
Compared to using oracles this might need manual adjustment from time to time (potentially based on a governance vote), but should only be necessary when a currency does 10x-100x

5 Likes
17

Solid post, thank you. …buuuuut, what if we look at this from another POV, from absolute numbers perspective?

Ignoring price elasticity, the difference between now and with $5 min cap is 1705 - 542 = $1163 or roughly $68.4 per day for the whole protocol. That’s a $25 000 increase for the protocol’s bottomline.

What happens when we 5x our $ volume (let’s not forget, this is a slow epoch!)? That’s extra $125 000 for the protocol. What if we 10x our volume? $250 000. Scaling.

With increased adoption and development of low-cost blockchains like Solana we’re bound to see more newcomers with smaller bankrolls and this implementation will be even more important.

…or let’s consider community fund. 10% from $125 000 (5x $ volume scenario), that’s extra $12 500 just for the community fund. Or $25 000 if we play with 10x volume scenario.

Should a business disregard such increase to it’s bottom line? No.

Do we need to prioritize this (if it’s hard to implement) over host 2 host, integrations, enclaves and other priority development? I don’t think so.

Will the dev salary and time investment in this implementation pay for itself? Definitely.

The fee structure can be discussed, sure. Though first I’d want to learn more on the tech side of this proposal…

2 Likes
18

You wouldn’t need a price oracle for this, simply set a fixed fee and update this once a month or something using governance. Doesn’t really matter for a user whether they are e.g. paying $4.92 or $5.11.

But I can’t make a comment on whether a minimum fee is easy to add to RenVM right now as it is.

2 Likes
19

Interesting discussion, cheers @Arviee

I’m generally against any complexity added to infrastructure layer. RenVM is about to introduce something we have not yet seen, with host<>host and smart contract capability available, the less restrictions you have the more creativity can flourish.

Who knows what crazy ideas people can build on top of RenVM, min fee cap might sound like small thing but could be a critical bottleneck in many ideas. Just think about host<>host between low fee chains, imagine the financial tools that can be build on top of RenVM. Suddenly all these things will need to implement this extra fee thing into all their models.

Ideally you want an infrastructure layer that brings stability and consistency with as little friction as possible. I’m having difficulty seeing benefits beyond “DN’s can squeeze out more”, that arguably improves security agree, it is however very experimental at a high technical cost imo.

Ideally a proposal like this would need input from a developer base already established on top of renVM. The same way projects like Aave, Uniswap, Maker and so on have strong opinions over Ethereum development since it affects them directly and they have good insight. RenVM is not there yet, I am of the opinion full focus should be outwards rather than tinkering within

10 Likes
20

One example, universal wallet. With host<>host + smart contract capability someone can build a universal wallet that in effect holds renUSD on all host chains connected. In a situation like that having a % without caps allows anyone who interacts with cheap chains to transact tiny amounts for 15 bps.

Financial inclusivity for everyone. Regardless if shrimp or whale. Say you want to pay sth and the store accepts many different options, you just chose the cheapest chain to pay on. This can even be made autonomous similar to how 1inch works, in addition to choosing cheapest dApp it also checks cheapest chain. We recently witnessed a grassroot explosion with Axie’s NFT boom, there are many unbanked out there thirsty for financial inclusivity.

Someone can pay their coffee using chains/layers such as Solana, Polygon, Arbitrum and renVM will only take a fee of 15bps when it mints on that chain. In a situation like that a $5 standing fee will exclude big portion of your market/users, then you need governance to act to adjust fees and suddenly RenVM can be perceived as “meddling” with dApp affairs, I could see the fud angle there in terms of how much power DN’s have.

Can think of a few more examples as well but will try to avoid a rant lol :innocent:

oh sorry, one last thing, one could argue the fee encourages txs to bundle and thus increase centralization of txs flow and actors (services on top can bundle txs and offer users lower socialised fee, basically a “hack” to avoid the fixed fee implemented)

9 Likes
21

Interesting example Sabobi, I’ll admit I haven’t thought of this. But for the sake of sportsmanship and debate, let me try to go around this…

First point and a question, in a future where low cost TXs are widespread, we will likely see quite a few high frequency transfers from one chain to another, right? Do we really not need any kind of defense system against bad actors spamming RenVM with TXs that cost a fraction of a cent and a 0.15% fee with no min. amount?

Even if disregard this and go with your route with no min fee cap on RenVM, which makes sense in the future you envision. But what about now? Can you shrug off everything I said in this post?

At the moment our two biggest earners are Curve and RenBridge, one of which is our product. Why not enable min cap fee on the RenBridge itself and leave the RenVM as it is? :slight_smile:

I think that’s a solid option as well. We’re not limiting RenVM usecases, but profiting more from the bridge using an industry standard practice.

1 Like