How a Client Reaches a Node

A client asks for a write in one of four ways. They differ in three things: what the client must hold, who authorizes the write, and who can read the request on its way in. The first two are protocol questions, answered in delegated authorship and TEE authorship. The third is about transport, and it is where sealed transport comes in.

	1. Own node	2. Relay	3. TEE relay, sealed	4. TEE authority
client holds	a node (or an account on one)	one device key	one device key	nothing; the TEE writes itself
who runs the method	the client’s node	the relay	the relay, inside its TD	the TEE, from its own scheduler
who authorizes the write	the node’s own member key	the author’s warrant	the author’s warrant	the namespace’s TEE admission and authoring policies
author_id on the delta	the node’s member	the author	the author	TEE_AUTHORITY
who can read the arguments	the node	the relay host, and whatever ends TLS	only the attested TD	only the TD
what the client checks	its own node	the relay’s descriptor	the relay’s quote, in the page	—

Peers never trust the relay in 2 or 3: they re-verify the warrant and authorize the write as the author. What a TEE relay adds is confidentiality: who can read the request, not whose it is.

1. The client’s own node

The baseline. The client holds a session on a node that runs the application, holds the scope key and is a member of the group. It asks; the node writes as itself.

▶ Replay

See the write path for what happens inside the node.

2. Through a relay: delegated execution

A browser tab or a phone holds one signing key: no node, no scope key, no application. It cannot run the method or decrypt the state, so a relay runs it on its behalf, and the author’s consent travels with the write as a signed warrant.

▶ Replay

• The directory is the cloud (MDMA) on hosted deployments; it only says which relay to use. The intent goes straight to the relay, never through the directory.
• The relay authenticates nothing about the caller except the warrant. On a node with --delegated-access, GET/POST .../intents need no session: the warrant is the credential. The exact contract is in the delegated-execution client guide.
• The relay can read the method and its arguments, and decide when (or whether) to publish. It cannot forge a write, change one, or replay a warrant: peers check all of that themselves.

3. Through a TEE relay, sealed end to end

The protocol is path 2, unchanged. What changes is who can read the request. A hosted relay runs merod inside a TDX trust domain (TD), but TLS ends at the host’s ingress, outside the TD. There the warrant and the arguments are plaintext. Sealing moves the end of the encryption into the TD:

▶ Replay

• The client verifies the relay itself. It checks the quote in the page against Intel’s collateral (which the node serves with the quote and cannot forge) and against the measurements of the release it trusts: MRTD and RTMR1–3 together, since on GCP the MRTD alone is the platform’s firmware, shared by every image. On path 2, the only assurance about a hosted relay is that the cloud checked it at registration.
• Only the TD reads the intent. The ingress, the host and anything else in the path see opaque POSTs. The session keys come from ephemeral keys on both sides, so a session’s traffic cannot be opened after it ends, even with the transport key.
• The warrant still carries the authority. Sealing hides the request; it does not replace the warrant, and peers verify exactly what they verify on path 2.

In mero-js, pass a verifier to connectCloud({ seal }), or give a RelayClient a createAttestedSealedFetch (sealed transport guide).

What can be sealed, and where

The node opens an envelope and routes the request inside it like a direct one. Whether that request then meets an auth check depends on who does the checking:

Node’s auth mode	Who checks requests	Reachable through a sealed request
embedded	merod itself	everything: login, admin API, JSON-RPC, SSE, intents
proxy (hosted TEE nodes)	the proxy in front of merod	only what merod serves without a credential: .../intents (with delegated_access), /admin-api/health, /admin-api/ready, /admin-api/is-authed, and the public TEE routes

In proxy mode, the proxy sees only POST /sealed/v2, never the route inside. If an opened request could reach a route the proxy guards, the envelope would be a way around the guard. So merod refuses such a request inside the envelope with 403 and code sealed_route_unguarded. The route is not executed and nothing is published.

For a client of a hosted TEE relay this means:

• Intents are sealed. That is the write path, and the part carrying the arguments.
• Reads (POST .../query) and login are not. They need a session, which the proxy and mero-auth check outside the TD. A client that needs its reads confidential too should read from a node it trusts, or from a node running embedded auth, where everything can be sealed.

4. The TEE authority: a different mechanism

Not a relay at all. A TEE can hold a namespace role of its own, TEE_AUTHORITY, and write into TeeOnly state from #[app::tee] methods its own scheduler fires. No client asks for those writes; an ordinary write call to a TEE is discarded and refused with ReadOnlyWriteRefused. Members trust the image their namespace admits (MRTD and RTMR1–3) and the authoring policy they set, not the node, and every peer verifies the TEE’s evidence offline. See TEE authorship.

The two are easy to confuse because both involve “a TEE writing”. They answer different questions:

	TEE relay (paths 2–3)	TEE authority (path 4)
whose write it is	the member’s	the TEE’s own role
authorized by	the member’s warrant	the namespace’s admission (the image) and authoring policies
what peers verify	the warrant and the relay’s grant	the TEE’s quote, collateral and policy
can open TEE-sealed state	no: a delegated run’s principal is the member	yes, in #[app::tee] methods

Where each path is documented

• Own node: the write path, auth.
• Relay: delegated authorship, the delegated-execution client contract.
• TEE relay, sealed: sealed transport, the attestation quote.
• TEE authority: TEE authorship.