How modules work

The chain of trust

Resolving yoursite.quai walks three small hops. Each one is verified against the next.

• Name → anchor. The name hashes to a nameHash, which resolves through the QNSAnchorRegistry to a 96-byte anchor — the first trusted pointer. It carries a version, chain ID, module address, topology, and the expected manifest hash. Nothing else.
• Anchor → module. The anchor names a module contract. The loader reads its topology and manifest and checks they match what the anchor promised.
• Module → renderer. The manifest declares a renderer and a topology. The loader runs the matching built-in renderer to draw the page from on-chain data.

The manifest

Every module returns a moduleManifest() — ABI-encoded bytes whose keccak256 must equal the anchor’s manifestHash. The manifest declares the title, default route, renderer, a permission policy, a resource budget, and the topology-specific data. The loader refuses to render if any hash fails to match.

What the loader does

A wallet (natively, via Pelagus) or a gateway runs the same deterministic steps:

• Parse the entry into a name or a direct module address, keeping the route path and query.
• Resolve the anchor, decode it, and confirm the version, chain, and topology are supported.
• Read the module’s manifest and verify its hash, then verify every file or payload hash before display.
• Render with bundled, known-safe renderer code — never code returned by the contract.
• Fail closed: unknown topology, unknown renderer, or a bad hash means nothing is shown.

Topologies

A topology is the rendering model a module declares. v1 ships static sites and redirects; the rest are reserved in the spec so future modules boot through the same anchor and manifest path.

Try it