Currently, registering a name costs 10 RAD. Though in itself, the amount is high in $ terms, another issue is that we require all users to buy RAD before registering a name. This means they have to go on Uniswap and exchange some ETH or USDC for RAD, before being able to register a name.
Since name registration is integral to creating a globally unique identity on Radicle as well as creating an Org, and is part of the onboarding process, any friction there will slow down growth of the network.
I propose that we set the registration fee to 0, which will no longer require users to hold RAD, and focus on the other areas (eg. Radicle Funding) to drive demand for the token.
Reasoning & Analysis
This fee was originally set as a way to create utility and drive demand for RAD alongside usage. The business models of p2p networks have evolved and it is no longer necessary to charge for the creation of a radicle name.
Gas prices are also high right now it adds far too much cost, which results in major drop-off when onboarding.
The radicle network benefits from network effects and thus shouldn’t create blockers for users joining
Heads up here, you have “November 6th”, but I presume you mean “December 6th”
Slight nitpick: it’s not integral to creating an identity on Radicle, because one can do that via Link without any interaction with the chain Perhaps change the wording, or scope this discussion to on-chain applications?
So we’re assuming they have ETH to pay the gas, right?
And final question, is this a permanent change or should there be a grace period specified?
That’s fair Maybe it’s my lack of interactions with txns that made me think, “Oh right ya, fees.” It’s just a suggestion to call it out, so up to you!
I guess my issue is that it’s a vague statement, at least for me. I don’t know what the previous business model was, I don’t know how they evolved, and I don’t know why it’s suddenly not necessary to charge. I’m not saying I’m against removing the fee, just to be clear. However, I can’t exactly evaluate why it’s a Good Thing from this statement
Points 2 and 3 do make sense to me though But I will say it would be useful to add evidence to gas prices being high and the drop-off during onboarding. I’m sure the former is easy to show but do we have recording of the latter?
Hope these observations are helping Again, I’m not attempting to block on this, just trying to understand the proposal better
Yeah. Tbh. I don’t really want to get into the business model discussion here as it’s a meaty one. Perhaps I should have just said it’s a blocker to onboarding/adoption and not currently adding enough value to remain.
Sample size of issues are currently too small to share more data than anecdotal experiences whilst I try onboard partners. Adds a bunch of steps and costs to what’s already a long, challenging, and expensive process.
That’s all fair enough, however, I don’t understand how a community is supposed to vote on such proposals without seeing evidence backing up what’s said in the proposal. How can I, as a member of the Radicle community, evaluate this proposal and its benefits? Surely this is where the meat (I’m more of a veg man myself ) of the discussions should happen before they get voted on?
Want me to edit it to pull back my statement on it not being required for business model reasons? Will keep it simple and limit scope of statements in future.
wonder if it’s reasonable to expect every community member to understand and evaluate every proposal? Perhaps can start by trying to keep it simple and if proposal isn’t getting sufficient support THEN adding more details to get more people to support? Keen to not add a bunch of extra politicking.
What I want to see is a fleshed-out reasoning of why this proposal makes sense. @bordumb’s answer does that perfectly:
When I surface outside of the realm of the Link protocol and decide to look at a governance proposal I’d like to easily understand what are the motivations, what’s the overview, and what’s the reasoning for the proposed solution. I think you have the motivations and the overview but there’s a little bit lacking for the reasoning. You have the three listed reasons, but how do I can evaluate them without much evidence? I can look up the gas prices I could experience the blockers (but I know you have good evidence yourself on that account from doing onboarding, let me hear it!). But I have no idea how to get started for point 1.
I think I’ve touched on some of this above. Granted, you’re not going to get every community member involved. But I think if we’re to move forward on making proposals we should be holding each other accountable for having good quality arguments that make it clear what’s being proposed and why the proposal is the right way to go.
Anecdotally, I’ve been destroyed on an RFC before, and rightfully so. I didn’t think enough parts through and didn’t support what I wrote with enough thinking. The second time around, it came out a lot better and was accepted.
Hope that helps with understanding where I’m coming from playing devil’s advocate
To avoid a quagmire, I recommend focusing on the logic/code of this proposal:
This code snippet alone would have been enough to get a “Yes” vote from me. I would have come to the same conclusions I listed above about poor vs good sign-up flows.
So I would err on the side of treating the Reasoning/Analysis section as a similar exercise in simplicity (especially when the code involved is so clearly defined). @fintohaps point about evidence around business models is valid. It does open a “can of worms” that requires lots more evidence than is probably easy (or possible?) to provide. It’s the kind of thing that would need an entire market analysis to sit well with some people. So probably worth removing it.
IMO, this proposal is strong enough just with the argument around improving the sign-up/registration flow (avoid gas fees, opportunity cost, too many steps/poor experience).
With all of that said, I’d still implore people to focus on the code snippet. I think this proposal comes down to that and anyway we slice/discuss the reasoning behind it won’t change the code.
Great point! The majority of the focus should be on the code. We still back up these changes with solid reasoning, like when someone puts in a good commit message explaining a code change they’re essentially arguing for the change they make
That’ll be my last point, though! I approve the change and will be voting yes on the proposal. Thanks @nas and @bordumb!