ENI6MA Use Cases: Developer Introduction

Audience: Developers, architects, and product owners integrating or evaluating ENI6MA.
Purpose: Describe major application scenarios, command and API usage, and why ENI6MA is better for each.
Capabilities covered: CLI (circuit binary commands), Registry (HTTP API), Ledger (nonce lifecycle, audit).

Introduction
Scope and How to Use This Document
Use Case 1: Consumer Sovereign Login (Passwordless Web Auth)
Use Case 2: Enterprise Policy Gates (Privileged Operations)
Use Case 3: High-Value Financial Transactions and Approvals
Use Case 4: Machine and API Identity (No Static API Keys)
Use Case 5: Agent-to-Agent Authentication (A2A / Oscillation)
Use Case 6: Blockchain and Digital Custody (Enigma-ECDSA Bridge)
Use Case 7: Healthcare PHI and Clinical System Access
Use Case 8: IoT, Edge, and Mesh Device Authentication
Use Case 9: Sovereign and Air-Gapped Deployment
Use Case 10: Deployment and CI/CD Approval Gates
Use Case 11: Message Signing and Verification
Use Case 12: OP_RETURN Encrypted Metadata (On-Chain Privacy)
Use Case 13: Ethereum Address Derivation and Transaction Signing
Use Case 14: Audit and Compliance (Ledger Trails, No PII)
Use Case 15: Phishing-Resistant Authentication
Use Case 16: Instant Revocation (Hash-Based Policy)
Use Case 17: Post-Quantum Resilient Authentication
Use Case 18: Zero-Trust Per-Event Authorization
Use Case 19: Developer Integration (Three API Calls)
Use Case 20: Circuit Discovery and Binary Verification
Use Case 21: Crypto Wallet and Transactions
Use Case 22: PII (SSN/DOB) Validation and Credit Check Service
Use Case 23: Password Manager
Summary Table: Use Cases and Primary Surfaces
Conclusion: Circuit Capabilities and the ENI6MA Surface
References

Introduction

This document is the developer-facing guide to ENI6MA’s use cases and capabilities. It is written for engineers, architects, and product owners who need to understand not only what ENI6MA can do but how it fits into real systems, which commands and APIs to use, and why it solves problems that credentials and legacy auth cannot. The text is organized around twenty-three major application scenarios, each with a full description, a simplified Mermaid diagram, integration context for existing systems, and a fictitious partner example that spells out the risks and attack vectors addressed. By the end, you will have a clear map from your problem domain to the ENI6MA surface: the circuit binary (CLI), the Registry (HTTP API), and the Ledger (nonce lifecycle and audit).

The problem this document addresses. Digital identity and authentication have relied for decades on reusable credentials: passwords, API keys, session tokens, certificates, and private keys. Whatever form they take, these artifacts share a fatal property: once an attacker obtains a copy, they can use it until it is rotated or revoked. Breaches, phishing, and credential stuffing succeed because the industry has been protecting artifacts instead of eliminating them. ENI6MA takes a different path. It replaces the credential with an ephemeral interactive proof—a one-time, non-replayable demonstration of knowledge that is bound to a specific moment (timestamp), a specific challenge (nonce), and a specific context. There is nothing to steal, nothing to phish, and nothing to replay. This document shows how that single primitive—the proof—unlocks twenty-three distinct use cases across consumer login, enterprise policy gates, financial approvals, machine identity, agent-to-agent auth, blockchain custody, healthcare, IoT, sovereign deployment, CI/CD gates, message signing, on-chain privacy, Ethereum operations, audit and compliance, phishing resistance, instant revocation, post-quantum resilience, zero-trust per-event auth, developer integration, circuit discovery, crypto wallet and transactions, PII validation and credit check (encrypted secret store and self-signed encrypted data), and password manager. For each, we describe the flow, the integration points, and the attack vectors that ENI6MA removes.

The three surfaces. ENI6MA exposes three main surfaces that you will see in every use case. The circuit binary (CLI) is a compiled Rust executable that embodies a user’s or service’s identity. It contains embedded entropy, the proof machinery, and—when used with the Enigma-ECDSA bridge—the ability to derive signing keys and run sign-msg, verify-msg, opret-encrypt, opret-decrypt, ethereum-address, sign-ethereum-tx, and verify-ethereum-tx. The binary is run locally or remotely via the Registry’s CLI proxy (POST /api/circuits/{handle}/cli/{command}). Core proof commands are challenge, validate-response, and validate-proof; ledger-related commands are ledger/status, ledger/tx, and ledger/mine. The Registry is the public HTTP API (e.g. at registry.eni6ma.net) that applications call to request challenges, submit proofs, discover circuits, download binaries, and execute any CLI command by proxy. Key endpoints are POST /api/circuits/{handle}/challenge, POST /api/circuits/{handle}/validate, GET /api/circuits, GET /api/circuits/{handle}/verify, GET /api/binaries/handle/{handle}, and POST /api/circuits/{handle}/cli/{command}. The Registry does not store credentials; it coordinates the proof flow and talks to the Ledger and the executor that runs the circuit. The Ledger is the nonce registry that enforces one-time use and time-to-live. It exposes POST /reserve (returns uuid and tau), POST /response (consumes the nonce—burn-before-validate), GET /status/{uuid}, and GET /events. Replay attempts get HTTP 409; expired nonces get HTTP 410. Every use case in this document is built from some combination of these three surfaces.

What the circuit is and why it matters. The circuit is not a credential. It is a compiled identity: a binary produced by the ENI6MA compiler from a user’s configuration (secrets, color–direction or other cognitive mapping, rounds, alphabet). The compiler never retains the configuration; it delivers the binary and destroys the build environment. The binary alone cannot authenticate—it requires the user’s cognitive key (e.g. the private mapping of six colors to six directions, or another 720-way bijection). During the proof ceremony, the user sees a six-zone hexagonal grid whose geometry is derived from a session timestamp (tau) and the circuit’s embedded entropy. They select bearings (e.g. Up, Down, Left, Right, Forward, Back) according to where their secret characters appear and their private mapping. The observable transcript (the sequence of bearings) is designed to be non-informative: an observer cannot learn the secret or the mapping from any number of observed sessions. The Ledger ensures that each proof is non-replayable (one nonce per challenge, burn before validate) and time-bound (TTL expiry). Together, non-informativeness and non-replayability remove the two main ways attackers defeat auth: stealing a credential and replaying it, or learning the secret from observation. The circuit also supports signing (message and Ethereum), OP_RETURN encryption/decryption, agent-to-agent protocols (symmetric clones, oscillation), and sovereign/offline operation with a local ledger snapshot and sync when connected. All of these capabilities are covered in the use cases and in the Conclusion.

How the use cases are organized. Each of the twenty-three use cases follows the same structure. First, What it is—a one-paragraph definition of the scenario. Second, How it works—the step-by-step flow using Registry, Ledger, and optionally the CLI. Third, CLI/Registry/Ledger mapping—a quick reference to the endpoints and commands used. Fourth, Why ENI6MA is better—a comparison to credential-based alternatives and the attack vectors that disappear. Fifth, Diagram, integration context, and partner example—a Mermaid diagram (sequence or flowchart), a section on how ENI6MA plugs into existing systems (IAM, apps, pipelines, vaults), and a fictitious partner (e.g. SafeBank Retail, TechFlow Inc, NorthStar Treasury) with a concrete story: what they used before, how they use ENI6MA now, and five risks or attack vectors that ENI6MA solves. This structure lets you read by scenario (e.g. “I need CI/CD approval gates”) or by surface (e.g. “what does the Ledger do in every use case?”). The Summary Table at the end maps all twenty-three use cases to Registry, Ledger, and CLI in one view.

How to read this document by role. If you are a developer integrating ENI6MA into an app, start with Use Case 19 (Developer Integration) and Use Case 1 (Consumer Login); then open the Registry’s OpenAPI spec (GET /api/swagger) and Swagger UI (/docs). You will see the three-call pattern (challenge, ceremony, validate) and the full set of CLI commands available via POST .../cli/{command}. If you are an architect evaluating ENI6MA for enterprise policy gates, zero-trust, or compliance, read Use Cases 2, 14, 16, and 18; the diagrams and integration context show where ENI6MA sits relative to SSO, RBAC, and audit. If you are a product owner or security lead comparing ENI6MA to passwords, MFA, or passkeys, read the “Why ENI6MA is better” and partner example sections in Use Cases 1 and 15 (phishing-resistant auth); the attack-vector lists make the value proposition concrete. If you are working on blockchain custody, healthcare, IoT, or sovereign/air-gap deployments, go directly to Use Cases 6, 7, 8, and 9. The Conclusion then ties everything back to a single picture of circuit capabilities: proof lifecycle, CLI command set, Registry API, Ledger semantics, and security properties.

What you will not find here. This document does not replace the product vision or the cryptographic and protocol detail in product.MD. It does not specify every CLI flag or every Registry query parameter; those are in the OpenAPI spec and the codebase. It does not describe the compiler, the executor, or the identity service in depth; it focuses on the public and integration-relevant surfaces: Registry, Ledger (as used by the Registry and optionally by visibility tools), and the circuit binary’s commands. Internal services are mentioned only where they affect the flow (e.g. the Registry reserves a nonce from the Ledger and runs the binary via the executor). You will find enough here to design an integration, explain ENI6MA to a partner, and map your use case to the right endpoints and commands; for full protocol and security arguments, see product.MD and the references listed at the end.

A note on the partner examples. Every use case includes a fictitious partner (e.g. SafeBank Retail, TechFlow Inc, MedFirst Health Network). These are not real customers; they are illustrative personas. Their stories—previous pain (credential stuffing, phishing, session hijacking, key extraction, revocation delay, etc.) and how ENI6MA addresses those risks—are intended to make the value proposition and the attack-vector discussion concrete. You can reuse or adapt these narratives for training, sales, or internal alignment.

The proof ceremony and the Ledger in more detail. Understanding the ceremony and the Ledger helps you see why every use case shares the same security guarantees. When an application requests a challenge, the Registry calls the Ledger’s POST /reserve. The Ledger creates a new nonce: a UUID and a tau (timestamp in microseconds). That nonce is in state RESERVED and has a TTL (e.g. 300 seconds). The Registry passes tau to the circuit binary (run in a sandboxed executor); the binary generates the challenge geometry from tau and its embedded entropy pool. The geometry—which characters appear in which of the six colored zones—is session-unique because tau and the entropy selection are unique. The client receives nonce_uuid, tau, and the challenge data, and renders the six-zone grid. The user (or agent) selects a bearing for each round based on where their secret character appears and their private color–bearing map. The client computes a proof hash over the transcript and sends the proof payload to the Registry. The Registry’s first action is to call the Ledger’s POST /response with the nonce UUID and payload: the burn. If the nonce is already SPENT, the Ledger returns 409 (replay). If the nonce is past TTL, the Ledger returns 410 (gone). If the payload’s tau does not match the reserved tau, the Ledger returns 400. Only if the burn succeeds does the Registry run the binary again to verify the proof cryptographically. This burn-before-validate order is critical: it means each challenge accepts exactly one validation attempt. An attacker cannot try many guesses against the same challenge; the first attempt (right or wrong) consumes the nonce. Combined with rate limiting and the combinatorial size of the proof space, brute force is infeasible. Every use case that uses the Registry for challenge/validate gets this guarantee; sovereign mode uses a local ledger snapshot with the same semantics and syncs when connected.

The twenty-three use cases as a landscape. The use cases are grouped conceptually. Identity and login (1, 15, 19, 23): consumer passwordless login, phishing-resistant auth, developer integration with the three-call pattern, and password manager (proof as master secret). Enterprise and zero-trust (2, 10, 16, 18): policy gates for privileged operations, CI/CD approval gates, instant revocation, and zero-trust per-event authorization. Finance and high-assurance (3, 6, 11, 12, 13, 21): financial approvals, blockchain custody and Enigma-ECDSA, message signing, OP_RETURN privacy, Ethereum operations, and crypto wallet and transactions. Machine and agent (4, 5): machine/API identity without static keys and agent-to-agent authentication with symmetric clones and optional sovereign mode. Sector-specific (7, 8, 9): healthcare PHI access, IoT/edge/mesh device auth, and sovereign/air-gapped deployment. Compliance and assurance (14, 17, 22): audit and compliance with Ledger trails (no PII), post-quantum resilient authentication, and PII validation and credit check (encrypted secret store, self-signed encrypted data). Discovery and supply chain (20): circuit discovery and binary verification. You can combine use cases in one system: e.g. consumer login (1) for end-users, policy gates (2) for admins, and developer integration (19) for API access, all using the same Registry and Ledger and the same circuit-based identity.

Security properties at a glance. Across all use cases, ENI6MA delivers a small set of guarantees that credential-based systems cannot match. No reusable credential: Nothing is stored or transmitted that, once captured, grants future access. The proof is one-time and bound to a nonce and timestamp. No replay: The Ledger burns the nonce before validation; a second submission with the same nonce returns 409. Non-informative transcript: The user’s bearing responses are designed so that an observer (or a phishing site) cannot learn the secret or the cognitive mapping from any number of observed sessions; the attacker’s success probability does not improve with more observations. Time-bound: Nonces expire (410 after TTL); there is no indefinite validity. Instant revocation: Revoking an identity is removing its circuit hash from the policy allowlist; the next proof from that circuit fails. No server-side secret store: The Registry and Ledger hold metadata and nonce lifecycle, never passwords, keys, or TOTP seeds. Audit without PII: Ledger events record “circuit hash, nonce, time, payload hash” for compliance and forensics without storing user secrets. Post-quantum resilience: The proof system’s security does not depend on factoring or discrete logarithms; it is already resilient to quantum adversaries. These properties are not optional add-ons; they are structural consequences of the design. When you integrate ENI6MA, you get all of them for every proof flow.

Deployment and integration patterns. ENI6MA can be adopted incrementally. Pattern A: Gate high-value actions only. Keep existing login (SSO, password, or passkey) for initial access; add ENI6MA as a required step for sensitive operations (wire transfer, deploy approval, admin console). The app calls Registry challenge and validate only at those gates; the rest of the session uses the existing token. Pattern B: Full ENI6MA login. Replace the login step with the three-call ENI6MA flow; issue a short-lived session (JWT or cookie) after validated proof for legacy APIs. Pattern C: Per-event zero-trust. No long-lived session; every sensitive API call or action triggers a new challenge and validate. Pattern D: Machine and agent. Services and agents hold circuits; they authenticate to each other or to the API with challenge/validate (and optionally A2A oscillation). Pattern E: Sovereign and offline. Deploy a local ledger snapshot and circuit cache; run proof ceremonies offline and sync when connected. The same Registry API and CLI command set support all patterns; the only difference is where and how often you call challenge and validate. The diagrams and integration context in each use case show how to plug ENI6MA into your existing IAM, app server, and pipelines without a big-bang replacement.

Reading paths by scenario. If your immediate need is to integrate “Login with ENI6MA” into a web or mobile app, read Use Case 1 and Use Case 19, then open the Registry’s Swagger UI and implement the three calls plus the ceremony UI. If you are designing an enterprise policy (e.g. “every production deploy must be approved with a proof”), read Use Cases 2 and 10 and the integration context for existing IAM. If you are building or evaluating custody or signing (Bitcoin, Ethereum, or message signing), read Use Cases 6, 11, 12, and 13 and the Conclusion’s “Enigma-ECDSA bridge” and CLI command set. If you are working on healthcare, IoT, or air-gapped deployments, read Use Cases 7, 8, and 9. If your focus is compliance and audit, read Use Cases 14 and 16 and the Ledger sections in the Conclusion. If you are comparing ENI6MA to passwords, MFA, or passkeys for phishing resistance or post-quantum assurance, read the “Why ENI6MA is better” and partner example sections in Use Cases 1, 15, and 17. If you are building a crypto wallet, a PII/credit-check service (encrypted secret store, self-signed encrypted data), or a password manager, read Use Cases 21, 22, and 23. The Table of Contents at the top of this document links to every section so you can jump directly to the use case or the Conclusion.

Conventions and terminology. In this document, handle means the public identifier for a circuit (e.g. a username-like string). Circuit means the compiled binary (or the logical identity it represents). Proof means the payload (tau, bearings, proof_hash, etc.) produced by the user or agent after the ceremony. Nonce means the Ledger’s reserved slot (uuid, tau) for one challenge. Burn means consuming the nonce via POST /response so it cannot be used again. Registry means the public HTTP API (e.g. registry.eni6ma.net). Ledger means the nonce registry (reserve, consume, status, events). CLI means the circuit binary’s commands, whether run locally or via the Registry’s POST .../cli/{command}. Ceremony means the six-zone grid and the user’s bearing selections. Cognitive key means the user’s private mapping (e.g. colors to directions). Fictitious partner names (SafeBank Retail, TechFlow Inc, etc.) are illustrative only. All API paths and commands are accurate at the time of writing; for the latest contract, use the Registry’s OpenAPI spec and the codebase references in the References section.

Next steps. After the Introduction and the Table of Contents, the document moves to Scope and How to Use This Document, which summarizes the three surfaces and the structure of each use case. Then come the twenty-three use cases in order. Each is self-contained; you can read them in any order. The Summary Table gives a one-page map from use case to Registry, Ledger, and CLI. The Conclusion consolidates all circuit capabilities: the proof lifecycle, the full CLI command set, the Registry API surface, the Ledger lifecycle and semantics, and the security properties (non-replay, non-informative transcript, post-quantum resilience, instant revocation). The References section points to product.MD, the public interface spec, the scripts and Swagger sources, and the strategic technology report for further reading. Use the Table of Contents above to jump to any section.

Scope and How to Use This Document

ENI6MA replaces reusable credentials (passwords, API keys, session tokens, private keys) with ephemeral interactive proofs: one-time, non-replayable, non-informative demonstrations of knowledge. The platform exposes three main surfaces:

CLI: Commands run by the circuit binary (locally or via Registry proxy): challenge, validate-response, validate-proof, sign-msg, verify-msg, ledger/status, ledger/tx, opret-encrypt, opret-decrypt, ethereum-address, sign-ethereum-tx, verify-ethereum-tx, pool, interactive, nonce-interactive, and others.
Registry: REST API at registry.eni6ma.net: GET /api/circuits, GET /api/circuits/{handle}, POST /api/circuits/{handle}/challenge, POST /api/circuits/{handle}/validate, POST /api/circuits/{handle}/cli/{command}, GET /api/binaries/handle/{handle}, GET /api/circuits/{handle}/verify, index and health.
Ledger: Nonce registry (internal or visibility service): POST /reserve (uuid, tau), POST /response (consume/burn), GET /status/{uuid}, GET /events; TTL expiry, replay rejection (409), tau binding.

Each use case below is a major application scenario with a substantial description: what it is, how it works with ENI6MA, which commands and capabilities it uses (CLI, Registry, Ledger), and why ENI6MA is better than credential-based alternatives. For each use case, an additional section (~1200 words) provides: (1) a simplified Mermaid diagram of the flow or architecture, (2) integration context for existing systems (how ENI6MA plugs into current IAM, apps, and ops), and (3) a fictitious partner example (name, industry, how they use the tech, and the risks and attack vectors they currently suffered from and how ENI6MA solves them). The Summary Table at the end maps all use cases to the three surfaces.

What it is: End-users sign in to web applications without passwords, recovery emails, or SMS codes. Identity is a compiled circuit plus a personal cognitive key (e.g. color–direction mapping); there is no credential to phish or steal. The user holds a circuit binary (and optionally backups) and remembers a private mapping (e.g. six colors to six directions); the server never stores that mapping or any secret.

How it works: The application requests a challenge from the Registry (POST /api/circuits/{handle}/challenge). The Registry reserves a nonce from the Ledger (uuid, tau), runs the circuit binary in a sandboxed executor to generate session-unique geometry from tau and embedded entropy, and returns the challenge (nonce_uuid, tau, challenge data) to the client. The client renders the six-zone hexagonal grid, collects the user’s bearing selections for each round, computes the proof hash, and submits the proof to POST /api/circuits/{handle}/validate with kind: "proof" and payload (nonce_uuid, tau, bearings, proof_hash, alphabet_count). The Registry first burns the nonce via Ledger POST /response (burn-before-validate): if the nonce is already spent, the Ledger returns 409 and the Registry does not run verification; if the nonce is expired (past TTL), the Ledger returns 410. Only after a successful burn does the Registry run the binary to verify the proof. On success, the application treats the user as authenticated—optionally issuing a short-lived session cookie for legacy compatibility. The entire flow is stateless; no API keys are required for the Registry.

CLI/Registry/Ledger mapping: Registry: POST .../challenge, POST .../validate; GET .../verify for SHA256 and manifest. Ledger: Reserve on challenge (Registry calls Ledger internally), consume on first validate; replay returns 409, expired nonce returns 410; optional visibility/events for audit. CLI: For local or scripted flows, the binary can be run with challenge, validate-response, validate-proof; when the Registry is used, it performs reserve/consume so the same burn semantics apply. Verify: GET /api/circuits/{handle}/verify returns SHA256 and manifest for integrity checks before or after login.

Why ENI6MA is better: Passwords and password managers are reusable artifacts: once stolen or phished, they grant access. Database breaches expose hashes that can be cracked; phishing captures the secret at the moment of entry. MFA adds a second factor that can be relayed (real-time phishing proxies) or bypassed (SIM swap, fatigue). Passkeys improve on passwords but still rely on a durable private key that must be stored, synced, and recovered—device compromise or cloud sync compromise can expose that key. ENI6MA removes the artifact entirely: there is no string to type on a phishing site, no token to intercept, and no key to exfiltrate. Each proof is bound to a single nonce and timestamp; a captured proof cannot be replayed (Ledger rejects with 409) and expires (410 after TTL). Phishing stops working because a fake site cannot obtain a valid nonce from the real Ledger or generate a valid challenge from the real Registry; any copied UI would yield a proof that either does not match any real nonce or is already burned. Compliance and breach impact shrink: a leaked database holds circuit metadata and audit trails, never credentials. Developers integrate with three API calls and no SDK or API key provisioning.

Diagram, integration context, and partner example (Use Case 1)

Rendering diagram…

Integration context for existing systems. ENI6MA consumer login slots into a typical web stack without replacing the whole auth surface at once. The existing system keeps its identity store (e.g. user id, handle, roles) and optionally keeps SSO or email for account recovery or first-time binding. The new flow is: when the user chooses “Log in with ENI6MA,” the app calls the Registry for a challenge, embeds or launches the ceremony UI (six-zone grid), and on success receives a validated proof. The app then maps the proof (e.g. via handle or circuit hash in the response) to an internal user and issues whatever session object the rest of the stack expects—JWT, session cookie, or SAML assertion. No credential is ever stored; the “user record” is a handle plus an allowlist of circuit hashes. Legacy APIs and front-ends can stay unchanged; only the login step is swapped for the three-call ENI6MA flow.

Fictitious partner example: SafeBank Retail. SafeBank Retail is a mid-size neobank with 2M retail users. They previously used password + SMS OTP for login. They suffered from credential stuffing (breached username/password pairs reused from other sites), real-time phishing (attackers proxied both password and OTP), and high support cost for resets and lockouts. After integrating ENI6MA, login works as follows: the mobile and web apps request a challenge from the Registry, display the six-zone ceremony, and submit the proof; SafeBank’s backend validates via the Registry and then issues a short-lived session token for the existing API layer. Risks and attack vectors addressed: (1) Credential stuffing — there is no password to try; the attacker would need to pass the interactive proof, which requires the user’s circuit and cognitive key. (2) Phishing — a fake login page cannot obtain a valid nonce from the real Ledger or produce a valid challenge; any proof the user completes on a fake site is useless (wrong or already burned nonce). (3) SMS/OTP interception and SIM swap — second factor is eliminated; the only “factor” is the one-time proof. (4) Database breach — a breach of SafeBank’s DB yields handles and metadata, not credentials; no hashes to crack. (5) Session hijacking — sessions can be kept short; each re-auth is a new proof, so stealing an old cookie has limited value. SafeBank also uses the Ledger’s audit trail (nonce, timestamp, circuit hash) for compliance and fraud analysis without storing PII in the auth path.

Use Case 2: Enterprise Policy Gates (Privileged Operations)

What it is: Sensitive actions—admin console access, deployment approval, privilege escalation, treasury operations—require a fresh proof ceremony instead of a long-lived session token. Each action is gated by reserve–challenge–validate and logged with nonce and circuit hash. The enterprise can keep initial access via SSO or ENI6MA and then require a new proof for every privileged step.

How it works: After initial access (e.g. SSO or ENI6MA), the user navigates to a privileged action (e.g. “Approve deployment,” “Execute wire,” “Change IAM role”). The backend calls POST /api/circuits/{handle}/challenge (optionally with x-eni6ma-ledger-url if using a dedicated ledger), receives nonce_uuid and tau and challenge data, and presents the challenge to the user—or to an agent that holds the circuit and can produce the proof. The user or agent completes the six-zone ceremony; the client sends the proof payload to the backend, which calls POST /api/circuits/{handle}/validate with kind: "proof" and the payload. The Registry burns the nonce (Ledger POST /response) and runs the binary to verify; only on validated proof does the backend execute the action (e.g. run Terraform, approve a wire, change IAM). The Ledger records reserve, consume, and optional access-log/success events; auditors see “circuit hash H completed proof for nonce N at time T” without any stored secret. Multiple gates in one session require multiple challenge–validate cycles and thus multiple nonces.

CLI/Registry/Ledger mapping: Registry: POST .../challenge, POST .../validate; optional x-eni6ma-ledger-url for dedicated ledger. Ledger: Reserve per gate, burn on validate; GET /events or visibility service for audit. CLI: challenge, validate-response, validate-proof for scripted or local gates; POST /api/circuits/{handle}/cli/challenge and POST .../cli/validate-proof for server-driven flows with remote binary execution.

Why ENI6MA is better: Traditional models grant broad access after one login; a stolen session cookie or token authorizes everything until expiry. With ENI6MA, each privileged step requires a new proof bound to a new nonce. The attack window collapses from “session lifetime” to “single ceremony.” There is no token to steal for later use; revocation is instant (remove circuit hash from policy). Zero-trust “never trust, always verify” is native: continuous verification is per-event proof, and least privilege is enforced by gating each action. Compliance (SOC 2, ISO 27001, PCI-DSS) is simplified because audit trails are non-PII and there is no credential store to protect or breach.

Diagram, integration context, and partner example (Use Case 2)

Rendering diagram…

Integration context for existing systems. Enterprise policy gates fit into current IAM and app architecture by treating ENI6MA as an additional authorization layer at privilege boundaries. The existing system continues to handle first-factor access (SSO, VPN, or ENI6MA login). When the user or automation hits a protected action (e.g. “Approve deployment,” “Run Terraform,” “Execute wire”), the backend does not rely on the existing session alone; it calls the Registry for a challenge, presents the ceremony to the user (or to an agent that holds the circuit and can produce the proof), and only on validated proof proceeds. The backend can pass an action context (e.g. resource id, amount) into its own policy engine so the Ledger and logs record “proof for nonce N at time T for action X.” Existing RBAC can stay: ENI6MA proves “this circuit (hash) is allowed to perform this action now”; RBAC still maps circuit hash or handle to roles. No need to rip out SSO or directory; add ENI6MA at the gates that matter.

Fictitious partner example: TechFlow Inc. TechFlow is a SaaS company that runs infrastructure and deployments for enterprise clients. Their internal platform has admin consoles, Terraform pipelines, and a treasury approval workflow. Previously, once an engineer logged in with SSO they had broad access for hours; a stolen session or a malicious insider could approve deployments or move funds. They introduced ENI6MA policy gates: every “Approve production deploy,” “Run Terraform apply,” and “Approve wire over $X” requires a fresh proof. The backend requests a challenge from the Registry (optionally with x-eni6ma-ledger-url for their dedicated ledger), shows the six-zone ceremony in the same UI, and on validated proof allows the action and logs it. Risks and attack vectors addressed: (1) Session hijacking — a stolen cookie no longer authorizes privileged actions; each action needs a new proof. (2) Insider threat — an insider cannot hand over a “master token”; they would need to re-perform the ceremony for each action, and every action is tied to a nonce and circuit hash in the Ledger. (3) Credential reuse — there are no long-lived deploy tokens or API keys for approvals; rotation is recompile and policy update. (4) Audit and compliance — Ledger events give “circuit H, nonce N, time T” for every gate; no PII, no secrets in the trail, so SOC 2 and PCI-DSS evidence is straightforward. (5) Revocation — when an engineer leaves or a circuit is compromised, TechFlow removes that circuit hash from the policy allowlist; the next proof from that circuit is rejected. No CRL or token revocation delay.

Use Case 3: High-Value Financial Transactions and Approvals

What it is: Each critical financial action—large transfer, mandate change, release of funds, treasury approval—requires a one-time proof bound to a ledger nonce. No long-lived token or cookie can be replayed; stolen session capture does not yield future access. This aligns with regulatory focus on ICT risk and operational resilience (e.g. DORA): authentication is per-event authorization, not a static credential.

How it works: For each critical action, the backend requests a challenge: POST /api/circuits/{handle}/challenge. The Registry reserves a nonce from the Ledger (uuid, tau), runs the circuit binary to generate the challenge geometry, and returns nonce_uuid, tau, and challenge data. The backend issues the challenge to the user or to the treasury circuit (human or agent). User/agent runs the circuit (locally or via POST .../cli/validate-proof with the proof payload) and returns the proof. Backend calls POST /api/circuits/{handle}/validate with the proof; the Registry first burns the nonce via Ledger POST /response. Only after successful burn does the Registry run the binary to verify the proof. Once committed, that nonce cannot be reused (replay returns 409); unused nonces expire (410 after TTL). Audit: Ledger events and optional visibility service provide “circuit H, nonce N, time T, payload hash” for regulators; no PII or secrets in the trail.

CLI/Registry/Ledger mapping: Registry: POST .../challenge, POST .../validate; GET .../verify for integrity. Ledger: Reserve on challenge, consume on validate; 409 on replay, 410 on expiry. CLI: challenge, validate-response, validate-proof; for programmatic treasury flows, POST /api/circuits/{handle}/cli/validate-proof with payload.

Why ENI6MA is better: Banks and fintechs today rely on passwords, OTPs, and session tokens. A compromised session or phished OTP can authorize irreversible transfers. ENI6MA ties each approval to a single nonce and timestamp; replay is impossible at the infrastructure layer. Audit trails are non-PII (circuit hash, nonce, time, payload hash)—suitable for regulators without storing secrets. Rotation is recompile and policy update, not key distribution or cert renewal. There is no “approval token” that can be replayed for a second transaction.

Diagram, integration context, and partner example (Use Case 3)

Rendering diagram…

Integration context for existing systems. High-value financial flows typically sit in a core banking or treasury app that already has user identity, limits, and audit. ENI6MA plugs in at the “approve” step: before the system executes an irreversible action (wire, mandate change, release of funds), it requests a challenge from the Registry, presents the ceremony to the human or treasury circuit, and only on validated proof calls the existing execution path. The existing system still does KYC, limits, and sanctions; ENI6MA adds a per-event, non-replayable authorization proof. Back-office and regulators can use Ledger events (and optional visibility service) to see which circuit approved which nonce at which time, with no credentials in the trail. Integration is the same three API calls; the only change is that the “approver” is identified by circuit hash and proof instead of a password or OTP.

Fictitious partner example: NorthStar Treasury. NorthStar Treasury is a corporate treasury platform used by large enterprises to approve wires, mandate changes, and funding releases. They previously used password + hardware OTP for approvers; they faced replay risk (if an OTP or session was captured, it could be used before expiry), phishing of approvers, and regulatory pressure to show “who approved what and when” without storing more PII. They integrated ENI6MA so that every critical action (e.g. wire over threshold, mandate change) requires a fresh proof: backend requests challenge, approver completes the six-zone ceremony, backend validates and then runs the existing execution engine. Risks and attack vectors addressed: (1) OTP replay and capture — there is no OTP; the proof is one-time and burned, so capture is useless. (2) Session hijacking — a stolen session cannot approve a new transaction without a new proof. (3) Phishing — a fake approval page cannot get a valid nonce or challenge from the real Registry/Ledger. (4) Regulatory audit — Ledger provides non-PII evidence (circuit hash, nonce, time, payload hash) for DORA-style ICT risk and operational resilience. (5) Insider and approver compromise — revocation is immediate (remove circuit hash); no waiting for token or cert revocation.

Use Case 4: Machine and API Identity (No Static API Keys)

What it is: Services and scripts authenticate to each other or to APIs using circuit-based proofs instead of static API keys or client certificates. Each service holds a compiled circuit; mutual auth is challenge–validate in both directions.

How it works: Service A (verifier) requests a challenge for Service B’s handle: POST /api/circuits/{handle-B}/challenge. Service B (prover) runs its circuit with the returned tau (or uses Registry CLI proxy POST /api/circuits/{handle-B}/cli/validate-proof with the proof payload). Service A submits the proof to POST /api/circuits/{handle-B}/validate. On success, A treats B as authenticated. For mutual auth, B then challenges A’s handle and the flow repeats. Rotation is recompile, upload, update latest pointer, and optionally restrict Ledger/registry policy to the new circuit hash; no key distribution or cert renewal.

CLI/Registry/Ledger mapping: Registry: POST .../challenge, POST .../validate; POST .../cli/{command} for running binary commands (e.g. validate-proof) with payload. Ledger: Reserve on challenge, consume on validate; same replay and expiry semantics. CLI: challenge, validate-response, validate-proof; nonce-interactive or interactive for custom flows. Binaries: GET /api/binaries/handle/{handle} for distribution.

Why ENI6MA is better: API keys and client certs are long-lived secrets; leakage grants access until rotation. ENI6MA gives per-event proof: each call can require a fresh challenge–proof pair. Keys are not stored on servers; “rotation” is recompile and policy update. Compromise of the API server yields no reusable credential; the circuit binary alone cannot authenticate without the prover’s ability to complete the proof (e.g. embedded secrets and mapping).

Diagram, integration context, and partner example (Use Case 4)

Rendering diagram…

Integration context for existing systems. Machine and API identity can replace or sit alongside existing service auth (API keys, mTLS, OAuth client credentials). Service A (verifier) calls the Registry to get a challenge for Service B’s handle; Service B (prover) runs its circuit—locally or via POST .../cli/validate-proof—and returns the proof; A submits the proof to the Registry for validation. The existing API layer can stay: instead of checking an API key in a header, it triggers this challenge–validate flow and only allows the request if the proof is valid. Mutual auth is two such flows (A challenges B, then B challenges A). Existing key vaults or secret managers are no longer the source of service-to-service secrets; the “secret” is the ability to produce a proof from the circuit, and rotation is recompile and policy.

Fictitious partner example: CloudMesh APIs. CloudMesh runs a multi-tenant API platform where tenant services call each other and call CloudMesh’s control plane. They previously used static API keys and client certificates; keys leaked from configs and repos, and rotation was painful. They adopted ENI6MA for service identity: each tenant service has a circuit (handle); when Service A needs to call Service B or the control plane, the verifier requests a challenge for the prover’s handle, the prover produces a proof (via its circuit, often via Registry CLI proxy), and the verifier validates. Risks and attack vectors addressed: (1) API key leakage — no long-lived key; each call can use a fresh proof. (2) Cert and key rotation — rotation is recompile, upload, update policy; no cert distribution or CRL. (3) Server compromise — if the API server is compromised, there are no stored API keys or client certs to exfiltrate. (4) Replay — each proof is bound to one nonce; Ledger rejects replay (409). (5) Audit — Ledger events show which circuit (hash) proved for which nonce when, for compliance and forensics.

Use Case 5: Agent-to-Agent Authentication (A2A / Oscillation)

What it is: AI agents or autonomous services authenticate each other using symmetric circuit clones—two instances of the same circuit binary that can generate and verify each other’s proofs without a central authority, API key, or token.

How it works: Each agent runs the same circuit (same handle/build or same compiled config). They use the A2A oscillation protocol: bidirectional entropy exchange, sealed messages that only the other can open (e.g. Kyber768 + X25519 in hybrid builds). In each cycle, one agent seals a message, the other unseals and responds with its own sealed message; after multiple rounds, mutual authentication and shared session context are established. Optionally, challenge–validate flows go through the Registry and Ledger for nonce binding and audit.

CLI/Registry/Ledger mapping: CLI: Hybrid binary commands for agent init, respond-interactive, validate-proof; client, verifier for prover/verifier roles. Registry: POST .../challenge, POST .../validate and POST .../cli/... for remote execution. Ledger: Used when proofs are validated via Registry (reserve, burn, events). Sovereign/offline mode can use a local ledger snapshot and sync when connected.

Why ENI6MA is better: Agent-to-agent auth today relies on shared secrets or PKI; both create long-lived artifacts that can be stolen from an agent’s environment. ENI6MA’s symmetric clones allow mutual proof without storing each other’s secrets; each proof is one-time and time-bound. Sovereign mode supports air-gapped or intermittent connectivity with deferred ledger sync—no other system offers offline-capable, mutually authenticated A2A proof ceremonies with that property.

Diagram, integration context, and partner example (Use Case 5)

Rendering diagram…

Integration context for existing systems. A2A fits into agent orchestration and workflow engines where agents need to trust each other without a central token server. Each agent is provisioned with the same circuit binary (symmetric clone) or with circuits that are mutually accepted (e.g. by hash). The oscillation protocol runs between agents (seal/unseal cycles); optionally, challenge–validate flows go through the Registry and Ledger so that each proof is bound to a nonce and auditable. In sovereign or offline deployments, agents use a local ledger snapshot and sync when connected; the same proof semantics apply. Existing agent frameworks can call ENI6MA as a library or via the Registry CLI proxy; no need to replace the whole orchestration stack.

Fictitious partner example: AutoScale AI. AutoScale AI runs autonomous scaling and cost-optimization agents that talk to cloud APIs and to each other. They previously used shared API keys and service-account tokens; keys were found in logs and one agent’s compromise could impersonate others. They moved to ENI6MA A2A: each agent runs a clone of the same circuit; agents authenticate via the oscillation protocol (seal/unseal), and for audit-sensitive actions they also run challenge–validate through the Registry so each proof is logged on the Ledger. Risks and attack vectors addressed: (1) Key exfiltration from agent — there is no long-lived shared secret; mutual auth is proof-based. (2) Agent impersonation — only an agent with the circuit and ability to complete the proof can authenticate. (3) Offline and edge — in sovereign mode, agents use a local ledger snapshot and sync when online; no dependency on central auth at runtime. (4) Audit — when online, Ledger records which circuit (hash) proved for which nonce, for compliance. (5) Rotation — new circuit, re-deploy to agents, update policy; no key distribution.

Use Case 6: Blockchain and Digital Custody (Enigma-ECDSA Bridge)

What it is: Signing of Bitcoin or Ethereum transactions (or other ECDSA/secp256k1 operations) is gated by an ENI6MA proof. The signing key is derived from the circuit’s entropy pool and is only materialized after a successful interactive proof; the circuit binary alone cannot sign without the user’s knowledge.

How it works: User (or agent) completes a challenge–proof ceremony. The confirmed entropy indices from the proof are used to derive deterministic signing keys via the circuit’s secp256k1 implementation. The circuit exposes sign-msg, verify-msg, ethereum-address, sign-ethereum-tx, verify-ethereum-tx (and Bitcoin-oriented signing in eni6ma-btc). These are invoked locally or via Registry: POST /api/circuits/{handle}/cli/sign-msg, POST .../cli/sign-ethereum-tx, etc., with appropriate flags and payloads. OP_RETURN encryption/decryption (opret-encrypt, opret-decrypt) uses the circuit’s prime to seed a BLAKE3-XOF stream for on-chain private metadata.

CLI/Registry/Ledger mapping: CLI: sign-msg, verify-msg, opret-encrypt, opret-decrypt, ethereum-address, sign-ethereum-tx, verify-ethereum-tx; enigma-hash for nonce matrix hash (debug). Registry: POST /api/circuits/{handle}/cli/{command} for each of these. Ledger: Challenge–validate flows that gate signing use reserve/consume; signing itself is a local binary operation after proof success.

Why ENI6MA is better: Traditional custody depends on protecting a private key; extraction means total loss. ENI6MA transforms custody into “proof work for every transaction.” The key is not a file to copy—it is derived only after a successful proof. Institutional custody gains an auditable, time-bound authorization event per spend; compromise of an endpoint cannot silently sign without the proof ceremony.

Diagram, integration context, and partner example (Use Case 6)

Rendering diagram…

Integration context for existing systems. Blockchain and custody systems today hold private keys in HSMs, vaults, or hot wallets. ENI6MA adds a proof gate before any signing: the user (or authorized process) completes a challenge–proof ceremony; only then does the circuit derive the signing key and execute sign-msg, sign-ethereum-tx, or Bitcoin signing. The existing wallet or custody UI can call the Registry for challenge and validate, then invoke the circuit (locally or via POST .../cli/sign-ethereum-tx etc.) with the same session. OP_RETURN encrypt/decrypt (opret-encrypt, opret-decrypt) uses the circuit’s prime for on-chain private metadata; only the same circuit can decrypt. Integration keeps the existing chain and wallet logic; ENI6MA is the authorization and key-derivation layer.

Fictitious partner example: VaultChain Custody. VaultChain provides institutional custody for Bitcoin and Ethereum. They previously relied on HSMs and multi-sig; key extraction and insider threats remained a concern, and auditors wanted per-transaction authorization evidence. They integrated the Enigma-ECDSA bridge: every sign operation requires a successful ENI6MA proof first. The custody operator (or an approved agent) completes the ceremony; the circuit then derives the key and signs. Risks and attack vectors addressed: (1) Key extraction — the key is not stored; it is derived at signing time after proof. (2) Silent signing by compromised endpoint — without the proof ceremony, the circuit does not sign. (3) Replay — each proof is one-time (Ledger burn); no reusing a proof for another tx. (4) Audit — Ledger and optional access-log provide “proof for nonce N at time T” per transaction for regulators. (5) OP_RETURN privacy — metadata can be encrypted with the circuit’s prime so only the intended circuit can read it on-chain.

Use Case 7: Healthcare PHI and Clinical System Access

What it is: Access to PHI and clinical systems is proof-based; no central password or token store. Each access can be tied to a unique nonce and logged as “proof succeeded for circuit hash H at time T,” supporting HIPAA-style minimum necessary access and access logging without storing secrets or biometric templates.

How it works: Clinicians or systems prove identity via the interactive ceremony (or an agent with the circuit). Backend requests POST /api/circuits/{handle}/challenge, presents the challenge, collects the proof, and calls POST /api/circuits/{handle}/validate. Ledger records reserve, consume, and optionally access-log; logs record authorization events (proof + nonce + hash) without sensitive content. Breach of the log store does not yield reusable credentials.

CLI/Registry/Ledger mapping: Registry: POST .../challenge, POST .../validate; GET .../verify for circuit integrity. Ledger: Reserve, consume, GET /events for audit. CLI: challenge, validate-response, validate-proof for local or scripted access flows.

Why ENI6MA is better: Passwords and tokens in healthcare are high-value targets; stolen credentials enable broad PHI access. ENI6MA provides access logging and non-PII audit trails by design; no credential database to encrypt or breach. Revocation is immediate (remove hash from policy); rotation is recompile and policy update.

Diagram, integration context, and partner example (Use Case 7)

Rendering diagram…

Integration context for existing systems. Healthcare apps (EHR, clinical portals, medical devices) typically use username/password and sometimes smart cards or SSO. ENI6MA plugs in as the authentication step for PHI access: the app requests a challenge, presents the ceremony to the clinician (or system with a circuit), and on validated proof grants access and logs the event. The existing EHR still enforces role and resource permissions; ENI6MA adds proof-based identity and a non-PII audit trail (circuit hash, nonce, time). No need to store passwords or biometric templates; breach of the log store does not yield reusable credentials. HIPAA-style “minimum necessary” and access logging are met by logging “proof for circuit H at time T” without storing secrets.

Fictitious partner example: MedFirst Health Network. MedFirst runs hospitals and clinics with a shared EHR and clinical portals. They suffered phishing of clinician credentials, shared passwords, and audit findings about credential storage and access logging. They deployed ENI6MA for clinician and system access to PHI: each access (or each high-sensitivity view) requires a proof. The EHR backend calls the Registry for challenge and validate; the Ledger records reserve and consume; internal logs record “circuit H, nonce N, time T” for every access. Risks and attack vectors addressed: (1) Phishing of clinician credentials — there is no password to type on a fake site; proof is non-replayable and bound to the real Registry/Ledger. (2) Credential sharing — the proof requires the circuit and cognitive key; sharing is harder and each use is logged. (3) Database breach — no credential or biometric store to steal; logs are non-PII. (4) Access audit — Ledger and app logs provide “who (circuit hash) accessed when” for HIPAA and internal audit. (5) Revocation — when a clinician leaves or a device is lost, MedFirst removes the circuit hash from policy; next proof from that circuit fails.

Use Case 8: IoT, Edge, and Mesh Device Authentication

What it is: Devices hold circuit binaries and authenticate each other via challenge–validate; no central CA or online OCSP. In mesh or edge deployments, each node can run a circuit; trust is “do we share the same circuit (or mutually accepted hashes)?” and “did the other side pass a fresh proof?”

How it works: Devices obtain circuits from the Registry (GET /api/binaries/handle/{handle} or build-specific path) or from a sovereign cache. They challenge each other (e.g. one device requests a challenge for the other’s handle from Registry, or uses a local challenge generator in sovereign mode). Proof is generated locally and validated via Registry or locally with a verifier binary. Ledger is used when online (reserve, burn); sovereign mode uses a local snapshot and syncs when connected. Provisioning is “deploy this binary (hash)”; revocation is “stop accepting that hash” and burn nonces.

CLI/Registry/Ledger mapping: Registry: GET /api/circuits, GET /api/binaries/..., POST .../challenge, POST .../validate, GET .../verify. Ledger: Reserve/consume for online flows; visibility/events for audit. CLI: challenge, validate-response, validate-proof, verifier, client; ledger/status, ledger/tx when ledger is available.

Why ENI6MA is better: PKI for IoT scales poorly (cert distribution, CRL, OCSP). Pre-shared keys in firmware are extractable. ENI6MA’s symmetric compiled twins and per-proof verification reduce dependency on connectivity to a central authority and avoid a single vault of keys; fleet updates are “compile new circuit, push to registry, update policy to accept new hash.”

Diagram, integration context, and partner example (Use Case 8)

Rendering diagram…

Integration context for existing systems. IoT and edge deployments today use PKI (device certs, CA, OCSP) or pre-shared keys. ENI6MA offers an alternative: devices hold circuit binaries (from Registry or sovereign cache) and authenticate each other via challenge–validate. When online, the Registry and Ledger provide nonce reservation and burn; when offline, sovereign mode uses a local ledger snapshot and syncs later. The existing device management and fleet orchestration can stay; ENI6MA is the identity and auth layer. Provisioning is “deploy this binary (hash)”; revocation is “stop accepting that hash” and optionally expire nonces; no cert distribution or CRL propagation.

Fictitious partner example: GridSense Industrial. GridSense deploys thousands of field sensors and gateways that communicate in a mesh. They previously used device certs and a central CA; cert renewal and OCSP were costly and connectivity to the CA was not always available. They adopted ENI6MA: each device (or device class) has a circuit; devices challenge each other and validate proofs. When the mesh has connectivity, they use the Registry and Ledger; when offline, they use a sovereign snapshot and sync when back online. Risks and attack vectors addressed: (1) Cert and key extraction from firmware — the circuit binary alone cannot authenticate without the proof; no static key to dump. (2) Central CA dependency — no online OCSP; devices can authenticate peer-to-peer with local or synced ledger. (3) Fleet compromise — revocation is “reject this circuit hash”; no need to push revocations to every device. (4) Scale — provisioning is “push binary (hash)”; rotation is new circuit and policy update. (5) Audit — when online, Ledger records which device (circuit hash) proved for which nonce, for forensics.

Use Case 9: Sovereign and Air-Gapped Deployment

What it is: Sites or device fleets operate without continuous access to the central platform. A ledger snapshot is stored locally in encrypted form; proof ceremonies run offline. When connectivity is restored, local operations synchronize to the cloud ledger.

How it works: Sovereign mode (or equivalent) downloads a ledger snapshot and caches circuits. Challenge generation and proof validation use local entropy and local ledger state; no live call to the central Registry or Ledger during the ceremony. When back online, local reserve/consume events are synced so the cloud ledger has a complete audit trail. Circuits are imported by handle or SHA256 from the Registry when connected; GET /api/circuits/{handle}/verify and GET /api/binaries/... support integrity and download.

CLI/Registry/Ledger mapping: CLI: Full binary command set locally: challenge, validate-response, validate-proof, ledger/status, ledger/tx, signing, etc. Registry: Used only when connected: index, verify, binaries, challenge/validate if delegating to cloud. Ledger: Local snapshot for offline reserve/consume; sync when connected; visibility service for read-only audit when available.

Why ENI6MA is better: No other mainstream auth system supports fully offline, mutually authenticated proof ceremonies with deferred ledger sync. Military, industrial, and high-security sites can run ENI6MA in air-gapped segments while retaining audit continuity when connectivity returns.

Diagram, integration context, and partner example (Use Case 9)

Rendering diagram…

Integration context for existing systems. Sovereign and air-gapped deployments run ENI6MA without live access to the central Registry or Ledger. A local proxy (or sovereign node) holds a ledger snapshot (encrypted) and a cache of circuits. Challenge generation and proof validation use local entropy and local ledger state; no outbound call during the ceremony. When connectivity is restored, local reserve/consume events sync to the cloud Ledger so the full audit trail is preserved. Circuits can be imported by handle or SHA256 from the Registry when connected; GET /api/circuits/{handle}/verify and GET /api/binaries/... support integrity and download. Existing air-gap procedures (sneakernet, approved data diodes) can carry snapshot and binary updates.

Fictitious partner example: SecureDefense Labs. SecureDefense Labs runs classified research in air-gapped networks. They need strong mutual authentication between systems and users but cannot depend on real-time access to the internet or a central auth service. They deployed ENI6MA in sovereign mode: a local ledger snapshot and circuit cache are updated via approved transfer when connectivity is available; inside the air gap, all proof ceremonies run offline. When data is allowed to leave the segment, local ledger events are synced so the central Ledger has a complete audit trail. Risks and attack vectors addressed: (1) No live dependency — auth works fully offline; no single point of failure to the internet. (2) Mutual authentication — symmetric circuit clones and per-proof verification without shared secrets. (3) Audit continuity — sync when connected gives regulators and internal audit a full trail. (4) Key and credential elimination — no passwords or long-lived keys to protect in the segment. (5) Rotation — new circuits and snapshot updates via approved process; no CRL or online OCSP.

Use Case 10: Deployment and CI/CD Approval Gates

What it is: Deployment pipelines or CI jobs require a human or system to prove identity before triggering a release. Each approval is a one-time proof bound to a nonce; no long-lived deploy token can be replayed.

How it works: Pipeline reaches an approval step; backend requests POST /api/circuits/{handle}/challenge for the approver’s circuit. Approver completes the ceremony (or an agent with the circuit returns the proof). Backend calls POST /api/circuits/{handle}/validate; on success, the pipeline proceeds. Ledger records the event; auditors see which circuit (hash) approved which nonce at which time. Optional: use POST /api/circuits/{handle}/cli/validate-proof with a precomputed payload for scripted approvers.

CLI/Registry/Ledger mapping: Registry: POST .../challenge, POST .../validate; POST .../cli/validate-proof for automation. Ledger: Reserve on challenge, consume on validate; 409 replay, 410 expiry. CLI: challenge, validate-response, validate-proof for local or scripted gates.

Why ENI6MA is better: Deploy tokens and approval APIs often rely on static tokens or long-lived sessions; compromise allows repeated unauthorized releases. ENI6MA gates each approval with a single-use proof and full audit trail without storing secrets.

Diagram, integration context, and partner example (Use Case 10)

Rendering diagram…

Integration context for existing systems. CI/CD and deployment pipelines usually have an approval step (human or automated). That step can call the Registry for a challenge, present the ceremony to the approver (human or agent with circuit), and only on validated proof allow the pipeline to continue. The existing pipeline (GitHub Actions, GitLab, Jenkins, etc.) keeps its structure; the approval gate is “validate ENI6MA proof” instead of “check deploy token” or “wait for manual click.” Optional: for scripted approvers, the pipeline can call POST .../cli/validate-proof with a precomputed payload. Ledger records every approval (circuit hash, nonce, time) for compliance and incident review.

Fictitious partner example: ShipRight DevOps. ShipRight runs CI/CD for multiple product teams; production deploys require approval. They previously used long-lived deploy tokens and “approve” buttons that could be abused if a session was hijacked. They integrated ENI6MA: at the approval step, the pipeline requests a challenge, the approver (human or designated agent) completes the ceremony, and the pipeline validates the proof before proceeding. Risks and attack vectors addressed: (1) Deploy token theft — no static token; each approval is a one-time proof. (2) Session hijacking — a stolen session cannot approve without the proof ceremony. (3) Replay — each proof burns a nonce; Ledger rejects replay (409). (4) Audit — Ledger shows which circuit (hash) approved which nonce at which time for every release. (5) Revocation — when an approver leaves, remove circuit hash from policy; no token revocation delay.

Use Case 11: Message Signing and Verification

What it is: Documents or messages are signed using the circuit’s derived key (enigma-gated); only someone who can complete the proof ceremony can produce a valid signature. Verifiers use the same circuit or public material to verify.

How it works: Signer runs the proof ceremony (or has already done so in the same session), then invokes sign-msg with the message (and optional flags). The binary produces a signature. Verifier uses verify-msg with message and signature (and circuit or public params). Commands can be run locally or via Registry: POST /api/circuits/{handle}/cli/sign-msg, POST .../cli/verify-msg.

CLI/Registry/Ledger mapping: CLI: sign-msg, verify-msg (with flags as per swagger/flagsByCommand). Registry: POST .../cli/sign-msg, POST .../cli/verify-msg. Ledger: Not required for sign/verify alone; if signing is gated by a prior challenge–validate, that flow uses reserve/consume.

Why ENI6MA is better: Traditional signing relies on a stored private key; compromise allows unlimited forgeries. ENI6MA ties signing capability to proof-of-knowledge; the key is derived and used in a controlled way, and there is no persistent key file to steal.

Diagram, integration context, and partner example (Use Case 11)

Rendering diagram…

Integration context for existing systems. Document or message signing today uses stored private keys (files, HSMs). ENI6MA adds a proof gate: the signer completes the ceremony (or has already done so in the same session), then invokes sign-msg; the circuit derives the key and signs. Verifiers use verify-msg with the message and signature (and circuit or public params). Existing doc workflows (e.g. contract signing, audit logs) can keep their format; the only change is that the “signing key” is proof-gated and not stored. Commands run locally or via Registry: POST .../cli/sign-msg, POST .../cli/verify-msg. If signing is gated by challenge–validate, that flow uses Ledger reserve/consume.

Fictitious partner example: DocSign Pro. DocSign Pro offers legally binding document signing. They previously relied on stored private keys per user; key compromise meant unlimited forgeries until detection. They integrated ENI6MA: to sign, the user completes the proof ceremony, then the circuit runs sign-msg on the document hash. Verifiers use verify-msg with the same circuit or public material. Risks and attack vectors addressed: (1) Key theft — no persistent key file; key is derived at sign time after proof. (2) Unlimited forgeries — each sign action can require a fresh proof (and nonce), limiting blast radius. (3) Non-repudiation — proof and Ledger (if used) tie the sign event to a nonce and time. (4) Rotation — new circuit, new hash; no key escrow or recovery that could be abused. (5) Audit — if proof is Ledger-bound, “circuit H signed for nonce N at time T” is available without storing secrets.

Use Case 12: OP_RETURN Encrypted Metadata (On-Chain Privacy)

What it is: Arbitrary metadata is encrypted with the circuit’s prime (BLAKE3-XOF stream) and embedded in a blockchain transaction’s OP_RETURN field. Only circuits compiled with the same prime can decrypt, enabling private channels on public chains.

How it works: Sender uses opret-encrypt with plaintext and optional params; receiver uses opret-decrypt with ciphertext. Both are run via the circuit binary (local or Registry): POST /api/circuits/{handle}/cli/opret-encrypt, POST .../cli/opret-decrypt.

CLI/Registry/Ledger mapping: CLI: opret-encrypt, opret-decrypt. Registry: POST .../cli/opret-encrypt, POST .../cli/opret-decrypt. Ledger: No direct use; optional if encryption is gated by a proof (challenge–validate uses Ledger).

Why ENI6MA is better: On-chain data is typically public. OP_RETURN encryption with circuit-bound keys gives “visible but unreadable” metadata and avoids separate key exchange; only the intended circuit (same config/prime) can decrypt.

Diagram, integration context, and partner example (Use Case 12)

Rendering diagram…

Integration context for existing systems. Blockchains that support OP_RETURN (e.g. Bitcoin) or similar metadata fields are public; anyone can read the data. ENI6MA’s opret-encrypt and opret-decrypt use the circuit’s prime to seed a BLAKE3-XOF stream so that only a circuit with the same prime (same config) can decrypt. The existing wallet or chain integration stays; ENI6MA is the encryption/decryption layer. No separate key exchange or key agreement protocol is needed; the “key” is the circuit’s embedded prime. Optional: gate encryption/decryption with a proof (challenge–validate) so only an authenticated user can run opret-*.

Fictitious partner example: ChainMemo. ChainMemo lets users attach short memos to Bitcoin transactions for accounting or compliance; they wanted memos to be private between sender and receiver. They integrated ENI6MA OP_RETURN: the sender runs opret-encrypt with the memo (and optional params), embeds the ciphertext in OP_RETURN; the receiver runs opret-decrypt with their matching circuit. Risks and attack vectors addressed: (1) Public metadata — memos are encrypted; only the intended circuit can decrypt. (2) Key exchange — no separate key agreement; the circuit’s prime is the shared secret (only both parties have it via same config). (3) Replay of ciphertext — ciphertext is bound to the tx; replay does not reveal new info. (4) Supply chain — if encryption is gated by proof, only authenticated user can create valid ciphertext. (5) Audit — chain still shows that a tx has metadata; content is hidden from third parties.

Use Case 13: Ethereum Address Derivation and Transaction Signing

What it is: Ethereum addresses and transaction signatures are derived from the circuit’s entropy and gated by the proof ceremony. Used for wallet integration, agent-controlled wallets, or institutional custody with proof-per-transaction.

How it works: Circuit exposes ethereum-address, sign-ethereum-tx, verify-ethereum-tx. After proof (or in a flow that requires proof before signing), the binary derives the address or signs the tx. Invoked locally or via Registry: POST /api/circuits/{handle}/cli/ethereum-address, POST .../cli/sign-ethereum-tx, POST .../cli/verify-ethereum-tx.

CLI/Registry/Ledger mapping: CLI: ethereum-address, sign-ethereum-tx, verify-ethereum-tx. Registry: Same via POST .../cli/{command}. Ledger: Challenge–validate flows that gate signing use reserve/consume.

Why ENI6MA is better: Hot wallets and API keys for signing are single points of failure. ENI6MA keeps the signing key derivation inside the circuit and requires proof for each signing action; no long-lived key at rest.

Diagram, integration context, and partner example (Use Case 13)

Rendering diagram…

Integration context for existing systems. Ethereum wallets and custody systems hold private keys in hot or cold storage. ENI6MA gates signing: after proof (challenge–validate if desired), the circuit runs ethereum-address, sign-ethereum-tx, or verify-ethereum-tx. The existing wallet UI or backend can call the Registry for challenge/validate, then invoke the circuit (local or POST .../cli/sign-ethereum-tx) with the tx payload. Ledger reserve/consume can be used to bind each sign action to a nonce for audit. No change to Ethereum protocol or node; the key is derived inside the circuit and never stored.

Fictitious partner example: EthVault Finance. EthVault provides Ethereum custody for institutions. They previously used HSMs and hot wallets; key extraction and insider risk were concerns. They integrated ENI6MA: every Ethereum sign requires a proof first; the circuit then derives the key and runs sign-ethereum-tx. Risks and attack vectors addressed: (1) Key extraction — key is not at rest; derived at sign time after proof. (2) Silent signing — compromised endpoint cannot sign without the ceremony. (3) Replay — if proof is Ledger-bound, each sign uses one nonce. (4) Audit — Ledger (and optional access-log) provides “proof for nonce N at time T” per transaction. (5) Rotation — new circuit, new derivation path; no key backup to steal.

Use Case 14: Audit and Compliance (Ledger Trails, No PII)

What it is: Every authentication or proof event is recorded on the Ledger with nonce, tau, payload hash, and status (reserved, spent, expired). Auditors and compliance teams get “who (circuit hash) proved what (nonce) when” without stored secrets or PII.

How it works: Ledger exposes POST /reserve, POST /response (consume), GET /status/{uuid}, GET /events. Registry uses these during challenge and validate; optional POST /access-log, POST /success record access and success. Visibility service at ledger.eni6ma.net (or equivalent) provides read-only events. Scripts and operators can use ledger/status, ledger/tx via CLI proxy: POST /api/circuits/{handle}/cli/ledger/status, POST .../cli/ledger/tx.

CLI/Registry/Ledger mapping: Ledger: Reserve, consume, status, events; TTL and replay (409/410) are part of the lifecycle. Registry: Challenge/validate drive reserve and consume; verify and index support circuit integrity. CLI: ledger/status, ledger/tx, ledger/mine (if supported) via Registry CLI proxy.

Why ENI6MA is better: Traditional audit trails often log credentials or tokens (hashed or not); breach or misuse can still be high impact. ENI6MA’s ledger stores no secrets—only nonce lifecycle and payload hashes—so compliance evidence is strong without increasing exposure.

Diagram, integration context, and partner example (Use Case 14)

Rendering diagram…

Integration context for existing systems. Audit and compliance teams need “who did what when” without storing credentials or PII. The Ledger is the source: every challenge triggers a reserve (nonce, tau); every validate triggers a consume (burn). Optional access-log and success endpoints record additional context. The visibility service (e.g. ledger.eni6ma.net) or internal GET /events exposes read-only events. Existing SIEM, compliance tools, and regulators can consume this feed; the format is nonce lifecycle and payload hashes, not secrets. Registry challenge/validate drive the writes; CLI ledger/status, ledger/tx (via Registry proxy) support operational checks.

Fictitious partner example: AuditFirst Corp. AuditFirst provides compliance and audit services to regulated firms. Their clients needed evidence of “who authenticated when” without exposing credentials or PII in the audit trail. They integrated ENI6MA and the Ledger: every client authentication (challenge–validate) is recorded on the Ledger (reserve, consume, optional success). AuditFirst’s compliance dashboard reads from the Ledger visibility/events and shows “circuit H, nonce N, time T, payload hash” per event. Risks and attack vectors addressed: (1) Credential exposure in logs — Ledger stores no secrets; only lifecycle and hashes. (2) PII in audit — no user secrets or tokens in the trail; compliance without privacy loss. (3) Tampering — Ledger is immutable; append-only reserve/consume. (4) Replay and nonce misuse — 409/410 and tau binding are visible in events. (5) Regulator acceptance — evidence is falsifiable and linkable to artifacts (nonce, time, hash).

Use Case 15: Phishing-Resistant Authentication

What it is: Users never type a reusable secret into a page. A phishing site cannot present a valid ENI6MA challenge because it cannot obtain a nonce from the real Ledger or generate a valid challenge from the real Registry; any captured response is bound to a single nonce and cannot be replayed elsewhere.

How it works: Legitimate app uses Registry POST .../challenge (which reserves a nonce from the Ledger) and returns challenge data. User completes the ceremony and submits proof to POST .../validate. A phishing site has no valid nonce and no access to the Registry/Ledger; a copied challenge UI would yield a proof that either does not match any real nonce or is already burned. Ledger burn-before-validate and TTL ensure one-time, time-bound use.

CLI/Registry/Ledger mapping: Registry: POST .../challenge, POST .../validate. Ledger: Reserve (only by legitimate service), consume on first validate; replay 409, expiry 410. CLI: Same semantics when binary is used with Registry for challenge/validate.

Why ENI6MA is better: Phishing succeeds against passwords and OTPs because the user delivers a reusable or replayable secret. ENI6MA’s proof is non-replayable and bound to the nonce issued by the real infrastructure; the attacker cannot complete the chain without controlling the Registry and Ledger.

Diagram, integration context, and partner example (Use Case 15)

Rendering diagram…

Integration context for existing systems. Phishing resistance is a property of the ENI6MA flow: the legitimate app obtains a challenge from the Registry (which reserves a nonce from the Ledger). A phishing site has no access to the real Registry or Ledger; it cannot obtain a valid nonce or generate a valid challenge. If the user is tricked and completes the ceremony on the fake page, the proof they produce is either for a nonce the attacker made up (validation fails) or for a nonce the attacker cannot use (already burned or bound to another session). The existing app only needs to use the three-call flow (challenge from Registry, ceremony, validate to Registry); no extra “phishing detection” layer is required.

Fictitious partner example: PaySure Wallet. PaySure is a consumer payments app; users had been phished with fake login pages that stole passwords and OTPs. They switched to ENI6MA for login: the app requests the challenge from the Registry and shows the six-zone ceremony. A phishing site cannot get a valid challenge (no Registry/Ledger access), so any “proof” the user enters on the fake page is useless—validation fails or the nonce is not the attacker’s. Risks and attack vectors addressed: (1) Credential harvesting — there is no password or OTP to type; the user only completes a ceremony that is bound to the real app’s nonce. (2) Real-time proxy attacks — even if the attacker relays the real challenge to the user, the proof goes to the real Registry and burns the nonce; the attacker cannot reuse it. (3) Replay — Ledger burn-before-validate and TTL ensure one-time, time-bound use. (4) User habit — users learn “only complete the grid on the real app”; no secret to accidentally type on a fake form. (5) No credential DB to breach — breach of PaySure’s systems does not yield credentials; only circuit metadata and Ledger audit.

Use Case 16: Instant Revocation (Hash-Based Policy)

What it is: Revoking a compromised or departed identity is immediate: remove the circuit’s SHA256 hash from the authorized set (allowlist). The next authentication attempt for that circuit fails at policy check; no CRL propagation, no OCSP, no delay.

How it works: Policy engine (or registry/backend) maintains a set of accepted circuit hashes per handle or per resource. After revocation, that hash is removed. When a proof is submitted to POST /api/circuits/{handle}/validate, the Registry resolves the circuit (e.g. latest build or by hash); if the resolved hash is not in the allowed set, validation is rejected before or after Ledger consume. Ledger still records the attempt (e.g. access-log) for forensics. Rotation is: recompile, upload new binary, update “latest” or build pointer, add new hash to policy, optionally remove old hash.

CLI/Registry/Ledger mapping: Registry: Validate endpoint and resolve logic; verify GET .../verify returns current hash. Ledger: Consume and events unchanged; policy is applied at the application or registry layer. CLI: No change; revocation is server-side policy.

Why ENI6MA is better: Certificate revocation (CRL/OCSP) is slow and often not checked. Password and token revocation still leave a window of use. ENI6MA revocation is atomic and effective on the next request; no secret to revoke, only the artifact hash.

Diagram, integration context, and partner example (Use Case 16)

Rendering diagram…

Integration context for existing systems. Revocation is a policy decision at validate time. The Registry (or the application backend) resolves the circuit (e.g. latest build or by hash) and checks whether that hash is in the allowed set. If the hash was removed (revocation), validation is rejected; the Ledger can still record the attempt (e.g. access-log) for forensics. No CRL, no OCSP, no propagation delay. Existing IAM or policy engines can hold the allowlist; the only requirement is that the validate path consults it before or after Ledger consume. Rotation: add new hash, optionally remove old hash; next proof from old circuit fails.

Fictitious partner example: SecureAccess IdP. SecureAccess provides identity and access management for enterprises. Their clients needed instant revocation when employees left or when a device was compromised; CRL and token revocation had delays and gaps. They integrated ENI6MA with hash-based policy: the allowlist of circuit hashes is maintained per client; when a user is revoked, that circuit’s hash is removed. The next authentication attempt from that circuit fails at policy check. Risks and attack vectors addressed: (1) Revocation delay — no CRL propagation or OCSP check; policy is evaluated on every validate. (2) Stolen token still valid — there is no token; only proofs, and the circuit hash is rejected. (3) Insider leaves — remove hash; immediate effect. (4) Compromised device — revoke circuit hash; binary without policy acceptance cannot authenticate. (5) Audit — Ledger can log rejected attempts (wrong hash) for forensics.

Use Case 17: Post-Quantum Resilient Authentication

What it is: Security does not depend on factoring or discrete logarithms. Transcript non-informativeness and combinatorial hardness (e.g. 6^L rounds, 720 map ambiguity) mean quantum computers gain no advantage; no “post-quantum migration” of the core proof is required.

How it works: The same challenge–validate flow and CLI commands apply. Proof geometry and bearing space are designed so that observation does not reduce the attacker’s uncertainty (information-theoretic and combinatorial arguments). Grover’s algorithm gives at most a square-root speedup on search; rate limiting and round count keep the effective space out of reach. No change to Registry or Ledger APIs; only the cryptographic design of the circuit and proof system.

CLI/Registry/Ledger mapping: CLI: Unchanged: challenge, validate-response, validate-proof, etc. Registry: Unchanged. Ledger: Unchanged. Property is in the proof system and transcript design.

Why ENI6MA is better: Systems that rely on RSA or ECC must migrate to PQC algorithms and manage two worlds during transition. ENI6MA is already resilient by design; no algorithm swap required for the authentication primitive.

Diagram, integration context, and partner example (Use Case 17)

Rendering diagram…

Integration context for existing systems. Post-quantum resilience is inherent in the proof system and transcript design; no change to APIs or integration. The same challenge–validate flow and CLI commands apply. Existing systems that adopt ENI6MA do not need a separate “PQC auth” project; the authentication primitive is already safe against quantum adversaries (non-informative transcript, combinatorial search space with Grover-only square-root speedup). Integration remains three API calls and optional CLI; no algorithm migration or dual-stack auth.

Fictitious partner example: FutureProof Gov. FutureProof Gov is a government agency preparing for long-term cryptographic assurance. They were concerned about RSA/ECC being broken by future quantum computers and wanted an auth system that did not depend on those assumptions. They adopted ENI6MA: the same integration (challenge, validate, Ledger) works today and remains valid post-quantum. Risks and attack vectors addressed: (1) Quantum key recovery — there is no static key to recover; the transcript does not reveal the secret (information-theoretic). (2) Grover on search — combinatorial space (e.g. 6^L × 720) remains out of reach with square-root speedup under rate limits. (3) Migration cost — no PQC algorithm swap or dual-stack period. (4) Long-term assurance — no dependency on factoring or discrete log. (5) Same ops — Registry and Ledger unchanged; no new procedures.

Use Case 18: Zero-Trust Per-Event Authorization

What it is: Every sensitive operation is authorized by a fresh proof, not by a prior login or session. No “trust after first auth”; each event is verified and logged.

How it works: Each time a sensitive operation is requested, the backend requests a challenge, presents it to the user/agent, and validates the proof. Ledger reserve and consume occur per event; there is no long-lived session token. Optional short-lived session can be issued after proof for legacy UIs, but the authoritative authorization is the proof event. CLI and Registry support repeated challenge–validate for each gate.

CLI/Registry/Ledger mapping: Registry: POST .../challenge, POST .../validate per event. Ledger: One nonce per event; reserve → consume; replay 409, expiry 410. CLI: challenge, validate-response, validate-proof per event when run locally or via CLI proxy.

Why ENI6MA is better: Zero-trust is often implemented with short-lived tokens or re-auth; both still have a window where a stolen token works. ENI6MA’s per-event proof removes that window; there is no token to steal, only a one-time proof per action.

Diagram, integration context, and partner example (Use Case 18)

Rendering diagram…

Integration context for existing systems. Zero-trust “never trust, always verify” is implemented by requiring a fresh proof for every sensitive operation. The existing app defines which operations are sensitive; for each, it requests a challenge, presents the ceremony, and validates the proof. Ledger reserve and consume occur per event; there is no long-lived session token (or the token is short-lived and the authoritative auth is the proof). Optional: issue a short-lived session after proof for legacy UIs, but treat the proof as the authorization event. CLI and Registry support repeated challenge–validate for each gate; no special “zero-trust mode”—just use the flow per action.

Fictitious partner example: ZeroTrust Health. ZeroTrust Health runs a healthcare API where every access to PHI must be explicitly authorized. They wanted zero-trust: no “login once, access many resources.” They integrated ENI6MA per-event: every API call that touches PHI triggers a challenge–validate flow (or the client presents a very short-lived proof-backed token). Each event gets its own nonce; Ledger records it. Risks and attack vectors addressed: (1) Token theft — there is no long-lived token; each action needs a new proof. (2) Session hijacking — stolen session cannot be used for new actions without new proofs. (3) Least privilege — each proof is for one action/context; no broad grant. (4) Audit — Ledger has one nonce per event; full trail. (5) Continuous verification — no “trust after first auth”; every sensitive op is verified.

Use Case 19: Developer Integration (Three API Calls)

What it is: Integrators add ENI6MA to an app with minimal code: request challenge, present ceremony, submit proof. No SDK, no API key provisioning, no OAuth client registration, no session management. The security model is proof-based, not token-based; the Registry’s public endpoints do not require API keys.

How it works: (1) Request a challenge: POST /api/circuits/{handle}/challenge. The Registry reserves a nonce from the Ledger, runs the circuit binary to generate session-unique geometry, and returns JSON with nonce_uuid, tau, and challenge data (and any metadata needed to render the grid). (2) Present the six-zone grid to the user; collect bearing selections per round; compute the proof hash (e.g. SHA256 over round-tagged transcript). The user’s response is in “bearing” space (e.g. Up, Down, Left, Right, Forward, Back), not zone IDs—the private color–bearing map is never sent. (3) Submit the proof: POST /api/circuits/{handle}/validate with body { kind: "proof", payload: { nonce_uuid, tau, bearings, proof_hash, alphabet_count } } (or the canonical envelope your stack uses). Response: { validated: true } or { validated: false, error: "..." }. The Ledger is used internally by the Registry: reserve on challenge, consume (burn) on first validate; replay returns 409, expired returns 410. OpenAPI at GET /api/swagger (optionally ?handle={handle}) and Swagger UI at /docs document all endpoints, request/response schemas, and the ExecRequest schema for programmatic binary execution (POST .../cli/{command}). CORS is enabled; rate limits (e.g. 10 challenge/validate per minute per IP) protect availability.

CLI/Registry/Ledger mapping: Registry: POST .../challenge, POST .../validate; GET /api/swagger, GET .../verify, GET /api/circuits, GET /api/binaries/.... Ledger: Used by Registry for reserve/consume; optional visibility/events for debugging. CLI: For advanced flows, POST .../cli/{command} runs any supported binary command (challenge, validate-proof, sign-msg, verify-msg, ledger/status, etc.) with optional args and flags.

Why ENI6MA is better: OAuth and SAML require client registration, client secrets, redirect URIs, and session handling; API keys must be provisioned and rotated. ENI6MA is stateless and proof-based; integration is three calls and a small ceremony UI. There are no long-lived tokens to store or refresh. Rate limits protect availability without storing credentials. Developers can go from zero to a working integration in under an hour using the OpenAPI spec and the three-call pattern; optional CLI proxy allows server-side execution of any circuit command for automation or advanced flows.

Diagram, integration context, and partner example (Use Case 19)

Rendering diagram…

Integration context for existing systems. Developer integration is minimal: the app backend (or front-end) calls the Registry for challenge and validate; the only custom piece is the ceremony UI (six-zone grid, collect bearings, compute proof hash). Existing auth middleware can be extended: “if path is /login-eni6ma, call Registry challenge, render ceremony, on submit call Registry validate, then issue our session.” No SDK required; OpenAPI at GET /api/swagger and Swagger UI at /docs document all endpoints and the ExecRequest schema for POST .../cli/{command}. CORS is enabled; rate limits (e.g. 10 challenge/validate per minute per IP) protect the Registry. The Ledger is used internally by the Registry; developers do not call it directly unless building a custom validator or audit tool.

Fictitious partner example: DevPortal SaaS. DevPortal provides a developer portal and API catalog for enterprises. They wanted to add “Login with ENI6MA” so that developers could authenticate without passwords and without OAuth client setup. They integrated in a day: (1) new route that calls POST /api/circuits/{handle}/challenge, (2) small React component for the six-zone grid and proof submission, (3) on success call POST .../validate and then issue their existing JWT. Risks and attack vectors addressed: (1) OAuth client secret leakage — no client secret; proof-based. (2) Password and credential sprawl — developers use ENI6MA; no passwords to store or reset. (3) Onboarding friction — no API key or OAuth app registration for ENI6MA; just handle and circuit. (4) Rate limit abuse — Registry rate limits protect availability without credential storage. (5) Documentation — OpenAPI and Swagger UI give one source of truth for all endpoints and CLI proxy.

Use Case 20: Circuit Discovery and Binary Verification

What it is: Developers and operators discover published circuits, inspect builds and manifests, and verify binary integrity (SHA256) against the Registry and manifest before use.

How it works: List circuits: GET /api/circuits (with optional search, sort, pagination). Get circuit by handle: GET /api/circuits/{handle}; list builds: GET /api/circuits/{handle}/builds; get build: GET /api/circuits/{handle}/builds/{date}/{id}. Get manifest: GET /api/circuits/{handle}/manifest or build-specific. Verify: GET /api/circuits/{handle}/verify (or build-specific) returns sha256, version, verified, uploaded_at. Download binary: GET /api/binaries/handle/{handle} (or build path); response headers include X-ENI6MA-SHA256, X-ENI6MA-Version, X-ENI6MA-Manifest-URL. Clients can compare SHA256 to verify before execution.

CLI/Registry/Ledger mapping: Registry: All of the above; index refresh POST /api/index for catalog updates. Ledger: Not used for discovery/verify; used when the binary is used in challenge/validate. CLI: Binary can be run with print-config, pool (load/validate), or any command after download; verification is via Registry verify and header checks.

Why ENI6MA is better: Supply-chain integrity is ensured by verifying artifact hash against the manifest and Registry; no need to trust a single download URL without checksum. Combined with proof-based auth, the chain is: trusted manifest → verified binary → proof-only authentication.

Diagram, integration context, and partner example (Use Case 20)

Rendering diagram…

Integration context for existing systems. Circuit discovery and verification fit into existing DevOps and security workflows. The Registry is the source of truth: GET /api/circuits (list, search, paginate), GET /api/circuits/{handle} and GET .../builds and GET .../builds/{date}/{id} (inspect), GET .../manifest and GET .../verify (manifest and SHA256). Download via GET /api/binaries/handle/{handle} (or build path); response headers include X-ENI6MA-SHA256, X-ENI6MA-Version, X-ENI6MA-Manifest-URL. Clients compare the downloaded binary’s hash to the manifest or verify response before execution. Index refresh POST /api/index updates the catalog. No Ledger involvement for discovery/verify; Ledger is used when the binary is used in challenge/validate.

Fictitious partner example: BuildChain Sec. BuildChain Sec provides supply-chain security and artifact verification for enterprises. Their clients needed to discover and verify ENI6MA circuits before deploying them in production. They integrated with the Registry: their tooling calls GET /api/circuits and GET .../verify (and build-specific variants), downloads binaries with GET /api/binaries/..., and checks X-ENI6MA-SHA256 against the verify response and manifest. Risks and attack vectors addressed: (1) Untrusted download — hash is verified against Registry/manifest before use. (2) Supply chain tampering — manifest and verify endpoint provide authoritative hash; clients do not trust the download URL alone. (3) Stale catalog — POST /api/index refreshes the index so discovery is up to date. (4) Build pinning — build-specific paths (/builds/{date}/{id}) allow pinning to a known good build. (5) Combined with proof auth — verified binary plus proof-only auth gives a full chain: trusted manifest → verified binary → no credential to steal.

Use Case 21: Crypto Wallet and Transactions

What it is: Consumer or institutional crypto wallets where viewing balances and signing transactions are gated by an ENI6MA proof. There is no seed phrase or private key stored at rest; the signing key is derived from the circuit’s entropy only after a successful proof ceremony. Each transaction (or each session) can require a fresh challenge–validate cycle, so compromise of the device or app does not yield a reusable key.

How it works: The wallet app requests a challenge from the Registry (POST /api/circuits/{handle}/challenge). The user completes the six-zone ceremony; the client submits the proof to POST /api/circuits/{handle}/validate. Only after validated proof does the circuit derive the signing key material (via the Enigma-ECDSA bridge). The wallet then invokes ethereum-address, sign-ethereum-tx, or Bitcoin-oriented signing (e.g. via sign-msg or eni6ma-btc) locally or via POST /api/circuits/{handle}/cli/sign-ethereum-tx (and related CLI proxy endpoints). The Ledger records reserve and consume per proof; optionally each transaction uses its own nonce for per-tx audit. Rotation is recompile and policy update; there is no seed phrase to back up or leak.

CLI/Registry/Ledger mapping: Registry: POST .../challenge, POST .../validate; POST .../cli/ethereum-address, POST .../cli/sign-ethereum-tx, POST .../cli/verify-ethereum-tx (and sign-msg, opret-* as needed). Ledger: Reserve on challenge, consume on validate; optional one nonce per transaction for audit. CLI: challenge, validate-response, validate-proof, ethereum-address, sign-ethereum-tx, verify-ethereum-tx, sign-msg, verify-msg.

Why ENI6MA is better: Traditional wallets rely on a seed phrase or a hot private key; both are single points of failure. Phishing and malware can exfiltrate the seed or key; once stolen, all funds are at risk until the user moves them. ENI6MA removes the persistent key: the user proves identity via the ceremony, and the key is derived only then. A stolen binary cannot sign without the cognitive key; a stolen proof is one-time and already burned. Each send can require a new proof, so even session hijacking has limited value. Audit: Ledger events record “circuit H, nonce N, time T” for every proof (and optionally per transaction), without storing any key material.

Diagram, integration context, and partner example (Use Case 21)

Rendering diagram…

Integration context for existing systems. Crypto wallet apps today store a seed phrase (encrypted or not) or a hot key. ENI6MA plugs in as the unlock and sign gate: the app calls the Registry for challenge and validate; only after validated proof does it call the circuit (locally or via Registry CLI proxy) to derive the address or sign the transaction. The existing chain integration (RPC, broadcast) stays unchanged; ENI6MA is the identity and key-derivation layer. Multi-sig and institutional flows can require multiple circuits (multiple proofs) per transaction. The Ledger provides a non-PII audit trail for compliance and forensics.

Fictitious partner example: CoinVault Consumer. CoinVault is a consumer mobile wallet for Ethereum and Bitcoin. They previously used encrypted seed phrases and PIN unlock; users were phished for seeds, and device compromise sometimes led to key extraction. They integrated ENI6MA: to unlock the wallet or sign a transaction, the user completes the six-zone ceremony. The circuit derives the key only after validated proof; there is no seed phrase to back up or type. Risks and attack vectors addressed: (1) Seed phrase phishing — there is no seed; the user never types or stores a recoverable phrase. (2) Hot key extraction — the key is not at rest; it is derived at sign time after proof. (3) Malware signing without consent — without the ceremony, the circuit does not sign. (4) Replay — each proof burns a nonce; Ledger rejects replay (409). (5) Audit — Ledger records which circuit (hash) proved for which nonce at which time, for compliance and dispute resolution.

Use Case 22: PII (SSN/DOB) Validation and Credit Check Service

What it is: A service that validates identity (e.g. SSN, date of birth) for credit checks or KYC without the validator ever holding raw PII in plaintext. It uses an encrypted secret store pattern: sensitive PII is encrypted under a circuit-bound key (e.g. derived from the circuit’s prime or from proof-confirmed entropy). The store holds only ciphertext. Validation is performed via self-signed, encrypted data: the user produces an attestation (signed and optionally encrypted by the circuit) that the validator can verify (signature and binding) without seeing SSN or DOB. ENI6MA proof establishes that the holder controls the circuit; the attestation binds the claim to that proof.

How it works: The user’s PII (SSN, DOB, or other fields) is encrypted using the circuit’s key material (e.g. opret-encrypt or a key derived from the circuit’s prime / proof session) and stored in an encrypted secret store (application-managed). To satisfy a credit check or KYC request, the user completes a challenge–validate flow with the Registry so the service has a validated proof (and Ledger record). The user (or client) then produces a self-signed, encrypted payload: the circuit signs a structured claim (e.g. “identity matches request id X”) and optionally encrypts sensitive fields so only an authorized validator (e.g. credit bureau with a known key or circuit) can verify or decrypt. The validator receives proof of identity (circuit hash, nonce, time from Ledger) plus the signed/encrypted attestation; it never receives raw SSN/DOB. The Ledger records the proof event for audit without any PII.

CLI/Registry/Ledger mapping: Registry: POST .../challenge, POST .../validate; POST .../cli/sign-msg for attestation; POST .../cli/opret-encrypt, POST .../cli/opret-decrypt for encrypted store or encrypted attestation. Ledger: Reserve, consume on proof; events for “circuit H, nonce N, time T” audit; no PII. CLI: challenge, validate-proof, sign-msg, verify-msg, opret-encrypt, opret-decrypt.

Why ENI6MA is better: Traditional credit check and KYC flows send SSN and DOB in plaintext or weakly protected form; breaches and insider access expose high-value PII. With ENI6MA and the encrypted secret store, the service stores only ciphertext; decryption is possible only with the circuit (and user’s proof). The self-signed, encrypted attestation lets validators get a “yes/no” or attested claim without ever handling raw PII. Revocation is instant (remove circuit hash from policy); audit trails are non-PII (Ledger). Compliance (e.g. FCRA, GDPR) is easier when the validator never sees or stores plaintext SSN/DOB.

Diagram, integration context, and partner example (Use Case 22)

Rendering diagram…

Integration context for existing systems. Credit bureaus and KYC providers today receive SSN, DOB, and other PII from consumers or aggregators; they store and process it for matching and reporting. ENI6MA fits in by moving PII into an encrypted secret store (key bound to the user’s circuit) and replacing raw PII submission with a proof plus a self-signed, encrypted attestation. The existing bureau matching logic can be adapted to accept “proof + attestation” instead of raw fields; verification uses the circuit’s public material or a shared decryption path. The Registry and Ledger provide proof lifecycle and audit; no PII touches the Ledger.

Fictitious partner example: CreditSafe Verify. CreditSafe Verify provides identity verification for lenders and credit bureaus. They previously received SSN and DOB from consumers and stored them for matching; a breach or insider could expose millions of records. They adopted the encrypted secret store pattern with ENI6MA: consumer PII is encrypted under the circuit-bound key and stored as ciphertext. For a credit check, the consumer completes the proof ceremony; the service then issues a self-signed, encrypted attestation that the bureau can verify (and optionally decrypt under policy) without ever receiving raw SSN/DOB. Risks and attack vectors addressed: (1) PII breach — the store holds only ciphertext; compromise does not reveal SSN/DOB. (2) Insider access — validators get attested claims, not plaintext PII. (3) Phishing for SSN/DOB — the user never types PII into a third-party form; proof and attestation are bound to the real circuit. (4) Audit without PII — Ledger records proof events (circuit hash, nonce, time) for compliance; no PII in the trail. (5) Revocation — remove circuit hash from policy; next proof fails and attestations from that circuit can be rejected.

Use Case 23: Password Manager

What it is: A password manager where the “master secret” is not a master password but an ENI6MA proof. Unlocking the vault and decrypting stored credentials require a successful proof ceremony; there is no master password to phish, keylog, or steal. The vault is encrypted with a key derived from the circuit (and optionally bound to the proof session); only after validated proof can the client derive the decryption key and access the stored passwords.

How it works: The password manager app holds an encrypted vault (ciphertext of the user’s credentials). To unlock, the app requests a challenge from the Registry (POST /api/circuits/{handle}/challenge), presents the six-zone ceremony to the user, and submits the proof to POST /api/circuits/{handle}/validate. After validated proof, the circuit (run locally or via Registry CLI proxy) derives key material from its entropy pool (and optionally from the proof session); the app uses this to decrypt the vault. No master password is ever stored or transmitted. Optionally, each unlock is bound to a nonce (Ledger reserve/consume) so the Ledger records “circuit H unlocked at time T” for audit without storing any secret. Rotation: recompile a new circuit, re-encrypt the vault under the new circuit’s key material; no password reset flow.

CLI/Registry/Ledger mapping: Registry: POST .../challenge, POST .../validate; optionally POST .../cli/{command} if key derivation is done via proxy. Ledger: Reserve on challenge, consume on validate; optional audit of unlock events (circuit hash, nonce, time). CLI: challenge, validate-response, validate-proof; key derivation can use circuit entropy (and optionally opret-decrypt-style key material for vault encryption).

Why ENI6MA is better: Traditional password managers rely on a master password (or biometric + device key). The master password is the single point of failure: phishing, keyloggers, and credential stuffing (if the master is reused) compromise the entire vault. ENI6MA removes the master password: unlock is proof-only. There is nothing to type on a fake site and no master hash to crack in a breach. Each unlock can be a fresh proof (one nonce per session); stolen session tokens do not yield vault access without a new ceremony. Revocation is immediate (remove circuit hash); the user can recompile and re-encrypt the vault under a new circuit if the device or binary is compromised.

Diagram, integration context, and partner example (Use Case 23)

Rendering diagram…

Integration context for existing systems. Password managers today use a master password (and often a key derived from it) to encrypt the vault; some add biometrics or device binding. ENI6MA replaces the master password with the proof ceremony: the app calls the Registry for challenge and validate, then uses the circuit (local or proxy) to derive the decryption key. The existing vault format (encrypted blob of credentials) can be retained; only the key derivation step changes from “master password → KDF” to “validated proof → circuit entropy → key.” Sync and backup can still encrypt the vault blob; the key is always derived at unlock time from the proof and circuit. No server need ever store a master password hash.

Fictitious partner example: VaultLock Pro. VaultLock Pro is a consumer password manager with millions of users. They previously used a master password with PBKDF2 and optional 2FA; users were phished for master passwords, and keyloggers captured unlocks. They integrated ENI6MA: to unlock the vault, the user completes the six-zone ceremony. There is no master password; the decryption key is derived from the circuit after validated proof. Risks and attack vectors addressed: (1) Master password phishing — there is no master password to type on a fake site. (2) Keylogger capture — nothing is typed; the proof is non-replayable and bound to the nonce. (3) Vault breach — a stolen vault blob is still encrypted; the key is not stored. (4) Replay — each unlock can use a new nonce; Ledger rejects replay (409). (5) Revocation — if the device or circuit is compromised, remove circuit hash from policy and re-encrypt vault under a new circuit; no “forgot master password” recovery that attackers could abuse.

Summary Table: Use Cases and Primary Surfaces

Use case	Registry	Ledger	CLI (examples)
1. Consumer login	challenge, validate	reserve, consume	challenge, validate-*
2. Policy gates	challenge, validate	reserve, consume, events	challenge, validate-*
3. Financial approvals	challenge, validate	reserve, consume	challenge, validate-*
4. Machine/API identity	challenge, validate, cli/*	reserve, consume	validate-proof, client, verifier
5. A2A	challenge, validate, cli/*	reserve, consume (if online)	hybrid: respond-interactive, validate-proof
6. Blockchain custody	cli/sign-, cli/opret-	(if gated by proof)	sign-msg, verify-msg, sign-ethereum-tx, opret-*
7. Healthcare PHI	challenge, validate	reserve, consume, events	challenge, validate-*
8. IoT/edge	circuits, binaries, challenge, validate	reserve, consume, snapshot	challenge, validate-*, verifier, client
9. Sovereign/offline	when connected: verify, binaries	local snapshot, sync	full set local
10. CI/CD gates	challenge, validate, cli/validate-proof	reserve, consume	challenge, validate-*
11. Message signing	cli/sign-msg, verify-msg	(optional)	sign-msg, verify-msg
12. OP_RETURN	cli/opret-encrypt, opret-decrypt	(optional)	opret-encrypt, opret-decrypt
13. Ethereum	cli/ethereum-*, sign-ethereum-tx	(if gated)	ethereum-address, sign-ethereum-tx
14. Audit/compliance	validate, verify	reserve, consume, status, events	ledger/status, ledger/tx
15. Phishing-resistant	challenge, validate	reserve, consume, 409/410	same as 1
16. Instant revocation	validate + policy	events	—
17. Post-quantum	(unchanged)	(unchanged)	(unchanged)
18. Zero-trust per-event	challenge, validate per event	one nonce per event	challenge, validate-*
19. Developer integration	challenge, validate, swagger	internal to Registry	optional cli/*
20. Discovery/verify	circuits, builds, verify, binaries	—	print-config, pool
21. Crypto wallet/transactions	challenge, validate, cli sign-, ethereum-	reserve, consume (per proof/tx)	challenge, validate-*, sign-ethereum-tx
22. PII validation/credit check	challenge, validate, cli sign-msg, opret-*	reserve, consume, events	challenge, validate-proof, sign-msg, opret-*
23. Password manager	challenge, validate	reserve, consume (optional)	challenge, validate-*

Conclusion: Circuit Capabilities and the ENI6MA Surface

This conclusion consolidates all capabilities of the circuit and the ENI6MA surface (CLI, Registry, Ledger) as they appear across the twenty-three use cases. It is intended as a single reference for what the circuit can do, which commands and APIs implement each capability, and how the security properties are achieved end to end.

The circuit as compiled identity. The circuit binary is a Rust executable produced by the ENI6MA compiler from a user or service configuration. The configuration includes secrets (character strings or phrases), a cognitive key (e.g. a bijection from six zone labels such as colors to six response labels such as directions), round count, alphabet settings, and optional parameters for hybrid or A2A builds. The compiler embeds the configuration and an entropy pool into the binary and never retains the configuration after delivery. The binary is the compiled identity: it can generate and verify proofs, and—when built with the Enigma-ECDSA bridge—derive signing keys and perform message and transaction signing. The binary alone cannot authenticate; it requires the cognitive key (the private mapping) that only the user or authorized agent holds. Stealing the binary does not yield a usable credential; it is a lock without the combination. This design is shared by every use case that involves authentication or signing.

Proof lifecycle: challenge, response, validate, burn. The core capability of the circuit is the interactive proof. The lifecycle is: (1) Challenge generation — a verifier (or the Registry on behalf of the application) obtains a nonce (uuid, tau) from the Ledger, runs the circuit with tau to generate session-unique geometry, and returns the challenge to the client. (2) Proof generation — the user or agent sees the six-zone grid, selects bearings per round according to their secret and private map, and the client computes the proof hash and forms the proof payload (tau, bearings, proof_hash, etc.). (3) Validation — the client submits the proof to the Registry (or runs the binary locally for verify). The Registry burns the nonce via Ledger POST /response (burn-before-validate); only after a successful burn does it run the circuit to verify the proof cryptographically. (4) Outcomes — validated proof means the prover demonstrated knowledge; replay returns 409, expired nonce returns 410, tau mismatch returns 400. This lifecycle is implemented by Registry endpoints POST /api/circuits/{handle}/challenge and POST /api/circuits/{handle}/validate, and by CLI commands challenge, validate-response, and validate-proof. It is the foundation of Use Cases 1–5, 7–11, 14–15, 18–19 and is optionally used to gate signing in Use Cases 6, 11, 13.

CLI command set: proof, ledger, signing, and utilities. The circuit binary supports a wide command set, all invokable locally or via Registry POST /api/circuits/{handle}/cli/{command}. Proof and session: pool (entropy pool status/load), challenge, validate-response, validate-proof, validate-proof-payload, interactive, nonce-interactive, test-epsilon-tau-pi, synthesize, simulator. Ledger: ledger/status, ledger/tx, ledger/mine, ledger-service. Message and blockchain: enigma-hash, sign-msg, verify-msg, opret-encrypt, opret-decrypt, ethereum-address, sign-ethereum-tx, verify-ethereum-tx. Verifier and client roles: verifier, client. Utilities: verify-block, print-config, generate-nonce, validate-nonce-file, generate-from-row-hashes, test-horner-reduction, test-tau-sensitivity. Hybrid binaries add A2A and agent commands such as respond-interactive (with identity key), agent init, and oscillation-related flows. Every use case in this document uses some subset of these commands; the Summary Table maps use cases to the main commands (e.g. challenge, validate-*, sign-msg, ledger/status).

Registry API: circuits, challenge, validate, CLI proxy, binaries. The Registry is the public HTTP surface for applications. Circuit discovery and metadata: GET /api/circuits (list, search, sort, paginate, include_builds), GET /api/circuits/{handle} (by handle), GET /api/circuits/{handle}/builds, GET /api/circuits/{handle}/builds/{date}/{id}, GET /api/circuits/{handle}/manifest, GET /api/circuits/{handle}/verify (and build-specific variants). Proof flow: POST /api/circuits/{handle}/challenge, POST /api/circuits/{handle}/validate (canonical; body includes kind: "proof" or "response" and payload). Legacy wrappers: POST .../validate-response, POST .../validate-proof. Optional header x-eni6ma-ledger-url allows a dedicated ledger when allowed by the executor’s allowlist. CLI proxy: POST /api/circuits/{handle}/cli/{command} with body ExecRequest (command, args, flags, input). Any CLI command can be run remotely; the Registry proxies to the executor. Binaries: GET /api/binaries/handle/{handle} (download latest), POST /api/binaries/handle/{handle} (execute), and build-specific paths for download and execute. Response headers include X-ENI6MA-SHA256, X-ENI6MA-Version, X-ENI6MA-Manifest-URL. Index and health: GET /api/index, POST /api/index (refresh), GET /api/health, GET /api/health/db. Documentation: GET /api/swagger (OpenAPI, optional ?handle={handle}), Swagger UI at /docs. These endpoints cover all twenty-three use cases: login and policy gates use challenge/validate; signing and OP_RETURN use cli/sign-, cli/opret-; discovery and verification use circuits, builds, verify, binaries.

Ledger: reserve, consume, status, events, TTL, replay, tau. The Ledger is the nonce registry that makes proofs one-time and time-bound. Reserve: POST /reserve (with optional auth) creates a nonce (uuid, tau), state RESERVED, TTL (e.g. 300 s). Consume (burn): POST /response with nonce UUID and payload. Ledger checks: still RESERVED? tau match? not expired? If yes, transition to SPENT and return 200. If already SPENT → 409 Conflict (replay). If expired → 410 Gone. If tau mismatch → 400 Bad Request. Status and audit: GET /status/{uuid} returns current state; GET /events (or visibility service) provides a read-only feed of reserve, consume, and optional access-log/success events. Security role: Burn-before-validate ensures each challenge accepts exactly one validation attempt. TTL prevents challenge stockpiling and stale replay. Tau binding ties the proof to the challenge. No secrets are stored; only nonce lifecycle and payload hashes. Use Cases 1–5, 7–10, 14–15, 18–19 rely on the Ledger for replay prevention and audit; Use Cases 6, 11, 13 can gate signing with a proof that uses the Ledger.

Enigma-ECDSA bridge: proof-gated signing. The circuit can derive signing keys from the entropy pool and perform ECDSA (e.g. secp256k1) operations after a successful proof. Commands: sign-msg, verify-msg, ethereum-address, sign-ethereum-tx, verify-ethereum-tx, and Bitcoin-oriented signing in eni6ma-btc. The key is not stored; it is derived at sign time from the entropy indices confirmed by the proof. This enables proof-per-transaction custody (Use Case 6, 13): no hot wallet key at rest; each sign requires the ceremony. OP_RETURN encryption/decryption (opret-encrypt, opret-decrypt) uses the circuit’s prime to seed a BLAKE3-XOF stream for on-chain private metadata (Use Case 12). All of these are exposed via the Registry CLI proxy and are used in blockchain custody, message signing, and Ethereum use cases.

Agent-to-agent and hybrid capabilities. Symmetric circuit clones (same binary on both sides) can authenticate each other without a central authority. The A2A oscillation protocol (seal/unseal with Kyber768 + X25519 in hybrid builds) provides mutual authentication and shared session context. Commands: client, verifier, and in hybrid binaries respond-interactive (with identity key), agent init. Optionally, A2A flows can use the Registry and Ledger for challenge/validate and audit (Use Case 5). Sovereign mode uses a local ledger snapshot and circuit cache; proof ceremonies run offline and sync when connected (Use Case 9). This gives offline-capable, mutually authenticated proofs with deferred ledger sync—a capability no other mainstream auth system offers in this form.

Security properties across capabilities. Every capability that uses the proof flow inherits the same security properties. Non-replay: Ledger burn-before-validate and one nonce per challenge; 409 on replay. Non-informative transcript: The observable bearing sequence does not reduce the attacker’s uncertainty about the secret or the mapping (information-theoretic and combinatorial design); observation and phishing yield no advantage. Time-bound: TTL expiry (410); no indefinite validity. Post-quantum resilience: Security does not depend on factoring or discrete log; transcript non-informativeness and combinatorial hardness are unchanged by quantum computing (Use Case 17). Instant revocation: Remove circuit hash from policy; next proof from that circuit fails (Use Case 16). No credential store: The Registry and Ledger store metadata and nonce lifecycle, never secrets or password hashes. Audit without PII: Ledger events and optional access-log provide “circuit H, nonce N, time T, payload hash” for compliance (Use Case 14).

How the twenty-three use cases map to capabilities. Consumer and phishing-resistant login (1, 15) use proof lifecycle + Registry challenge/validate + Ledger reserve/consume. Enterprise policy gates, financial approvals, CI/CD gates, zero-trust per-event (2, 3, 10, 18) add repeated proof gates per action and optional dedicated ledger. Machine and API identity (4) use the same proof flow with service-held circuits and mutual challenge/validate. A2A (5) uses symmetric clones, oscillation, and optionally Registry/Ledger. Blockchain custody and signing (6, 11, 12, 13, 21) use proof-gated Enigma-ECDSA and OP_RETURN via CLI (and Registry proxy). Healthcare and IoT (7, 8) use proof for access and device auth; sovereign (9) uses local ledger and cache. Audit and compliance (14) use Ledger events and visibility; revocation (16) uses hash-based policy. Post-quantum (17) is inherent in the proof system. Developer integration (19) is the three-call pattern and OpenAPI; discovery and verification (20) use Registry circuits, builds, verify, binaries and SHA256 checks. Crypto wallet and transactions (21) use proof-gated signing and Ledger per proof or per tx. PII validation and credit check (22) use encrypted secret store, self-signed encrypted attestations, and proof for identity; Ledger for non-PII audit. Password manager (23) uses proof as master secret and optional Ledger for unlock audit. Together, the circuit’s proof lifecycle, full CLI set, Registry API, and Ledger semantics cover authentication, authorization, signing, privacy, audit, and supply-chain verification across all twenty-three scenarios.

Implementing and extending. To implement any use case, start from the Registry’s OpenAPI spec and the three-call pattern (challenge, ceremony, validate). Add the ceremony UI (six-zone grid, bearing collection, proof hash). For policy gates or zero-trust, call challenge/validate per sensitive action. For signing, run the proof flow first, then invoke the appropriate CLI command (sign-msg, sign-ethereum-tx, etc.) via the Registry or locally. For discovery and verification, use the circuits and verify endpoints and check X-ENI6MA-SHA256 on download. The Conclusion and the Summary Table give you a single place to see all circuit capabilities and their mapping to use cases; the references point to the full product document and API specs for deeper detail.

Recap: one circuit, many capabilities. The circuit binary is a single artifact that supports proof generation and verification, Ledger-aware nonce binding, message signing, Ethereum address derivation and transaction signing, OP_RETURN encryption and decryption, and—in hybrid builds—agent-to-agent oscillation and sovereign operation. The Registry exposes all of this over HTTP: challenge and validate for the proof flow, CLI proxy for every command, and discovery and verification for supply-chain integrity. The Ledger enforces one-time use and TTL for every proof that flows through the Registry (or through a local snapshot in sovereign mode). There are no separate “auth circuit,” “signing circuit,” and “audit circuit”—the same circuit and the same three surfaces (CLI, Registry, Ledger) implement login, policy gates, financial approvals, machine identity, A2A, custody, healthcare access, IoT auth, sovereign deployment, CI/CD gates, message signing, on-chain privacy, Ethereum operations, audit, phishing resistance, revocation, post-quantum assurance, zero-trust per-event auth, developer integration, circuit discovery, crypto wallet and transactions, PII validation and credit check (encrypted secret store, self-signed encrypted data), and password manager. This document’s twenty-three use cases are a map of that single capability set onto the real-world problems they solve; the Conclusion you have just read is the consolidated reference for what the circuit can do and how it all fits together.

Cross-reference: capabilities to use cases. For quick lookup: Proof lifecycle (challenge, validate, burn) → Use Cases 1, 2, 3, 4, 5, 7, 8, 10, 14, 15, 18, 19, 21, 22, 23. Ledger (reserve, consume, status, events) → all of the above plus optional gating in 6, 11, 13. sign-msg / verify-msg → 6, 11, 22. opret-encrypt / opret-decrypt → 6, 12, 22. ethereum-address / sign-ethereum-tx / verify-ethereum-tx → 6, 13, 21. ledger/status / ledger/tx → 14 (audit). Pool, interactive, nonce-interactive → 1, 4, 5 (proof and testing). verifier / client → 4, 5, 8. Hybrid A2A (respond-interactive, agent) → 5. Registry circuits, builds, verify, binaries → 8, 20. Sovereign / local snapshot → 5, 8, 9. Hash-based policy (revocation) → 2, 16. Post-quantum → 17 (inherent in proof system). Three-call integration → 1, 19. Crypto wallet / proof-per-tx → 21. Encrypted secret store, self-signed encrypted attestation → 22. Password manager (proof as master) → 23. This cross-reference, together with the Summary Table and the detailed CLI/Registry/Ledger sections above, gives a complete index of circuit capabilities and where they appear in the use cases.

References

Product and technology: product.MD (full vision, Part III–VI, Sections 8–10 for lifecycle and Ledger).
Public API and routes: DOCS/development/PUBLIC_INTERFACE_SPEC.md.
CLI commands and flags: Registry app/api/swagger/route.ts, lib/swagger-command-schemas.ts; scripts/USAGE.md (Quick Reference: Binary Commands by Use Case).
Ledger lifecycle and testing: DOCS/system-design/TESTING_LEDGER.md, scripts/tests/test-ledger-validation-e2e.sh.
Strategic use cases (finance, healthcare, IoT): DOCS/STRATEGIC_TECHNOLOGY_EVOLUTION_REPORT.md (Part IV).

ENI6MA Use Cases: Developer Introduction

ENI6MA Use Cases: Developer Introduction

Table of Contents

Introduction

Scope and How to Use This Document

Use Case 1: Consumer Sovereign Login (Passwordless Web Auth)

Diagram, integration context, and partner example (Use Case 1)

Use Case 2: Enterprise Policy Gates (Privileged Operations)

Diagram, integration context, and partner example (Use Case 2)

Use Case 3: High-Value Financial Transactions and Approvals

Diagram, integration context, and partner example (Use Case 3)

Use Case 4: Machine and API Identity (No Static API Keys)

Diagram, integration context, and partner example (Use Case 4)

Use Case 5: Agent-to-Agent Authentication (A2A / Oscillation)

Diagram, integration context, and partner example (Use Case 5)

Use Case 6: Blockchain and Digital Custody (Enigma-ECDSA Bridge)

Diagram, integration context, and partner example (Use Case 6)

Use Case 7: Healthcare PHI and Clinical System Access

Diagram, integration context, and partner example (Use Case 7)

Use Case 8: IoT, Edge, and Mesh Device Authentication

Diagram, integration context, and partner example (Use Case 8)

Use Case 9: Sovereign and Air-Gapped Deployment

Diagram, integration context, and partner example (Use Case 9)

Use Case 10: Deployment and CI/CD Approval Gates

Diagram, integration context, and partner example (Use Case 10)

Use Case 11: Message Signing and Verification

Diagram, integration context, and partner example (Use Case 11)

Use Case 12: OP_RETURN Encrypted Metadata (On-Chain Privacy)

Diagram, integration context, and partner example (Use Case 12)

Use Case 13: Ethereum Address Derivation and Transaction Signing

Diagram, integration context, and partner example (Use Case 13)

Use Case 14: Audit and Compliance (Ledger Trails, No PII)

Diagram, integration context, and partner example (Use Case 14)

Use Case 15: Phishing-Resistant Authentication

Diagram, integration context, and partner example (Use Case 15)

Use Case 16: Instant Revocation (Hash-Based Policy)

Diagram, integration context, and partner example (Use Case 16)

Use Case 17: Post-Quantum Resilient Authentication

Diagram, integration context, and partner example (Use Case 17)

Use Case 18: Zero-Trust Per-Event Authorization

Diagram, integration context, and partner example (Use Case 18)

Use Case 19: Developer Integration (Three API Calls)

Diagram, integration context, and partner example (Use Case 19)

Use Case 20: Circuit Discovery and Binary Verification

Diagram, integration context, and partner example (Use Case 20)

Use Case 21: Crypto Wallet and Transactions

Diagram, integration context, and partner example (Use Case 21)

Use Case 22: PII (SSN/DOB) Validation and Credit Check Service

Diagram, integration context, and partner example (Use Case 22)

Use Case 23: Password Manager

Diagram, integration context, and partner example (Use Case 23)

Summary Table: Use Cases and Primary Surfaces

Conclusion: Circuit Capabilities and the ENI6MA Surface

References