RFC-000-050: DAO/Foundation Nodes

Requests For Comment | RFC
1

Name: DAO/Foundation Nodes for Funding Operations
Authors: @PappyShappy
Category: Governance, Funding
Status: Draft
Scope: Using DAO/Foundation Nodes for Funding

Overview

With the passage of RIP-000-018: Ren 2.0 funding and Ren Foundation and RIP-000-019: Round RIP-000-018 funding results, the DAO has voted to establish a Ren Foundation and mint 180 million new REN tokens to help fund Ren 2.0 development and ecosystem growth. With passage of RIP-000-020: Ren Foundation Domicile, the DAO is moving forward with a legal structure to support the continuing operations of the DAO and the transition to REN 2.0. The overall objective that ties these together is to move away from external funding from Alameda such that the REN DAO and community is self-funded. Using DAO/Foundation Nodes will support this effort by enabling us to have long-term perpetual funding of our development, governance, marketing, etc. operations.

Background

In various discussions leading up to, and after, the votes for RIP-000-018 and RIP-000-019, there is a lot of controversy about how to use the new 180M REN tokens to fund operations (i.e., development, marketing, legal, etc.), but there doesn’t seem to be any clear consensus.

One option is to keep the number of possible nodes at 10,000 by increasing the bond per DN from 100K to 118K. So that this would not burden current DNOs, this option includes an airdrop of 18K REN to all “current” DNs with the balance of the 180M REN to be used for funding operations. This option is what was described in the RIPs, but it is nonetheless controversial since there is an ongoing debate on how to fairly determine the “current” DNs for purposes of the airdrop.

The second option being discussed is to keep the bond at 100K to avoid the appearance of unfairness by avoiding the airdrop altogether. Part of the rationale for this option is that there is no reason to keep the maximum number of nodes at 10K and that the entire 180M REN is kept for funding operations.

A potential issue with both options is that they appear to only be taking a short-term view of how continuing operations are funded. For example, what happens when the current funding of 180M REN is exhausted? Do we propose another funding round a few (or many) years from now? Do we look for another outside funding source? Do we keep using the current “haircut” process of allocating a percentage of earnings every Epoch from all DNs to generate future funding once current funding is exhausted or to supplement funding?

Because these long-term funding issues are not fully vetted, this proposal is being put forth to generate discussion and hopefully a consensus on how to proceed once the legal structure is fully operational.

Proposal

Within the new DAO structure (e.g., board, managers, etc.), a portion of the new 180M REN should be used to set up Treasury DNs. This would replace the current haircut from all DNs to fund operations, allow transparent funding in perpetuity, and minimize the number of new REN that needs to be sold to fund short-term operations. This should be done in a very transparent manner, such that ongoing funding information from the Treasury DNs is always shared with the community. To increase incentives for supporting the REN community over the long-term, a portion of the Treasury DN income should be shared with all non-Treasury DNs in proportion to how long each DN has been in operation (up to a limited number of epochs).

As part of this proposal, the DN bond can be kept at 100K and the total number of possible nodes can be allowed to rise above 10K, but with the goal of burning / buying back most or all the 180M REN in the long-term. Whether all the 180M REN is burned or not can be determined later, but it would involve a decision on whether to keep the total number of possible nodes at 10K or just the total number of non-Treasury nodes at 10K.

Discussion

Over time, the process of using Treasury DNs should provide significantly more funding for operational uses, e.g., development, marketing, etc. While this presents us with a dilution issue (i.e., more nodes mean smaller shares of total income per node), we could replace the current haircut from all DNs with a “bonus” for non-treasury DNs that is “balanced” to keep relative net income as consistent as possible. It also allows us to create incentives to reward long-term DNO support.

For example, if we assume there are currently 2,000 DNs that share in $800,000 of income per epoch, the gross income per DN is $400. If we assume that the current haircut is 5%, then $40,000 per epoch is allocated to the funding pool and each DN has a net income of $380. The haircut should be based on the per epoch funding that we should have been using if we were not using outside funding from Alameda so we get a more accurate comparison.

If we add, say, 200 Treasury DNs into the picture, then the gross income per DN is $364 and the total gross income for the Treasury DNs would be $72,727 per epoch. Assuming we only need a budget of $40,000 per epoch for operations then approx. 40% of the Treasury income could be allocated back to the non-Treasury DNs as a bonus, the net revenue for the Treasury is $43,636, and the net income per non-Treasury DN is $378.

While this example is intended to be realistic, the actual number of Treasury DNs and the share of the Treasury income allocated as a bonus to non-Treasury DNs will need to be based on projections and budgets. However, it also illustrates that this makes it possible to pay additional costs of running the Treasury DNs, increase the Treasury compared to the current situation so we can build up a war chest for unexpected development costs, marketing opportunities, and in the long-term buy back and burn the 180M new REN.

We should expect that the number of Treasury DNs and bonus share would change periodically, with the DAO proposing the numbers along with budgets and support for their recommendations so that all DNOs could vote on it. Other discussion points for these recommendations could include “What is the optimal share of Treasury DNs to avoid concentration issues?” and “How can this funding be used to expand the REN ecosystem and transactions for the benefit of all DNOs?” among others.

To avoid the potential concentration issues, we could add recommendations to the proposal such as limiting the number of Treasury DNs to between 10-20% of the non-Treasury DNs and noting that the Treasury DNs will have no voting power since they are for the benefit of all DNOs and the community.

Another potential benefit of this approach is that even though the DAO can mint another 180M REN, perhaps we can start with much less than the full amount and if the funding pipeline from the Treasury DNs is sufficient, and hopefully becomes more than sufficient, we won’t need to sell as much of the REN in the short-term and we will have fewer new REN to burn in the long-term to get back to the original 1B REN.

Regarding the allocation of the Treasury bonus per epoch, it seems appropriate to keep it simple but long-term focused. Since there were 35 full epochs prior to the “Alameda shutdown”, each DN should earn a share of the Treasury bonus based on how many of the “current” 36 epochs it has been in operation. Thus, a DN that has been operational for the full 35 “prior” epochs would get a full share, and a new DN that has only been in operation for 1 “new” epoch would get a 1/36 share of the Treasury bonus. For counting the “current” epochs, we would exclude the latest few epochs after the “Alameda shutdown” and start counting “new” epochs once the entire network is operational again (i.e., whether we can restart using version 1.0 or need to wait until 2.0 is ready). Thus, after the restart a DN could have a maximum of 35 “prior” epochs and 1 “new” epoch for a total of 36/36. For each subsequent “new” epoch, the oldest “prior” epoch is dropped from the “current” count, and once we reach 36 “new” epochs, the “prior” epochs will no longer be part of the “current” count.

A nuance of counting “current” epochs for a DN could arise if a DNO needed/wanted to transfer their DN from an old to a new wallet. For example, if they thought the security of the old wallet was compromised or they just wanted to move to a new wallet for practical reasons. In this case, we should allow the DAO to grant a “transfer” of the count from one wallet to another with sufficient documentation and proof. In this case, the 2-3 epochs when the old wallet was being deregistered would be excluded from the “current” count, so the “penalty” for transferring to a new wallet is just those 2-3 epochs and not having to start over at a 1/36 share of the bonus.

As a final thought on transparency, it should be possible to include the full Treasury DNs share of the epoch income on the Command Center along with the number of Treasury DNs and the bonus share for non-Treasury DNs. Similarly, for each DN accessed through the Command Center, their “current” epoch count could be shown along with their share of the bonus income. It would also be a nice improvement to show pending income from the current and prior epochs separately – i.e., the headings could become Withdrawable, Pending Epoch X, Pending Epoch X-1, Pending Bonus. Unlike the regular DN income per epoch, the bonus share would become withdrawable immediately and not split over two epochs.

1 Like
2

Thank you for taking the time with this, couple thoughts (and I look forward to the input of others):

  1. I think it best, especially given your idea as funding would then be secured for future, that we print the complete 1.18 billion tokens and can burn what we don’t need later. Starting small and minting more later not only disturbs the last vote entirely, but keeping the contract open will invite criticism over the unlimited potential to inflate and may allow us to rely on inflation in the future instead of pursuing other methods of funding.

  2. with that being said, ideally we leave the bond at 100k Ren, and maintain a rough target of 18% treasury nodes so true investor node count is still maxed out at 10,000 nodes. Makes it very simple and solves our issue over who gets an airdrop. Once we start hitting a high enough number of nodes to make it unreasonable to continue spinning more up, say 500 or so, then the income from those 500 should start buying/burning Ren at opportune times to lower the total supply. 500 nodes should be adequate to fund Ren protocol indefinitely. And over time they can even be slowly deregistered and the bonds burned until an ideal target is hit (which might be all of them and a small node tax is the simplest solution for perpetual funding).

  3. my devils advocate stance is why do we even go through all this trouble of creating and maintaining nodes, just to pay back other nodes with most of the earnings? Wouldn’t it just be easier to tax the nodes, even tax them in a way that still rewards nodes who have been registered longer, and even have a small % of the tax go to a fund to buyback and burn Ren at a set rate? I feel this solution performs the same functions of treasury nodes but much simpler. Treasury nodes give the benefit of security with more nodes in the system, but I struggle to see what more benefit they have over a simple tax strategy. Can you provide explanation of benefits of treasury nodes vs an advanced tax system?

3

Doesn’t make much sense to have the Foundation become an operator, this damages decentralization, adds a lot of operation and legal risk to the Foundation.

The point about ensuring the Foundation is funded long-term is valid, but that can already be taken care of by the CEF, without any operational/legal overhead to the Foundation.

Also it’s a much simpler parameter for governance, voting on the percentage of rewards going to CEF/Foundation, which can go up or down as needed, compared to having Foundation registering/deregistering bonds and operating nodes.

1 Like
4

Thank you for your comments. I will give you my thoughts on each point and, like you, look forward to input of others.

  1. You make a good point about minting all tokens now, which I am not opposed to. My point about using less now was not about how many to mint or print now, but rather about how we use them over time in the most economical way. If part of the operational plan includes selling the treasury REN to generate US$ or Euros or whatever, it makes more economic sense to sell less now while the price is suppressed and keep as much in reserve for later when the price goes up.

  2. With this point it sounds like we are on the same page in the sense we are expressing variations on a common theme. It seems to me that the key is to have the DAO “management” (whatever form that takes) present a complete budget to support the numbers (i.e., number of Treasury Nodes, non-Treasury share, etc.). I have no issue with your 18% max as it falls within my initial thought of a 10-20% max. My range was meant to convey that in the short term with fewer non-Treasury DNs the max is likely to need to be higher, maybe higher than 18-20%, but in the long term it should naturally decrease to 10% or less or even zero as you suggest. Time will tell and I think we only need to agree on guidelines at this stage.

  3. I agree that in some ways continuing with a tax is simpler and one of my motivations for putting this forward is to draw out the pros and cons of each approach. In addition to the security benefit that you note, I think there are two key benefits to this approach. First, I think for any DAO to be successful we need to have what I will term “hyper” transparency so that the community can have faith in their leadership and open and full discussions about options. I will expand on this point in my response to sotashinokomata. The second benefit is psychological and motivational. If one of our goals is to grow the network and community with new DNs and DNOs, then which option will be more appealing? Imagine yourself having newly discovered REN a year or two from now and consider the options. Would you be more likely to want to set up a DN knowing that part of your earnings are being taxed, or would you prefer to see supplemental earnings that you will get a share of and that that share is growing the longer you keep your DN active? If you also discover that the tax is less the longer you keep your DN active will you view this as a penalty for opening an new DN?

As an aside, I think these psychological and motivational issues make using an airdrop the worst option. Consider the scenario where you discover REN a year or more from now. The bond is 118K and you try to figure out why such an unusual number (i.e., why not 53K or 184K), so you start digging to discover it used to be 100K but the early DNOs voted to give themselves an additional 18K so it cost them nothing to keep their DN active while you need to buy the extra 18K. How will that help us to attract new DNOs?

5

Thank you sotashinokomata for your comments.

I don’t follow how adding more nodes damages decentralization? My understanding is that we can use multi-sig, exclude the Treasury DNs from voting, and perhaps other options to reduce any operational risks while adding more security. Perhaps you can expand on your reasoning for this damaging decentralization and why the risks can’t be mitigated.

Yes, there are some additional operational costs with this option compared to just keeping a tax, but in order to understand the options better, more details are needed. The ongoing costs are $6 per month per DN using Digital Ocean, so it would be helpful to understand the rest of the costs in order to have an informed discussion.

I’m not a lawyer, so I have no idea what the legal risks are to the Foundation and whether they can be mitigated or not. Someone more qualified than me should help address this issue.

I agree that keeping the tax is the simpler operational option, but I don’t think it is fair to just dismiss the Treasury Nodes option out of hand without digging deeper into the pros and cons. I expanded on what I see as the key benefits to using the Nodes in my response to shiny above, but let me dig deeper into the transparency issue here. In order to support keeping the tax on DNs, I would want to see a lot more transparency regarding how much of my DN earnings are being taxed each epoch, the total tax being diverted into a treasury, the current treasury balance, what it is being spent on, etc. Yes, some of this applies to the Nodes option too. Perhaps the tax is transparent and I just don’t know where to look for it, but my impression is that it feels hidden. Even when it becomes fully transparent, I personally feel that this does not overcome the psychological and motivational advantages of the Nodes option.

I look forward to reading more about the thoughtful points you raised.

6

cost per DN on AWS is about $10-12/mo. They have a teaser rate at about $5/month, but it’s temporary. Was wondering if a teaser rate was also possible with DO (i.e. the $6 being introductory/temporary)?

Another question if adding more nodes for a treasury, why not also have an option for existing DNOs to double their nodes at no extra bonding (essentially half the bonding between 2 cloned nodes or something like that)?

Another item previously mentioned was using the airdrop as some sort of a loan, or essentially having a longer time commitment, so it’s not just a one-off when the DNO just bails out as soon as they get an airdrop. There are many comments with the sentiment that they’re just hanging on long enough to get the airdrop (which is really peanuts now), and then essentially they’re out of the project. Doesn’t really do much good long-term.

We’re probably going to have to keep the bonding level at 100k REN. And, I don’t see how we’re going to avoid an inflation hit to the existing DNOs. We voted to increase the token supply with the understanding of making it right with the existing DNOs, but longer term, not really going to end up being a priority to stay in a project like this.

I don’t know if minting the additional 180M token all at once is a good idea. Lump sum vs an annuity stream…probably valid arguments on both side of this on which would be better for the project. The lack of communication with the inner working of the development team has really hamstrung the community confidence. I was initially against minting, but was needed emergently to avoid a total loss of 1.0; which is now 2 months after the fact and was unnecessary. And, it seems there has been no feeling of any urgency to get 2.0 further developed anyway, other than establishing the foundation setup; which is administrative, not development/operations. Mentioning this as it continues to show the pattern of behavior similar to the past few years. So, we just go back an need to increase supply again, and again?? Has any successful tech company ever asked permission to develop their tech? (sorry, end rant)…

Another thing of mention, the project is going nowhere if the ability to mint doesn’t come back online. But, that’s just stating the obvious.

7

I love the idea of taking a portion of the newly minted funds and setting up founder/treasury DNs for funding future operations.

The decision would be how much would go to creating DNs and how much goes directly to funding operations.

I’m also in favor of just increasing the max number if DNs rather than the amount required as airdropping may lead to added complications and maybe even vulnerabilities with all the hacking going on recently.