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 prover and verifier twin circuits sharing a sealed private map while the public channel carries only witnesses — 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.

Twin circuits → · Foundry →

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.

Circuit Authority →

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.

Gate → · Protocol →

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 validation topologies

Start with one-shot metered validation for a new relationship, move to hosted validation as the relationship persists, and graduate to local cache when volume justifies it — all against the same pinned digest. Choose enterprise self-hosted when compliance requires execution inside your boundary.

Topology A · Often pairs with envelope Model A (local verifier).

Local pull / cache

The relying service fetches the verifier once, verifies the digest, caches under a digest-keyed path, and validates locally thereafter. Periodically recompute the cached digest; pair with a status-freshness policy so a byte-correct cache cannot authenticate a revoked binding.

Choose for high volume, edge latency, and air-gap tolerance after first pull.

Topology B · Often pairs with envelope Model B (Control plane).

Hosted executor

The service sends the challenge or proof with the pinned digest. A managed executor resolves, verifies, runs the circuit in a sandbox, burns the nonce, and returns a verdict with a signed receipt. Client envelope code stays the same; ops load moves to the host.

Choose when you will not execute third-party native code or need fast integration.

Topology C · Edge Gate may still use local validation with approved sync paths.

Enterprise self-hosted

The organization runs the same executor inside its boundary. Authority records resolve through internal mirrors or signed snapshots. Challenges, proofs, validations, and ledger records stay inside the enterprise. Air-gap is possible within an explicit maximum staleness.

Choose for regulated, residency, or sovereign estates that cannot depend on a third-party control plane.

Topology D · Commercial metering beside envelope Model A or B.

One-shot metered

A merchant or partner who has never seen the subject resolves the published digest and status, requests a single metered validation, relays the challenge, and retains a signed independently verifiable receipt. No long-lived account relationship is required.

Choose for first-contact commerce, checkout, or entitlement checks. Billing scaffolding may be roadmap-honest where StatusBadge applies.

Adopt / topologies → · Deployment models · topologies → · Book a live demo →

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 names
digest — content address of the verifier artifact
location — where authorized fetchers retrieve bytes
last-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

Ready to install on one route? Homepage adopt path · Quickstart