1. Applicant Information
- Company / Team Name: dWeb.host
- Website/Other: https://dweb.host
- Primary Contact/entity ENS Name.eth: dwebhost.eth
- Primary Contact(s)
- Chomtana Chanjaraswichai
- chomtana.eth
- Telegram: Contact @chomtana
- Company Overview: dWeb.host is a collaboration between Opti.Domains and Upnode to research, build, and deploy critical dWeb infrastructure on ENS. We identify gaps in ENS dWeb infrastructure and address them.
- Requested Amount:
- $300k - Basic Scope
- $400k - Extended Scope
- Size of team and commitment
- 5 full time engineers (frontend/backend/smart contract/devops)
- Engineers will appropriately allocated to each task
2. Eligibility Confirmation
(Please confirm each point below.)
- Company Age & Reputation
- Opti.domains has been working on ENS L2 on Optimism for more than 1 year.
- Upnode has been a mainnet validator for Celestia for more than 1 year and has received foundation delegation.
- Our company has been registered in the Isle of Man for more than 1 year.
- More information on “Past Achievements” section
- Team Experience:
Chomtana Chanjaraswichai - Team Lead
- Opti.domains: ENS L2 on OP
- Optimism TechNerd
- RetroList - Optimism Retro Funding Discovery UI
- Maintaining simple-optimism-node
- Top 100 Optimism Delegate
- Won many hackathons
- And more…
Johny Phan - Full Stack Developer - Dedicated to dWeb.host project
- Develop prototype of dWeb.host IPFS Pinning for ENS domains
- Develop prototype of dWeb.host Vercel for ENS
- Develop UI for Opti.domains ENS L2 on OP
1 more full stack developer, 1 more frontend developer and 1 more backend developer
- ENS Token Endorsement Requirement: No public endorsement as of yet. Please consider voting for us in the upcoming vote!
- OFAC Sanctions Compliance
- Our company is registered in the Isle of Man, a Crown Dependency of the United Kingdom.
- All employees currently reside in the Isle of Man, the United Kingdom, Thailand, and Vietnam.
- We, dWeb.host, confirm that neither our organization nor any of our employees, contractors, or executive leadership is located in, or a resident of, an OFAC-sanctioned country. We further confirm that none of our business resources are derived from or routed through any country or entity that is subject to sanctions imposed by the United States (OFAC) or equivalent regulatory bodies. We pledge to remain compliant with all applicable sanctions laws and will promptly notify the ENS DAO if our status changes.
3. Open Source Commitment
Yes, dWeb.host is fully open-source, and its source code is accessible at dwebhost · GitHub
The source code for our dWeb.host prototype (Both the IPFS Pinning service and the Vercel for ENS prototype) is open-source and available at GitHub - dwebhost/dweb-alpha.
4. Scope of Work & Budget
At dWeb.host, our team is addressing key infrastructure and application gaps in the ENS dWeb ecosystem.
To tackle these challenges, we propose the following solutions:
- Develop a decentralized IPFS and IPNS pinning service for all ENS domains with at least 3 external node operators.
- dWeb Deployer and Builder Network: Develop an infrastructure and SDK that enables developers to easily develop and deploy a profile dWeb that anyone can claim and personalize, and a community subdomain dWeb that serves all members of a community.
- dWeb Gallery: Enable end users to easily configure and claim a subdomain representing a personalized website derived from the base domain.
- (Extended Scope) CNAME Gateway: Enable end users to connect their DNS names to ENS websites through CNAME and TXT records in a Vercel-like experience.
Here are the key issues we are addressing:
- Most ENS websites are hosted on IPFS but many of them are inaccessible.
- Unique dWeb use cases exclusive to ENS? Claimable profile dWeb for all, Subdomain community dWeb? These solutions remain challenging to develop today.
- (Extended Scope) When there are such unique websites but users prefer to use their Web 2 domain, there is currently no way to easily link a Web 2 domain to an ENS website.
And by having external node operators run the infrasturucture, we can improve the overall reliability of the ENS dWeb infrastructure. They would not only support essential services but also pave the way for future innovations—such as a serverless function system, which, while outside the scope of our current proposal, exemplifies the potential benefits of a decentralized node operator network.
Working Prototype
To demonstrate our expertises and commitment, we have developed two prototypes:
- An IPFS pinning service for all ENS domains.
- A Vercel-like deployer for building and deploying decentralized websites from the source code of any open-source repository.
The IPFS pinning service prototype indexes all content hash change events and attempts to pin each corresponding IPFS website to our local IPFS node. As a result, we discovered that many ENS websites on IPFS are no longer retrievable.
Currently, we have indexed over 40,000 websites on 20,000 unique ENS domains and have successfully pinned over 8,000 websites, which occupy approximately 40 GB of disk space. This number continues to grow as more sites are pinned.
Live pinning statistics are available at: dWeb - Deploy decentralized websites
Another prototype is a Vercel-like deployer that enables anyone to deploy any open-source repository on GitHub directly to their ENS domain name.
This Vercel-like deployment UI is live at: https://alpha.dweb.host
The source code for both prototypes is available at: GitHub - dwebhost/dweb-alpha
Critical Infrastructure: Decentralized IPFS and IPNS Pinning for all ENS domains
This same idea was discussed years ago on this forum.
Many websites hosted on IPFS have been lost in eternity. Moreover, IPNS websites are even more prone to loss because they are mapped to a key on an IPFS node that is easily lost. Notably, even https://nick.eth.limo, which is hosted on IPNS, is inaccessible at the time of writing.
We solve this by providing a free IPFS pinning service for all ENS domains, regardless of the primary pinning service (e.g., Pinata, Firebase) they use.
| Features | Cost |
|---|---|
| IPFS Pinning for all .eth domains | 20,000$ |
| IPNS Caching network for .eth domains | 20,000$ |
| IPFS Direct peering with eth.limo | - |
| Explorer and Wayback Machine | 10,000$ |
| 2 Instances of pinning node hosted by us | 40,000$ |
| 3 External pilot node operators | 60,000$ |
| Total | 150,000$ |
Initially, we propose that free IPFS pinning support be rate-limited to 1 GB per 2LD .eth domain to prevent abuse. We expect to increase this limit once the network is stable to accommodate new use cases.
This is the most critical infrastructure within ENS, and we will allocate all of our engineers to its development and launch in Q2 2025.
Decentralized Source Code Builder Network
Imagine you are building a no-code website maker. Traditionally, you would need to develop a deployment pipeline to build websites on demand. However, because no-code website makers are designed for developers with both frontend and UX/UI skills, creating these pipelines can be a cumbersome process. With the Decentralized Source Code Builder Network, developers can build websites directly from the frontend, eliminating the need for a dedicated builder server.
| Features | Cost |
|---|---|
| Source code builder node | 20,000$ |
| Control plane for task distribution | 20,000$ |
| Share node operators with IPFS pinning | - |
| Total | 40,000$ |
The pilot set of node operators is shared with the Decentralized IPFS and IPNS Pinning services, so it doesn’t incur additional cost. The control plane will enforce an appropriate rate limit.
API and SDK for building a dWeb for every name
To build a no-code website maker, we typically require two components that do not currently exist:
- An SDK and API capable of building a website template from source code and returning a pinned IPFS CID. This serves as the interface for the decentralized Source Code Builder Network.
- An SDK that dynamically resolves records based on the origin domain name (e.g., accessing
chomtana.sourcer.eth.limoshould resolve records fromchomtana.sourcer.eth, which merges records fromchomtana.ethwith specific records defined inchomtana.sourcer.eth).
If we are using Vercel, we had to handle a complicated authentication process that needed a user key just to trigger a new deployment, which meant we even had to rebuild Vercel to build a portfolio maker site.
| Features | Cost |
|---|---|
| Source Code Builder API and SDK | 20,000$ |
| Origin ENS name resolver SDK | 10,000$ |
| Total | 30,000$ |
Source Code Builder API and SDK
An SDK that let developer deploy any website from source code with a simple syntax like this
deploy({
repo: "https://github.com/Chomtana/snake-game",
branch: "main",
buildSettings: {
installCommand: "yarn install",
buildCommand: "yarn build",
rootDirectory: "",
outputDirectory: "dist",
},
environmentVariables: {
VITE_SOME_KEY: "Hello World!",
},
authentication: ... (Optional) ...,
})
Authentication is optional; however, if the user authenticates with a wallet that holds an ENS domain, it will be given higher priority during high-demand periods.
Our goal is for this API to work in the browser, enabling developers to build website builders without requiring any server or DevOps expertise.
Origin ENS name resolver SDK
To build a website like https://web3.bio/vitalik.eth and have it accessible from URLs like https://vitalik.web3bio.eth.limo or even linked to a custom DNS domain such as https://vitabio.me we need an SDK that dynamically converts the origin (e.g., https://vitalik.web3bio.eth.limo or https://vitabio.me) into the corresponding ENS domain name (vitalik.eth).
In the case of Web3.bio, the domain name is specified in the path (/vitalik.eth), so there’s no issue. However, when the domain is specified as a subdomain (vitalik.web3bio.eth.limo) or as a custom domain (vitabio.me), resolving the ENS name becomes less straightforward.
The origin ENS name resolver SDK addresses this challenge as follows:
originEnsName("vitabio.me") -> "vitalik.web3bio.eth"
cname("vitalik.web3bio.eth") -> "vitalik.eth"
Additionally, the ENS domain vitalik.web3bio.eth is equipped with a special resolver that merges the records from vitalik.eth with specific records set directly in vitalik.web3bio.eth.
We might also require an ENSIP to set up a CNAME record for an ENS name, as well as a TXT record for a DNS domain that points to an ENS name.
dWeb Gallery and Deployer
The dWeb Gallery and Deployer simplify the development and user experience for use cases unique to ENS, such as:
- Claimable profile dWebs for all ENS users
- Subdomain-based community dWebs
With dWeb.host, developers can deploy their app just once—similar to Vercel—but then allow .eth holders to claim subdomains and customize their records. For instance, once sourcer.eth website is deployed, a user holding chomtana.eth can claim the chomtana.sourcer.eth website, with records automatically inherited from chomtana.eth for a personalized experience.
By default, dWeb Gallery uses the user’s .eth 2LD domain as a subdomain, increasing the utility of the eth domain and boosting revenue for the DAO. Additionally, this approach prevents minting legally sensitive or speculative names such as coinbase.sourcer.eth.
| Features | Cost |
|---|---|
| UX/UI Design | 10,000$ |
| dWeb Gallery Development | 20,000$ |
| dWeb Deployer Development | 40,000$ |
| Smart Contract Development | 10,000$ |
| Total | 80,000$ |
Finally, we will collaborate with subdomain communities to deploy dWeb solutions that serve all their members. Subdomains should not merely be just names for airdrop hunting; instead, each should feature an innovative dWeb that encourages real use cases.
Extended Scope
For extended scope, we plan to expand the external node operator set from three to five node operators to enhance reliability, develop a CNAME gateway based on the eth.limo codebase and a load balanced gateway across node operators.
We have discussed with the eth.limo developer to ensure that we have not recreated anything already done by eth.limo, and to obtain guidelines for developing a CNAME gateway based on their codebase.
To develop the CNAME gateway, we first need to propose an ENSIP standard that links traditional DNS names to ENS domains using a TEXT record, and create a Domain API endpoint that resolves DNS names to ENS names.
Additionally, to enhance the utility of node operators, they could work together to form a reliable, load-balanced gateway for .eth domains.
| Features | Cost |
|---|---|
| 2 More node operators | 40,000$ |
| CNAME Gateway Development | 40,000$ |
| Load-balanced Gateway Endpoint | 20,000$ |
| Total | 100,000$ |
4.1 Basic Scope of Work
- Requested amount: $300k
- Description: Develop and manage infrastructure solutions, including decentralized IPFS and IPNS pinning for all .eth domains and a decentralized source code builder network along with its API and SDK for developer to build dWeb applications, alongside a dWeb gallery and deployment UI application. More information is in the above section.
- KPIs / Success Metrics
- Developed a decentralized IPFS and IPNS pinning infrastructure for all .eth domains by Q2 2025.
- Developed a decentralized source code builder network by Q3 2025.
- Proposed and developed developer tooling and an SDK by Q3 2025.
- Developed dWeb gallery and deployer by Q3 2025.
- Launched 2 internal nodes and collaborate with 3 external node operators by Q3 2025.
- Maintained 99.99% uptime for the decentralized IPFS and IPNS pinning service and source code builder network (considered operational if at least one node operator remains online).
- Number of domains deployed with dWeb deployer.
- Number of subdomains claimed in dWeb gallery.
- Budget: $300k/year
4.2 Extended Scope of Work
- Requested amount: $400k
- Description: Expand the external node operator set from three to five node operators to enhance reliability, develop a CNAME gateway based on the eth.limo codebase and a load balanced gateway across node operators.
- KPIs / Success Metrics
- Launched 2 internal nodes and collaborate with 5 external node operators by Q3 2025.
- Developed a CNAME gateway based on the eth.limo codebase by Q3 2025.
- Create an ENSIP for pointing a traditionally managed DNS name to an ENS name by Q4 2025.
- Budget: $400k/year
5. Past Achievements & Additional Information
dWeb.host is a collaboration between Opti.Domains and Upnode to research, build, and deploy critical dWeb infrastructure on ENS. Here are our past achievements:
Opti.Domains
- Completed a grant for the Opti.Domains project focused on scaling ENS to Optimism
- Received a Gitcoin Grant in the past year for the project “Opti.Domains | Scale ENS to OP”
- Was the first to build a fault gateway for Optimism following its migration from L2OutputOracle to the Dispute Game mechanism
- Developed a Superchain CCIP gateway with a unique “deploy-once, run-anywhere” feature, enabling each individual domain to specify the chain and resolver from which it should be resolved without the need to deploy a dedicated verifier contract and gateway
- Received an ENS small grant for adding custom UniversalResolver support to Wagmi (Previously, Wagmi did not support setting a custom UniversalResolver contract)
Opti.Domains ENS L2 is live at https://ens.opti.domains
Opti.Domains developer documentation is available at GitHub - Opti-domains/opti-registry: An extendable smart contract for developer to develop creative domain name use cases on superchain and GitHub - Opti-domains/superchain-gateway: ENS Gateway for Superchain
Upnode
- Upnode has been a mainnet validator for Celestia for more than 1 year and has received foundation delegation
- We have hosted many validators and indexers on behalf of private investors, whose identities cannot be disclosed due to confidentiality agreements.
- Upnode has successfully completed multiple Optimism grants focused on the development of developer tooling.
- signer-proxy: An RPC signer proxy server used for signing transactions via YubiHSM2 hardware or AWS KMS signers. Used by a few OP Stack chains.
- UpRoll: OP Stack deployment tool [Demo Video]
- opstack-compose: OP Stack docker compose deployment script (Superseded by UpRoll)
- Our objective is to leverage our expertise and connection in validator node operations to build and maintain a decentralized dWeb infrastructure for ENS.
6. Video Introduction (The BEST WAY to learn about our project!)
7. Conflict Of Interest Statment
- Several of our projects have received grants from Optimism. One project directly related to ENS, Opti.domains, scaling ENS to OP, is funded by an OP grant. However, this proposal is not intended as double funding; rather, it aims to build a new project for dWeb infrastructure on ENS, which falls outside the scope of the OP grant.
- Upnode generates revenue through its validator business.
- We are also researching and developing Turbo, a ZK and P2P framework designed to bring real-time games fully onchain. This project is intended for fundraising purposes, and while we might incorporate dWeb.host in some features of Turbo, it is not within the scope of this grant and does not conflict with our work on ENS.
