I do not agree 100%, and I have already addresses this with comparison to NFTtrader & NFTs;
The majority of users: 1. won’t go out of their way to screw the system, and 2. will be shamed for hurting Web3 creators (and all data is onchain).
With regard to:
There are always some concerns, much can be mitigated,
but there will always be ways to game ANY system, somehow.
Nevertheless, aren’t we talking about Public Goods?
Web3 will not work if we can’t support independent users work;
(Just like NFTs would falter if the system for royalties fails, or does not evolves.)
At the core, we have two options:
Option #1: Create an open affiliate-system
that rewards creators, but can be abused.
Option #2: Do not create a system that rewards creators,
and then, no abused can occur with the system that doesn’t exist.
Why not base a referral system on a top x% of referrers, or referrers getting above x registrations per time period? It would need to be managed to some extent, but not nearly as much as a fully selective registry/list.
Essentially means that users wouldn’t be able to self-refer (unless they were registering a large amount of names).
Disincentivises anyone from forking the front-end to make names X% cheaper, since payments would be made in bulk to a single wallet so the gas fees of sending referrals back to each wallet would outweigh the original fee most of the time.
Still not a great solution but I feel like there really isn’t one here.
In my opinion, mobile is the where 99% of all users will get a name in the future. An affiliate program works perfectly for mobile. The convenience makes any small fee irrelevant, and it encourages this practice.
You could write a smart contract that acts as a ‘referrer’ and allows anyone to claim their referral fees back. It’d get good bulk rates if everyone used it!
If you register a 5+ char name for 10 years, you’d get $5 back at a 10% referral rate. I can’t imagine that the smart contract would be able to let anyone claim without gas fees taking a significant chunk, effectively making it useless for most people. If the referral is also being applied to the premium period or <5 char names though, that’s a different story.
Ok, this is what I am imagining right now. I think this will work.
Create a mapping of addresses to addresses for the beneficiaries for each account.
Crete a mapping of addresses to balances to store the balances for commissions.
Create a Register function with a beneficiary so that the beneficiaries mapping can be set at the time of registration.
Allow the user to change the beneficiary in their account settings, including to themselves — this is also a great opportunity to create a list of public goods that the user can chose. I would not show the beneficiary on the first checkout page, as I think this will disincentivize the use of the affiliate program for referrers.
Create a claim function to transfer commissions at any time.
I think this will add a minimal amount of gas to an initial transaction, with just two mapping updates. Any secondary transactions will have only one mapping update.
I think it is also possible to save a lot of gas in the future by phasing out the old registrar and only using a V2 NameWrapper, which with the new upgrade code coming in V1 NameWrapper makes this possible.
Wouldn’t intentionally obfuscating these incentive payments be suspect? Especially if the motive is to prevent the user from making the choice that we acknowledge they would likely make if fully informed?
Would we expect lots of large advertising focused entities to set up claim accounts and drive traffic through advertisements (Google AdSense, Media[.]net, PropellerAds, etc?) There would be no accountability on the messaging that ENS is subsidizing through these hidden incentives.
@AvsA’s transparent model mitigates some of this, but even that might not be received well when users see that they’re funding web2 advertising companies.
Final thought - any 3rd party is free to build a value add layer on top of the existing ENS registration system and charge whatever fee they wish.
The ENS DAO could instead continue to focus on encouraging these value add layers that incorporate ENS registration into other business models that would ultimately be more additive to the user experience. Rainbow is a fantastic example.
There is not am easy way to prevent this, unless the user clears their catch.
People who create content & code need ways to generate revenue for their work.
If content & code creators succeed in getting the user to click the link to ENS, and the user buys via the ENS contract, then the content & code creators should get compensated. Period.
Why are we building systems to hurt Web3 creators?
Why do we want to make it easy to hurt content & code creators?
Why should it matter if the content & code creator is getting paid, since they did the work to get the users to the ENS site?
The talk about hurting the content & code creators is counter intuitive, and if it is built that way, then most will not use this affiliate system; since the risk is too great a risk for loss, for the content & code creators time and resources.
I understand there are cases where we may want to “police” the system, but this is an issue across all decentralized products. Are we running a company or a protocol?
I love how dedicated & thorough the coders & engineers are here,
but it seems few here respect business & marketing for a healthy ecosystem.
Making it easy for Web3 creators “to be denied value-reward for their hard work” is a bad system.
The referral fee is not going to a random organization,
and is not designated by the DAO, or a centralized organization.
The referral fee would be going to the person/organization,
whom did the work to get a user to facilitate the ENS sale, on the ENS contract.
If the affiliate system blocks the Web3 creators value-reward for their hard work [content or code that brought visibility & traffic to ENS], then this system is no longer a real affiliate system [since a percentage of those users lead to sales, and a large percentage of those sales will always deny the affiliate when giving the option]; and then the point is lost, and the system will fail meeting meaningful adoption or its objectives [of brining visibility, traffic, & sales to ENS].
Again, this comes back to who we have a duty to serve first: end users, or platforms. I’m firmly of the belief that the ENS app ought to serve users’ best interests first, and it’s not in users’ interests to make choices for them without them being able to change those decisions.
May we talk about this again? Maybe we/you/they can place this on the ENS/.eth Protocol roadmap, with more meaningful consideration to help our ENS end-users and Web3 platforms.
Professionally, (with my 25+ years and enterprise-level experience), I know that a strong ENS Affiliate-Referral Marketing Program, (built-in to our ENS-Web3 system), will help directly and significantly help “ENS end-users, Web3 platforms, and the greater public-ecosystem”, at large.
I’m firmly of the belief that the ENS App WITH a built-in ENS Affiliate-Referral Marketing Program will serve sovereign Web3 users’ best interests first. It is in users’ interests to incentive a healthy “Web3 ecosystem and permissionless economy” of information and value.
ENS is a public good with great success–With its actual use and utility, ENS has the ways and means to lead the way for the Web3 “permissionless economy”, evolving a meaningful and impactful public good.
An important design constraint of the ENS affiliate program should be to never add costs to customers.
Costs should never be directly added: Ex: Asking customers to leave an additional “tip” is not an affiliate program.
Costs should never be indirectly added: Ex: Adding gas costs to affiliate registrations and renewals (that don’t exist on non-affiliate transactions) is a penalty to all in the ENS community who use any referring application, as well as an unfair price competition penalty to all in the ENS community who invest themselves in building alternative registration / renewal frontends.
This post has been edited for clarity and to make room for an improved affiliate program proposal I’m drafting .
The key is to separate the onchain tracking from the accounting that aggregates all the tracking results. Accounting can be achieved in a decentralized and gas-free way offchain using the onchain tracking. For example, decentralized accounting is already being achieved through Dune and can be further enhanced through a few code updates to the ENS Subgraph.
We have some good solutions already for onchain tracking:
Duration parameter. Enables tracking of both registration and renewals. Also enables easier accounting as all tracking data is emitted through onchain events. See this thread for details. Planning is moving fast and thanks to feedback from the community there’s already some improvements to this idea that haven’t been updated on the forum yet.
Secret parameter. Enables tracking on registrations only and requires more specialized techniques for accounting that have the ability to inspect internal transactions. See the existing ENSIP-14 draft for details.
The above are not complete end-to-end solutions for a full ENS Affiliate Program. They represent just one part of a larger solution that needs to be designed. An end-to-end solution proposal is being drafted through a community effort. Feedback and advice from all members of the ENS Community are very appreciated ! A number of these feedback sessions have already been coordinated 1-on-1 or in small groups. For the current state of planning, I think these smaller group feedback sessions help to produce more detailed critiques / analysis and open conversation.
The key is to find the best overall solutions and I’m confident if we combine insights across the community we can achieve a great result.
@accessor.eth if you’re interested in setting up a call to discuss in more detail, please let me know in a DM All feedback is appreciated !
This invite to contribute to the planning is also open to everyone else in the ENS Community. If you’re interested in helping the ENS Ecosystem grow, this is a great opportunity to participate. All are very welcome to DM me here on the DAO Forum, on Twitter, or on Telegram.
Hey, thanks for asking. We’ve been making progress on including a wider range of web3 projects or creators as ENS Ambassadors. There’s a lot happening in parallel here. We’re also working hard each day on launching some other projects for the ENS Ecosystem. Will share more as we hit those milestones
.
All feedback is appreciated !