Web Hosting

WebF is Cocoon's decentralized web hosting layer. It replaces the traditional model — deploy a server, configure DNS, manage TLS certificates — with a model where websites are published as torrents, registered on-chain, and served by any participating Erigon node.

A website's identity is tied to the chain, not to a hosting provider. As long as at least one node is seeding the site's torrent, the site is accessible. Operators can run their own nodes or rely on the network of existing participants.

WebF sites have built-in access to the node's JSON-RPC. A portfolio dashboard, investor portal, or compliance reporting UI can read on-chain data directly — no separate backend, no API key management, no CORS configuration.

How It Works

A WebF site is a zip file containing the site's assets and, optionally, a Cloudflare Workers-compatible entrypoint. The zip is published via torrent-ccip and registered on-chain with a human-readable name. Any node that receives a request for the site downloads the zip, extracts it, launches a workerd subprocess (Cloudflare's open-source Workers runtime), and proxies the request.

Static sites — the zip contains HTML, CSS, JS, and static assets. workerd serves them directly with no additional configuration.

Dynamic sites — the zip contains a Workers entrypoint (index.js or equivalent). workerd executes the Worker for each request, providing the full Workers API: Fetch, KV, Streams, Crypto, and Cocoon's Web3 extensions.

Request Flow

Site names are resolved by the on-chain WebF registry contract. The contract maps names to infohashes, enabling on-chain governance of name ownership — no centralized DNS registrar.

Process Cache

Launching a workerd subprocess has non-trivial startup cost. Cocoon maintains a process cache: running workerd instances are kept alive and reused for subsequent requests to the same site. An idle reaper monitors instances and terminates those that have not received a request within the configured window.

The process cache means that frequently accessed sites (e.g., a live investor portal) have near-native request latency. Infrequently accessed sites (e.g., a quarterly report page) may have a cold-start delay on the first request after an idle period.

Web3 Integration

Workers running inside workerd have in-process access to the node's JSON-RPC via a special binding. This eliminates the usual hurdles of building Web3 frontends:

• No external RPC endpoint to configure or pay for

• No CORS issues between frontend and RPC

• No rate limiting from a shared public endpoint

• RPC calls are authenticated with the same UCAN capabilities as any other node interaction

A Workers script can read token balances, query historical events, resolve identities, and trigger on-chain actions — all via the local JSON-RPC binding.

// Example: read on-chain data from within a WebF Worker
export default {
  async fetch(request, env) {
    // env.RPC is the in-process node JSON-RPC binding
    const balance = await env.RPC.call("eth_getBalance", [
      "0xInvestorAddress",
      "latest"
    ]);
    return new Response(JSON.stringify({ balance }), {
      headers: { "Content-Type": "application/json" }
    });
  }
};

HTTPS and TLS

Cocoon uses CertMagic for automatic TLS certificate provisioning and renewal. Certificates are obtained via ACME (Let's Encrypt or a configured CA) and stored encrypted in the torrent-ccip layer, enabling multiple nodes serving the same site to share certificates without each node needing its own provisioning flow.

The encryption uses the same UCAN envelope + ML-KEM key-wrapping model as other sensitive data. Only nodes with the appropriate UCAN capability can decrypt and use the shared certificate material.

Multi-Node Deployment

A single site can be served by multiple nodes simultaneously, providing redundancy and geographic distribution.

On-chain server registry — nodes that are serving a site register their endpoint in the on-chain server registry. Clients (or DNS resolvers) can query this registry to find all active servers for a site.

DNS resolution — the WebF DNS module integrates with DNS infrastructure, enabling standard domain names to resolve to the set of nodes currently serving a site. The DNS response is derived from the on-chain registry, so it updates automatically as nodes join or leave.

Heartbeat liveness — registered servers must post periodic heartbeats to the on-chain registry. Nodes that miss heartbeats are removed from the active server list, ensuring DNS responses only point to live nodes.

Multi-node deployments require all serving nodes to have access to the site's torrent. If the site is encrypted, all nodes must also have the appropriate decryption keys configured in their keystores. Publishing a site update (new zip version) requires re-seeding and re-registering the infohash.

Use Cases

Use Case	Description
Fund portal	Investor-facing portal with live NAV, subscription/redemption flows, and on-chain document access
Investor dashboard	Personalized view of holdings, returns, and compliance status — identity resolved via DID
Compliance reporting UI	Regulatory reports generated on-demand from on-chain data, accessible to auditors via UCAN-gated URL
DAO governance interface	Proposal viewing and voting UI with direct on-chain interaction
Token documentation	Whitepaper, legal docs, and fund terms linked to the token contract and served permanently

Key APIs

Method	Description
erigon_publishWebSite	Publish a site zip via torrent-ccip and register it on-chain under a given name
erigon_getWebSite	Retrieve the registration record (infohash, metadata, server list) for a site name
erigon_listWebSites	List all sites registered by a given address or visible to the caller

// erigon_publishWebSite example
{
  "method": "erigon_publishWebSite",
  "params": {
    "name": "fund-portal",
    "zipPath": "/path/to/site.zip",
    "encrypt": false,
    "capabilities": ["/webf/fund-portal/*"],
    "ttl": 0
  }
}

After publishing, the site is immediately accessible at /webf/fund-portal/ on any node that has downloaded the torrent, and at the configured domain name once DNS propagation completes.