Security model

AttestMesh is built around a small number of explicit trust statements. Everything not listed here is meant to be verified, not trusted.

Roots of trust

Root	Used for
The chain (Base mainnet in v1)	Membership, attestation policy, public keys, mesh addressing, message ordering. If the chain says it, every node believes it.
The TEE + its KMS (dstack/Intel TDX in v1)	Key derivation and code identity. A node’s keys exist only inside an attested CVM running an allowlisted compose.
The cluster owner	Governs the allowlists: which compose hashes boot, which app ids may join, which KMS roots are accepted. Also owns the IndexerRegistry record and the sponsorship policy.

What is verified, not trusted

• Member admission. Registration carries a dstack KMS signature chain; the attestor facet verifies it on chain before a member record exists. A node cannot join by assertion.
• Peer identity in the mesh. Wireguard peer keys come from chain state, never from the network. A tunnel either authenticates to the on-chain key or it doesn’t come up. The TCP/TLS leg used for transport through the dstack gateway is routing, not security — its certificates are deliberately not relied upon.
• Heartbeats. Signed with the sender’s Ed25519 key, which travels inside an encrypted envelope whose sender is authenticated by the chain.
• The Cluster Shared Key. Whoever serves it, the receiver verifies keccak256(CSK) against the one-time on-chain commitment. A malicious peer cannot hand over a bogus key.
• Indexer pushes. Ed25519-signed (key registered on chain, derived in-TEE, bound by attestation quote) and carrying an RPC repro stub. The sidecar treats a verified push as a wake-up and re-reads chain state — pushed payloads are never the source of truth.

What stays secret

• Private keys never leave the CVM. They are derived from the TEE seed at boot, deterministic per app identity, and survive restarts by re-derivation.
• The CSK plaintext never touches the chain or the operator. It moves only peer-to-peer over the authenticated mesh, sealed to the requester’s on-chain x25519 key.
• Message payloads on chain are sealed-box ciphertexts. The project rule is absolute: no plaintext member-to-member payloads on chain, ever.

Known boundaries (v1)

Honest limits worth knowing:

• The dstack gateway is a traffic path. Mesh bootstrap rides TCP through it. It can drop or delay traffic (availability), but cannot read or forge it (wireguard) — and the pure-UDP upgrade path removes even the availability dependency later.
• The Indexer is liveness-critical for low latency, not for correctness. If it lies by omission, the sidecar’s chain polling still converges.
• The cluster owner is privileged. It curates allowlists and the registry. A malicious owner can admit bad code identities going forward; it cannot read existing traffic or extract keys.
• Sponsorship is a policy gate, not a security boundary. The webhook controls who spends the operator’s gas; on-chain access control stands on its own.
• One attestation method ships in v1. The isolation discipline (method details confined to the attestor facet and its sidecar provider) is what keeps the next methods honest.