Replying to the summarized list of options from @AvsA:
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.
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).
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.
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.
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 !