Fundamentals · Mechanism overview
How the tech works
Identity is a content-addressed verifier. Access is a one-shot proof against a burned challenge. Publish a digest-pinned twin-circuit verifier, onboard with an XOR binding, run a ceremony, and grant a short-lived session and/or a request-bound Gate envelope — under the reference architecture and claim model.
Matched pair · sealed map · per-event work
Mirror the prover and verifier twins: they share a sealed private map relationship that never rides the public channel. Only witnesses and challenges travel between them. Takeaway: identity lives in matched circuits and per-event work, not in a reusable ambient secret.
Paradigm
Reusable credentials authorize until someone rotates them — including an attacker who already has a copy. ENI6MA relocates identity into a digest-pinned verifier (a twin circuit: private prover + public verifier) and relocates access into an interactive proof bound to a single-use challenge. The verifier observes allow or deny for that binding; the secret material does not become lasting authority on the public channel under the named model.
Stages
Three stages from first publish to a usable grant. Homepage strip #how-tech-works summarizes the same spine.
Stage 1
Publish
Mint and register a content-addressed verifier: a digest that pins the artifact and a location where authorized parties can fetch it. Relying parties (Gate + Control ledger) resolve by digest, not by a shared reusable secret. Foundry-class minting produces twin-circuit binaries; Control records the active handle and digest.
Stage 2
Onboard (XOR)
Bind identity for a relying party with exactly one of: a Circuit Authority org handle, or an external verifier URL you already host. Dual binding is rejected so resolution has a single path. The free human baseline tier remains roadmap-honest — institutional pilots now; civic free tier when open.
Stage 3
Ceremony
Challenge with a fresh nonce → prover responds → verifier checks → burn the nonce → grant. The grant may be a short-lived session or cookie (login-style UX) and/or a request-bound Gate envelope (primary builder path for APIs and agents). Either way, authority is one-shot under the reference architecture.
Challenge · witness · burn · twin verdict
Follow the five-stage flow: fresh challenge, local private map, bearing witnesses on the public channel, burn nonce, twin verdict. The eavesdropper watches only the channel strip; the private map never leaves the vault. Takeaway: membership is proven once, then authority dies at burn.
Digest-cache progressive stack
Verifier artifacts are content-addressed. Resolution prefers warmer, already-checked layers and fails closed on digest mismatch — never silently accept a substituted binary.
- Origin fetch — retrieve the artifact from the registered location when cold.
- Blob by digest — store and serve by content hash so location and content stay bound.
- Warm memory — keep verified digests in process or edge cache for subsequent requests.
If the bytes at a location no longer match the registered digest, validation fails closed. Ops note also on Deployment models.
Four execution topologies
Same envelope contract; different places the verifier and durable nonce ledger run. Model A / Model B remain the envelope-validation axis; these topologies describe where execution and ops live.
Local pull / cache
The relying party fetches the verifier artifact by digest and caches it locally. Lowest control-plane dependency; suits air-gap and edge. Maps to Model A (local verifier) for envelope validation.
Choose when latency and air-gap matter more than instant central revocation.
Hosted executor
A managed control plane runs validate-proof and ledger burns. Client code stays the same; ops load moves to the host. Overlaps Model B (registry control plane).
Choose for Cloud / Connected Team fleets that want centralized lifecycle and visibility.
Enterprise self-hosted
You host Foundry and Control under your trust boundary. Gate at the edge can still run Model A with registry sync over approved paths.
Choose for Sovereign stacks, classified, or regulated estates that cannot depend on a third-party control plane.
One-shot metered
Proof volume and protected endpoints are metered commercially. Same envelope contract; billing and quota sit beside Gate and Control.
Choose when you want pay-per-proof economics without standing API-key blast radius.
Integration blueprint
ENI6MA replaces the authorization layer (bearer tokens, API keys, lasting JWTs as request authority). It coexists with authentication (OIDC, SAML, mTLS) and sits behind the reverse proxy, gateway, or mesh you already run.
Identity record shape
Store enough to resolve and audit — not a reusable shared secret:
subject— who or what the identity namesdigest— content address of the verifier artifactlocation— where authorized fetchers retrieve byteslast-verified— when digest match was last confirmed
Agents and high-risk APIs should authorize with a one-shot envelope before the side effect (proof-before-sign). See APIs & endpoints and AI agents.
Protect an endpoint
Minimal wrap-this-route diagram for protecting an endpoint
Related
Identity in twin circuits
Compiled prover / verifier twins and sealed private relationship.
Engineering stack
Foundry, Control, Gate, Verify planes.
Deployment models
Model A/B plus four execution topologies.
Migration
Shadow mode then proof-required per route.
Circuit Authority
Baseline mint → prove; onboard XOR teaser.
Claims / honesty
Model-scoped affirmative claims.
Ready to install on one route? Homepage adopt path · Quickstart