This is the official draft and Snapshot poll for adjusting the name registration fee. With this post, the proposal has entered the third phase of the governance process.
We’d like the radicle name registration fee to be removed. The goal of this initiative is to support the adoption of Radicle Orgs by reducing cost and effort when onboarding.
Purpose & Background
In order to register a name on radicle it cost 10 RAD:
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
This proposal will make it easier and less expensive for new users to onboard which we believe will help support long-term adoption of Radicle features.
UPDATE: This change to the registration to remove a RAD fee will be in place indefinitely, unless superseded by a future proposal reinstating the price.
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?
Integral to creating a globally discoverable identity?
Yup. Assuming they need ETH to pay gas for Org creation
Unsure what you mean by grace period in this context? If we want to change it again it should be as easy as going through this proposal/governance process again.
With a working replication system, an identity can be globally discoverable too However, globally unique might be what you’re looking for.
Makes sense, maybe call out that ETH would still be involved for gas prices. It might seem misleading that the price to register the identity is 0, whereas there’s the caveat of gas prices.
Ya, so that’s what I was wondering. I saw two options (perhaps there are more):
This proposal states that registration will be “free” for 6months, 1year, etc.
This proposal states that registration will be “free”, unless superseded by a future proposal reinstating the price.
I think it would be useful to call this out, at least from my perspective. Or perhaps this is something that should be considered permanent and a very good reason should prompt any other follow up?
I probably have a knowledge gap here because I dunno what the following means:
Why isn’t it necessary anymore? Will it become necessary again?
I guess my view was that the fact that gas fee still needs to be paid in ETH does not impact the decision to remove the RAD fee. Happy to add if you feel strongly about it.
Sure. Can update with note on it being a permanent change that will require another vote to change.
Business model discussion is a can of worms that I would rather not have here. Is there a way to change that statement that makes it satisfactory?
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?
If I don’t have RAD, that means exchanging something in order to get RAD.
This incurs 3 bits of overhead:
The time it takes to exchange something for RAD
The opportunity cost of making that exchange (what if RAD goes down and ETH goes up?)
The gas costs to make that exchange
Just writing out that process and thinking “That’s what it takes just to register?” is enough for me to vote in favor of this proposal.
It’s a bit like looking at a sign-up flow for an app and realizing it takes 5 steps, when it could be built in a way that takes just 1 step. The poor experience/process is all the evidence I need.
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:
setRadRegistrationFee(0)
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!
do agree with you @fintohaps - good to have solid reasoning and I’m sure I’ll think twice before making unnecessary and broad statements. Like the RFC and commit message comparison. wagmi
We’ve revived this proposal in the new year to keep it moving through governance and submitted it for Formal Review again. Please review the proposal and vote in the Snapshot poll by 11:00 CET - Tuesday, February 22nd.
We’re putting the proposal up to vote again because despite resounding support of the first formal review, we still weren’t able to meet participation requirements. While our participation requirements for formal reviews and on-chain governance proposals are currently being re-evaluated by the community due to their unsuitability (see [Temperature Check] Re-evaluate participation requirements and Proposed Next Steps for RGP Proposal), we believed it would be best practice to resubmit the proposal for community evaluation.
@fintohaps@nas@bordumb - I incorporated all of your thoughts and feedback into the updated proposal, so please do check it out!
Fyi, your “Formal Review again” link is missing a 0, the link should be [Formal Review 🌿][v2] - Remove name registration fee. Also, the Snapshot poll looks closed. Is it the old one? Should the link be to a new one?
21:00 GMT - Monday, December 6th
Perhaps change the wording, or scope this discussion to on-chain applications?
However, globally unique might be what you’re looking for.
from this statement 
Again, I’m not attempting to block on this, just trying to understand the proposal better 
) of the discussions should happen before they get voted on?
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.
lolol jk
