Important thing to understand is that this RFC does NOT mean that Ren 2.0 will keep the same tokenomics it has now. Ren 2.0 will still need to have inflation.
This RFC, while being interesting and potentially viable down the line, introduces significant short-term hurdles on top of what we already have.
Ren Bridge would need its own management team, dev team, marketing team. A fundraising campaign will need to be organized and chances are that it might get a lot of negativity due to what lead to its inception (dire need for Ren 2.0 funding) and how raw everything is (Bridge team, long term vision etc).
And the delay of Ren 2.0 due to this is just a nail in the coffin.
It is my strong opinion that we need to launch Ren 2.0 and get $renBTC back in the game as soon as possible. We do not want to lose our position in the interop game.
If there is any substantial time cost to implementing this RFC as Max above plainly states there will be (substantial and unknown length), then I am strongly against this RFC.
I think it is ultimately a superior design for security and decentralisation (compartmentalising the risks of various components of the ecosystem) but it cannot come at the cost of months (or even longer) of delays whilst 1.0 is sunset.
I also fail to see how it really is any different from a dilution perspective as just inflating the supply of REN by x%, and airdropping DNOs x% of the tokens they have bonded so that their percentage share of total tokens remains the same and all the dilution is passed onto those holding unbonded REN, except for the fact that many people will be left with a non-integer division of 100k REN extra so will not functionally be able to run any more nodes- their nodes will be slightly less valuable if presumably more nodes come online (because 100k REN is cheaper to acquire post dilution) so there might be more nodes sharing rewards, but at least they will have extra REN to sell or to be closer to their next node(s).
Any loss here is splitting hairs compared to the pressing concern of getting REN 2.0 funding and REN 2.0 online asap, or else the potential total erosion of the value of REN tokens. In both cases the REN team/DAO can get all the tokens not airdropped to avoid dilution to DNOs, and with straight inflation, there are no legal problems with who can use the funds for what, and the whole process will be massively quicker.
I am almost certain we will lose massively more via lost network effect and lost opportunity to grow business and presence in the time difference between trying to implement this spin-out proposal and just getting vanilla 2.0 out via simple inflation than any gain that might be had from superior design.
The proposal is a good long term idea, but we can work on refactoring 2.0 into this form ONCE it is online and the project is out of crisis mode.
If this spinoff RFC is chosen, then the Ren dev team does not know when Ren 2.0 could be live, it would likely delay everything by many months as it would require further technical developments to Ren 2.0.
This claim really deserves a more technical explanation, Max. It’s based on a critical assumption that Ren 2.0 could not be launched until the layered security model with an external RenBridge network were fully supported.
Why can layered security not be treated like a feature that would be supported as part of a phased release of Ren 2.0? That was what was implied by this RFC and the impression given when this idea was first proposed in July.
Achieving a stable mainnet before its release would be a responsible technical approach and an essential use of funds. As long as investors were informed that the RenBridge network requires a stable Ren 2.0 to host the application and that it would be supported as part of a responsible phased release, I wouldn’t see risk of a breach of trust.
I agree with you on all counts, all that matters now is getting Ren 2.0 out as soon as possible.
Anything else is a waste of time and could mean the end for Ren 2.0
It’s really up to us now to stand behind the team and accept the inflation and do everything we can to get Ren 2.0 out as soon as possible.
Whether with more staff or whatever, we should now trust Susruth 100% again and no one else, because he is mainly building Ren 2.0
Thanks Max for the kind answer.
If this well defined path proposed by David leads to further delay in Ren 2.0 deployment, I would certainly vote for your RIP. We can’t afford further delay. There is a huge opportunity cost at stake.
I agree, especially since there are also many network effects at stake that are in danger of being lost with further delays. More and more BTC bridges are coming and that has always been our main benefit.
Yes that’s why the team proposed it, think it would be very reassuring for all sides to know that the team is securely funded.
It needs inflation for that and investors want to see tokens.
Before that there probably won’t be any information about a possible investor.
Get 2.0 up and out the door asap. If that can be done, and still work this RFC around/on top/parallel to 2.0, then even better
If it results in long delays for 2.0, don’t scrap it completely, just work it in afterwards if possible.
If inflation is what keeps the ball moving, let do it. Bonus points for Arvee’s suggestion of rewarding existing DNO’s, and also considering length of operation of the nodes.
(related to 3 above) As a multiple DNO, who also owns unbonded REN. It would be nice to also take into consideration this third group of folks (not just DNO’s and non DNO’s). I’ve had nodes for a long time and was accumulating ren to run more, but stopped short of registering them as I thought 2.0 was near, and then the whole ftx thing happened. I’m assuming there are more folks here like me who have always run nodes, but also had other REN ready and waiting. It would be nice if that were “counted” along side what was already bonded as well…just a thought.
I really appreciate your work @DavidPerkins and it’s also great to see what kind of expertise you have.
But even you have to realize at some point, when it no longer makes sense to constantly bring out a new rfc and that it only delays everything further.
Back then with your rfc for Renbase it went smoothly and the voting was done within a few days.
Now it’s even more urgent and since we simply don’t have any resources left we can’t get around inflation. Your proposal would work just as well without new tokens in my view.
Which means that it’s just another kind of inflation but in the end it’s the same.
Only that we have a delay and don’t know for sure if we will even collect enough money.
The days are gone that people invest in everything where an ICO is coming.
It would be nice if you could accept that.
Again I appreciate you very much but also everyone else. One alone is no one in crypto.
We should now decide on the solution from the team and pull together, because it only works with the team and the community.
You should know that best, right?
Why do you want to reward one who only holds Ren but does nothing for network?
Why reward people who have run dnos in the past and now stop or sell their Ren because they think it continues to fall and then maybe buy again?
Should not reward people who will run a node at Ren 2.0 from the beginning. That you get per epoch xx Ren as a small compensation for inflation and you have incentives, especially if it is not worth it at the beginning to operate a node because the return will still be very low.
Ren Labs would become the RenBridge team since they would be funded by RenBridge investors. As mentioned, if Ren-specific, non-RenBridge salaries or use of funds could be considered a breach of trust, then they could be paid by the Ren Foundation via a more modest inflationary policy.
Or, this would be pitched as an opportune time to publicly share new designs for the most secure and decentralized Bitcoin bridge to date, which would have required a new token eventually anyway.
I agree with these points, which is why I wasn’t referring to those groups in my comment. If there were a hypothetical airdrop, it should not reward those who only hold ren, or those who may have run dn’s in the past but not longer do, I totally agree there. I was referring to a sub group of folks who are current (and possibly long-time) dno’s who also may have been accumulating and had been holding off on running new nodes because of all of the change/drama. It’s all on chain, not hard to come up w some parameters and verify. That’s all I meant. Not the end of the world, would just be nice to consider that scenario.
If you continue to spam this RFC to try to influence governance with low-quality posts and misinformation, you will be removed as you were in Discord for doing the same using multiple accounts. You’ve made your opinion known and there is no need to continue to belabor it.
Whether it’s adopted or not, this proposal has arguably received the most support of all options thus far. So, the time to stop proposing ideas is clearly not now.
This very RFC is a practical proposal to avoid printing tokens for the sole purpose of raising short-term capital to fund development. As I’ve mentioned many times, I would be in support of a more modest inflationary policy for long-term ecosystem investments.
it is a great proposal, however, will there be enough time to sunset 1.0 and get a new token off the ground?
Luna tried it, and it looks like LUNC is still the token of choice with the market place.
I don’t know if this is agreeable sidenote, but both FTT and LUNC have much higher market cap than Ren, and both of those I consider to be nothing but zombie tokens at this point in time.
Anyway, I don’t know if there much time to get your idea rolling with essentially a project crisis point as it is in now.
Good to know it isn’t necessary to delay rollout of “regular” 2.0 in order to accept this technical design. Do you foresee any delays in the future- large technical milestones for regular 2.0 that would be pushed back in order to develop and activate this? If we attempt a funding round for this now how is there going to be issues with investors knowing development for what they are giving money for will not even start for some time?
Does the 2nd token increase security above having this technical implementation alone, you may have explained already. I just wonder if having added complexity and tokenomics is adequately reimbursed by the added security of a 2nd token. I still think inflation alone isn’t such a taboo thing since learning Ren will also function as a gas token. This may help increase its value as it = more income for nodes as well as more demand since more need to hold for transactions.
Perhaps we have an inflationary round and later when ready to begin a RenBridge round, we burn an appropriate amount of Ren based on how much is raised.
