WebHash × ENS: Service Provider Program (SPP3) Application

Team & identity

• Team / organization: WebHash (formerly 1W3), building on ENS continuously since 2022
• Primary contacts: hidayath.eth, Z7Lab.eth
• ENS for payment: webhash.eth
• Team status: Prior ENS DAO grantee across Terms 3–6 (delivered). Applied to SPP2, found eligible, not selected, and kept shipping on grants throughout.
• Category: ENS Infrastructure (primary); Outreach & Integrations (secondary)
• Requested amount: $275,000 (breakdown in §6)
• Public evidence: webhash.com, pro.webhash.com, app.webhash.com, GitHub github.com/WebHash-eth and github.com/Z7Lab, deployed registry contracts (§5)
• Email: hid@webhash.com, vincent@webhash.com | Telegram: @W3hidayath, @zadok7_eth
• Program Terms: read and accepted, ENS DAO SPP Program Terms v1.0, dated 14 May 2026. Award Notice to be executed if selected.

Overview: the line we've been walking since 2022

ENS lets a name point at content. The four years since, WebHash has been closing the gap between that promise and infrastructure people can actually build on, one funded, delivered step at a time.

Then (2022–2023, as 1W3, Terms 3–4). We built the first no-code way to make an ENS name resolve to a real website, a decentralized link-in-bio and site builder, gasless updates via IPNS, a .eth resolver extension. We shipped it, and the DAO funded it twice. Result: ENS names that resolved to something you built in minutes, no code.

Now (2024–2026, as WebHash, Terms 5–6). We rebuilt that into verifiable publishing infrastructure: a no-code dweb builder, WebHash Pro (connect a repo → deploy to IPFS → connect an ENS name, "decentralized Vercel"), an on-chain ContentRegistry that records each piece of content's provenance (who uploaded it) and which nodes are pinning it, and an operator-run hash-node network. The DAO funded this twice more. Result: today, 11k+ users, 15k+ decentralized sites, 3.25M+ page views, all resolving through ENS, all verifiable on-chain.

Next (SPP3, 2026–2027). We have proven that humans can publish verifiable content to ENS names. But every operation still runs through a browser, which locks out the audience now building the next wave of ENS-addressed applications: agents, CI/CD, and automation. The timing is now: ENS has published its own agent-identity standard (ENSIP-25), and ERC-8004 drew 22,900+ agent registrations in its first three days on mainnet, each one a candidate for an ENS-addressed identity, and none with a way to publish verifiable content today. This cycle we make the whole platform programmatic, a CLI, MCP server, and API so agents and developers register ENS names, publish verifiable content, and prove agent identity directly, built on ENSIP-25 and the live ERC-8004 trustless-agent stack. Result: ENS becomes the addressing and identity layer for the agentic web, and the node infrastructure is forkable, so the ecosystem owns it.

One line, four years: point at content → verify content → infrastructure agents build on. We have never missed a delivery on an ENS grant. SPP3 is the next step on a line we've been walking since 2022.

1. Ecosystem objective & category

Primary category: ENS Infrastructure. The lead deliverable is a new programmatic agent layer for ENS (a CLI, MCP server, and API for registering names, publishing verifiable content, and proving agent identity) built on the infrastructure WebHash already operates: the no-code builder, the operator-run node network (which this cycle doubles as distributed ENS gateway nodes), and the developer/org deploy product. Primary value accrues to ENS: more names registered, more resolution served, ENS's own standards (ENSIP-25, contenthash) made usable.

Secondary: Outreach & Integrations. The CLI/MCP/API put ENS registration and resolution directly into developer and agent stacks, and we run grassroots ENS outreach in India, well-timed with Devcon 8 in Mumbai (3–6 Nov 2026, within this cycle). We are not claiming General Ecosystem Benefit (Category 4).

2. Scope

2.1 Problem

ENS is becoming the identity layer for AI agents: it has published its own agent-identity standard (ENSIP-25), and the agentic ecosystem is converging on it (ERC-8004 went live on Ethereum mainnet 29 Jan 2026 with ENS among its backers, 22,900+ registrations in three days). But there is a gap: the agentic web has no programmatic, verifiable, ENS-addressable publishing layer.

Agents now generate real artifacts (reports, dashboards, datasets, documentation sites, dApp frontends) with nowhere to put that output that is simultaneously durable, addressable by a stable name, verifiable as untampered, and owned by a known identity. WebHash solves this for humans today, but every operation runs through a browser. That locks out agents, CI/CD, and automation.

Two adjacent problems compound it:

• Frontend tampering is a top Web3 loss vector. Major losses have come not from contract exploits but from silently modified frontend JavaScript, a compromised DNS operator, CDN, or host. A DeFi swap interface or DAO treasury-voting frontend is only as safe as the most compromised host in its delivery chain.
• No ENS-addressed encrypted storage exists for agents. When agents need to hold or exchange private data, the only options are centralized or unencrypted. IPFS is public by default, so encryption is the only meaningful confidentiality control, and nobody has packaged it as ENS-addressable agent storage.

2.2 Approach

The lead investment this cycle is the agent layer, which we will build on three proven surfaces WebHash already operates.

Agent layer (new this cycle, the bulk of this proposal): we will build a CLI, MCP server, and SDK that let an agent take an ENS name as its on-chain identity and publish decentralized sites and dApps to ENS, no browser. Plenty of tools already let agents publish, and an agent can already wire up ENSIP-25 / ERC-8004 bidirectional identity on its own. WebHash's differentiator is bringing it together in one flow: an agent publishes verifiable content (the CID committed on-chain) that is provably tied to the agent's ENS name and its ERC-8004 identity, so the content, and the agent behind it, are both verifiable from the name. Alongside it, ENS-addressed encrypted storage for agents. The agent layer will also integrate the emerging ERC-8217 standard (below) so an agent's ENS name and content can be packaged and transferred together. Detail in the mechanics below.

The target flow (once shipped): an agent can already use agent-skill frameworks to build an Ethereum dApp today; with the WebHash agent layer it will then publish that dApp to IPFS in one command, register the CID on-chain, and connect it to an ENS name, reachable through a WebHash gateway node and the eth.limo resolver. We will ship dApp templates agents can start from, collapsing "agent builds a dApp" and "agent has a live, ENS-named, verifiable dApp" into one step.

The proven foundation it builds on (operated and improved continuously since 2022, and what makes "we can ship this" credible):

1. No-code builder (non-technical users): anyone builds a censorship-resistant website and connects it to an ENS name, no code. Expanding this cycle with 4,000+ new decentralised web templates and a templates MCP server (app.webhash.com/templates) so templates, web and agent-deployable dApp templates alike, will be accessible programmatically and to agents.
2. Node network: WebHash already runs a live network of hash-nodes that pin and serve decentralized content in production today (the storage layer behind the 15k+ sites above). This cycle we add the eth.limo gateway stack as an optional sidecar (a complement to the nodes we've already built, not a new dependency) so each operator can also run their own ENS gateway on the same machine. A node that today only pins content can then resolve any ENS name → content locally, turning WebHash's pinning network into a distributed ENS gateway network and giving operators resolution sovereignty instead of relying on the single central eth.limo endpoint. Governed by the on-chain NodeRegistry + ContentRegistry.
3. WebHash for developers & organizations: a "decentralized Vercel" that connects a repo, deploys a dApp or frontend to IPFS, and connects it to an ENS name, with the verifiable on-chain content record as the integrity guarantee.

Across all surfaces, here is how the system is designed to work. The on-chain ContentRegistry and the node network exist today; the CLI/MCP/API, agent-identity tooling, encrypted lane, and trustless contract governance are what we build this cycle:

• Programmatic surface: we will build a CLI, MCP server, and REST/JSON-RPC API exposing publish, update, resolve, verify, usable by any agent, script, or CI pipeline. The CLI will also register an ENS name or subdomain directly, so registration is one command.
• ENS-native publishing + on-chain provenance/replication: a name resolves to content through the contenthash record (ENSIP-7), and because content is addressed by CID (a hash), what loads is verifiably the content that was published. Separately, the on-chain ContentRegistry records, per CID, who uploaded it, its size, and which registered nodes are pinning it, a verifiable on-chain record of provenance and replication across the node network. That is the moat: not IPFS pinning (a commodity) or ENS resolution (a public standard), but verifiable on-chain proof of who published a piece of content and how many independent nodes are storing it, which a bare ENS pointer doesn't provide.
• Agent identity: bidirectional ENSIP-25 verification (the ENS text record points to the ERC-8004 registry entry and the entry points back; the verify_agent tool we build will check both directions and handle challenge/revoke of stale records), plus reverse resolution (agent address → ENS name).
• Encrypted storage for agents (a private, decentralized drop-box): agents can pin encrypted content to the WebHash node network, encrypted client-side (AES-256-GCM) before it reaches any node so no operator can read it, and addressed by an ENS name. One agent can share with another: the sender encrypts to the recipient's public key, resolved from the recipient's ERC-8004 identity, so only that agent can decrypt. In effect, a private, end-to-end-encrypted place for agents to store data and hand it off to each other, with no central host that can read or remove it.
• Trustless contract governance: ownership and admin of WebHash's on-chain contracts (NodeRegistry, ContentRegistry) move to a multisig + timelock, so no single party, WebHash included, can unilaterally change the infrastructure, and every change is visible on-chain before it takes effect. (Audited; see §6.)
• ENSv2-ready: WebHash commits to implementing the subregistry / role-based-access model as ENSv2 ships, operating as a naming system inside the ENS hierarchy.
• Packaged, transferable agent ownership (via external standards): WebHash will integrate the ERC-8217 agent↔NFT binding standard (authored by nxt3d; live on Ethereum and Base, indexed by OpenSea) so an agent's ERC-8004 identity binds to its ENS name NFT and the name, identity, and content transfer as one unit. ERC-6551 token-bound accounts (also an external standard) hold the wallet and content references. These are standards WebHash builds on, not WebHash's own.

The standards this builds on are live and ENS-native: ENSIP-25 (ENS's own agent-identity standard), ERC-8004 (Trustless Agents, mainnet since 29 Jan 2026), ERC-8217 (agent↔NFT binding, authored by ENS-ecosystem contributor nxt3d), ERC-6551 (token-bound accounts), and contenthash (ENSIP-7).

2.3 What success looks like at end of cycle (verifiable)

• CLI, MCP server, and API are public, released, and operable without a browser, verifiable via public repos, released packages, and live endpoints.
• Agents register ENS names/subnames and publish verifiable content programmatically, verifiable via on-chain registrations and resolvable names.
• ENSIP-25 verification (bidirectional) and reverse resolution work against live agent identities, verifiable by running the tools.
• Hash-nodes resolve ENS names as gateway nodes, verifiable by resolving a name through a WebHash node.
• Expanded NodeRegistry and trustless-governance (multisig + timelock) contracts are deployed and verified on a public explorer.
• Measurable adoption against the targets in §4.

3. Milestones

12-month cycle (≈Q3 2026 → Q2 2027, anchored to stream start after ratification June 22–July 1, 2026), output-defined, with a verification method and target quarter for each, and quarterly reporting throughout. Milestones span all four pillars (no-code builder, node network, developer/org deploy product, and the agent layer, the new build), sequenced by value and probability: the agent layer first, then the identity/node/dev pillars, then the on-chain and composable pieces. They map to the budget in §6, so the scope can be funded as a coherent subset if the committee chooses.

4. Adoption, revenue & ecosystem utility

Registration growth is the outcome this program most wants to advance, and WebHash already drives it today, with new upside from the agent layer.

4.1 The proven engine (already running)

WebHash already drives ENS registrations today, when someone wants to build decentralized and censorship resistant website:

• No-code builder users are prompted to register an ENS name when they publish, so their site is censorship-resistant and self-owned.
• Developers & organizations deploying a dApp through WebHash are prompted to register and connect an ENS name as the deployment's address.

This is not a hoped-for funnel, it is the mechanism behind today's 11k+ users and 15k+ decentralized sites, up from ~7k users / ~8k sites in early 2025. Each new user or project is one or more ENS registrations, and ongoing identities drive renewals, a direct, attributable effect.

4.2 The new upside (this cycle)

The agent layer adds a new, high-volume registration driver: agents register an ENS name or subname directly through the CLI/SDK, the SDK can register a name automatically and use it as the agent's identity, or issue subnames per agent. With ERC-8004 already at 22,900+ agent registrations in its first three days, each is a candidate for an ENS-addressed identity. This is where registration growth compounds beyond the human funnel.

4.3 Resolution growth, decentralization & integration breadth

• Resolution: each operator who adds the gateway sidecar runs their own ENS gateway, so every such hash-node becomes a node in ENS's resolution network, decentralizing resolution and reducing dependence on the central eth.limo endpoint (an ENS-approved provider, so this extends approved infrastructure rather than forking it).
• Standards into tooling: ENSIP-25 and contenthash become things agents actually invoke.
• Integrations as a by-product: the CLI/MCP/API put ENS registration and resolution into developer and agent stacks. WebHash already integrates eth.limo, NameStone, NameSpace, EFP, 3DNS, .box, and Dentity (§5).
• Forkable, ecosystem-owned: node software and contracts are open (MIT) and self-hostable, growing ENS infrastructure the ecosystem controls, not a single-vendor dependency.

4.4 Revenue

There are two revenue effects here, and they grow together: one accrues to ENS, the other sustains WebHash.

For ENS (the program's first-order outcome): to publish anything self-owned and censorship-resistant on WebHash, a user, developer, or agent needs an ENS name or subname. Every no-code site, every dApp deployment, and every agent identity created through WebHash drives one or more name registrations, plus the renewals that follow as those identities persist, so the registration and renewal revenue accrues directly to ENS. The agent layer adds a new, high-volume driver on top: each agent that takes a name or is issued a subname is another registration, at machine scale rather than human scale.

For WebHash (our sustainability): our revenue is storage. We charge for the decentralized storage utilized on the hash-node network, the content pinned and served behind those ENS names. The more sites, dApps, and agent data published, the more storage is utilized.

The two move on the same curve by construction: more content published through WebHash means more ENS names registered and renewed (ENS revenue, and the outcome this program targets) and more storage utilized (WebHash revenue). Our commercial incentive is to grow exactly the thing the program wants to grow.

4.5 Metrics (outcome-based, attributable, verifiable)

Baseline (today): 11k+ users, 15k+ decentralized websites, 3.25M+ page views.

4.6 Counterfactual (why SPP3 funding matters)

• The programmatic layer doesn't get built otherwise. WebHash stays browser-only; agents, CI, and scripts stay locked out, and ENSIP-25 + ERC-8004 remain live standards with no usable ENS-addressed publishing/identity tooling on top.
• No one else is positioned to build it. WebHash already operates three of the four required pieces (verifiable IPFS, the on-chain ContentRegistry, ENS resolution). A team starting fresh would have to rebuild that base first.
• It is not on an ENS Labs roadmap, not duplicative of work that would ship anyway.
• The novel pieces have no current equivalent: ENS-addressed encrypted agent storage, and hash-nodes doubling as distributed ENS gateway nodes, don't exist elsewhere today.

5. Prior delivery record: four years, four funded cycles, every one delivered

WebHash is not an SPP1/2 funded provider; the record below is ENS DAO grants, each with a shipped product behind it, plus delivery in other ecosystems. Every one was delivered: a clean record, nothing incomplete or abandoned.

The delivery timeline

ENS DAO Ecosystem Term grants (each with a shipped product behind it):

Across Terms 3–6 that is $65,000 USDC + 450 ENS delivered (Term 4 was two $10,000 grants; the 250 ENS was the Term 5 closeout distribution to 2024 grantees in Dec 2024, and 200 ENS came with the Term 6 grant).

Separately, WebHash received an ENS allocation under the DAO's Governance Distribution Pilot (EP-5.19 → EP-5.26), a 30,000-ENS distribution to 2024 grantees by quadratic funding, on 2-year Hedgey vesting: 575.57 ENS (separate from, and additional to, the 250 ENS Term 5 closeout above).

Combined ENS: 1,025.57 ENS (200 from the Term 6 grant + 250 from the Term 5 closeout + 575.57 from the governance distribution).

Live products (public evidence of shipped work):

• WebHash Pro (pro.webhash.com): deploy static / React / Vite sites to IPFS and connect to ENS; GitHub integration. Repo: github.com/WebHash-eth/pro.
• No-code dweb builder (app.webhash.com): 40+ blocks, 200+ tokenized templates, free Hash.is ENS subnames.
• Hash-node network + on-chain registries: NodeRegistry (0x85216f8b1b7bf3C0fF947dBb1a5b7c38C67d2437) and ContentRegistry (0x6f7a486515c240893b7dDaa8B74d8c6601695BbB) deployed and live on Base Sepolia (testnet), with active on-chain transaction history (content registrations and node pins); node software open at github.com/WebHash-eth.
• eth.cd, Hash Dweb Gateway (Chrome extension, uses eth.limo DoH), modly (content moderation): additional shipped ENS-ecosystem products.

Other ENS grants & ecosystems: ENS Small Grants: 5.4 ETH total (Round 10: 3 ETH, Round 8: 0.7 ETH, Round 7: 0.7 ETH, Round 4: 1 ETH); Gitcoin ENS Ecosystem (Oct 2024) + ENS Identity (Apr 2024) rounds; Octant inaugural accelerator + Epoch 6; Optimism RetroPGF3 (19,875 OP); Mask Network grant (eth.cd). Hosted the ENS India event at ETH India 2023.

Team: a 5-person team, majority India-based. Established November 2022. Open source under MIT.

6. Budget

Total requested: $275,000 (above the $200,000 floor). Context: our SPP2 ask was $300,000 for narrower (dwebsite-only) scope; SPP1 (as 1W3) was $500,000. The trajectory is a smaller ask for materially larger scope, programmatic agent layer + identity + gateway network + encrypted lane + on-chain governance + India outreach, kept efficient by an India-based team. (Note: SPP3's total provider pool is ~$3.25M, down from SPP2's $4.5M; this ask is sized to be fundable within a tighter cohort, and the milestone→budget mapping lets the committee scope it.)

Appendix: supporting technical detail

Reference detail for the sections above.

A1. The dual-lane node architecture

WebHash nodes today serve one lane: public, verifiable, immutable content, websites and frontends pinned from the ContentRegistry contract. Adding a token-gated encrypted upload layer creates a second lane on the same infrastructure:

• Public lane, existing pinner, ContentRegistry-driven, open reads, verifiable on-chain.
• Encrypted lane, token-gated proxy, AES-256-GCM encrypted before anything touches IPFS, ephemeral or permanent per TTL config.

From the uploader's perspective (human or agent) it's the same node; from the operator's, one IPFS daemon serving both. This turns the node network from a public hosting network into general-purpose dweb infrastructure, and is the concrete utility reason to run a node without financial incentives.

Access control: one-time upload tokens with configurable TTL, consumed on first use. A token captured in transit (logs, proxies, extensions) is already dead, it cannot be reused.

Encryption: AES-256-GCM, key derived in the browser or CLI via PBKDF2. The node never sees plaintext; the passphrase never leaves the client. Since IPFS content may persist indefinitely regardless of unpin attempts, encryption is the only reliable confidentiality guarantee.

ENS relevance: the node is the delivery layer behind an ENS name. Public-lane sites resolve via a name's contenthash (ENSIP-7) to the CID the node pins and serves; encrypted-lane content is addressed by CID and can be published under an ENS name (or shared directly, per A2). Either way, ENS is how a human or agent reaches what the node holds.

A2. Secure cross-system agent data exchange (ENS-addressed)

This is the decentralized drop-box for agents: a private, end-to-end-encrypted way for one agent to leave data for another, addressed by ENS name. The gap it fills: when agents on different systems need to share private data, there's no standard, secure, durable way to do it. MCP is agent-to-tool, not data transfer. A2A is task delegation, not encrypted transfer. No tool combines IPFS encrypted storage + ENS addressability + ERC-8004 identity into one developer-friendly interface.

Concrete flow (Agent A drops private data for Agent B, addressed by B's ENS name agentB.eth):

1. agentB.eth is bound to B's ERC-8004 identity (ENSIP-25); that identity record includes a public key derived from TEE attestation.
2. A's agent encrypts the data (AES-256-GCM) → uploads via a WebHash encrypted-lane node → receives CID + passphrase.
3. A's agent resolves agentB.eth → ERC-8004 identity → TEE public key → encrypts the passphrase with it → uploads the encrypted passphrase as a second CID.
4. A registers both CIDs under an ENS name (or communicates them directly).
5. B's agent fetches both CIDs, decrypts the passphrase with its TEE private key, decrypts the data.

ENS relevance: the agent's ENS name is both the address you send to and the binding to its identity, agentB.eth resolves (via ENSIP-25) to the ERC-8004 identity and key that secure the hand-off, and the dropped data lives under an ENS name B can fetch, verify, and decrypt. ENS is the addressing layer for agent-to-agent secure exchange, end to end.

A3. Expanding the NodeRegistry: hosting registry → capability registry

Today the NodeRegistry answers "is this a legitimate WebHash node?" Capability flags (public_lane, encrypted_lane, ephemeral) make it answer "what can this node do, and who can use it?" An agent querying "which nodes have encrypted_lane?" gets a discoverable list of on-chain-verified endpoints. The NodeRegistry becomes the trust layer for content delivery: agent publishes → CID on-chain → ENS resolves → any registry node can serve it, verifiably end-to-end.

A4. Three-tier upload authorization

Checked in sequence, proved via EIP-712 signed message (no gas for uploaders):

1. NodeRegistry reciprocity, uploader runs a registered hash-node → automatic access to any other node's encrypted lane. Self-governing network effect.
2. ERC-8004 agent identity, registered trustless agent → on-chain identity is authorization. Agents are first-class. Aligns with ENSIP-25.
3. Bearer token fallback, one-time token for use outside the ecosystem; backwards compatible. If chain RPC is unavailable, falls back to bearer tokens, and since those are one-time and consumed on first use, the fallback window is not a meaningful risk.

ENS relevance: the agent identity in tier 2 (ERC-8004) is the same identity bound bidirectionally to the agent's ENS name under ENSIP-25, so when an agent's on-chain identity authorizes an upload, its ENS name is effectively what's being authorized. Authorization and the agent's ENS name resolve to one another.

A5. ENSv2 detail

ENSv2 replaces the single global registry with hierarchical linked registries; each label (agent1.alice.eth) lives in its own registry. Resolution traverses root → .eth → alice's registry → agent's registry. A parent can grant a child genuine independent authority, its own resolver, token representation, subregistry:

research.alice.eth   → resolver → WebHash-published research output
writer.alice.eth     → resolver → WebHash-published content
storage.alice.eth    → resolver → WebHash-pinned encrypted storage

ENSv2 explicitly enables "naming systems within ENS rather than around it." WebHash can operate as a subregistry inside the ENS tree, handling content publishing natively. Note the fuse-based → role-based access-control shift, which changes the trust guarantees around subname permanence and operator control.

A6. Hash-nodes as distributed ENS gateway nodes

This is an enhancement to infrastructure WebHash has already built, not a new dependency. WebHash already operates a hash-node network that pins content (each node runs Kubo). eth.limo has published its gateway as a self-hostable Docker Compose stack with functional parity to production eth.limo (IPFS Rainbow, Wayfinder Router, Bee/Swarm, limo dweb-proxy-api). Adding that stack as an optional sidecar lets each operator run their own ENS gateway on the same machine, so a node that today only pins content can also resolve any ENS name → content locally:

agent publishes content → WebHash registers CID on-chain → ENS name updated
limo gateway on same node → resolves ENS name → routes to IPFS content on same Kubo instance

The effect complements the existing network: operators gain resolution sovereignty (they serve ENS names themselves rather than depending on the central eth.limo endpoint), and the pinning network becomes a distributed ENS gateway network, publish, register, and resolve on the same infrastructure. Because the eth.limo stack is ENS-approved and self-hostable, this extends approved infrastructure and decentralizes resolution rather than forking it.

A7. Verifiable artifact distribution

Any CLI tool, script, or library distributed via WebHash gets tamper-resistant provenance for free:

developer publishes artifact → WebHash pins to IPFS → CID registered on-chain
ENS subname (e.g. cli.tool.eth) → resolves to current CID
user downloads → hashes file → compares against resolved CID → verified

Updating the ENS record on each release is the release step, the record is the attestation. Extends WebHash's security guarantee from websites to the software supply chain.

A8. JS encryption library: composable primitive

• encrypt(file), pure browser-side crypto, AES-256-GCM, PBKDF2-derived key. Returns encrypted bytes + passphrase. No network, no node required.
• encryptAndUpload(file, endpoint), thin layer that uploads the encrypted bytes to an encrypted-lane WebHash node, returns a CID.

Crypto is independent of transport: dApps not running nodes still use WebHash's encryption standard; integrated dApps get the full encrypt → pin → ENS-addressable CID flow. The library ships as a WebHash artifact at a verifiable CID, demonstrating the platform's own supply-chain guarantee.

ENS relevance: once pinned, the encrypted output is an ENS-addressable CID, it can be published under an ENS name or subname so the data is resolvable and shareable by name, not just a raw hash.

A9. The build-around pattern: validation before native support

Developers who need the encrypted lane today build their own token-gated encryption proxy alongside whatever IPFS they run. That stopgap is itself the signal: the need is real enough that people build workarounds. WebHash funding closes the gap between "workaround" and "standard infrastructure", and those developers are ready to migrate the moment it ships.

ENS relevance: those workarounds give developers encrypted IPFS storage but no ENS-addressability and no ENS/ERC-8004 identity integration, which is precisely the gap WebHash closes. What turns a stopgap into standard infrastructure here is the ENS-native layer: content addressed by ENS names and tied to ENS-bound agent identity.