# Remote Attestation and State Commitments

#### **4.7.1 The Purpose of Remote Attestation in NSF**

In decentralized governance, execution must occur on infrastructure:

* **Not physically controlled** by stakeholders
* Running in **heterogeneous jurisdictions**
* Performing **policy-critical actions**

NSF uses **Remote Attestation** to ensure that clause execution environments:

* Are cryptographically identifiable
* Can be independently verified as secure
* Operate only under certified configurations
* Bind their output to verifiable **state commitments**

This creates a **distributed but trust-verifiable execution substrate** for smart governance.

***

#### **4.7.2 What Is Remote Attestation?**

Remote attestation allows a node (e.g., a TEE or secure runtime) to generate a **cryptographically signed proof** of:

* The software and configuration it is running
* The hardware identity and trust root
* The active execution scope (clause, DAO, jurisdiction)
* The code measurement (hash of clause logic)
* The runtime state at launch

This is verifiable **remotely by any validator, auditor, or DAO**—establishing **provable trust before execution begins**.

***

#### **4.7.3 NSF Remote Attestation Lifecycle**

1. A node starts an enclave or secure runtime
2. It generates a **measurement report** (e.g., SGX quote, SEV evidence, Enarx attestation)
3. The enclave signs:
   * Clause ID
   * Governance scope
   * Input hash
   * Runtime hash
   * Node identity
4. The attestation is sent to the **NSF Attestation Registry**
5. Verified parties can:
   * Confirm execution validity
   * Accept or reject CACs
   * Audit execution trust boundaries

***

#### **4.7.4 Required Fields in Attestation Statements**

NSF-compliant attestations must include:

```json
{
  "runtime_type": "TEE",
  "enclave_type": "SGX",
  "measurement_hash": "0xabc123...",
  "runtime_hash": "0xdef456...",
  "signer_did": "did:nsf:TEEExecutor#node27",
  "jurisdiction": "ZAF",
  "dao_scope": "AgriReliefDAO",
  "execution_policy": "static",
  "timestamp": "2025-04-30T18:32Z",
  "signature": "0xDEADBEEF..."
}
```

These are included in:

* CAC metadata
* TEE registration proofs
* Rollup signing
* Credential issuance justification (VC `evidence` fields)

***

#### **4.7.5 Verification of Attestation Statements**

Validators, DAOs, and downstream systems verify:

* **Runtime hashes** match approved clause interpreters
* **Measurement hashes** are whitelisted by NSF Governance Registry
* **Signer DIDs** are linked to approved enclave operators
* **DAO scope** matches clause permissions
* **Timestamp** falls within acceptable execution window

If any component is invalid, **CAC output is rejected or disputed**.

***

#### **4.7.6 Anchoring Attestation and CAC State Commitments**

Each enclave’s state is represented as:

```json
state_commitment = hash(runtime_state + inputs + clause_hash + DAO + jurisdiction)
```

This is:

* Signed by the enclave
* Optionally:
  * Aggregated with other CACs into a **Rollup root**
  * Anchored on-chain (e.g., Ethereum, Filecoin, sovereign chain)
  * Published to treaty or UN governance channels

This guarantees **the execution occurred as claimed**, under a **publicly verifiable state lineage.**

***

#### **4.7.7 Aggregated Attestations and Multisig Signatures**

For mission-critical or cross-border clauses:

* **Multiple enclave nodes** may execute the same clause
* All attestations are collected and compared
* A threshold (e.g., ⅔ majority) is used to approve execution
* A **multisignature aggregate** is added to CAC or Rollup

This ensures:

* Higher execution fidelity
* Censorship resistance
* Hardware diversity
* Cross-jurisdictional trust validation

***

#### **4.7.8 Attestation Slashing and Revocation**

If a node:

* Produces invalid attestations
* Violates jurisdictional governance rules
* Runs compromised runtime environments
* Is found to forge CACs

It can be:

* **Slashed** from NSF validator sets
* **Revoked** via TEERevocationVC
* Blocklisted from the Registry Layer
* Publicly reported through **governance audit dashboards**

Attestation accountability is baked into NSF’s fault-resilient trust model.

***

#### **4.7.9 Audit Layer Integration**

All verified attestations are:

* Logged in the Audit Layer
* Linked to CACs, VCs, and DAO decisions
* Queryable by:
  * Clause ID
  * Node ID
  * Time window
  * Jurisdiction
  * Risk classification

Example query:

```json
find all attestations from nodes in jurisdiction = "IDN"  
for clauses matching "WaterSafetyClause@*"
```

***

#### **4.7.10 Remote Attestation as the Gateway to Trust**

In NSF, no execution is trusted **unless it’s attested**.

Remote attestation enables:

* Zero-trust governance
* Execution provenance
* Jurisdictional enforcement
* Public observability
* Interoperability between enclaves, validators, and DAOs

It is the **cryptographic handshake between governance intent and compute action**.

No clause runs without proving it can be trusted—first.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.therisk.global/organization/standardization/nexus-sovereignty/iv.-verifiable-execution/remote-attestation-and-state-commitments.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.