Protocol Overview

Introduction

NexArt is a protocol for producing verifiable execution records. It allows any system to create a Certified Execution Record (CER), have it attested by a node, and allow independent verification of the result.

The protocol separates three concerns:

• Execution. A system performs an operation and records what happened.
• Attestation. An independent node signs the record to prove it existed at a specific time.
• Verification. Anyone can check the record's integrity and the node's signature.

The Execution → Attestation → Verification Flow

Execution

An AI or deterministic system performs an operation. The system records inputs, outputs, and relevant metadata.

CER Creation

A Certified Execution Record (CER) bundle is created with bundleType: "cer.ai.execution.v1". The bundle contains execution metadata and hashes of inputs and outputs. It follows a deterministic structure so that the same data always produces the same hash.

certificateHash

A SHA-256 hash of a strict whitelist projection of the CER bundle, canonicalized per the profile bound to protocolVersion (1.2.0 → nexart-v1, default; 1.3.0 → jcs-v1 / RFC 8785, opt-in). It is computed ONLY over bundleType, version, createdAt, snapshot, and (if present) context, contextSummary, and policyEvaluation. certificateHash, meta, declaration, verificationEnvelope, verificationEnvelopeSignature, receipt, and any unknown fields are NOT hashed. Verifiers MUST apply the whitelist projection to the bundle exactly as received and use the canonicalization profile corresponding to the bundle's protocolVersion.

Attestation

The CER (or its certificateHash alone) is sent to an attestation node. The node timestamps the record and signs it using Ed25519. This creates a binding between the node's identity, the timestamp, and the record.

Signed Receipt

The node returns a signed receipt stored at meta.attestation in the CER bundle. The receipt contains the certificateHash, timestamp, nodeId, and kid (the signing key identifier).

Verification

Anyone can verify the record by checking three things: bundle integrity, node signature, and receipt consistency. Verification can be performed locally using the SDK or through verify.nexart.io. The node is not required for verification. Integrity is proven by the hashes alone.

Core Components

Certified Execution Record (CER)

A structured record that captures execution metadata and hashes of inputs and outputs. The CER is the base unit of proof in NexArt. It is portable, self-contained, and deterministic.

Attestation Node

An independent witness that signs CERs and produces receipts. The node does not define truth or control verification. Nodes publish their public keys at node.nexart.io/.well-known/nexart-node.json using kid and activeKid fields so verifiers can independently retrieve them.

Signed Receipt

A cryptographic proof returned by the node. It proves that the node witnessed the certificateHash at a specific time. The receipt does not imply the node stores or owns the execution data.

Verification

Verification confirms that the CER has not been modified and that the receipt signature is valid. Verification statuses are VERIFIED, FAILED, or NOT_FOUND. Each check returns PASS, FAIL, or SKIPPED.

Record Types

NexArt supports several record types depending on the attestation scope and export path:

• cer.ai.execution.v1. AI execution record. Fully verifiable when attested with a signed receipt.
• signed-redacted-reseal. A redacted version of a CER that has been re-signed by the node for safe sharing.
• hash-only-timestamp. Attestation of only the certificateHash. Snapshot contents are not attested.
• legacy. Older records from previous system versions. May lack full attestation data.

Public Surfaces

• verify.nexart.io is the public verification portal for CERs and Project Bundles.
• node.nexart.io is the attestation node identity and status surface.
• node.nexart.io/.well-known/nexart-node.json publishes the node's signing keys for independent signature verification.

Why This Matters

AI systems increasingly make decisions autonomously. Organizations need to prove what happened, when, and that the record has not been altered. CERs provide a portable, cryptographic record of execution that supports:

• Auditing
• Compliance
• Reproducibility
• Independent verification

Because verification is independent of the original system, any third party can confirm the integrity of a record without trusting the system that produced it.