Can you please provide metrics in the form of a DUNE analytics chart that shows the on chain activity from your project?
We havenât launched our first campaign officially yet. So, currently, we donât have any traction to report. Give me a few days to launch the first campaign.
However, our campaign will never get as many users in a few days as ONS but it will benefit the Optimism ecosystems regardless of our projectâs success.
Hi, this is Makoto from ENS team.
If I understand correctly, itâs a ENS fork. Are you going to divert from ENS smtart contract codebse and your own featureset, or keep syncing to upstream (=ENS)?
We will keep syncing upstream except for the ETHRegistrarController and XXXPriceOracle contracts. However, we donât often sync it as it requires users to migrate their NameWrapper manually, which is a pain. We plan to do it quarterly if needed.
ETHRegistrarController is necessary to divert from the ENS codebase as we are adding feature such as interoperability that requires a considerable modification to ETHRegistrarController to grant access to the Transport layer to mint the domain.
Universal Registry Resolver integrated to forked Ethers.js, and Metamask (Prototype) will be developed in a separate repository connected with interfaces so that this feature wonât affect the ENS codebase.
I heard you will deploy the new NameWrapper to the ETH mainnet soon. So, we think that your NameWrapper should have enough stability when it comes to our time launching on the mainnet.
Thank you for your quick response. I have another quesiton.
In your business map, you positioned yourself as âbuild & contributeâ category despite being mainly a fork to start from. What new aspect (other than maintaining the fork and keeping your own registrar for revenue) are you intending to build and what are you planning to contribute back to ENS?
Currently, we have three in the plan.
-
Interoperability cross-chain domain. Once this has some maturity with enough use cases, this process takes years. ENS can utilize our solution to enable cross-chain capability to your .eth domains without risky experiments on the mainnet with your 2M+ user bases.
-
Universal Registry Resolver. I see that currently, ethersjs is hardcoding for mainnet mapping to the official ENSRegistry only. However, now there are many domain names on each chain, such as .bnb by Space ID. As a result, one party must develop this solution.
- ENS Lightweight indexer - A solution to index ENS in multiple chains using a serverless solution and public fullnode provided officially by each chain. Currently, our testnet 1 is using it, and it costs us 0$ per month if there are a few users. Compared to the subgraph solution, this one is more cost-efficient and easier to scale cross-chain. However, we may still contribute to the subgraph solution.
Can you give us more detail about how your solution differ (or supplementary ) with ENSâs own L2 plan?
Are you developing on your own? Is there a github repo?
The main difference is that I believe each chainâs resolver should hold different data specialized to that chain independently. Letâs give an example
axlUSDC address is different on each chain. With an independent resolver on each chain, one just simply points the domain to the correct axlUSDC address on each chain.
Another use case, Starb*** chain may keep their membership information in their chain. Independent resolvers let Starb*** chain operator design their specialized resolver on their chain without worrying about any compatibility problems.
To query data on L2 or L3 (such as Base or Starb*** chain deployed with Op Stack if any) one doesnât need to query a smart contract in L1 to get StorageHandledByL2 revert message to query smart contract in L2 / L3. Because the resolver in L3 is independent of L2, one can query data from the resolver in L3 directly.
If there is an important thing that must be done on the main Optimism chain, one can ask for the data from L3 chain and wait for the transport layer (Optimism bridge) to pass the data back and call necessary function without needing to use offchain gateway. Hope we donât need to wait 7 days anymore in the future.
I donât feel sure that I understand your L2 design correctly, as I mostly see that you are focusing on offchain things.
I have just made it public. But it is in development currently. It combines a whitelist system and indexer in a monolithic way. To have it used by others, I must separate the indexer from the whitelist system first.
If you have more questions I will answer tomorrow as I have to go sleeping now.
Thank you for all the answers @chom. I see you are a solo dev working on this, but in many places you talk about âWEâ
Do you mind telling more about your team if you have one?
I am developing this solo. But for marketing, I ask for advice from my friends and contact NFT communities in Thai. However, I havenât hired them; now they are all busy. So, may need to shift to organic reach by talking about the project in the community first.
Sorry for confusing you with âWEâ.
I am developing DiamondResolver as I have tried new alpha ENS, upgraded the resolver, and lost all existing records. I donât think this is good as either canât store data permanently or canât upgrade the resolver but donât sure what ENS thinks. Moreover, if ENS keeps adding functions, one day contract size will exceed the limit. Diamond (ERC-2535: Diamonds, Multi-Facet Proxy) is designed to solve these problems.
GitHub - Opti-domains/ens-diamond-resolver (Not completed yet)
Just a general observation as an ENS protocol delegate.
ENS has been working on Layer 2 plan for the past 2 years.
For Optimism related works, we have proof of concept level code and also dm3 team is working on Optimism resolver
As far as I understand, most of the work you have completed (apart from building your own indexer) is based on forking ENS contracts. It would be really nice if you can spend time and effort contributing to the ENS ecosystem, rather than doing your own (especially since there are already 3 different versions of name services on OP already).
Hi, I have done market research for several days and have understood that people usually just want to do a few clicks, except we have multi-million dollars invested from VCs (Because of airdrop).
The new flagship feature in testnet 2, according to market research, will accelerate the use case of ENS in the NFT field. After the success of Optimism, I can adapt it to NFT communities in Ethereum and greatly benefit the ENS ecosystem itself.
I have successfully deployed the first version of DiamondResolver at 0x6eE51AB6f1dA30D8B833aD234E406Fffc49D6813. It is a crucial component as one can develop just the part that we want to change (For example, OptimismResolverStubFacet â DiamondResolver). Not the entire resolver and is still compatible with PublicResolver standard.
However, there are many forkers with millions of dollars ready to steal the innovation, buy the hype and kill the developer. I choose to close the source of the upcoming DiamondResolver (The first version will remain open source) and other innovations until enough support and adoption.
I am happy to share the code with some of you @matoken.eth @Gonna.eth if you want.
I canât reply to you in the ENS gov forum because I donât have the write access. I have asked for it for almost 5 days and will open a support ticket tomorrow.
80% hasnât been breakdown formally this year. It is intended to support individual developers and projects that contribute to Opti.domains (which is also ENS compatible, so almost every eligible projects benefit ENS DAO) and Optimism ecosystems.
It should indefinitely share revenue to all our early partners, especially ENS DAO, if we can cooperate. You may not trust me, but I think other super hype forks never share any revenue with you, and my project has the highest chance to implement it.
If you want me to contribute to the ENS ecosystem and lead the adoption on Optimism, I want to make sure that I will never be sued for developing .eth in the Optimism chain. There is a lot of drama in Optimism now.
Here is my current design for L2 .eth. Itâs a merge of you and my idea about the cross-chain domain. Having minted .eth NFT in Optimism play a crucial role in driving adoption. And it must also be ERC-721 compatible, for unlimited compatibility with NFT marketplaces.
It designs to avoid the L1 gas fee and collect some small additional bridge fees to operate our infrastructure and share revenue with ENS DAO.
We are pleased to provide you with an update on our recent progress and developments. This report encompasses completed milestones, newly formed partnerships, and numerous technological breakthroughs.
Milestones
As of now, we are delighted to inform you that we have achieved around fifty percent of our outlined milestones. Please see the attached image for a more detailed visualization of our milestone completion.
Partnership with Bored Town
In our pursuit of innovation and expansion, we are thrilled to announce our collaboration with Bored Town to establish the .town domain name. Bored Town, the largest Non-Fungible Token (NFT) community on Optimism, boasts high-quality artists globally. With more than 20,000 unique holders in its NFT ecosystem, we are optimistic about this allianceâs potential to drive significant advancements.
Bored Town has expressed several challenges in its current whitelisting system, including:
- Fake impersonated wallet addresses
- Duplicated entries
- Sybil attacks
- Often missing entries
- Uncertainty about address submission
- Lack of transparency
- Incompatibility with alternative wallets
- Inability to account for the amount of NFT holdings
Opti.domains aims to address these concerns effectively. We are planning to launch the .town domain before the .op domain name to ensure we garner enough adoption and traction.
Our testnet has been launched for weeks and is available at https://town-testnet.opti.domains/
Mainnet Launch
We are excited to announce the successful deployment of our smart contracts on the Optimism mainnet following the bedrock merge. Our smart contracts, composed mainly of Ethereum Name Service (ENS) and Diamond Resolver, are now live on both the Optimism Goerli testnet and Optimism Mainnet.
Our primary focus now shifts to the upcoming launch of the mainnet, planned for next week. We will start with the .town domain, collaborating with Bored Town to ensure user adoption. Following this, we will launch our flagship .op domains, introducing additional features subsequently.
Permissionless and Deterministic Deployment
In terms of technological development, we have introduced a novel deployment technique that enables permissionless deployment of the entire Opti.domains smart contracts across multiple chains, while retaining the same address.
Before that, we could only permissionless deploy a smart contract that is not ownable and has the same address across chains with the Seaport Deployment technique.
We have extended the Seaport Deployment technique to deploy entire ENS ecosystems, which involve ownable contracts. We will publish more detail about this once we get enough adoption.
This represents a significant step towards enabling the deployment of many protocols, fostering greater interoperability between OP stack chains.
Deployed Contract Addresses
Our contracts are deployed into same addresses for both Optimism Mainnet and Optimism Goerli Testnet (and OP Stack chains in the future)
Opti.domains contracts are branded with 0x888811⌠while .town related contracts are branded with 0xB02EDâŚ
Core Contracts
Contract | Address |
---|---|
Root | 0x88881190D24e8ecA11F0262972cff8081b2AFc45 |
ENSRegistry | 0x888811b3DFC94566Fc8F6aC5e86069981a50B490 |
ReverseRegistrar | 0x888811225d6751A0cf8a9F7fa6a77f4F1EF69DC9 |
Universal Registry and Resolver
Contract | Address |
---|---|
UniversalENSRegistry | 0x8888110038E46D4c4ba75aFF88EaAC6f9aA537c1 |
UniversalResolverTemplate | 0x888811D93EE697768FB2Eb23B4225038Beeb7FDc |
Diamond Resolver
Contract | Address |
---|---|
NameWrapperRegistry | 0x888811E08f362edB8B1BF4A52c08fED2A58a427E |
OptiDomainsAttestation | 0x888811653D30Ed5bd74f5afd4B2bffe2dE3192B3 |
DiamondResolver | 0x888811Da0c852089cc8DFE6f3bAd190a46acaAE6 |
RegistryWhitelistAuthFacet | 0x888811761f31b8242fAe670C3f0a054e226D10e8 |
PublicResolverFacet | 0x888811B3c11F37a978eED349b174F7e9cCec14D7 |
.op Domains
Contract | Address |
---|---|
BaseRegistrarImplementation | 0x8888111BAd1a449a6a0618C0fE7DC1727e3aaf99 |
MetadataService | 0x88881191aba4DEFD926dE9708C457d092120beaa |
NameWrapper | 0x888811F1B21176E15FB60DF500eA85B490Dd2836 |
RegistrarController | 0x8888117A2d8cC4e02A9A9691Ba0e166b2842360D |
.town Domains
Contract | Address |
---|---|
BaseRegistrarImplementation | 0xB02ED512702C46dbDB260053C97f79c3F467E39E |
MetadataService | 0xB02EDED8502B029aA7f2CB02e1C2a0c452531279 |
NameWrapper | 0xB02ED980693e14E082F0A3A33060046Ae8495EB2 |
RegistrarController | 0xB02EDc247246ACD78294c62F403B3e64D5917031 |
Diamond Resolver
Our Diamond Resolver technology has been developed to address the issue of data loss when upgrading resolvers. By leveraging ERC-2535: Diamonds, Multi-Facet Proxy, we have ensured compatibility with PublicResolver, thus facilitating stable user data and enabling upgrades to introduce new features without needing user action.
Typically, upgrading the resolver in ENS (Ethereum Name Service) results in data loss, requiring significant gas fees to store the data again. However, the upgrade process is relatively painless because 99.99% of ENS users primarily store only their Ethereum wallet address in the resolver.
In collaboration with our partner, Bored Town, we have devised a user journey that involves users connecting and storing their wallet addresses, wallet connections, and social profiles in the resolver. Migrating all of this data can be both laborious and costly for users. So, we solve this problem with the development of Diamond Resolver.
Finally, we have improved the Diamond standard to enable Extendable Diamond. Users can build and add features to their resolver while upgrading from the main Diamond Resolver by cloning a new Diamond Resolver and performing facet cuts on the new cloned diamond.
EAS Integration
We are proud to announce that we are the first protocol to integrate with Ethereum Attestation Service (EAS), achieved through our Diamond Resolver system. This integration will result in a new attestation from our attestor smart contract every time there is a data change in the resolver.
This picture shows the domination of Opti.domains in utilizing EAS with a wide range of testers 14 days ago.
Social and Wallet Oracle
As part of our efforts to address Bored Townâs pain points, we have developed an oracle responsible for signing attestations to the EAS, verifying the validity of the association between social profiles, wallets, and domain names.
The oracle is responsible for signing an attestation to the EAS that the association between social profile, wallet, and domain name is valid. Thereafter, this attestation will be referenced from the user attestation.
Any external services can verify the validity of the connection by checking if the oracle is trusted and if there is a matching attestation between the user and the oracle.
This picture shows off-chain attestation generated by our social oracle to verify that Chomtana is the Twitter account for Chomtana.
This picture shows on-chain attestation generated by the diamond resolver contract to associate Twitter account with the domain chomtana.town
Universal Registry and Resolver
Universal Resolver is developed by ENS to generalize the resolver logic into a single smart contract. Added support to ENSIP-10: Wildcard Resolution standard.
However, the capability of name resolution is still limited to ENS on the mainnet only. With Universal ENS Registry deployed to the same address across chains, we can set a universal standard for ENS name resolution across all EVM chains, especially OP Stack.
ENS has set a standard called ENSIP-9: Multichain Address Resolution, which relies on SLIP-0044 standard. It doesnât work for OP stack chains, as these chains usually have one of the following properties that donât fit into SLIP-0044 standard:
- OP Stack chains tend to use ETH tokens, which share the same coin type, 60.
- OP Stack chains are often developed per use case, which may not be popular enough to have a dedicated coin type in SLIP-0444 standard.
- SLIP-0444 standard canât separate records between the testnet and mainnet chain.
With Universal Registry, we can resolve ENS record on-chain in each OP stack chain directly without relying on registering a coin type in the SLIP-0444 standard, which is highly centralized.
Universal Registry is deployed at 0x8888110038E46D4c4ba75aFF88EaAC6f9aA537c1 and source code is available at optidomains-ens-contract/contracts/universal-registry/UniversalENSRegistry.sol at master ¡ Opti-domains/optidomains-ens-contract ¡ GitHub
Rainbowkit and Wagmi Integration
Lastly, we are glad to report that we have successfully integrated our Universal Registry and ENSâs Universal Resolver with Rainbowkit and Wagmi, making Opti.domains compatible with these platforms.
We have submitted a pull request to the Wagmi repository: Support custom UniversalResolver for ENS resolution by Chomtana ¡ Pull Request #2559 ¡ wagmi-dev/wagmi ¡ GitHub
However, it's not officially supported yet. To facilitate integration between the Dapp on Optimism platform and Opti.domains, it is necessary to substitute rainbowkit, @wagmi/core, and wagmi with the respective @optidomains replacement. If your Dapp exclusively relies on rainbowkit, inclusion of @wagmi/core and wagmi from the @optidomains scope is also essential for proper functionality of rainbowkit.
List of packages to substitute:
-
@wagmi/core
: npm:@optidomains/wagmi-core@1.2.0 -
wagmi
: npm:@optidomains/wagmi@1.2.0 -
rainbowkit
: npm:@optidomains/rainbowkit@1.0.1-ure2
Hi @chom, Tempe Techie from Punk Domains here.
I came across your project, Opti.domains, on the Optimism forum a few months ago, and I must say, itâs great to see the growing number of builders in this space. However, I want to address a serious concern regarding domain collision that you need to be aware of.
We have tried to reach you via email a couple of months ago, but unfortunately weâve received no answer from you.
This is an urgent matter, because if you proceed with launching .op domains via your Opti.domains service, you will cause a domain collision which can result in people losing funds.
How so?
The .op
domain already exists. It was launched by us (Punk Domains) in early 2022 (hereâs the website link: https://optimistic.domains/).
Our .op
names have been actively operating for over a year, and 100% of our registration fees contribute to the official Optimismâs RetroPGF fund (at the retroPGF.eth address).
If you proceed with launching .op
domain via your own service, youâll cause a domain collision.
This can result in people mistakenly sending funds to a wrong .op
name holder (if the same domain name is registered on both services, but by two different users).
Domain collisions are a serious thing and should be avoided at all cost.
Since you havenât launched your service on Optimism Mainnet yet, we strongly suggest that you use another domain extension instead of .op. For example, you could use .opti extension instead (this one makes sense due to your website name being opti.domains
).
Thank you for giving this matter your attention. We strongly believe that through collaboration and coordination, we can ensure a safe experience for everyone in the ecosystem.
P.S.: Hereâs a list of all domain extensions issued through the Punk Domains protocol on all chains: TLD addresses | Punk Domains Docs (we are also coordinating with other projects in this space, such as Unstoppable Domains, to avoid domain collisions).
Hi @TempeTechie, itâs true that we have a plan to .op. However, we will pilot launching .town with Bored Town first then we will get in contact with Optimism Foundation about this domain collision problem.
However, the logic behind isnât the first one that deploys .op that will get accepted as an official one. For example, your .polygon got taken over by unstoppable domains. We canât decide these things ourselves.
Currently, there are at least 4 .op domains in the Optimism system. Two are much bigger than us, with more than 10,000+ people engaging in their campaign, but they donât even succeed in Optimism.
So how can we decide who will be the one that gets into official? The answer is we need to enter the vote by Token House when we get enough adoption.
Note: Applied to Optimism only. For other chains, there are other processes for example, in Polygon, it will be determined by only the Polygon company itself (Centralized).
Considerable factors in voting may include but not limited to
- Number of users adopted
- How much we contribute to the Optimism ecosystem
- How much we contribute to the Ethereum ecosystem
- How many delegates liked our product
- Compatible with existing infrastructure (Etherscan, for example)
In case we win the vote, we can do this
- Main .op will be long to us.
- Your ***.op domain will be migrated to ***.p.op or ***.punk.op on your choice or you may have your own TLD on our system like ***.opunk. These domains can be used in supported wallets.
In case you win the vote, we can migrate to ***.opti
For example, your .polygon got taken over by unstoppable domains.
This is a good example because we actually coordinated with Unstoppable Domains to prevent domain collisions. Weâve stopped .polygon sales soon enough so that only a small number of domains were minted. And Unstoppable Domains offered our existing users $2500 per domain to burn these domains and transition to UDâs domains.
Thatâs why we believe that early detection and collaboration to prevent domain collisions is important. Both UD and us take these matters seriously.
However, the logic behind isnât the first one that deploys .op that will get accepted as an official one.
The point here is not about being âofficialâ or not. I talked with Optimism Foundation team members last year at DevConnect Amsterdam and their stance was not to issue any official support in these kind of matters (which makes sense).
Instead, the point here is to protect users from domain collisions which can result in them losing funds.
As you noted, there is another actor that launched the .op domain (despite us warning them about domain collision issue). Which is the problem that we unfortunately have to deal with by educating users.
But since you havenât launched your smart contracts on mainnet yet, you can avoid having the same problem. The solution is easy, just use a different domain extension. This way youâll be able to protect the users of your service.
In the end it boils down to what is important to you - having a domain extension that already exist, or protecting your users. We cannot prevent you (or anyone) from launching another .op extension. Just like no one can prevent people from launching their own token with OP or UNI symbol. Blockchains are permissionless.
Itâs your decision and I hope you will consider it from all angles.
P.S.: Btw, one more thing. In your Business Positioning Canvas youâve marked us as a fork. Punk Domains is not a fork of any project. We have our own codebase which we developed ourselves. So please correct it and move our logo up, away from the Fork section.
We have updated your position canvas to be similar to us.
Milestone Update 24 September 2023
Mainnet Release
We apologize for the extended delay. The Mainnet release is now scheduled for 1 October 2023. The following challenges led to this postponement:
- I am the sole developer managing the entire system, which has considerably impacted the pace of our developments and releases.
- Originally, the Mainnet release was planned to launch with a bare ENS fork version of the domain. However, we now intend to release our mainnet with nearly all the features outlined in our milestones.
- The development complexity was more intricate than initially estimated.
- Iâve incorporated the Ethereum Attestation Service, which was non-existent at the time the proposal was written. I believe this integration is valuable as it will be utilized for Citizen House attestation and more in the future. Weâre proud to be the first to merge the EAS with an ENS-based domain name.
- Recently, Iâve been preoccupied with the grant proposal. Launching on the mainnet requires time, resources, and optimal timing to mitigate any potential FUDs within the community and ensure a positive reception.
- There could be potential political issues surrounding .op and .base. To address this, weâve partnered with Bored Town to initially release .town domains. Discussions with OP Labs or the Optimism Foundation regarding .op will follow.
Landing Page: https://opti.domains
Testnet: https://town-testnet.opti.domains
Mainnet: https://town.opti.domains
Universal Registry Resolver Integrated to Forked Ethers.js and Metamask (Prototype)
The code is available on https://github.com/Opti-domains/optidomains-ens-contract/blob/master/contracts/universal-registry/UniversalENSRegistry.sol
Wagmi integration: GitHub - Opti-domains/wagmi at universal-resolver
Note: Wagmi has officially considered UniversalResolver support on non-Ethereum chains which is a crucial part of the adoption as stated in our pull request to Wagmi: Support custom UniversalResolver for ENS resolution by Chomtana ¡ Pull Request #2559 ¡ wagmi-dev/wagmi ¡ GitHub
Rainbowkit integration: GitHub - Opti-domains/rainbowkit: The best way to connect a wallet đ đ§°
Over time, the Viem, Wagmi, and RainbowKit stack grew in popularity compared to Ethers.js. Hence, we successfully integrated with Viem, Wagmi, and RainbowKit in our fork before moving to ethers.js and metamask.
This process is needed to collaborate with ENS, so we submit an ENS small grant proposal to them but using a part thatâs provide the most impact to the ENS ecosystems: https://ensgrants.xyz/rounds/30/proposals/808
The Universal Registry Resolver is currently more intricate than necessary. We aim to streamline it to ensure minimal modifications to the ENS standard are required.
Next, we plan to audit our smart contracts with support from RFG-3 and then proceed with the integration into the forked Ethers.js and Metamask.
Mainnet Release on Base
Weâve developed a prototype to support .town across various chains, including Base. Thus, launching on Base should be straightforward after our mainnet debut.
Cross-Chain Domain (Prototype)
Weâve created a prototype to facilitate .town across multiple chains, currently active in Optimism, Base, and Mode testnet.
Additionally, weâve developed CrossDAO, a cross-chain governance prototype. It enables DAOs across various chains to collaboratively vote on a single proposal. Used to submit to the Axelar Flipside Hackathon.
See the demo video: https://www.youtube.com/watch?v=YIUDelwNifI
Live prototype: https://crossdao.opti.domains
Permissionless Deployment on OP Stack Ecosystems (Prototype)
Our first permissionless deployment to any EVM chains supporting the Seaport keyless deterministic deployer has been achieved (all OP stack chains are compatible). This allows us to deploy our domain name smart contracts to identical addresses across any EVM chains. However, itâs not open-sourced as of yet.
(Can also deploy on some non-standard EVM chains as well)
The deterministic deployment of ENS marks a pivotal move in connecting the web3 domain name across chains.
UI Redesign
The redesign is complete, undertaken personally rather than through decentralized efforts.
Landing Page
Domain Management UI
Profile System
Weâve harnessed the Ethereum Attestation Service to certify social profile and wallet verifications for each domain name.
Example Attestation from social oracle: Attestation (Opti.Domains Social Verification) - 0x6a20...94d72
Example Attestation from domain owner: Attestation (Opti.Domains Social and Text Record) - 0xebc8...990ef
This attestation establishes a transparent connection between the domain name, Ethereum wallet address, social profiles like Twitter, Discord, and GitHub, and non-EVM wallet addresses such as Sui and Aptos. Both social oracle and domain owner must be attested in the same way to have identity connection verified.
This data is accessible by querying the Ethereum Attestation Service.
Contrary to ENS, where one might attach someone elseâs record to their domain name, weâve crafted a verification system. This mechanism allows a social oracle to confirm the social profile link, ensuring the recordâs authenticity.
For enhanced decentralization, we advocate other social identity providers to attest according to our schema, enhancing the credibility of the global public social profile connection database.
Audit
We are planning to upgrade our smart contract to modify ENS smart contracts as little as possible. This significantly reduces the complexity of our smart contract and reduces nSLOC. As a result, audit costs will be significantly lower. We have planned to get audit costs subsidized with RFG-3.
Critical Milestones
Due to political concerns which example can be seen in the above comments, we launched .town with our partner, Bored Town, instead of .op and .base. However, .town is technologically equivalent to .op and .base (Just names are different but contracts are mostly the same). We plan to discuss with OP Labs and Base before launching .op and .base to prevent any further issues.
Critical Milestone | Task Name | Status | Source of Truth |
---|---|---|---|
.op and .base domains prototype | Deployment of smart contracts to the Optimism and Base Goerli | Completed | |
.op and .base domains prototype | - Core ENS system with permissionless deployment | Completed | Source Code Deployments Below |
.op and .base domains prototype | - Diamond Resolver and Social oracle system | Completed | Source Code Deployments Below |
Final testing for mainnet release | Testnet 2 | Completed | |
Final testing for mainnet release | Testnet campaign | Completed | 1000+ testers |
Mainnet release | Deployment to the Optimism Mainnet | Completed | |
Mainnet release | - Core ENS system with permissionless deployment | Completed | Source Code Deployments Below |
Mainnet release | - Diamond Resolver and Social oracle system | Completed | Source Code Deployments Below |
Mainnet release | - User interface | Completed | Live Application |
Universal Registry Resolver integrated to forked Ethers.js and Metamask (Prototype) | Universal registry and integration into frameworks | Completed | |
Universal Registry Resolver integrated to forked Ethers.js and Metamask (Prototype) | - Deployment of Universal registry to Optimism Mainnet | Completed | Source Code Deployments Below |
Universal Registry Resolver integrated to forked Ethers.js and Metamask (Prototype) | - Integration with Rainbowkit + Wagmi + Viem (Prototype) | Completed | NPM Package Source Code (Rainbowkit) Source Code (Wagmi) |
Universal Registry Resolver integrated to forked Ethers.js and Metamask (Prototype) | - Integration with ethers.js (Prototype) | Completed | Source Code |
Universal Registry Resolver integrated to forked Ethers.js and Metamask (Prototype) | - Integration with Metamask (Prototype) | Completed | Demo Video Source Code |
Mainnet release on base | Mainnet release on base | Completed | |
Mainnet release on base | - Deployment of Contracts on Base | Completed | Source Code Deployments Below |
Mainnet release on base | - User interface | Completed | Live Application |
Cross chain domain (Prototype) | Cross chain domain (Prototype) | Completed | |
Cross chain domain (Prototype) | - CrossDAO prototype (Same underlying domain tech + Axelar integration) | Completed | Demo Video Live Demo Source Code |
Permissionless deployment on OP stack ecosystems (Prototype) | Permissionless deployment | Completed | |
Permissionless deployment on OP stack ecosystems (Prototype) | - Deployment script for public | Completed | Source Code |
Permissionless deployment on OP stack ecosystems (Prototype) | - Documentation for permissionless deployment | Completed | Source Code |
UI Redesign | UI Redesign | Completed | |
UI Redesign | - Landing Page (Compare with the first version on the proposal) | Completed | Landing Page |
UI Redesign | - Domain registration and social profile dashboard (Compare with the first version on the proposal) | Completed | Live Application |
Profile system | Profile system | Completed | |
Profile system | - Domain social profile dashboard | Completed | Live Application |
Profile system | - Social oracle system for profile attestation | Completed | Source Code EAS Schemas Below |
Impact evaluation can be found on our Opti.domains RetroPGF application
Deployments
We have deployed our ENS contracts to the same addresses across multiple chains including Optimism Mainnet, Base Mainnet, Optimism Goerli Testnet and Base Goerli Testnet. Thanks to our deterministic and permissionless deployment technology
Core Contracts
Contract | Address |
---|---|
Root | 0x88881190D24e8ecA11F0262972cff8081b2AFc45 |
ENSRegistry | 0x888811b3DFC94566Fc8F6aC5e86069981a50B490 |
ReverseRegistrar | 0x888811225d6751A0cf8a9F7fa6a77f4F1EF69DC9 |
Universal Registry Resolver
Contract | Address |
---|---|
UniversalENSRegistry | 0x8888110038E46D4c4ba75aFF88EaAC6f9aA537c1 |
UniversalResolverTemplate | 0x888811D93EE697768FB2Eb23B4225038Beeb7FDc |
Diamond Resolver
Contract | Address |
---|---|
NameWrapperRegistry | 0x888811E08f362edB8B1BF4A52c08fED2A58a427E |
OptiDomainsAttestationDiamond | 0x8888119526F2AAE3525a3820F8893424E74E7af2 |
OptiDomainsAttestationFacet | 0x8888118F6913898253a94d8198207e113378Ae62 |
DiamondResolver | 0x888811Da0c852089cc8DFE6f3bAd190a46acaAE6 |
RegistryWhitelistAuthFacet | 0x888811761f31b8242fAe670C3f0a054e226D10e8 |
PublicResolverFacet | 0x888811B3c11F37a978eED349b174F7e9cCec14D7 |
Domain Registrar
Contract | Address |
---|---|
BaseRegistrarImplementation | 0xB02ED512702C46dbDB260053C97f79c3F467E39E |
MetadataService | 0xB02EDED8502B029aA7f2CB02e1C2a0c452531279 |
NameWrapper | 0xB02ED980693e14E082F0A3A33060046Ae8495EB2 |
RegistrarController | 0xB02EDc247246ACD78294c62F403B3e64D5917031 |
EAS Schemas
Name | Type | Actively Used |
---|---|---|
Opti.Domains ABI Record | Resolver | |
Opti.Domains Wallet Address Record | Resolver | Yes |
Opti.Domains Content Hash Record | Resolver | |
Opti.Domains DNS Zone Hashes Record | Resolver | |
Opti.Domains DNS Record | Resolver | |
Opti.Domains DNS Records Count | Resolver | |
Opti.Domains Interface Implementer Record | Resolver | |
Opti.Domains Name Record | Resolver | Yes |
Opti.Domains Social and Text Record | Resolver | Yes |
Opti.Domains Public Key Record | Resolver | |
Opti.Domains Wallet Address Verification | Social Oracle | Yes |
Opti.Domains Social Verification | Social Oracle | Yes |
.town Minter | Mint | Yes |
First 10000 .town minter | Mint | Yes |
First 2500 .town minter | Mint | Yes |
Opti.Domains Referral Wallet Only | Referral | Yes |
Opti.Domains Referral | Referral | Yes |
Grant Budget Distribution
In the proposal, we are getting a 50k OP builder grant locked for 1 year for which 30k OP, after unlock, we plan to distribute to bootstrap activities in our protocol as follows.
- 10k OP - Marketing budget - Distribute to domain minters for participating in campaigns or gas fee subsidization.
- 10k OP - Hackathon reward - We plan to use this portion to organize our first hackathon style RetroPGF round focusing on promoting the adoption of Opti.domains and scaling ENS to Optimism.
- 10k OP - Decentralized work - Will plan to distribute in a similar way to NumbaNERD tasks to bootstrap Opti.domains ecosystems.
Screenshots
Opti.domains UI with social profiles
Opti.domains forked Metamask integration demo
RainbowKit integration
Whatâs next
We are developing Opti.domains V2 using lessons from V1. Similar to Uniswap where Uniswap V2 has to be developed for the mass adoption to begin.
Opti.domains V2 is made from scratch while ensuring ENS compatibility such that wallets and SDKs supporting ENS are usable with Opti.domains V2 given that either registry or universal resolver address is configured properly. Opti.domains V2 is designed with a modular in mind, it can be ported to any superchains efficiently even though interop is not activated yet. Opti.domains V2 will support interop natively when interop is activated.
Opti.domains V2 will also have native support for Scale ENS to Optimism mission to link .eth on ETH mainnet to .op on Optimism without sacrificed any compatibility on .eth domain.
Hello @chom, the Milestones Committee has reviewed all these milestones and have no concerns. We will be recommending to the foundation to disburse the milestone funding upon the one year lockup. Good job and thanks for the clear communication.