Just for clarity - is the concern here 1) The current amount TVL is generally too high or 2) the TVL/TVB ratio is too high?
If 1) I can get behind this proposal. But there’s no beating around the bush - we are jacking up our rates intentionally to dissuade further minting during the Greycore period in order to decrease our risk of losing locked funds (hacked, accidental, or otherwise). We should also recognize that in doing so, we create a separate risk in losing [potentially significant] market share to up-and-coming 3rd party projects , as well as the chain-specific bridges. While I hate that we have found ourselves in this position, I trust Loong, Max, and the Core Team’s vision and will back them on the proposal.
If 2) I would think it would be much easier to control the denominator rather than the numerator. I recognize lowering the bond required for a darknode is outside the scope of this discussion, but it seems to me that would be the quickest way to adjust the TVL/TVB ratio. Not trying to derail this thread, but I do think this is something we will need to eventually consider if a low bonded value becomes an issue in Mainnet 1 (granted I’m not 100% clear on the Asylo stuff)
All things considered I’m incredibly excited to see the amazing progress the team has made and look forward to the future and next steps
Without security there is no project, there is no operational platform, there is nothing. Therefore agreement in a temporary system of Fees tending to reduce TVL (0.4% M- 0% B).
Dissent in the idea that the TVL is not an important metric. These days it has been clear that positive feedback between volume, TVL, price, visibility, etc. It is a concrete fact. Having said, the dynamics of host to host of course will convert to the volume traded into a more independent Data of the TVL (inside the home to pass room to room generates income without modifying the number of inhabitants of it).
Something that obviously was discussing doors in I consider that it could have been anticipated in some way by the team. Said constructively.
I hope everyone is doing well. I have analyzed and read the current proposal regarding the fees and all your comments across telegram and the forum.
One thing I have to say I don’t agree with is the timeline of the events surrounding the proposal.
“The Ren core team believes it is imperative to implement these changes now, for the duration of the Greycore transition, not only to secure long-term success by minimizing the risks and consequences of an unforeseen attack, but also not to put too much risk on the shoulders of the new Greycore members.”
Here is how I would have done it if I was the team.
Release host-to-host first in order to have the third fee (burnandmint) that’s so crucial to TVT. We could launch burnandmint function with 0.20%. This host to host functionality of RenVM will help users make the decision to spend 0.4% initially. For example, with host to host active there is no reason for me as a user not to spend 0.4% initially if I can move my renASSET between chains at the speed of light. More renVM functionality (h2h), more volume. More volume, more revenue, higher TVB.
Right after host-to-host is live propose the mint fee increase and burn fee decrease in order to limit depositors into RenVM or to generate enough revenue to increase TVB.
After community is on board and proposal regarding fees has passed, start moving greycore from testnet to mainnet.
Important to note that I think we are still on time to follow the timeline I have mentioned above and for the team to publicly acknowledge that the current proposal will only go live AFTER host to host has been released.
I will still go ahead and vote for 0.4% mint fee and 0% burn fee in order to help with RenVM’s security in support of Loong’s comment BUT I am hoping that this fee change goes live right after host to host is released in order to take advantage of the burnandmint function which could be a game changer for RenVM’s income. Again, as we all know, more income, more TVB . More renVM functionality (h2h), more volume.
Will coins already locked be subject to the new burn fee and thus get away with a 0.15% net if the burn fee is changed to zero?
Assuming that is a yes, I’ll vote .4/.1
I highly value the core team’s risk management discipline, but I’m also concerned that this market is driven by network effects and this market is moving at light speed, so adoption is paramount.
For that reason, I suggest applying further effort to educate prospective decision makers on why TVL is not the right metric to look at, and what to look at instead.
This is a good point. It may be better to have full control during host to host so team can learn and prepare the Greycore better than trying to have two unknown variables playing at the same time: h2h and Greycore testnet
On a less serious note, I couldn’t help reading that passage and thinking how poor Loongy woke up one recent morning covered in sweat, having finally realized that - thanks to his work and the hard work of the entire team - this little protocol, barely on Mainnet for a year, was about to see an unGodly amount of money flow into RenVM. I’ve been saying that for months, host-to-host, coupled with the added security of Greycore (critical for many users who have shied away from Ren to date) would likely cause an explosion in TVL. And here we are…
I model Ren income and can agree, TVL has zero theoretical impact on underlying value, at least if you believe in discounted cash flow value analysis. But I can also see quite clearly the market thinks otherwise. The price of REN seems to be highly correlated with TVL, likely because few crypto investors understand RenVM. But I also agree with @Joel that there are real, intangible benefits to TVL that go beyond what can be captured in a spreadsheet. And of course there are no guarantees the TVL-REN token price correlation will hold moving forward.
Clearly if your goal is to pump the short-term price of REN, a high TVL is your friend. But from a security standpoint, this is apparently quite bad… One of the things that always concerned me was the lack of clarity on what exactly we are trying to do with TVL. At one time we had a clear, objective goal with TVL in relation to TVB. But later we learned that the team had made some significant breakthroughs in this area, and now those initial numbers no longer apply, we can actually manage more TVL with the same TVB. But sadly this was never really quantified, perhaps it couldn’t be, not sure. So now it’s very hard for a layman like me to really understand how risky our current TVL/TVB numbers are (or even if that is the key metric any longer), and hence hard to really judge the importance of lowering it.
If the core team is convinced safety will be enhanced by reducing TVL, or perhaps better said reducing the growth of TVL (since the genie is out of the bottle), and max mint with min burn is the way to go, who am I to disagree? Obviously safety must take precedence over everything else. I only hope we have a bit more clarity moving forward on how to actually quantify the risk of TVL/TVB, or whatever metric is chosen. That would help the community in the future when debating changes to existing pricing.
I support the .4% mint. Considering a .05 or .1% burn - will this extra .05% or .1% change any minds? Maybe only arbs.
Couple points of question:
The .15% burnandmint fee is great - a low fee to hop chains and once you pay your ticket to get into RenVM you have a low cost way to follow the best yields. But what of stablecoins? Possible scenarios are if you have USDC on Solana, and you want to move it to Ethereum for a better opportunity, you either trade for an Eth-derived renUSDC and then burn for free back to USDC on Eth, or you have to mint a Sol derived renUSDC on Eth and trade if needed. I haven’t done enough yield chasing to know which is best, and how this may effect people’s decisions to use RenVM to make their change. Hopefully the functionality and UX is so good the .4% fee to make this hop is worth it.
Limiting TVL now is to achieve a lower value in risk. If we raise TVB, are we mitigating that risk at all, or is it just part of experimentation? In other words, if there is an exploit, how do we reimburse funds lost?
Increasing mint fee will ultimately contribute to lowering TVL but I am not confident that 0.4% does it
Decreasing burn fee WILL NOT contribute to lowering TVL
The proposal to lower burn fees is misguided.
I am also yield farming using BTC and I don’t monitor nor care if the fee is 0% or 1%. If I want out, it’s because I am in pursuit of other more lucrative opportunities, the low burn fee is not a factor at all and isn’t going to encourage me to leave. I know I am just one person but I believe my thought process mirrors most people’s because we all are motivated by earning yields.
I think we are leaving $$$ on the table and shortchanging our community fund by lowering the burn fees. People are going to burn regardless of whether it’s 0% or 1%. It’s too bad there’s no keep burn fee at 0.15% option.
Also, as another community member pointed out, mint + burn fee = total cost. By lowering the burn fee, we are actually lowering total cost and incentivizing more people to mint not disincentivizing them.
Looking at the rationale for this proposal, it seems as if the team is under the impression that mint/burn fees actually encourage/discourage user behavior.
My impression is that the market is largely price insensitive, especially in the context of yield farming and generating income, where yields far outpace fees.
So, while we can vote for a higher mint/burn fee, I’m not sure if it’s going to change users’ behavior. I’m not sure if the current burn fee is keeping people from using the network, much like the current burn fee is not preventing them, nor encouraging them from leaving .
For future conversations, I would advocate for using the Community Fund to conduct some research and analysis to determine users’ price sensitivity and historical analysis to determine whether the most potent determinant of mint/burn volume was profit taking/profit seeking behavior, rather than mint/burn fees.
As for those advocating for a 0 burn fee, that makes no sense on many levels. Certainly lower it, but not to zero.
Regarding the TVL discussion, the team said that this is a temporary measure, and it isn’t meant to radically reduce TVL over the long-term.
This. We assume too much about price sensitivity. Initially we only have two data points and no significant correlation (or even slightly inverse). Especially for H2H, with no direct competitor, even a high fee will still be much cheaper than current multi-hop approaches users must face, and minimal for the average user compared to slippage and gas fees faced on most amms.
Large increase in DNO revenue means a large increase in nodes and security value. Zero increase overall but lower TVL does not increase security; it only decreases risk.
The fastest way to know for sure is to increase fees, then we have 3 clear data points to extrapolate from. Same or similar fees will not help us gather new data on this issue, and therefore, will not help with long term security. Best to experiment now before we are at 10x more volume. Gathering data should be our priority as we think about what rates to pick next. (Ie same total rate with different burn/mint allocation is somewhat too minute to truly get significant data correlation on price sensitivity, but higher total rate macro first will give us a bigger movement if any)—let’s be wary of assumptions. Inverse correlations may surprise us.
Ps. What if we discover that sub 1% fee changes have zero sensitivity bc the market is moving so fast/liquidity is too low that nobody cares? We are not yet a multitrillion bond market, so rates may not affect much in a world where 3-4 figure yield farming or 1-5% swap/gas fees are common.
The reality is that we have no hard data on the market’s fee sensitivity (if any) as it relates to Ren VM and I think that there’s a decent chance we’re assuming causation and not correlation between raising mint fees from 0.1% to 0.15% last year and WBTC’s market dominance rising. The reality here is more likely, in my opinion, that DeFi summer brought in some bigger players who needed KYC/AML which they require and being built into a popular exchange already, they became an easy default for many.
We’ll likely learn the same things and discover the same bugs taking a 0.1% fee on burns as we will a 0% fee. Surely we can improve the security of the network without DNOs leaving money on the table.
I question the process of democratically determining fees, or prices. Democracy is not perfect, and neither is majority rule. Both can fail, and they often do. In political science, it is well known that failures occur when democracy is introduced into diplomacy. In business administration, democracy works only imperfectly even in the realm of marketing, and democratic decision making rarely works well in the highly sensitive area of pricing. dictatorship is highly favored when Renproject is positioned as a startup, and pricing If Renproject is positioned as a startup, dictatorship is highly favored, and someone should be in charge of pricing, a task that requires inspiration and talent. Therefore, a paradoxical mechanism of indirect democracy or a committee system to avoid direct voting and democratically elect a dictator would be a realistic solution.
On the other hand, since Renproject aims to be completely decentralized, it is natural to think that no dictatorship should be allowed, considering the basic idea of the project. However, I think that deciding the price by voting is too naïve an approach that ignores the knowledge that humanity has accumulated about collective decision-making, especially the knowledge of failure.
This is not the first time we have voted on fees, especially to my knowledge. Price is a very important factor and signal for users. Democratically and ad hoc price changes are equivalent to denying stable service provision to users. We don’t want Ren’s service to be like gasoline prices or some other products where the government politically decides the price before the election. I hope so.
My specific suggestions are as follows.
Don’t have a popularity contest for pricing.
Indirect democracy, in which people vote on who determines the price.
Or an indirect democracy that recognizes the autonomy of price fixing and overlooks its dictatorship.
Fix the price at zero or very low.
If prices are to be changed, they should be timed. If prices are to be changed, they should be timed, for example, revised once every two years.
Assuming that Ren is a great financial infrastructure service and that the existing financial business is not great, we should take seriously the fact that they have earned a certain level of trust from their users in that they do not revise their prices so often and do not let their shareholders vote on their fees, even for financial services that are not great (assuming banks, for example).
RenVM, the RenBridge UI, the Command Center, and RenJS need to manually be updated at the same time so that new fees can be implemented without any hiccups, as RenVM will be running without downtime and users will be coming to RenBridge as normal. The frontend and backend teams will be deploying these changes very soon, within a few days, coordinating to make the process as smooth as possible and laying out the process for the future where fees might be changing much more frequently and even algorithmically.
There is an internal discussion on the safest implementation for the fees with regards to decimal points, so will update you all shortly when that part is confirmed.
General comments
Thanks to everyone in the community providing feedback, we’ve read all comments and consider them very carefully. The proposal was biasing towards a change, and that’s something we always try to avoid, but for the sake of security at this especially critical transition period, the team believes it is imperative that we double down on security practices.
We’ll have technical updates on the Greycore rollout on testnet and the H2H deployment coming up soon.
The final fees will be 0.36% for minting and 0.07% for burning, rounding to two decimal points.
The team suggests that the rounding policy should be conservative, meaning always round towards the value that is closest to the previous fee. This would not have changed anything for this vote compared to regular rounding, but for example if the results were 0.368…% for the minting fee, that could have be rounded down to 0.36%, which in a small way reduces the volatility of the fees.
Date: The team will aim to have the fees updated by next Monday (October 4th)
