A few updated thoughts.
My goal in the last few weeks has been to make sure the community exhausts all of its options and makes the most informed decision possible. Since inflation is within our control, it has always been the easiest option to execute and fall back on, so it made sense to do proper diligence on all of our options. Now that we have, it’s clear that a modified version of RFC 046 is the best way forward.
Labs’ risk tolerance is simply too low at the moment to entertain or help with a fundraise for a new token. There’s no Foundation yet, and the DAO in its current form couldn’t legally or practically lead a fundraise, let alone in a few weeks. While layered security would unlock the most secure versions of RenEVM and RenBridge and would not have delayed 2.0 at a technical level, fundraising on the premise of it would have. But the enthusiasm for it as a feature — independent of RFC 047 — makes me hopeful that it’ll be supported as a security option for RenEVM apps in the future.
If RFC 046 turns into a fundraise around Labs’ token grant (which is a new development and not part of this RFC) in conjunction with operators receiving their proportion of inflation and increasing the bond size for future nodes, that would be a winning proposal. The DAO should stipulate that any tokens sold to investors be subject to long-term, on-chain vesting with a one year cliff. Those tokens would need to be sold at a discount, so on-chain vesting with a cliff would verifiably prevent arbitrage and short-term selling and align us with longer-term investors. It may be better for Labs to do that upfront all at once than for the Foundation to provide quarterly grants, because those would each need to be sold off to fund operations, while on-chain vesting with a cliff could raise cash without creating short/medium-term sell pressure. It is worth confirming if the Ren Foundation were able to custody the funds raised and still provide quarterly grants to Labs in USD.
Operators would need to vote to receive their proportion of inflation to offset REN dilution and to increase the bond size for new nodes to offset revenue dilution. Without both, operators would be diluted of REN and/or their revenue.
Since we’re starting with ~2k nodes, the new bond size would need to be increased by slightly more than the inflation rate for operators to not be diluted. For example, based on a 12.5% token print, then if the bond size were increased to 112.5k REN with a 1.125b supply and exactly 2k existing nodes, there would be a maximum of 10,222 nodes, which would be slightly dilutive.
((1.125b - 200m) REN / 112.5k bond) + 2k existing nodes = 10,222 nodes
To enforce a maximum of 10k nodes, the bond size would need to be 115,625 REN:
((1.125b - 200m) REN / 8k new nodes) = 115,625 REN
Thanks to everyone for participating these last few weeks. Now let’s get 2.0 out.