Architecture

An AttestMesh deployment has four components. One lives on chain; three run off chain. The chain is the single source of truth — every off-chain component can be rebuilt from chain state plus its own attested keys.

                          ┌────────────────────────────┐
                          │       EVM chain (Base)     │
                          │                            │
                          │  ClusterDiamond (ERC-2535) │
                          │   ├─ AttestFacet           │
                          │   ├─ MessageFacet          │
                          │   ├─ NetworkFacet          │
                          │   └─ DstackFacet (attestor)│
                          │  ClusterMember (per node)  │
                          │  IndexerRegistry           │
                          └─────┬──────────┬───────────┘
            sponsored UserOps   │          │   reads + getLogs
          ┌─────────────────────┘          └──────────────────┐
          │                                                   │
   ┌──────┴───────┐    wireguard mesh (gateway TCP)    ┌──────┴───────┐
   │  Node 1      │◄════════════════════════════════►  │  Node 2      │
   │  sidecar +   │                                    │  sidecar +   │
   │  app (CVM)   │       signed, attested pushes      │  app (CVM)   │
   └──────┬───────┘    ┌────────────────────────┐      └──────┬───────┘
          └───────────►│  Indexer (attested CVM)│◄────────────┘
                       └────────────────────────┘
   ┌──────────────────────────────────────────────────────────┐
   │  Gas-sponsorship webhook (Cloudflare Worker)             │
   │  gates the EIP-4337 paymaster for every node UserOp      │
   └──────────────────────────────────────────────────────────┘

The cluster contract (ClusterDiamond)

An ERC-2535 diamond — one address whose behavior is composed from facets:

• Core facets (attestation-method-agnostic, always installed):
  • AttestFacet — the canonical member registry. Member records hold the attestation method id, the member’s contract address, its x25519 and wireguard public keys, and registration time. Derives each member’s mesh IP deterministically from its member id.
  • MessageFacet — encrypted member-to-member messaging. send is gated by membership; payloads are sealed-box ciphertexts carried in MessageSent events with the sender’s member id authenticated on chain.
  • NetworkFacet — wireguard key publication and rotation.
• Attestor facets (one per attestation method, installed by diamondCut):
  • DstackFacet (v1) — verifies the dstack KMS signature chain and admits members. It also implements dstack’s IAppAuth, so the same contract acts as the boot-authorization gate for the dstack KMS: a CVM whose compose hash isn’t allowlisted never receives its keys.

The hard rule: only an attestor facet knows its method’s details. The core never sees a quote, a signature chain, or anything TDX-specific — which is what makes future attestor facets (raw TDX, SEV-SNP, NVIDIA CC, non-TEE methods) additive.

ClusterMember — the node’s on-chain identity

Each node is represented by a ClusterMember contract that combines two roles on one address:

• a dstack-style app proxy, so dstack tooling and the KMS recognize the node, and
• an EIP-4337 smart account, so the node transacts gaslessly.

On dstack’s base KMS the member contract is the CVM’s provisioned app id: the operator deploys a stock dstack app, then upgrades it in place to the ClusterMember implementation (“Path A”). The node’s owner key — recovered from the attestation proof at registration — is installed on chain by the registration call itself, so the account bootstraps from owner = 0 in a single sponsored operation.

The sidecar

A Rust agent (cluster-mesh-agent) inside every node. On boot it:

1. Derives its keys from the attestation-bound seed (dstack KMS /GetKey).
2. Self-discovers its member contract from the CVM’s identity, finds its cluster.
3. Builds the attestation proof and self-registers via a sponsored UserOperation.
4. Brings up the mesh: enumerates peers from chain, configures wireguard over the gateway TCP transport, exchanges encrypted endpoint envelopes via MessageFacet, runs signed heartbeats.
5. Acquires the Cluster Shared Key (originates it, re-derives it, or pulls it from a live peer).
6. Subscribes to the Indexer for low-latency event pushes, with direct RPC log polling as the always-on fallback.
7. Serves the application a gRPC API (unix socket): mesh status, peer events, encrypted send/receive, and the CSK — gated on cluster health.

The node reports healthy only when the mesh has converged (every live member sees every other) and the CSK is held.

The Indexer

A single shared, attested service — one instance serves every cluster on the chains it watches (never one per cluster). It follows the chain, classifies cluster events, and pushes them to subscribed members with three layers of verifiability:

• an Ed25519 signature over every push (key derived in-TEE, registered on chain),
• a TEE attestation quote binding that key to the indexer’s code identity, and
• an RPC repro stub so any member can re-fetch the event from its own RPC.

Members trust the Indexer for liveness only. Correctness is independently verifiable per event, and the sidecar keeps polling chain logs regardless.

The gas-sponsorship webhook

A Cloudflare Worker that gates the EIP-4337 paymaster. Every sponsorship request is checked for provenance: the UserOperation must be a ClusterMember.execute call into a known cluster, with an inner selector on the operator’s allowlist (registration, messaging, CSK commitment, and cluster admin operations). Nodes hold zero ETH from first boot.