Proposal to replace ENS14

[accessor.eth]

Could you please explain more in-depth about ‘set-up a resolver’, ‘domain-delegate’, ‘domain-campaign’?

I guess I’m seeking clarification on what the ‘set up’ process or idea of what the ‘set up’ process it.

@AvsA

I believe one of the things the DAO could really work for is make sure that there are more distribution of voting rights to members who contribute value to the community, be it via grants or other areas.

How value of contribution is measured here is being able to quantify various ways a person or entity contributes in a fair manner.

I can see this going a few ways as there are differing opinions amongst active contributors contributing to ENS that also take part in DAO efforts etc.

Some people believe that builders with effective tangible goods that impact the community should receive tokens for voting. Some believe that measuring forum contributions are a viable method to decide. Some think both. Can you create another topic that addresses this so that we don’t have mixed conversation in this thread?

[slobo.eth]

Adding this to this weeks ecosystem agenda!

[matoken.eth]

@AvsA

which represents only 0.17% of the tracked registrations

the new v3 app should have referrel code so if it’s not reflected, either there is a bug in the integration or the site isn’t tracking the latest controller.

[raffy]

Can registration affiliates indicate their identity via custom resolvers that are immutable proxies to the Public Resolver? or is that too messy (does that break NameWrapper?) Maybe those bits are hard to set during registration too?

[AvsA]

@matoken.eth

so if it’s not reflected, either there is a bug in the integration or the site isn’t tracking the latest controller.

Thanks let’s wait a bit and see if its reflected there.

[nick.eth]

Can I suggest an alternative? Simply use the account that called the register function as the referrer. For individual users this will be their account, while third-party registrars can deploy a trivial forwarding contract that allows them to identify themselves as the referrer and earn referral fees. This will have a much lower gas cost than setting records, and is a natural interpretation of the data to boot.

[Premm.eth]

@nick.eth

Simply use the account that called the register function as the referrer.

Wouldn’t this essentially amount to reducing the price of all registrations by a certain percentage?

In my opinion, if the DAO were to vote on lowering the cost of all domains by, say, 5%, third-party registrars could still offer the $5 fee and pocket 5% of it. Additionally, they could use marketing tactics such as offering $4.99 names.

[lightwalker.eth]

One of the great things about this proposal from Nick: Affiliate tracking is accomplished without adding any incremental gas costs vs. third-party registrars that already implement a forwarding contract.

There’s many ways affiliate tracking could technically be implemented. However, any affiliate tracking method that requires incremental gas costs is wasteful and should be avoided. As a quick and dirty example, it’s wasteful if the person registering a name must pay an extra $10 in gas so that an affiliate can receive a $1 revenue share from ENS.

Whatever strategy is taken for tracking affiliates, I suggest we ensure it doesn’t require the introduction of incremental gas costs vs. not tracking affiliates.

Can I suggest another alternative?

What if we combine the ideas in the original ENSIP-14 (I think from Avsa and Slobo?) with this new suggestion from Nick?

• For affiliates that don’t use a forwarding contract: Affiliate tracking could be achieved through the platform source parameter recorded during the Commit operation.
• For affiliates that do use a forwarding contract: Affiliate tracking could be achieved through Nick’s proposal.

For background: At NameHash we’re building a platform that brings some fun enhancements to discovering / registering / managing ENS names. This post isn’t the place to go into any details on that. I only mention this here because our founding team has already made personal investments nearing 7-figures USD to build a big set of innovations for the ENS community.

The affiliate mechanism is important for ENS if it wants to attract teams like NameHash that are making large personal investments into advancing the ecosystem. If ENS wants to attract and retain professional teams making these investments, ENS will need mechanisms such as a strong affiliate revenue sharing mechanism enabling these teams to keep the lights on financially.

[lightwalker.eth]

Premm.eth is asking a good question here. I also saw some similar questions on an old thread in these forums about ENSIP-14.

Can I suggest we add some constraints to our goals in ENSIP-14? Without enough constraints to guide us we can easily get lost trying to solve everything for everyone.

Suggest that we constrain the goal of ENSIP-14 to providing a sustainable incentive mechanism to the people making large scale contributions to the growth of ENS registrations / renewals.

The key qualifier here being large scale contributions. The people making these large scale contributions are those who are most in need of a sustainable method of funding their efforts.

A separate goal (and I would argue, a lower priority goal) would be providing incentive mechanisms to the people making small scale contributions to the growth of ENS registrations / renewals, such as telling their buddy at work over a beer that they should get setup with an ENS name. I’m not saying there’s no value here. There’s value. I’m just proposing that we exclude these small scale cases from the goals of ENSIP-14.

There’s a lot of pragmatic benefits if we apply this suggested constraint. Any large scale contributor will by definition contribute a large stream of registrations / renewals. And therefore we can achieve a clean solution to the question Premm.eth asked above: Only pay out affiliate rewards to an affiliate after they build an affiliate balance of X or higher, where X might be something approximating 10 or 50 or 100 registrations, for example.

This effectively eliminates the concern that individuals would set themselves as their own affiliate referrer to get a discounted registration that doesn’t actually benefit any true referrer.

The goal of providing incentive mechanisms for small scale referrers who are true referrers could be worked on as a separate ENSIP in the future.

Let’s not make the perfect the enemy of the good.

What does everyone think? Please attack these suggestions and let’s find a good solution

[lcfr.eth]

My biggest concern here is adding unnecessary complexity, features, code and costs to the ENS contracts. Also I feel there will never be a “good” solution that works for both end users AND existing services which do registrations.

• If you add code to the ETHRegistrarController to track Referals with an address referral parameter for example then 3rd parties could just set their address as the referral to take the fee they charge on top and the referral value percent on the core contract. (you could blacklist them and hope larger registrar apps act in good faith.)

• ENS registration cost is already absurdly high. As @nick.eth and @lightwalker.eth mentioned requiring users to set records adding gas costs of $10 to a tx to get $1 seems not so good vs not setting those records and just saving your $10 so you are +10 instead of -9…

As I’ve said before frontends / sites / businesses who are providing registration services already get revenue from their registrations. They are already incentivized to promote… I’m not sure how having ENS in control of any part of that process makes it better for anyone.

My suggestion: The businesses or community members building UI’s and separate frontends could also build their own referral systems where referral fees are deducted from their added platform fee which incentivize usage and healthy competition / options for the ENS community to experiment with other frontends / services. ENS could / should promote them when ever a new one comes up. This removes the argument that its effectively reducing the cost of names registered through ENS via the % set aside from the fees. Platforms such as ENSVision or Namehash should just bake this into our contracts. If a registration comes through with a referral then part of the platforms fee is converted to referral fee for our users and everything on ENS remains neutral.

Extra personal opinion:

If you guys want ideas to gain users / wider adoption I think you are looking at the wrong issues. This is a power user / already existing user feature more than anything that I don’t think will actually bring a wave of new users… ENS community shills day and night 24/7 about ENS to anyone that will listen.

These efforts could be spent on making the commitment hash optional with the use of using flashbots or other relays. Something like the commitment hash and requiring two transactions per name is doing more harm to wider adoption than not having referrals.

You are expecting new-to-crypto people to understand the mempool, or get it explained to them and for them to still think this is a good idea after… then there is the added gas cost of every name which adds $6.75 at the time of writing this to the cost of every name.

I’m too lazy to do the dune queries to see how much money is wasted on commitments but I’d guess a lot. The goal of ENS currently should be reducing registration costs as much as possible to make people more okay with registering (without actually lowering the registration costs) not creating more complications and adding cost to the process.

[lightwalker.eth]

Nice post. Agree with many points you shared.

One point that needs more discussion though is to refine and constrain the goals of ENSIP-14. The message above seems to suggest that the goals are to incentivize individuals acting on a small scale to spread the word about ENS. For example: one person telling a friend about ENS over a beer. Maybe this person sends their friend to ens.domains, maybe they send their friend to ens.vision, or to Namehash or somewhere else, for example.

As I understand it however, this small scale use case is NOT the goal of ENSIP-14. That’s a fair goal, but just out of scope for ENSIP-14 as I understand it. Open to feedback of course !

The way I understand it, the goal of ENSIP-14 is to provide a kind of “performance-based grant issuance” to the large scale platforms that are making larger investments in advancing the ENS ecosystem through revenues the ENS DAO collects through registrations and renewals.

Why would the ENS DAO want to do this revenue sharing? Of course, platforms like ENSVision and Namehash can generate revenues all on our own without any action from the ENS DAO through registrations and renewals using a “forwarding contract” that adds incremental costs to customers. For example, we can collect $5.99 from a user to perform a registration and only $5.00 of that is ultimately retained by ENS. There’s no issues with anything here at a technical level. But it means that we’re adding more and more costs to end-users and that’s unfortunate and impacts overall ENS market adoption. We’d prefer to minimize these added costs!

It seems safe to assume that ENSVision made meaningful investments into building their platform. It also seems safe to assume that ENSVision’s innovations helped to spark a boom in ENS registrations. This boom is great. It helps everyone in the ENS community, including the ENS DAO, etc…

Wouldn’t it be better that we could reduce the need to add incremental costs to customers and instead acquire the revenues needed to economically sustain these large scale projects through a sharing of the $5.00 collected by ENS? With ENSIP-14 it seems there’s a way this could be achieved that’s performance-based and largely automated.

This idea connects with your big point about gas costs being a significant barrier for adoption. We can all add lots and lots of fees on top of base registration costs to generate revenue, but these added fees impact ENS adoption ! Price elasticity of demand is a real phenomenon !

Many people are going to use platforms like ENSVision, Namehash, and others to find and acquire their first “.eth” name because we’ve made significant investments in building specialized user experiences / marketing / etc… When these people get to the checkout, what is going to happen? Are they going to be turned off by prices that are too high? Will they decide to buy, or not to buy? Will the ENS ecosystem grow or not grow?

The goals I’m proposing for ENSIP-14 are to reduce the prices these people will pay to acquire a “.eth” name through platforms like ENSVision or Namehash while still retaining the ability for our platforms to be economically sustainable in making large investments for advancing the ENS ecosystem.

What do you think?

[lightwalker.eth]

I hope to not sidetrack a focused discussion of ENSIP-14 in this thread. But wanted to add my agreement that adding an option to register in a single transaction without any need to commit is a great one !

We can keep the option to commit + register for the people who want that. The mass of the market would prefer to reduce all the overhead and complexity from that. The platforms that are processing these registration requests can just make use of flashbots or other relays as you suggested.

[AvsA]

So I’d like to try to summarize the options presented:

• Maintain ENSIP14 as is. It would be useful for apps that allows the user to interact directly with the blockchain, but it would not catch apps that uses contracts or some other custom contracts
• Use account origin as the referrer: it would be more useful for apps that have their own custom contract or bridge, but would not benefit more decentralized apps that allow users to interact directly with the registrar
• Use text records: would probably be more gas expensive than the amount of money generated by the referral, but has the advantage of making sure the name is properly ready to be used (after all, names that have no resolver or any text records are more likely to be bought just for the ownership itself)
• Improve the resolver to have referral campaigns baked in, with some additions like cheaper batch transactions and single transaction registrations. Would be great for the future and we should focus on it, but will take a while to get there
• Do nothing and allow apps that register names just to add their own fee on top of the ens name sale.

I would also like to point that in the original ENSIP14 I had two kinds of referral codes:

• The App code is meant for apps to use as their main code for all registrations, to make sure that everything that goes through them gets counted
• Campaign codes, that would be set by third parties and honored by apps, which would allow any user that successfully created a social media campaign or a community club, to be rewarded for names.

It feels that each of these proposals could be used for a specific thing:

• ENSIP14 as is, seems to be still useful for more decentralized apps. Since it’s a client side setting, it feels that it could be better suited to the “campaign” style proposal in which anyone can start an ENS campaign.
• App code is probably better suited for larger custom made apps like ENS Vision, Rainbow or Namehash that have the technical ability to create proxies or bridge contracts

One way to move forward would be use all options to have different referral programs for specific purposes, depending on what we want to encourage at that moment, the sort of gas environment etc

• A referral campaign using bits of the reveal secret could catch all sort of small campaigns periodically
• A origin address could be used to give out larger grants for apps that are not being covered by the referral program above
• In periods that gas is cheaper, we could run campaigns for people to set up resolvers in which in order to participate ens owners would have to set up an avatar, and some text records, including the referral or a delegate
• And in the meantime we should reopen the debate on improving the ENSRegistrar contract with the work that @alexnetto did to make referrals part of DAO itself

[alextnetto.eth]

@AvsA

And in the meantime we should reopen the debate on improving the ENSRegistrar contract with the work that @alexnetto did to make referrals part of DAO itself

A small grant was proposed and approved in the last round to updating the work we did at blockful.io to the new ETHRegistrarController. I’ll have this ready in the next few weeks!

I would love to hear some opinions on what features we should include in this version:

• Referrer parameter to have a revenue share set by the DAO.
  Some suggestions I already heard
  • Should this parameter be permissioned? Only some addresses can be referrers.
  • Should we have a minimum referral fee collected for the referrer to withdraw?
• Batch commit/register/renew
• Commit with payment

Feel free to reach out on Telegram: Contact @alextnetto

Links

• Grant: ENS Small Grants
• Pull request: ETHRegisterControllerV2 by Alextnetto · Pull Request #128 · ensdomains/ens-contracts · GitHub
• Medium article: ETHRegisterControllerV2. A brief resume of features Blockful did… | by Alexandro T Netto | Blockful | Medium

[nick.eth]

@Premm.eth

Wouldn’t this essentially amount to reducing the price of all registrations by a certain percentage?

With any solution, including this one, the DAO can either allow anyone to be a referral target, or maintain an allowlist of referrers. We could also specify a minimum threshold for referral payouts, which would eliminate most individual users while still keeping referrals permissionless.

[nick.eth]

@AvsA

• Use account origin as the referrer: it would be more useful for apps that have their own custom contract or bridge, but would not benefit more decentralized apps that allow users to interact directly with the registrar

Such apps could deploy a trivial do-nothing forwarding contract in order to identify themselves, which would cost only a small amount of additional gas to use.

@AvsA

ENS Vision and Namehash have tried implementing but hit a roadblock: it’s hard to get the data from nonce used when the registration was made by a contract, a common feature in some registrars that use batch registering to cheapen gas prices. This was caught precisely thanks to devs from namehash and ens vision when they tried implementing the standard.

Can you expand on this a bit? We don’t emit a “commitment consumed” log, but we could. And we can use transaction traces via BigQuery or Dune to collect referral stats even for registrations made via another contract.

[Premm.eth]

@nick.eth

maintain an allowlist of referrers.

In my opinion, it’s preferable to avoid allow lists in order to maintain the open, permissionless nature of the protocol. Additionally, collecting data incurs costs beyond mere administrative overhead; for example, entities that refer a large number of registrations could gain disproportionate influence over the protocol. By not collecting data, we can mitigate this risk to some extent.

@Premm.eth

In my opinion, if the DAO were to vote on lowering the cost of all domains by, say, 5%, third-party registrars could still offer the $5 fee and pocket 5% of it. Additionally, they could use marketing tactics such as offering $4.99 names.

Is there any objection to simply reducing the price of all names by a small percentage and leaving it at that? I don’t understand why we need to do anything else if the goal is to allow third parties to earn a percentage on registrations. With account abstraction, fewer and fewer transactions will be carried out directly by wallets, and more and more smart contracts will execute transactions. These smart accounts could be integrated with ENS so that registrations cost slightly more than the base price. To maintain the $5 price tag of ENS five-letter names, the DAO could charge a slightly lower price, enabling any third party to take a small percentage without permission and still advertise the names for $5.

[0xc0de4c0ffee]

I’d like to add few more options in the list for discussion…

A) <bytes12 random>+<bytes20 address> :

1. referral format : https://app.ens.domains?ensref=domain.eth
   referrer address : ETH address record of domain.eth
   referrer hash : bytes12(random)+address
   msg.sender : EOA

2. referral format : https://register.myapp.eth.limo?ensref=domain.eth
   referrer address : ETH address record of domain.eth
   referrer hash : bytes12(random)+address
   msg.sender : Contract

Offchain referral counter(indexer) service:
a) if reverse record for address(abi.decode(bytes(hash), (address))) resolves to *.eth
b) if registration tx was from contract address && check if reverse record of that contract resolves to “*.eth”

I ?think bytes12(random) will be enough for security? Possible attackers also have to brute-force/guess address of referrer/app and ?domain label with that bytes12 random to frontrun. Registration app/services could also rotate their referral contract addresses to prevent such scenarios.

B) Same as current <bytes4 APP>+<bytes4 REF>+<bytes24 random>

referral format : https://register.namesys.eth.limo?ensref=<domain.eth || bytes4(ref)>
referrer hash : bytes4(APP)+bytes4(REF)+bytes24(random) for APP+REF, || bytes4(APP)+bytes24(random) for App only mode || bytes4(0)+bytes4(REF)+bytes24(random) for official app.

• ENS D/app Store (allow list):
  ENS DAO have to deploy an official d/app registry (?offchain? Soulbound:NON Transferrable NFT with uint32(bytes4) max supply) to list all apps managed by DAO and partners, allow d/apps to register after simple app verification by DAO/community as basic sybil protection from apes. Apps could also manage their own referral list to prevent bytes4 collision attacks.

C) wait & buidl better

Explore possible AA based ENS registration and referral systems for future.

[lightwalker.eth]

Replying to the summarized list of options from @AvsA:

@AvsA

• Maintain ENSIP14 as is. It would be useful for apps that allows the user to interact directly with the blockchain, but it would not catch apps that uses contracts or some other custom contracts
• Use account origin as the referrer: it would be more useful for apps that have their own custom contract or bridge, but would not benefit more decentralized apps that allow users to interact directly with the registrar

Couldn’t we combine both? This seems like the best approach. It provides a solution for all app builders. I suppose it is possible to require each app builder to deploy a minimalist forwarding contract to participate in ENSIP-14 so that we could always just use account origin as the referrer. However, from our testing at NameHash, the use of a forwarding contract in the simple way we implemented it adds a cost of 10,760 GAS per transaction. A simple heuristic is that this can add approximately $1 USD per transaction in registration costs. If a user is registering a $5 ENS name, this represents essentially a 20% cost increase to use a forwarding contract. Perhaps there’s a more efficient way to implement such a forwarding contract? If not, that’s an unfortunate cost to pass on to others.

@AvsA

• Use text records: would probably be more gas expensive than the amount of money generated by the referral, but has the advantage of making sure the name is properly ready to be used (after all, names that have no resolver or any text records are more likely to be bought just for the ownership itself)

The use of text records for affiliate / referrer tracking feels like turning our ENS names into a logo-covered uniform that an F1 driver might wear. Added gas costs is a big negative too, especially as the options above avoid any incremental gas costs. (if a 3rd party app needs to implement a forwarding contract to provide special functionality, there’s added gas costs, but no incremental gas costs since the forwarding contract is needed anyway).

@AvsA

• Improve the resolver to have referral campaigns baked in, with some additions like cheaper batch transactions and single transaction registrations. Would be great for the future and we should focus on it, but will take a while to get there

Strongly in favor of this ! It would be great for ENS adoption to advance these. As I understand though, none of these would be related to ENSIP-14? Suggest we work to push these great advancements forward in a separate initiative.

@AvsA

• Do nothing and allow apps that register names just to add their own fee on top of the ens name sale.

There’s no technical issues at all with this. The downside here comes when we consider how teams making big investments into building ENS apps (and boosting ENS adoption) need ways to be economically sustainable. When teams add their own fees on top to achieve economic sustainability it increases the total cost for their users to acquire an ENS name. The higher the cost to acquire an ENS name, the reduced probability that someone takes action to acquire it.

Therefore, the way I understand the goals of ENSIP-14 is that we’re working to advance the joint goals of maximizing the adoption of ENS while also supporting economic sustainability & economic incentives for teams making big investments into growing ENS. In other words, I understand ENSIP-14 to be a revenue sharing proposal, rather than a cost increasing proposal.

If the only goal of ENSIP-14 is to enable 3rd parties to charge fees when an ENS name is registered through their platform then I agree there would be no purpose at all for ENSIP-14. This capability already exists and ENSIP-14 isn’t needed to enable it.

@AvsA

I would also like to point that in the original ENSIP14 I had two kinds of referral codes:

There’s good goals and marking best practices behind the idea of being able to separately track App code from Campaign code. However, I don’t see why we should include the tracking of a Campaign code into ENSIP-14 or why we should be trying to achieve this goal in a decentralized way? If a 3rd party wants to track the performance of a campaign there’s a lot of other specialized marketing tools for that. None add gas costs to use. None require pollution of text records.

What do you think? Feedback appreciated !

[lightwalker.eth]

@nick.eth

@Premm.eth

Wouldn’t this essentially amount to reducing the price of all registrations by a certain percentage?

With any solution, including this one, the DAO can either allow anyone to be a referral target, or maintain an allowlist of referrers. We could also specify a minimum threshold for referral payouts, which would eliminate most individual users while still keeping referrals permissionless.

Seems attractive to specify a minimum threshold for referral payouts? Defining these policies in a permissionless way is attractive. If we took the alternative approach of requiring a permission then what could the qualification possibly be for such a permission? It sounds like source of some pain and community friction if these qualifications were decided by any subjective criteria.

As I understand, the options currently being debated for tracking referrals would all require some analytics computed off-chain from on-chain data. Assuming so, I understand that any rule about minimum threshold for referral payouts or other constraints on payouts would also exist off-chain and be a matter of policy rather than enforced by a smart contract.

Is that right?