Next Steps for the ENS domain dxdao.eth

Hey guys!

the currently active proposals(Add ENS generic scheme, Add ENS Public Resolver generic scheme) which will enable the dxdao to manage its ENS domain portfolio will be functional on the 28th January 2020 at 7:42 pm.

To prepare the launch of the BC-DAPP
we need to make sure that the dxdao.eth domain is ready to be used once the development of the smart contracts and frontend is done. Those are the next steps:

  1. Set the main ENS Public Resolver contract as the Resolver for the dxdao.eth domain so we can attach an IPFS hash to it.

(Optional we could go through all domains the dxdao owns and make all domains ready to be used by setting the main public resolver contract as the resolver for all domains the dxdao owns)

The dxdao currently owns:
dxdao.eth --> proposal out: sets the resolver contract to newest Resolver 0x226159d592E2b063810a10Ebf6dcbADA94Ed68b8
dutchx.eth --> proposal out: sets the resolver contract to the newest Resolver 0x226159d592E2b063810a10Ebf6dcbADA94Ed68b8
dxoasis.eth --> public resolver configured (0x226159d592E2b063810a10Ebf6dcbADA94Ed68b8)
dxfeeds.eth --> public resolver configured (0xD3ddcCDD3b25A8a7423B5bEe360a42146eb4Baf3)
dxwallet.eth --> public resolver configured (0xD3ddcCDD3b25A8a7423B5bEe360a42146eb4Baf3)
dxoracle.eth --> public resolver configured (0xD3ddcCDD3b25A8a7423B5bEe360a42146eb4Baf3)
dxinsurance.eth --> public resolver configured (0xD3ddcCDD3b25A8a7423B5bEe360a42146eb4Baf3)

  1. Once LevelK and dOrg are done with the smart contract/frontend development for the BC-DAPP I am proposing that we do a test run/version of the BC-DAPP so everyone can play around with it on Kovan/Rinkeby). If everything is fine the deployment of the smart contracts on the ethereum main network and the hosting of its frontend on IPFS should be ready to go. Once that is done, we only need to point the configured public resolver contract of the dxdao.eth domain to resolver the IPFS hash we defined. This will require the final proposal which needs to go through the whole dxdao membership!
4 Likes

ENS Documentation (for those curious souls)

2 Likes

So it seems like we need to do our own migration of at least one generic scheme (ENS main contract and maybe the Public Resolver contract) due to the recently discovered vulnerability of the main ENS contract (Announcement: Here).

The next steps should be for the ENS generic scheme:

  1. Remove the ENS generic scheme :white_check_mark:

  2. Redeploy a new ENS generic scheme which points to the new ENS contract :white_check_mark:

  3. Propose the new generic scheme to the Dxdao :white_check_mark:

  4. We need to deploy a new generic scheme which points to the .ETH ENS Registry as we need to use the reclaim() function to get our ownership back of all our ENS domains. :white_check_mark:

  5. Propose the new generic scheme to the Dxdao. :white_check_mark:

  6. Update Alchemy with the new .eth ENS contract generic scheme interface

  7. For each domain, we need to use the reclaim() function.

For more information check out
https://docs.ens.domains/contract-api-reference/.eth-permanent-registrar/registrar#reclaim-ens-record

1 Like