This is an excerpt from a post I made in september.
I want to introduce or explore the idea of implementing a team or process that would authenticate, approve and audit the contracts that will be supplementary to official ENS deployed contracts.
This will act as mechanism to achieve the following:
Evaluating the proper use of contract functions
Ensuring that public view of contracts are verified on chain and accessible and readily available for
- viewing and evaluating
- establishing an entrusted seal of approval by audit
- continuance in practicing the principles of true decentralization by open-source transparency
Prevent any contracts that incorporate ENS namespace functionality from malicious intent. (i.e, exploitation, credential hijacking etc.)
Achieving the adoption and consistent utilization of the ENS namespace through current and future technologies, globally.
The most important aspect of decentralization is ensuring the open-source transparency and trust is extended to the subsequent entity that is building on top of the protocol. If we can not ensure the above items are reflecting those transparent decentralized principles, the the standards that shape decentralization will ultimately diminish over time. I think there is a common notion that decentralization will ultimately be 100% autonomous. I honestly don’t think that will be the case with regards to sub-domains.
When the sub-domain wrapper contract is officially put to use on the blockchain, developers will be pushing their own contracts along with it. Realistically, they can do what ever they want with their customized smart contracts. Since we havn’t seen how those contracts will be used with official ENS contracts, we don’t know what to expect. This is truly a critical moment for ENS’s proof to stand true to it’s word and uphold the reputation it has earned.
I believe it is imperative that we implement agency of endorsement. What would happen if some supplemental contacts are exploited from the use of another contract and compromises lets say 10,000 ENS names and their subsequent wallets? Who is to blame? How would we approach that subject ?. Again putting an audit team over larger organizations who plan to or already have achieved hundreds or thousands of sub-domain registrations with a seal of approval might be something to think about. Like I said above, we need to extend the standards ENS is providing in the wrapper contract with their supplemental contracts.
This isn’t about control, being big brother or oversight for the sake of. This is about attempting to prevent any sort of failure points. I’m not saying any contracts or on chain events contain that possibility. There is a lot at risk by many people and we should be doing everything we can continue being one step ahead. I’m confused how you aren’t in favor of this sort of thing. You have have already suggested this mechanism be put in place
[/quote]
Onboarding new users to ENS and retaining them is likely to start here rather than registering a TLD. The most important thing to thing about with all the extra functionality like fuses, emancipation etc, is that it may scare some users away if they don’t feel they can trust the third-party. It’s imperative to acquire that trust immediately or ENS may never see that user interested in ENS again.A visible display of ENS official approval may be an effective way to retain that users trust in third party registrars, just like @hodl.esf.eth was mentioning in a sense.
I think the challenge behind that is: how do you display an approval that corresponds with specific contract addresses without the ability for a malicious party to display a fake / counterfeit approval.