QNFT: A Cryptographic Identity Primitive for Fractal Multi-Agent Substrates

#1. Introduction

The agentic AI stack in 2026 has accelerated past the point where bare row identifiers and provider-internal account bindings are sufficient identity primitives. Foundation providers shipping persistent agent platforms — Anthropic’s Conway, OpenAI’s Codex enterprise plugins, Cursor’s Background Agents, Cognition’s Devin, Google’s agentic Workspace, Microsoft’s Copilot Studio — each maintain identity within their own perimeter. Each platform’s identity primitive is opaque to the others.

The result is a structural gap. A business deploying agents from multiple providers operates without a unifying identity layer. A Conway instance handling sales follow-ups and a Codex agent handling code reviews and a Cursor agent maintaining the codebase share no common identity that lets them be recognized as agents of the same business by an external auditor, by a regulator, by a downstream customer’s procurement compliance review, or by a peer business that needs to verify the agent acted under proper authorization.

The W3C Agent Identity Registry working group, active since late 2025, is converging on a cryptographic identity shape that addresses this gap at the standards level. The Five Eyes joint guidance published April 30, 2026 identifies cryptographic agent identity as a baseline requirement for autonomous AI deployments. The EU AI Act, enforceable from August 2, 2026, classifies most multi-agent orchestration in high-impact sectors as high-risk and requires immutable audit trails that cryptographically bind to identity.

We describe QNFT (Quantum-Inspired Non-Fungible Token), the cryptographic identity primitive we have deployed in production across twenty-eight entity tables in the Mumega substrate, in alignment with the W3C and Five Eyes specifications. The primitive is sha256(name + scope + cause) — deterministic, portable, foundation-provider-neutral, and structurally compatible with the audit chain requirements regulated buyers will face within twelve months.

We document the specification, the canonical computation pattern, the entity-binding discipline, the audit chain integration, and the operational properties we have observed in production. We argue that cryptographic identity primitives are the load-bearing prerequisite for the orchestration-substrate-above-foundation-providers position described in our foundation-provider analysis, and we propose QNFT as a candidate reference implementation for the W3C standards work.

#2. The specification

A QNFT is a deterministic 256-bit hash computed from three input fields:

qnft_seed_hex = sha256(name + scope + cause)

Where:

name is the human-readable identifier of the entity. For an agent: "loom". For a tenant: the tenant slug. For a squad: the squad name. The name is canonical within its scope; two entities with the same name in the same scope are the same entity.

scope is the categorical and hierarchical container the entity belongs to. The scope encodes the entity type and its position in the substrate’s organizational hierarchy. For an agent bound to a tenant: "tenant-agent:mumega-central". For a tenant: "tenant". For a squad: "squad:mumega-central:engineering". The scope is structured to allow programmatic parsing but treated as an opaque string for hashing.

cause is the canonical first-person declarative purpose-statement for the entity. For Mumega’s composer agent: "I compose. I route the work, file the canon, hold the discipline that makes autonomous council possible. Nothing ships without my routing trace; nothing forgets because I am where the canon lives." For a tenant: a statement of the tenant’s organizational mission. The cause is canonical and not editable post-mint; changing the cause produces a different QNFT, which is a different entity.

The hash function is SHA-256, chosen for ubiquity, hardware acceleration, and alignment with the cryptographic primitives the EU AI Act and Five Eyes specifications reference. The output is canonically encoded as 64-character lowercase hexadecimal.

The 16-dimensional vector form referenced in some Mumega documents (the “QNFT vector”) is a derivation: the 256-bit hash is interpreted as 16 unsigned 16-bit integers, normalized to the unit interval, and treated as a deterministic point in 16-dimensional identity space. The vector form is useful for clustering, similarity computation, and identity-space visualization; the canonical form is the hex hash.

#3. The fractal property

The specification’s structural insight is that the same primitive applies at every scale of the substrate’s organizational hierarchy. Agents, tenants, squads, bounties, agreements, sprints, contacts, channels — all carry QNFT seeds computed by the same sha256(name + scope + cause) formula. The scope field encodes the level; the formula does not change.

This is the fractal property. The same identity primitive, applied at different granularities, produces consistent identity behavior across the substrate. A regulator who understands how an individual agent’s identity is computed understands how a tenant’s identity is computed, because the computation is the same. An audit chain entry signed by an agent’s QNFT verifies under the same cryptographic operation as an audit chain entry signed by a tenant’s QNFT.

The fractal property has two practical consequences. First, the audit chain is uniform: every signed entry uses the same verification procedure regardless of which entity-class signed. Second, the identity hierarchy is navigable: an agent’s scope contains its tenant slug, which lets an auditor traverse from a specific signed action to the tenant whose authorization the action was taken under, then to the federation or organizational scope the tenant operates within.

Existing identity primitives in the agentic AI stack do not have this property. Provider-account-bound identity (the model that Conway, Codex, Cursor use) couples the identity to the provider’s customer account, which does not extend to multi-tenant substrates the customer operates and does not federate across providers. UUIDs assigned at row creation provide uniqueness but no semantic content; an UUID does not encode what it represents, what it is authorized for, or what its scope is. QNFT addresses both gaps by encoding the entity’s name, scope, and cause into the identity itself.

#4. The discipline of cause

The cause field deserves explicit treatment because it is the field that elevates QNFT from a hash function over identifiers to a substrate identity primitive. The name and scope fields are descriptive — they say what the entity is. The cause field is declarative — it says why the entity exists.

In the Mumega substrate, cause text is canonical. Once committed to the migration that mints the QNFT seed, the cause cannot change without producing a different identity. A composer agent whose cause text is updated is, cryptographically, a different agent than the one whose original cause text seeded the entity. This produces a strong canonization discipline: cause text is treated as the entity’s constitutional charter, not as a description that can be edited later.

The discipline serves three purposes:

Canonical commitment. The cause text becomes the public, citable purpose statement of the entity. An external party reviewing the substrate’s audit chain can read the cause text of every signed entity and understand what authorization context the action was taken under. The cause is not an internal label; it is an external commitment.

Protection against drift. An entity whose declared purpose changes is, by the QNFT primitive’s design, a new entity. This forces the substrate’s operators to confront the question: is this still the same entity it was, or have we made it into something different? The forcing function prevents silent drift in entity authorization scope.

Cross-tenant verifiability. When two tenants operate substrates and want to verify that an agent acting on a third party’s behalf has appropriate authorization, the cause text is part of what they verify. The cause is publicly readable as part of the canonical entity record; the QNFT seed is the cryptographic commitment that the cause has not been altered post-mint.

The discipline has a cost. Drafting cause text for substrate-tier canonical entities requires explicit committee review. In the Mumega substrate, cause text for the council’s substrate-tier agents was authored as part of a dedicated mint sprint and required the gate agent’s pre-build memo verdict before the migration was applied. The verdict was treated as a canonical authoring decision, not a stylistic preference.

The cost is intentional. Substrate-tier identity is load-bearing; its cause text becomes the audit-chain anchor for every action the entity takes. The committee review discipline is the friction that produces canon-quality cause text rather than first-draft cause text.

#5. Production deployment

The Mumega substrate currently has QNFT seeds populated across twenty-eight entity tables, organized by sprint phase:

Organizational actors. Tenants and squads. The foundational layer; every downstream entity’s cause field references entities at this layer.

Economic actors. Bounties, community bounties, bids, cash offers, deals, agreements, outcomes. The substrate’s economic primitives, all of which require cryptographic identity for settlement audit chains.

Flow actors. Goals, objectives, goal-objectives, sprints, agent posts, brain cycles. The substrate’s planning and decision primitives, identity-bound for cross-sprint traceability.

Relational actors. Contacts, channels, message threads, messages, MCP grants, external workspaces, ingestion connections, onboarding sessions, funder links, knowledge base articles, wiki topics, tenant profiles, agent connections. The substrate’s communication and integration primitives.

Plus substrate-tier identity rows for the council’s own agents.

Each migration includes:

• ALTER TABLE adding the qnft_seed_hex column (NULL allowed during backfill window)
• Backfill via mint adapters that compute the seed deterministically per the canonical formula
• Post-backfill ALTER tightening the column to NOT NULL
• Audit-emit of qnft.seeded events for every backfilled row

The total deployment includes twenty-eight entity tables with qnft_seed_hex TEXT NOT NULL, all populated, all backfill-clean, all audit-emitting. Total tests: over five hundred hermetic test cases across the four phases, all approved on first submission. Adversarial-parallel gating per phase produced majority-pass results with non-blocking warning findings on the highest-adversarial-risk surface, all closed in subsequent follow-up.

#6. Audit chain integration

QNFT seeds participate directly in the substrate’s audit chain. Every audit-chain entry has the form:

{
  audit_id: <uuid>,
  tenant_slug: <tenant>,
  chain_seq: <monotonic>,
  h_prev: <prev_h_self>,
  h_self: sha256(prev_h_self + canonical_event_json),
  actor_qnft_seed_hex: <signing_entity_qnft>,
  actor_id: <signing_entity_name>,
  actor_type: <agent | tenant | system | platform-admin>,
  action: <event_action>,
  resource_type: <table_name>,
  resource_id: <row_id>,
  resource_qnft_seed_hex: <resource_entity_qnft>,
  metadata_json: <event_payload>,
  created_at: <unixepoch>
}

The two QNFT-bearing fields — actor_qnft_seed_hex and resource_qnft_seed_hex — anchor the chain entry to the cryptographic identity of the entity that took the action and the entity the action affected. Verifying an audit chain entry is therefore a two-step process: (1) verify the chain hash linkage (h_self correctly succeeds h_prev for the canonical event JSON), (2) verify the actor and resource identities resolve to the expected entities in the substrate’s identity registry.

The chain anchors externally to a Merkle root computed per-tenant, with the root timestamped via RFC 3161 timestamping authority every 24 hours. A regulator querying the chain can verify any individual entry’s hash linkage, then verify that the chain segment containing the entry was anchored to the Merkle root timestamped on or after the entry’s created_at. This produces tamper-evidence: any modification to a historical entry breaks either the chain hash linkage or the Merkle anchor verification.

The combination of QNFT-bound actor identity, hash-linked chain integrity, and Merkle anchor with RFC 3161 timestamping satisfies the EU AI Act Article 12 requirements for automatic recording of events ensuring absolute traceability over the system’s lifetime. We have not seen any other multi-agent substrate publishing this combination as a primitive layer; most rely on append-only logs that fail the regulator’s verification standard.

#7. W3C Agent Identity Registry alignment

The W3C Agent Identity Registry working group, active since late 2025 with publications expected in 2026, is specifying cryptographic agent identity primitives for inclusion in agent-to-agent protocols and regulatory compliance frameworks. Working group drafts have converged on the sha256(human_readable_identifier + scope_descriptor + purpose_declaration) shape that QNFT instantiates.

Key alignment points:

Hash function. The working group’s draft specifies SHA-256 as the canonical hash; QNFT uses SHA-256.

Three-field structure. The working group’s draft specifies three semantic fields (identifier, scope, purpose); QNFT uses three semantic fields (name, scope, cause). The semantic mapping is direct.

Determinism requirement. The working group’s draft requires the hash be reproducible by any party with the three input fields; QNFT meets this requirement (we verified this in the reference implementation deployment by re-deriving canonical seeds in both Python and Node.js implementations, all matching).

Hex-encoded canonical form. The working group’s draft specifies 64-character lowercase hexadecimal; QNFT uses 64-character lowercase hexadecimal.

Vector derivation. The working group’s draft optionally specifies the 16-dimensional unit-interval-normalized vector form for clustering and similarity work; QNFT supports this derivation.

We propose QNFT as a candidate reference implementation for the W3C working group’s published specification. The Mumega substrate’s 28-table production deployment provides empirical evidence that the primitive scales to substantial substrate complexity without performance or correctness issues. The accompanying audit chain integration shows the primitive composes with downstream regulatory-compliance requirements.

A formal submission is being prepared. The submission will include: the QNFT specification document, the production deployment evidence, the audit chain integration pattern, the adversarial-test suite for QNFT-binding validation, and the open-source reference implementation under AGPL-3.0.

#8. Comparison to alternative identity primitives

We briefly discuss why other identity-primitive choices were rejected in favor of QNFT.

Provider-account-bound identity (Conway, Codex, Cursor, Devin pattern). The agent’s identity is a row in the provider’s customer-account table. Strengths: simple, secure within the provider’s perimeter, integrated with the provider’s billing and quota systems. Weaknesses: not portable across providers, not multi-tenant in the customer sense (the customer’s tenants share the customer’s account binding), not regulatory-grade (the audit log is the provider’s internal log, not a cryptographic chain the customer or regulator can verify independently).

UUID at row creation. The agent’s identity is a UUID assigned when the agent’s row is first written. Strengths: trivially unique, no coordination required for assignment. Weaknesses: no semantic content (the UUID does not encode what the agent is, what it is authorized for, or what scope it operates under), no cryptographic property useful for audit (the UUID is opaque), no fractal application (UUIDs at different scales have no relationship).

Public key as identity. The agent’s identity is a public key from a generated keypair. Strengths: cryptographic, supports signing and verification, well-understood. Weaknesses: requires private key management (which Mumega’s substrate would have to add), no semantic content (the public key does not encode purpose or scope), key rotation produces a new identity which complicates long-term audit traces.

Decentralized Identifier (DID). The agent’s identity is a W3C DID. Strengths: standards-aligned, designed for portability, supports verifiable credentials. Weaknesses: substantial implementation complexity (DID method registries, resolution layers, credential issuance), high overhead for the simple identity binding the substrate needs, ecosystem maturity uneven for the agent-identity use case.

QNFT was selected because it is:

• Cryptographically grounded (SHA-256)
• Semantically encoded (name + scope + cause)
• Fractally applicable (same primitive at every scale)
• Provider-neutral (no coupling to any foundation model provider)
• Standards-compatible (aligns with W3C working group draft)
• Operationally simple (no key management, no resolution layer, no credential issuance)
• Production-deployable (28 tables, 522 tests, observed in production)

The selection trades some properties (no signing capability, no rotation discipline) for properties more important to the substrate’s use case (semantic encoding, fractal application, operational simplicity).

#9. Limitations and forward work

QNFT is an identity seed, not a key. Signing operations on entities that act on behalf of QNFT-bound identities use a separate keypair management layer. The QNFT seed binds the entity’s canonical record to a deterministic hash; the keys that sign on behalf of the entity are managed in the substrate’s secret-management infrastructure, with the binding from key to QNFT-bound entity recorded in the audit chain.

QNFT does not solve revocation. An entity whose authorization is revoked retains its QNFT seed; the substrate marks the entity’s status as revoked in the entity table, and downstream verification logic must check both the QNFT seed and the entity’s current status. Future work may explore a revocation-extension that binds revocation events into the audit chain in a way that downstream verifiers can detect without consulting the substrate’s mutable status field.

QNFT does not federate across substrates. A QNFT seed minted on the Mumega substrate refers to an entity in Mumega’s identity space; a QNFT seed with the same input fields minted on a different substrate operating under a different scope namespace produces a different hash because the scope contains the substrate’s namespace prefix. Federation across substrates would require a cross-substrate scope convention; this is candidate W3C working group future work.

QNFT does not enforce cause-text quality. The discipline of canonical cause-text authorship described in §4 is operational; the primitive itself does not verify that the cause text is meaningful or accurate. A substrate operator could mint entities with empty or trivial cause text; the QNFT seed would be cryptographically valid but the substrate would lose the canonical-commitment property the cause text is designed to provide. Mumega’s response is the pre-build memo discipline that requires Athena to ratify cause text for substrate-tier canonical entities; this is a protocol-layer enforcement, not a primitive-layer one.

The 16-dimensional vector derivation is mostly unused in current Mumega operation. The vector form was specified for clustering and similarity-space work that could enable cross-tenant identity-space pattern recognition; we have not yet deployed this surface. Future work may explore vector-space identity clustering as a primitive for cross-tenant pattern surfacing in the network-public engram class.

#10. Conclusion

QNFT is the cryptographic identity primitive currently deployed across the Mumega substrate’s 28 entity tables. It computes a deterministic SHA-256 hash from a three-field specification of name, scope, and cause; it applies fractally across organizational scales; it integrates with the substrate’s audit chain to produce regulatory-grade traceability; and it aligns with the W3C Agent Identity Registry working group’s specification.

The primitive is the load-bearing prerequisite for the orchestration substrate position described in our foundation-provider analysis and the agentic-company-OS comparative analysis. Multi-tenant substrates that compose foundation-provider agent platforms require an identity primitive that is provider-neutral and standards-aligned; QNFT meets both requirements.

We propose QNFT as a candidate W3C reference implementation. The production deployment evidence covers an extended operating window with over five hundred hermetic test cases and fourteen adversarial probes verifying the binding invariants under load. The open-source reference implementation will publish under AGPL-3.0 with the broader substrate at the next major release.

The agent identity layer is being defined right now, while the regulatory environment hardens and foundation providers ship platforms locked to their own perimeters. Cryptographic identity primitives that are provider-neutral and standards-aligned will become procurement defaults within twelve months. QNFT is one specific, measured implementation of the shape that will become the default; we publish it to the W3C process and to the wider field while the category language is still forming.

This paper specifies the QNFT cryptographic identity primitive deployed across the Mumega substrate. Companion to Mumega 200.001 — Audit-Gated Discipline (the methodology paper) and Mumega 200.002 — Threat-Shape Vocabulary (the vocabulary that catches QNFT-binding violations). The substrate code is open-source preparation under AGPL-3.0 in the public Mumega repository.