Protocol Compliance

    Standards for protocol-compliant applications.

    Third-party applications can implement the NexArt Protocol to create, preview, and certify deterministic deterministic systems. This page defines what compliance means and the different levels of integration.

    What Is Protocol Compliance

    A protocol-compliant application correctly implements the NexArt Protocol specification. This means:

    • Code Mode systems execute identically to the reference implementation
    • Determinism guarantees are preserved
    • Output can be independently verified
    • Systems created in one compliant app work in all others

    Compliance is not about branding or affiliation. It is a technical standard that any application can meet by implementing the protocol correctly.

    Compliance Levels

    There are two levels of protocol compliance, depending on which components an application integrates.

    LEVEL 1

    SDK Integration

    The application uses @nexart/codemode-sdk or @nexart/ui-renderer for preview and creation.

    Enables:

    • Creating valid Code Mode systems
    • Live preview during creation
    • Exporting system definitions
    • Interoperability with other compliant apps

    Limitations:

    • Previews are non-canonical (not suitable for on-chain anchoring)
    • No cryptographic verification of outputs
    • Cannot produce archival-grade renders
    LEVEL 2

    SDK + Canonical Renderer

    The application uses the SDK for creation and the Canonical Renderer for final output.

    Enables:

    • Everything in Level 1
    • Canonical, archival-grade rendering
    • Cryptographic output verification
    • Independently verifiable execution records for AI workflows
    • Full protocol guarantees

    Requirements:

    • Integration with NexArt Canonical Renderer API
    • Proper handling of output hashes
    • Compliance with on-chain anchoring standards

    Why Canonical Certification Matters

    Level 1 compliance is sufficient for creation and exploration, but Level 2 is required for certification because:

    • Determinism verification, Only the Canonical Renderer produces outputs that can be independently verified
    • Hash permanence, The output hash becomes the permanent proof of authenticity
    • Independent verifiability, Any party can verify that the output matches the original system
    • Long-term archival, Canonical outputs are the authoritative record

    A preview rendered in the browser may look identical, but it lacks the cryptographic proof that makes verification possible.

    On-chain anchoring is one application of certification; the same guarantees apply to simulations, audits, and verification workflows.

    Protocol-Compliant Applications

    The following applications independently implement the NexArt Protocol at different compliance levels. Inclusion reflects technical compliance, not ownership or endorsement.

    NexArt

    LEVEL 2

    Reference application for deterministic execution with full SDK and Canonical Renderer integration.

    nexart.xyz

    ByX

    LEVEL 2

    Deterministic rendering platform with certified on-chain anchoring.

    byxcollection.xyz

    Recanon

    LEVEL 2

    Canonical verification and replay client.

    Verify

    NexArt Science Lab

    LEVEL 2

    Deterministic research and simulation environment.

    nexartsciencelab.xyz

    Becoming Compliant

    If you are building an application that creates or displays NexArt systems, you can achieve compliance by:

    1. Integrating the Code Mode SDK for system creation and preview
    2. Optionally integrating the Canonical Renderer for on-chain anchoring capabilities
    3. Following the protocol specification for system structure and metadata
    4. Preserving determinism guarantees in your implementation

    There is no certification process. Compliance is self-declared and verifiable, if your outputs match the Canonical Renderer's outputs, you are compliant.

    Acceptance Checklist

    The canonical renderer adheres to the following behavior guarantees. Compliant clients and integrations should expect these behaviors.

    IDBehaviorExpected Result
    C1Valid request with all fields200, image/png
    C2Same inputs produce same outputIdentical outputHash
    C3Missing API key401
    C4Invalid API key401
    C5Account quota exceeded (distinct from rate limiting)429
    C6Protocol violation (e.g., wrong canvas size)400
    C7Rate limit exceeded429
    C8Response includes runtime hashx-runtime-hash header present
    C9Response includes protocol versionx-protocol-version header present
    C10Missing protocolVersion in request200, image/png, x-protocol-version present, x-protocol-defaulted: true, snapshot records resolved version

    C10 confirms that protocolVersion is lenient (optional) but always resolved and recorded. The canonical renderer defaults to its current version when omitted. C5 and C7 both return 429; quota enforcement (C5) is account-level and distinct from rate limiting (C7).

    Certified runs are subject to account-level plan limits. Quotas apply per account across all API keys. See pricing for details.

    For details on execution isolation, sandboxing, and audit guarantees, see Security Architecture.

    For technical details on SDK integration, see the Builders page.