Trust Model

How Trust Works

NexArt establishes execution integrity through three mechanisms:

1. Deterministic hashing. Every CER bundle produces a unique certificateHash (SHA-256). Any change to the record changes the hash.
2. Node attestation. An attestation node signs the certificateHash using Ed25519, producing a receipt stored at meta.attestation in the CER bundle.
3. Independent verification. Anyone can verify the record using the CER bundle and the node's published public keys. No API access is required.

Operational Guarantees

NexArt nodes enforce strict operational guarantees when certifying execution records:

1. Deterministic identity.
   • The same execution produces the same certificateHash.
   • Hash computation is defined by the SDK and never modified by the node.
2. Idempotent certification.
   • One execution_id maps to one certificateHash forever.
   • Re-submission with identical content returns the original record.
   • Mutated re-submissions are rejected with EXECUTION_MUTATION_DETECTED.
3. Controlled attestation.
   • Only authorized API keys can request certification.
   • Administrative operations (such as recertification) require elevated credentials.
4. Independent verification.
   • Verification logic is delegated to the SDK.
   • The node does not reinterpret or override verification outcomes.
5. Immutable attestation.
   • Once certified, a record cannot be altered without invalidating its certificateHash.

Certification Flow

Here is what happens when you call POST /v1/cer/ai/certify:

1. Your application sends execution data to the NexArt API
2. NexArt creates a CER bundle (bundleType: "cer.ai.execution.v1")
   and computes the certificateHash (SHA-256)
3. The attestation node signs the certificateHash → produces a receipt
4. The API returns:
   - certificateHash
   - receipt (with timestamp, nodeId, kid)
   - signatureB64Url
   - verificationUrl
5. Anyone can verify the record at the verificationUrl or independently

In the CER bundle, the receipt and signature are stored at meta.attestation. The API response duplicates them at the top level for convenience.

Node Attestation

The attestation node is an independent witness. It does not define truth or control verification. When it signs a CER, it produces a receipt that proves:

• The node witnessed the CER bundle at a specific time
• The certificateHash was computed from the bundle at that time
• The node's identity is bound to the receipt

Nodes sign using Ed25519. Their public keys are published at a well-known endpoint so anyone can verify independently:

GET node.nexart.io/.well-known/nexart-node.json

{
  "nodeId": "nexart-node-primary",
  "activeKid": "key_01HXYZ...",
  "keys": [
    {
      "kid": "key_01HXYZ...",
      "algorithm": "Ed25519",
      "publicKey": "MCowBQYDK2VwAyEA..."
    }
  ]
}

The node does not store or own the execution data. It witnesses the record and produces a cryptographic proof.

Independent Verification

Verification can be performed independently using:

• the CER bundle
• the node's published public keys

Two levels of verification exist:

1. Full verification.
   • Requires access to the complete CER bundle.
   • Allows recomputation of the certificateHash and validation of all signatures.
2. Public verification.
   • Uses a redacted representation of the bundle.
   • Confirms:
     • the node attested a specific certificateHash
     • the receipt signature is valid
   • Does not expose or allow recomputation of the original input/output data.

What Attestation Proves (and Does Not Prove)

Attestation proves that:

• The CER existed at the attested timestamp
• The record has not been modified since attestation
• A specific node witnessed and signed the record

Attestation does not prove that:

• The execution itself was correct or accurate
• The inputs or outputs were truthful
• The application behaved as intended

NexArt certifies that a record is intact and was witnessed. It does not evaluate the content of the execution.

Trust Boundaries

• NexArt does not store raw prompts or outputs. CERs contain hashes, not payloads.
• NexArt does not act as a certificate authority for user identity.
• The integrating application controls what metadata is included in the CER.
• Public verification uses a redacted representation. Sensitive data is not exposed.