Circuit (CLI)

The circuit is the compiled identity binary — a Rust executable that embeds the user’s secrets (encrypted), mapping, and entropy pool. It exposes a CLI used for proof generation and verification, ledger interaction, signing (message, OP_RETURN, Ethereum), and in the hybrid variant agent-to-agent (A2A) and sovereign operation. Commands can be run locally or via the Registry POST .../cli/{command}. Understanding the command set and the standard vs hybrid variants is essential for integration and deployment choices.

Anatomy of the circuit binary

An ENI6MA circuit binary is not a simple executable with a configuration file. It is a cryptographically hardened artifact with multiple layers of protection. Inside the binary you will find a unique 512-bit prime (used in entropy derivation, nonce generation, and the Enigma-ECDSA bridge), an encrypted entropy pool (typically 159 entries of 512-bit values) that drives challenge geometry, and the user’s encrypted configuration — secrets and personal mapping — protected by a BLAKE3-derived key so that even if the binary’s bytes are extracted, the configuration remains encrypted. Alphabets (uppercase, lowercase, digits) define the character sets for witness generation; in hardened builds only BLAKE3 hashes of symbols are stored to resist static analysis. The binary is self-contained: it includes ECDSA/secp256k1 for blockchain signing, BLAKE3 for key derivation and hashing, SHA256 for integrity, and the full Rosario-Wang proof system. No external libraries are needed at runtime.

Every compiled binary includes a self-validation checksum (e.g. MD5 of the binary appended as the last bytes). On startup, the binary verifies its own integrity and refuses to run if tampered. A separate SHA256 hash over the entire binary serves as the circuit’s immutable identity in the Registry — this is the artifact fingerprint used for revocation and policy. Memory protection follows Transform-Scatter-Zeroize patterns: sensitive values are transformed during processing, scattered across non-contiguous regions, and explicitly zeroed when no longer needed. Constant-time comparison and session-bound keys ensure that keys from one session cannot be extracted and applied to another.

Proof and session commands

pool, challenge, validate-response, validate-proof, validate-proof-payload, interactive, nonce-interactive, synthesize, simulator. These commands implement the proof lifecycle: generating or consuming challenges, running the interactive ceremony (six-zone grid, bearings), and validating payloads. When used locally, the circuit needs a nonce (uuid, tau) from the Ledger — often obtained via the Registry’s challenge endpoint. When used via the Registry CLI proxy, the Registry reserves the nonce and passes it to the circuit. Implications: replay is prevented by the Ledger; rate limits apply per circuit/handle; each challenge is one-time use.

Proof generation and the bearing transcript

The user (or their agent) interacts with the challenge through the six-zone hexagonal grid, making bearing selections for each round based on their secret characters and private color–bearing map. The result is a minimal proof payload: the tau timestamp, an array of bearing codes (the directional selections), and a proof hash (a SHA256 digest over the round-tagged transcript). Crucially, the payload does not include “which color” or “which zone” was selected in each round, and it does not include the user’s map identity (which of 720 possible bijections is being used). That omission is intentional: the observable transcript (bearings) is not directly alignable to the challenge (colored witness zones) without the private map. As a result, any attacker attempting to test secret hypotheses from observations must multiply their candidate space by 720 distinct maps. The transcript is designed to be non-informative and non-replayable; the Ledger ensures each nonce is single-use and time-bound.

The ceremony repeats for each round. The verifier (Registry or local circuit) reconstructs the same geometry from tau and entropy and checks that, for every round, the secret character appears in the witness zone corresponding to the prover’s bearing. The construction uses disjoint alphabet rings, entropy-time coupling for session freshness, cyclic rotation for diffusion, and the private bijective mapping (the cognitive key) shared only by the matched circuit and verifier. No external observer can align the bearing sequence to zone selections without knowing the map.

Ledger commands

ledger/status, ledger/tx, ledger/mine, ledger-service. These allow the circuit to query ledger state (status of a nonce, transaction history) and in appropriate modes to append or mine ledger entries. Used for audit (who reserved/consumed what) and in sovereign mode for local ledger snapshots that sync when connected. Implications: ledger commands are subject to the same Ledger semantics (reserve, burn, TTL); sovereign mode uses a local copy of the ledger for offline operation.

Message and blockchain: signing and OP_RETURN

enigma-hash, sign-msg, verify-msg, opret-encrypt, opret-decrypt, ethereum-address, sign-ethereum-tx, verify-ethereum-tx. The Enigma-ECDSA bridge derives signing keys from the circuit’s entropy pool after a successful proof (or from the configured prime/shard). sign-msg/verify-msg provide message signing; opret-* encrypt/decrypt metadata for OP_RETURN embedding; ethereum-* support Ethereum address derivation and transaction signing. Implications: custody is proof-gated — no proof, no signing; when used with the Registry, proofs are validated before signing is allowed; keys are not stored as files but derived on demand.

Enigma-ECDSA bridge and signing

The 512-bit prime and entropy pool inside the circuit are used not only for proof geometry but also for the Enigma-ECDSA bridge: deterministic key derivation for ECDSA/secp256k1 signing. After a successful proof (or when the circuit is unlocked with the correct identity material), signing keys can be derived for message signing (sign-msg, verify-msg), OP_RETURN encryption (opret-encrypt, opret-decrypt with a prime-seeded stream cipher), and Ethereum (ethereum-address, sign-ethereum-tx, verify-ethereum-tx). Keys are never stored as files; they are derived on demand and bound to the session and proof context. This keeps custody proof-gated: without a valid proof, the circuit cannot produce signatures. When the circuit is used with the Registry CLI proxy, the Registry validates the proof before allowing signing commands to run, so server-side signing is still gated by the user’s ceremony.

OP_RETURN commands allow embedding encrypted metadata in Bitcoin (or compatible) OP_RETURN outputs; the cipher is a prime-seeded BLAKE3-XOF stream. Ethereum commands support address derivation and transaction signing for compatibility with Ethereum-based applications. All of these capabilities are available in both standard and hybrid variants; the difference is that hybrid adds agent-to-agent and sovereign modes on top of the same signing and proof machinery.

Verifier and client roles

verifier and client implement the two roles in a proof flow: the verifier generates challenges (using tau from the Ledger) and validates submissions; the client performs the ceremony and submits the proof. In a typical deployment, the Registry runs the verifier path (or delegates to an executor), and the user’s environment runs the client path. These commands are used for testing, for custom integrations, and for peer-to-peer or agent flows where the circuit plays both roles in sequence.

Hybrid: respond-interactive and agent commands

Hybrid binaries add respond-interactive (with identity key or prime_shard_b64) and agent commands: init, discover, respond, insert, register, deregister, find, oscillate. These enable agent-to-agent (A2A) authentication: two circuits compiled from the same configuration can authenticate each other without a central authority. Oscillation uses a combined Kyber768 + X25519 KEM for post-quantum and classical security. Use hybrid when you need machine-to-machine or agent-to-agent proof flows, or sovereign operation with a local ledger snapshot.

Standard vs hybrid variant matrix

Standard circuits (e.g. eni6ma-btc) include proof lifecycle, Ledger binding, signing (sign-msg, verify-msg), OP_RETURN (opret-encrypt, opret-decrypt), and Ethereum (ethereum-address, sign-ethereum-tx, verify-ethereum-tx). They do not include A2A or sovereign mode. Hybrid circuits (e.g. eni6ma-btc-hybrid) add respond-interactive (with identity/shard), agent init/discover/respond/oscillate, and sovereign operation (local ledger snapshot, sync when connected). Choose standard for human-facing login and signing; choose hybrid for agent-to-agent and offline-capable deployments.

Local vs Registry proxy

Commands can run locally (binary on your machine or server) or via the Registry CLI proxy (POST /api/circuits/{handle}/cli/{command}). Local execution gives full control and works offline (with sovereign ledger snapshot); the Registry proxy avoids distributing the binary and centralizes rate limiting and audit. For web apps, the typical pattern is: Registry serves challenge and validate API; the user may run the ceremony in a hosted UI or a local binary. For agents, either the agent holds the binary and calls the Registry for challenge/validate, or the agent calls the Registry CLI proxy for all commands. Implications: revocation is by circuit hash (remove from policy); rate limits apply per handle/circuit; audit events are recorded by the Ledger and optionally by the Registry.

Use-case and variant mapping

Standard circuits (e.g. eni6ma-btc) cover the proof lifecycle, Ledger binding, signing (sign-msg, verify-msg), OP_RETURN, and Ethereum. They are the right choice for human-facing login, message signing, and blockchain integration where a central Registry and Ledger are used. Hybrid circuits (e.g. eni6ma-btc-hybrid) add respond-interactive (with identity key or prime_shard_b64), agent commands (init, discover, respond, insert, register, deregister, find, oscillate), and sovereign operation (local ledger snapshot, sync when connected). Choose hybrid when you need agent-to-agent authentication, machine-to-machine proof flows, or offline-capable deployments where the circuit holds a local copy of the ledger and syncs when the network is available.

Use-case to variant mapping: passwordless login and most consumer flows use the standard variant with the Registry and Ledger. Audit and compliance use cases (ledger/status, ledger/tx, visibility) work with both. Signing use cases (message, OP_RETURN, Ethereum) are supported in both; the choice depends on whether you need A2A or sovereign mode. Agent-to-agent and sovereign use cases require the hybrid variant. See the circuit capability matrix and use-case-variant mapping documentation in the repository for the full capability-by-variant table and recommended patterns per use case.

Circuit capabilities reference

For the full capability matrix and use-case-to-variant mapping, see the DOCS in the repository (circuit-capability-matrix.md, use-case-variant-mapping.md). For Registry CLI proxy schema and flags per command, see the OpenAPI spec (GET /api/swagger) and the x-flags-by-command extension. For developers: use the For developers page and the Registry API reference for integration details.