[READY][GF: Phase 1 Proposal] Opti.domains | Interoperable domain name for the OP Stack

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.

  1. 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.

  2. 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.

  1. 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?

1 Like

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)

2 Likes

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).

3 Likes

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.

1 Like

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

Universal Registry and Resolver

Contract Address
UniversalENSRegistry 0x8888110038E46D4c4ba75aFF88EaAC6f9aA537c1
UniversalResolverTemplate 0x888811D93EE697768FB2Eb23B4225038Beeb7FDc

Diamond Resolver

.op Domains

.town Domains

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:

1 Like

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).

1 Like

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

  1. Number of users adopted
  2. How much we contribute to the Optimism ecosystem
  3. How much we contribute to the Ethereum ecosystem
  4. How many delegates liked our product
  5. 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.

2 Likes

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

Universal Registry Resolver

Contract Address
UniversalENSRegistry 0x8888110038E46D4c4ba75aFF88EaAC6f9aA537c1
UniversalResolverTemplate 0x888811D93EE697768FB2Eb23B4225038Beeb7FDc

Diamond Resolver

Domain Registrar

EAS Schemas

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

image
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.

2 Likes

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.