Builder Certification for NexArt Protocol

What is canonical certification?

Canonical certification is the process of executing a Code Mode sketch through the NexArt canonical renderer and producing cryptographically verifiable proof of that execution. The result is not just an image. It is an auditable record that ties inputs, outputs, and execution environment together.

A certified run produces:

A deterministic PNG at canonical resolution
A snapshot file (.snapshot.json) containing all input parameters
Cryptographic hashes linking the snapshot to the output

Given the same inputs, any compliant renderer will produce byte-identical output with the same hash. This is the foundation of NexArt's reproducibility guarantee.

Determinism vs. certification

Determinism is a property of the code. A deterministic sketch, given the same seed and parameters, will always produce the same output.

Certification is proof that determinism was exercised under controlled conditions. It answers: was this output actually produced by running this code with these inputs?

Aspect	Determinism	Certification
Definition	Property of the system	Proof of a specific run
Dependency	Protocol-compliant logic	Canonical Renderer execution
Output	Repeatable result	Sealed, verifiable record
How to verify	Re-run with same inputs	Compare hashes against the record
Trust model	Trust the implementation	Verify the evidence

You can have determinism without certification (local execution). You cannot have certification without determinism.

What happens during a certified run

When a sketch is submitted to the canonical renderer:

Input validation, The renderer verifies the sketch is protocol-compliant, the seed is valid, and all parameters are within bounds.
Environment lock, Execution occurs in a controlled environment with pinned runtime versions, fixed canvas dimensions, and deterministic RNG.
Execution, The sketch runs exactly once. No retries, no branching, no external dependencies.
Output capture, The rendered canvas is exported as a PNG at canonical resolution.
Hash generation, The output is hashed. The code is hashed. Both are recorded in the snapshot.
Snapshot emission, The snapshot file is returned alongside the image, containing everything needed for future verification.

Artifacts produced

A certified run returns two artifacts:

1. Output PNG

The rendered image at canonical resolution (1950×2400 pixels). This is the visual output of the sketch.

2. Snapshot file

A JSON file containing:

{
  "protocolVersion": "1.2.0",
  "seed": "12345",
  "VAR": [50, 50, 50, 0, 0, 0, 0, 0, 0, 0],
  "codeHash": "sha256:...",
  "outputHash": "sha256:...",
  "timestamp": "2025-01-27T...",
  "rendererVersion": "1.9.0"
}

The outputHash is the cryptographic fingerprint of the PNG. The codeHash is the fingerprint of the source code. Together, they form an immutable link between input and output.

Canonical constraints

The canonical renderer enforces strict constraints to ensure reproducibility:

Fixed canvas size, 1950×2400 pixels. No exceptions.
No createCanvas(): The canvas is provided by the runtime. Do not create your own.
No custom dimensions, Width and height are not parameters. They are protocol constants.
Seeded RNG only, All randomness must derive from the provided seed. No Math.random().
No external resources, No network calls, no file system access, no dynamic imports.
No time-dependent behavior, Date.now() and similar are forbidden.

Protocol violation

Violating any constraint results in a 400 error. The render will not execute.

When certification is needed

Certification is required when:

On-chain anchoring, The output will be tokenized or registered on-chain.
Archival, The output must be reproducible indefinitely.
Provenance, Third parties need to verify the output was produced by specific code and inputs.
Auditability, Compliance, legal, or contractual requirements demand a verifiable record.
Dispute resolution, The snapshot serves as evidence of what was executed.

Certification is not required for:

Local development and iteration
Exploratory rendering in browser-based tools
Previewing outputs before committing to a final version

What certification is not

To avoid confusion:

Not a quality judgment, Certification proves execution, not aesthetic value.
Not copy protection, The output is not encrypted or access-controlled. Anyone can view it.
Not a blockchain transaction, Certification happens off-chain. On-chain registration is a separate, optional step.
Not a watermark, The image contains no embedded metadata. The snapshot is a separate file.
Not DRM, Certification is about proof, not restriction.

Certified runs are subject to plan limits. See pricing for details.

Why certification exists

Understanding the problem certification solves.

The reproducibility problem

Deterministic systems produce outputs from code. If the code is deterministic, running it again should produce the same output. In theory.

In practice, reproducibility fails. Runtime versions change. Dependencies update. Floating-point behavior varies across platforms. What rendered correctly in 2024 may render differently in 2027, or fail entirely.

This is not a hypothetical risk. It is the default outcome for any software system without explicit reproducibility guarantees.

Why determinism alone degrades over time

Determinism is necessary but not sufficient. A sketch may be deterministic today, same seed, same output. But determinism is fragile:

Runtime drift, Node.js 18 and Node.js 22 may handle edge cases differently.
Dependency rot, A library update changes internal behavior.
Platform divergence, ARM and x86 produce different floating-point results.
Canvas implementation, Browser canvas and node-canvas are not byte-identical.

Without a controlled environment, determinism is a local property that does not survive time or platform changes.

Why canonical environments matter

A canonical environment is a fixed, versioned execution context. It specifies:

Exact runtime versions (Node.js, canvas library, etc.)
Fixed canvas dimensions and pixel format
Pinned protocol version
Deterministic random number generation

When a sketch runs in the canonical environment, the output is not just deterministic, it is reproducible across time. The same inputs will produce the same output in 2025, 2030, or 2040, as long as the canonical renderer is preserved.

This is not a convenience. It is a prerequisite for any system where outputs have long-term significance.

Certification as a trust primitive

Certification creates a trust chain:

Code → Output, The sketch, given specific inputs, produces a specific output.
Output → Hash, The output is fingerprinted. Any modification is detectable.
Hash → Snapshot, The hash is recorded alongside inputs and metadata.
Snapshot → Verification, Anyone can re-run the sketch and confirm the hash matches.

This chain is the basis for trust without authority. You do not need to trust the author, the platform, or the marketplace. You can verify.

Long-term relevance

Certification addresses requirements that extend beyond the moment of creation:

Auditability, Years later, a third party can verify that an output was produced by specific code. No database lookup required.
Compliance, Regulatory or contractual requirements may demand proof of origin and execution.
Dispute resolution, The snapshot is evidence. It answers: was this the output of that code?
Archival integrity, Museums, archives, and institutions can preserve not just the image, but the proof.
Decentralized verification, Verification does not depend on NexArt. Anyone with the snapshot and a compliant renderer can verify.

Certification is not about today's transaction. It is about tomorrow's question: how do you know?

Canonical Certification