Request That Ren Labs/Catalog Team Submit RIPs and RFCs Outlining Recommended Short- and Medium-Term Darknode Fees for Review and Approval

General
1

Authors: Davoice321, JMKWorld, Wes

Note: This request is being posted in the General channel, as it does not meet the requirements for submission as an RFC.

The RenLabs/Ren team is in the process of potentially implementing major changes to fundamental aspects of the protocol given the ongoing work with the Catalog team. Given this we are submitting this post requesting more clarity, transparency and information from the core development team regarding their plans for the Catalog/Ren integration, especially as it relates to changing the current fee model.

There is ongoing (oftentimes heated) debate in the Discord regarding this issue (given that vital information is not being communicated clearly), and this is being posted to the Governance forums to shed light on these contentious topics and provide an opportunity for the team to respond formally, via RFC and RIPs to gather responses from the community and articulate their plan of action.

Summary

The recent Catalog AMA indicates that the Ren Team is “working on the fee model for applications like Catalog.” Furthermore, the article states: “This decision will be made by the Ren team, and will come into effect 60 days after the decision is officially announced.”

This is a formal request from the Ren community and Darknode owners (DNOs) that the Catalog/Ren Labs team develop RIPs outlining their proposal for a Catalog-specific fee structure for DNO review and approval (and later an RFC regarding a recommendation on longer-term fee structures for Darknodes for similar applications).

Given the speed of development and need to implement quickly, we ask (if possible) that RIP(s) be developed and published within 7-10 days, and an RFC be developed within a reasonable time frame (potentially within 30 days).

Background and Implementation

Over the previous weeks and months, the Ren Labs/Catalog teams have been making great progress in developing an application suite that will rely on Ren’s demonstrated security, reliability and efficiency to drive the Catalog application.

The recently published Catalog AMA indicates that the Ren team will be making decisions about the short- medium- and long-term fee structure for Catalog (and potentially subsequent applications) soon. The Ren team may have also – potentially – decided to bypass the normal RenVM mint/burn fee structure specifically for Catalog, although this is not clear.

Over the past year, the Ren team has encouraged the community and Darknode owners to take additional responsibility for the governance of the network, especially when it comes to implementing fees for applications utilizing Ren (as a bridge or Layer 0 application). Given this it is vital that the community and DNOs not only be consulted, but asked to approve recommendations regarding short-, medium- and long-term fee dynamics for Catalog and subsequent applications built on top of Ren.

The purpose of this post is to formally ask the Ren Labs and Catalog team to develop 1 to 2 RIPs (and 1 RFC) that outline:

  • Whether the standard Ren mint/burn fee structure is being bypassed for Catalog – and if so, requests formal approval of this step from DNOs

  • Specific details about the optimal short-term Darknode fee structure related to Catalog and which option they recommend Darknode owners implement (which would be put up for a formal vote via Snapshot)

  • Information about the longer-term options for Darknode fees and the timeline for consideration, community consultation and implementation (this would be developed into an RFC).

Subsequent to the RIP(s) a Snapshot vote would be held where DNOs can select which short-term fee structure they support for implementation, and whether the disabling of standard mint/burn fees is approved (if this is being requested). Structuring of the vote options and RFCs will be up to the Ren and Catalog teams to implement.

3 Likes
2

Rhetorical question to stop and think:

As a REN holder or Darknode operator, do you want Alameda and/or Ren Labs and/or team members to launch hundreds or maybe even thousands of nodes with all consequences that this will have?

Demanding consultations on technicalities and critical infrastructure decisions with unqualified people by the people who are actually qualified does not make sense. Those who lack specific knowledge consult with experts. Not the other way around.

Moving on, excessive fixation on DAO voting introduces unnecessary bureaucracy and slows down the development, as well as introduces extra sabotage vector (unintended included) because team is not running DNs (so we get more $$$, and ROI is better, and thus REN price is higher) and can not vote.

I believe you agree, that founders, developers and people who are working on Ren should have a say in Ren’s future, right? Than this brings us to the rhetorical question I started this post with:

As a REN holder or Darknode operator, do you want Alameda and/or Ren Labs and/or team members to launch hundreds or maybe even thousands of nodes with all consequences that this will have?

If you answer is “No, I don’t want that (now)”, than you’re most definitely in the majority… But one thing that majority forgets is that WE ALREADY VOTED on giving the team autonomy to develop REN when we bought the token!

And each REN holder IS CONTINOUSLY VOTING by not selling, that he believes in Ren’s future and respectively in those on whom that future depends on, i.e. Ren Labs.

In discord OP said “Why bother with decentralization and governance at all?” and called to “End the farce, if that’s the perspective”…

The truth is:

  • RenVM as a L0/L1 is not finished and is not self-sufficient (yet)!
  • DAO structure and framework is not finished (yet!)
  • There is no decentralization (yet)!

And the only farce is pretending that points above are false.

But that’s not to say that we are not working towards becoming a DAO and becoming decentralized!

Do you know how many people from those that complain about decentralization participate in the DAO effort and corresponding working groups?

Zero. One person was in the Treasury Working group, but his last activity was almost 6 months ago. Why do those, that work on decentralization do not complain on this matter?

Community and decentralization side of Ren is being piggybacked by just a few members and not a single one of them is complaining, because we understand that it’s an ongoing effort.

To summarize, we’re not at a stage where there is a DAO or when DNOs should dictate what should or should not be done on a technical level. The importance of these decisions is critical!

The voting that some of us want is being done continuously every second we hold REN. In some cases, if there’s dissatisfaction with management and direction, it’s best to move on.

On the communication part there’s definitely room for improvement. Team has already took steps to improve on this by going back to monthly reports and they did that well before all this fuss, which goes to show that they are listening. The RFCs and RIPs that this post demands were already confirmed by Susruth:

931Ă—191 41.2 KB

Which shows once again that team is listening and cares.

1 Like
3

I think this comment fails to consider that the only thing being requested here is clarity regarding the Ren DN fee schedule as it relates to Catalog.

This is clearly within the existing governance structure and precedent is on the side of asking for this information and enabling DNOs to vote on fee changes and adjustments. (See numerous RIPs posted on and voted on regarding fees here.)

This has nothing to do with trying to take ownership of technical decisions related to implementation, deployment, etc. outside of the fee structure.

This is a very narrowly defined request.

I look forward to hearing from the Ren team regarding this issue.

5 Likes
4

I feel this is needed, but premature.

Darknodes have no business voting on a fee structure now before the developers even know what’s really going to work and what isn’t. That’s the whole purpose behind the temporary allocation, to give dno something while the platform takes shape.

I think just about everyone can agree on the need for more frequent and fluid communication.

Disagree on the request for devs to create a RFC or RIP this early. This is a technical as much as economic challenge. When the technical parts are understood then we can determine the available options and debate the economic sensibilities of each. No sense voting on something that later on proves to be impossible or unreasonable to activate.

Would appreciate communication on their current thoughts about the different models.

The short term fee structure is just an airdrop of cat tokens. Not sure what the debate would be, though I think if catalog is generating volume right away the airdrop should be in addition to the 5% initial airdrop, not part of it. If it’s part of it, the call a spade a spade and say the initial airdrop is <5%. After that it is revenue from protocol usage, not an airdrop.

2 Likes
5

davoice321 et al – Could you clarify between your original post and your subsequent reply if your intention is that an RIP is provided to ask DNOs to decide by popular vote the critical and delicate fee structure/technical implementation that will make or break the viability of developers building on top of Ren, and in-turn Ren’s long-term prospects (the justification being that DNOs voted on the minting and burning fees for the Ren Bridge prior), or if you’re just “requesting clarity.” These seem like different statements and intentions; I might be able to support one but not the other.

6

I thought it was premature but not anymore. All signals from the Catalog and REN team are that Catalog is almost ready to be launched. So if not discussed now, when? The fact we are so close to the launch and this important subject has not been discussed makes you feel as an afterthought.

Not sure when you think the technical parts should be understood. Before or after the launch? If before then see my comment above about launch is almost ready so now is a good time.
If after the lunch, in discord Jaz mentioned that their view of the “temporal” period is until ren2.0 and full decentralisation. That’s pretty much until REN is completely done. I am sorry but that does not feel temporal at all and it can take years before we reach that state.

As Davoice clarified in one of his post. Changes to the fees have always been a subject for the community to decide on. Nothing new here. The only exception was when was arbitrarily changed by Loong arguing that TVL was exploding. Therefore this idea that the DAO has nothing to do is wrong IMO as we have always voted on this subject.

1 Like
7

Intention is to follow the standard process the team has put in place for review of fee schedules.

That’s always been up to DNOs to provide. I don’t know why this is any different.

In fact, the team mentioned they were planning on taking this step anyway (see image below).

response

Specifically note this: “Our plan was to finalize all the components of the Ren design before we create RFCs and RIPs.”

The situation is that they are already making decisions regarding Ren’s fee structure (prior to finalizing Ren, and their decisions will have a large impact on not just the network but DNOs short- and medium-term economic incentives). See below:

“There are three models Ren is looking into namely: a fixed fee per year paid in CAT/REN, a per use fee paid in CAT/REN and a TVL based fee (which would be a percentage of the total amount locked per year). This decision will be made by the Ren team, and will come into effect 60 days after the decision is officially announced.”

Clearly they are making decisions and creating models – far before Ren is finalized.

What this post does is request that, given the team already has some fee structures in mind and is considering pros/cons of each, that they engage in the formal governance process to provide these options, along with their pros and cons for consideration, deliberation and debate by DNOs.

The team have served as trusted, expert advisors to the community in previous discussions regarding fees, and the community has taken their advice. I don’t see why this wouldn’t happen in this case.

This is simply a formal request to begin this governance process, and also allow the community to understand what’s happening, and to be involved in the ratification of recommendations they make.

Just because the issue is highly complex and technical does not eliminate the need for oversight, transparency and accountability. If that were the case then governance would be broken when it comes to highly complex topics.

Governance is not about putting up votes for “popularity contests” it is about demanding transparency and accountability. Quite a few DNOs believe this is necessary at this stage.

1 Like
8

This is really a difficult topic. In one hand, will affect DNO and future success of Ren. In the other, how I read it, RenChain is a new product and I do believe the current fee structure will not work to sustain and compete with other chains. Also, most of us (I include myself) are not qualified to technically defend one or another model. I believe lack of proper communication is what got many of us disappointed and concern mainly for the uncertainties of where the project is heading. Looking forward to see the new roadmap.

I feel many are crushed by the possibility that Catalog could be built on any chain? So, what is the technology that differentiates Ren from others??? Is just a matter of the right economical model to incentives others to build in the top of Ren? I do not believe, but that is scary….

I agree the team shall determine what the best economical model is, but they need to demonstrate to the community the resonating behind it. That is usually part of the whitepaper!

Or… Alternative, a technically qualified board chosen by the community participate developing the model?

I do not think a standard RIP/RFC process is the most efficient way for this. Unless, the model is defined and send to the community for approval?

The most important thing is transparency and communication must improve.

1 Like
9

First of all thanks for your efforts on getting the discussion started on this @davoice321. I share the sentiment that more can (or should) be shared, discussed and deliberated with the community and especially DNOs.

That being said, let me try to clarify one thing (emphasis mine throughout).

The team mentioned on Discord that this was poorly worded, it is actually the community and DNOs who will make the decision. The AMA answer has since been updated to reflect this as well:

This decision will be made by the Ren Community and DNOs, and will come into effect 60 days after the decision is officially announced. [1]

As you mention as well, the team has already committed to submitting the necessary RFCs and RIPs to achieve this.

Am I right to conclude that your ask has been satisfied and we are now just waiting for the proposals to be posted by the team when they are ready, or is there something else you’d like to see/be discussed?

  1. Catalog AMA — April 2022
1 Like
10

Right now we are waiting to see the RFCs and RIP re: the potential Catalog fee structure and DNO fees on Catalog, yes.

So the ask is still outstanding, but we’re waiting to hear from the team on timing for the RFCs at the moment.

11

We are working on a big proposal outlining our vision at the moment

7 Likes
12

I have had issues with logging onto Discord so I am not in the loop FOR quite some time with any of the discussions taking place on the platform. I feel somewhat in the dark.

Hoping that Catalog Fi will be beneficial to the REN protocol and to DNOs.

The fee amendments are always put to a vote with DNOs when concerning the Mints and burns on the RENVM. So I don’t believe that should change.

Presumably Catalog Finance will have different fees for there various products so i do hope that DNOs can benefit greatly from that.

13

Actually I do sympathize with this viewpoint to some degree (more on that below). But it also reminds me of those that say, “If you don’t like this country, leave!” Maybe a better approach is to try to make things better first? And that’s how I view this particular RFC, as an attempt to make Ren better. More transparent. Ensuring DNOs have a chance to determine how they will be compensated.

This brings me back to your point of “voting by not selling” and trusting “those on whom that future depends on, i.e. Ren Labs.” Trust, you see, is earned. And two key components of trust are openness and honesty.

After trying on numerous occasions to get critical information from the core team on rather significant issues, I eventually realized that transparency is not how Ren Labs operates. At least not to my satisfaction. That the info I considered basic to do a proper job would never be forthcoming. And I could either accept it and continue to participate in a very flawed governance process (in this particular case the Treasury Working Group), or step back from direct participation and wait to see if things improve over time.

I chose the latter option. Hence why I do have sympathy for your view that holding the token is a tacit endorsement of the team itself and how it operates.

In any case, I think this RFC was forged out of frustration with Ren Labs and their lack of transparency, so I welcome any initiative that forces the core team to consult with the wider community. Certainly on critical matters such as pricing. And especially when there is a potential conflict of interest, as is the case when Ren Labs is a significant stakeholder in both Ren (likely) and Catalog (surely). And pricing is being fixed between those two entities.

I can’t see how anyone would view more clarity on how they will be paid as a bad thing, but :man_shrugging:.