Deep Dive: How we deployed a verifiable frontend using 3DNS, Marlin Oyster CVM, and KMS
In our previous case study of verifiable decentralized frontends, we introduced how a decentralized frontend could be hosted securely with on-chain verifiability. In this follow-up, we go deeper. We’ll explain the architecture and rationale behind the deployment of frontend on Marlin Oyster TEE using three core components: 3DNS, Oyster CVM, and Nautilus KMS. We’ll also walk through the actual implementation steps that made this theoretical stack a reality.
Why this stack?
Web3 frontend infrastructure still largely relies on centralized DNS and hosting. Oyster TEE set out to change that. The stack ensures:
- Domain ownership and DNS records are managed by on-chain smart contracts, eliminating reliance on centralized registrars. All changes, including record updates and transfers, are executed through transparent and verifiable contract interactions. This ensures domain control is secure, auditable, and programmable.
- Frontend code is deployed in attested Trusted Execution Environments (TEEs), which provide a secure and isolated environment for serving user interfaces. This ensures that the code delivering the frontend is tamper-proof, cannot be altered by the host system, and is running exactly as intended. Through remote attestation, users and applications can verify that the frontend is being served from a trusted source before interacting with it.
- Only approved and attested enclave images can generate signatures using keys derived with Nautilus KMS, which are then verified onchain when updating DNS records such as CAA and A. This ensures that all DNS changes originate from verified and trusted code.
The goal: end-to-end trust minimization from DNS resolution to the final rendered page.
Components involved
3DNS
3DNS replaces traditional DNS registrars with a blockchain-based registry. When you register or transfer a domain into 3DNS, it becomes an ERC‑721 NFT owned by your wallet.
- Self-custodied domain NFT: In 3DNS, domains are represented as ERC-721 tokens, granting direct ownership to the holder’s wallet. Transferring the token updates domain ownership on-chain, granting the recipient immediate authority over DNS management, subdomain assignments, and marketplace listings. This removes reliance on centralized registrars and avoids the inconsistencies typical of traditional domain transfers.
- On-chain records and access control: All DNS records are stored on-chain and governed by strict access controls enforced through smart contracts. Only authorized keys can modify records, ensuring resistance to unauthorized changes or administrative compromise. This provides transparent, verifiable governance over domain resolution and certificate authority permissions.
3DNS thus decentralizes the domain layer. Users can verify records directly from the chain, and a smart contract admin can programmatically decide where the frontend should point. For example, the DAO could vote on switching to a new server image, then update the on-chain DNS records in one atomic transaction.
Domain Manager Contracts
To support decentralized websites on Oyster, the Domain Manager Contracts provide a smart contract system for managing domains and DNS records on Optimism. The contracts offer a secure, permissioned framework for transferring domain ownership, delegating management, and updating DNS records using cryptographic signatures from Marlin KMS (Key Management System). This design ensures that DNS updates are both verifiable and tamper-proof directly on-chain.
At the core is the DomainManager contract, which works alongside interfaces for domain control and DNS resolution. Domain owners can assign managers, register KMS keys, and securely authorize record changes - enabling flexible, decentralized control without compromising security or ownership.
Oyster CVM
With 3DNS ensuring onchain DNS management, Oyster CVM provides the decentralized hosting and runtime. Oyster leverages Trusted Execution Environments (TEEs) to guarantee “code is law” for your frontend. The deployment flow is conceptually simple: you take your web app code (e.g. a React or Node.js app), package it into a Docker image, and deploy it to Marlin’s network.
Key properties of Oyster TEEs:
- Integrity: Code inside a TEE cannot be tampered with by the hosting machine. Oyster uses attestations so that anyone (or even a smart contract) can verify that a running service is executing exactly the intended code. In practice, this means the enclave image’s hash is known (e.g. the DAO publishes the “authorized image hash” on-chain), and each node provides a signed attestation of its PCRs (code measurements). Only if the attestation matches the approved hash is the node allowed to proceed. In other words, if someone tries to run modified code (say a phishing version of the frontend), the attestation will fail and that node will not be trusted.
- Confidentiality: All secrets inside the TEE (TLS keys, database credentials, etc.) stay hidden from the host OS. This lets Oyster safely generate and store long-term secrets inside the enclave. For example, an enclave can create an ACME account inside itself so that TLS private keys never leave the TEE. This isolation guarantees that even a malicious host cannot extract these keys, preventing hijacking or key exfiltration.
In summary, Oyster gives your frontend a verifiable, censorship‑resistant runtime. Users connecting to your domain will hit an Oyster node.
Nautilus KMS
Running trust-minimized frontends requires secure domain control, attested compute, and safe key management within enclaves. Marlin’s Nautilus KMS provides enclave-bound secrets without exposing them to the host, using attestation to tie them to the enclave’s identity. Since Oyster enclaves are ephemeral, Nautilus derives keys from a master seed on demand, ensuring secrets persist across restarts and remain secure.
Key features of Nautilus KMS:
- Enclave authentication: Nautilus verifies enclave identity via remote attestation before releasing secrets. It supports two modes:
- Image-bound: Secrets are tied to a specific enclave image; changing the code changes the secrets.
- Contract-bound: A smart contract defines trusted images, allowing upgrades while retaining the same secrets. This enables DAOs to manage update policies.
- Secure key derivation: A creator enclave generates a root seed encrypted via threshold encryption. The KMS root enclave, attested against an on-chain allowlist, holds the encrypted seed and derives sub-keys on request.
- Client-derived secrets: Application enclaves securely contact the KMS root, prove their identity, and receive enclave-specific secrets. These secrets are never exposed to the host and can be re-derived after restarts.
In short, Nautilus KMS ensures persistent, verifiable secrets for your enclave frontends. It preserves all the TEE guarantees (hosts can’t snoop keys) while allowing the network to reboot or scale enclaves without breaking access. The contract-bound mode especially ties secrets to on-chain governance, so the DAO can approve an upgrade by signing off on a new enclave image in the contract, and Nautilus will then permit that image to use the same persistent keys. This makes rolling out front-end updates both safe and auditable.
How we actually did it
The diagram above shows how the core components (3DNS, Domain Manager Contract, Oyster CVM, and Nautilus KMS) work together to enable verifiable frontend hosting.
Domain Governance with the Domain Manager Contract
The process began with acquiring a domain through 3DNS, where each domain name is represented as an ERC-721 NFT. Instead of retaining the domain in a user-owned wallet, we transferred it to a smart contract called the Domain Manager, which enables structured, role-based governance through on-chain access controls.
To manage domain metadata efficiently, we delegated WHOIS update permissions to a specific address. This allowed for easier updates while maintaining secure and controlled ownership.
Verifiable Deployment with Oyster and KMS
With the domain governance infrastructure in place, the next objective was to deploy the frontend securely using Oyster. To enable secure interactions between the deployed enclave and the blockchain, we made use of Nautilus KMS, which serves as a confidential key provisioning system for enclaves.
First, we deployed a KMS Verifier Contract. This contract is responsible for maintaining a list of approved enclave configurations. Each configuration is uniquely identified by a cryptographic hash, referred to as the image ID, which is deterministically computed from a Docker Compose setup. Once computed, the image ID was approved on-chain via the verifier contract, effectively whitelisting only those enclave instances that run this verified configuration.
This ensures that only enclave deployments running the approved configuration are able to derive secrets from the KMS - a foundational requirement for secure DNS signing, and identity binding.
Binding Domain to a Specific Enclave
Once the enclave infrastructure was verified, the next task was to bind it to the domain in a secure and verifiable manner.
This was done in two steps:
-
Set the KMS Contract for the Domain
The domain was linked to the verifier contract by calling a function in the Domain Manager to associate the KMS verifier with the domain ID. This action defined the source of truth for enclave validation. -
Set the KMS Signer for the Domain
After the enclave instance was deployed using the approved Docker image, it contacted Nautilus KMS to request its KMS signer identity. The KMS returned a signed proof, indicating that the request came from an attested enclave running an approved configuration. This signature was verified on-chain using EIP-712 signature recovery, and the signer address was registered on-chain.
These steps securely linked the domain to a specific enclave instance, ensuring that only this instance could perform sensitive operations like DNS updates.
Updating the DNS Records: A and CAA
With the enclave deployed and cryptographically tied to the domain, we moved on to configure DNS records. The Domain Manager contract was used to update the DNSResolver with attested records, signed by the enclave’s KMS key.
We configured two critical types of records:
- A Records: These map the domain name to the IP address of the enclave instance.
- CAA Records: These restrictions limit TLS certificate issuance to a specific Let’s Encrypt account. This account, known as the ACME account, is generated within the Oyster enclave.
ACME and CAA Integration
The Automatic Certificate Management Environment (ACME) is a protocol used by CAs like Let’s Encrypt to automate SSL certificate issuance. In our system, the enclave generates a secure ACME keypair internally and uses it to request certificates from Let’s Encrypt. To restrict issuance, we published CAA records specifying exactly which ACME account is authorized.
Example CAA records included:
0 issue "letsencrypt.org; accounturi=https://acme-staging-v02.api.letsencrypt.org/acme/acct/<ACME_ACCOUNT_ID>"
0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/<ACME_ACCOUNT_ID>"
These records ensure that only enclaves running the approved configuration - and holding the correct internal ACME account - can obtain TLS certificates for the domain.
All DNS records are submitted along with an EIP-712-compliant signature generated by the Oyster enclave. This signature ensures that all updates originate from a trusted and authorized source. Upon receiving a record update, the Domain Manager contract verifies the signature against the domain’s registered KMS signer. Only if this verification succeeds are the DNS records accepted and written to the blockchain, ensuring integrity and preventing unauthorized modifications.
For SSL certificate issuance, we integrated the Caddy web server, which automatically interacts with Let’s Encrypt via the ACME protocol. Since the required DNS A and CAA records were already published on-chain and had propagated through the DNS network, Caddy was able to complete the ACME challenge without manual intervention.
After a brief wait for DNS propagation, we were able to access our website securely through the linked domain, confirming that both DNS resolution and TLS certificate issuance were working as expected.
The complete process is illustrated in the following flowchart, which summarizes the key steps involved in our deployment workflow.
Conclusion
Deploying a verifiable frontend with 3DNS, Oyster CVM, and Nautilus KMS demonstrates how on-chain governance, attested compute environments, and enclave-bound key management can reshape web3 hosting. By treating domain names as NFTs with on-chain access controls, we remove single points of failure in DNS management. Running frontend code inside TEEs ensures integrity by making sure only approved code versions can serve content. Integrating Nautilus KMS ties secret derivation to enclave identity and on-chain policy, enabling secure, persistent credentials without exposing them to the host.
The implementation steps show that this architecture is more than theory: registering a domain as an ERC-721 NFT, whitelisting enclave images via a verifier contract, binding the enclave instance to the domain through KMS signatures, and updating A and CAA records with attested signatures together create a pipeline of trust minimization. Automating ACME certificate issuance inside the enclave and verifying DNS updates on-chain completes the loop, so users can reach the site over HTTPS with confidence in every layer of the stack.