NOMOI Network of Mandated Operational Invariants
Authority should be something you hold and can prove, not something that needs to be looked up. Act on it, pass a narrower slice of it onward, let anyone verify it — without having to query the issuer.
NOMOI records each delegation as a signed, immutable event instead of a row in someone else's database. Whoever receives authority may delegate a strict subset of it further on their own, and the chain that results verifies end to end: every signature back to the root, authority narrowing at each step, nothing revoked.
No central authority or governing bodyNo identity providerNo account with the issuerNo private APINo prior integration
com
com
com
Revoke any link — authority below it fails with it.
nomoi.the-gap
A board authorizes an executive. A manufacturer appoints an auditor. A bank lets a subsidiary sign on its behalf. These decisions usually live inside proprietary systems that stop being useful at the boundary of the institution that runs them.
When a CFO grants signing authority to a clerk, it becomes a flag in a database. There is no standard way to carry that fact elsewhere and verify it without the issuer's cooperation.
A regulator asking years later whether an action was authorized gets screenshots, email threads, and database exports. Nothing guarantees that the trail is complete or unchanged.
Sharing authorization across institutions usually means a custom agreement, a proprietary API, or a common platform. Each new counterparty adds another integration.
nomoi.primitives
NOMOI is deliberately small: a key pair, a directory, a signed record, and the rule that authority can only narrow as it passes from one party to the next.
01 — Identity
There is no username, account, registry, or DID resolver. The public key is the identifier; proving identity means proving control of the private key. You can keep separate keys for different employers, consortia, or platforms without linking them through a central account.
alg −8 Ed25519 · −7 ES256 · −35 ES384 · −36 ES512
declared per mandate, from the IANA COSE registry, inside the signed payload
02 — Trust Anchor
A Trust Anchor is a directory of small text files: the keys allowed to issue root mandates, the scopes they may grant, the peers accepted as roots, and any revocations. Each state is content-addressed and reached through a stable pointer that only the anchor's operator can update.
Each state names its predecessor by hash. Rewriting the past changes its address, and every state published since would have to be reissued to still point at it.
03 — Mandate
A mandate names its issuing anchor, its parent, its place in the chain, the keys and algorithms involved, its scope and validity window, and an optional context object. Deterministic CBOR ensures that the same content produces the same bytes and therefore the same address in every conforming implementation.
ta · iss · idx · alg · sub · salg · scope · iat · nbf · exp · ctx
04 — Scope
A scope is a dotted path. A child must extend its parent's scope: never the same scope, a sibling, or a broader one. Every verifier checks this locally. Time narrows in the same way: a mandate cannot begin before or expire after its parent, and must be issued while its parent is valid.
com.acme → com.acme.finance → com.acme.finance.banking.acmebank
com.acme ↛ com.acme · com.acme.operations ↛ com.acme.finance
nomoi.trust-anchor
A Trust Anchor is a canonical directory whose root hash identifies its exact contents. It can be published over IPFS, signed HTTP, or any other binding that provides content-addressed storage and mutable discovery.
nomoi.verification
The checks are deterministic and mostly local. The verifier only needs to fetch the anchors' current public state, and it does that independently rather than trusting the presenter to provide it.
Reject a claimed chain index at or beyond the verifier's MAX_GRAPH_DEPTH before doing any cryptographic work.
Is this anchor one we accept at all? Chains rooted anywhere else stop here, before any state is resolved.
The administrator anchor that governs this deployment, and the anchor that issued the chain — each resolved independently, every time. Anchor state is never taken from a presentation, because revocation cannot be supplied by the party asking to be trusted.
Follow each mandate's iss field to its parent, one hop at a time, until reaching index 0.
Verify the signature with the parent's subject key. Check both algorithms, the index, strict scope narrowing, and the validity window. Confirm that the child was issued while its parent was valid.
Check every mandate address and delegated key against the issuing anchor and the verifier's administrator anchor. Either can revoke the chain, so local policy may reject authority the remote issuer still considers valid.
The root signer was a registered root identity in the anchor state named at issuance, and still is in the current one. The anchor is whitelisted, and the root scope falls under a prefix that whitelist entry actually grants.
The chain alone does not prove that its presenter holds the delegated key. The verifier therefore sends a 128-bit nonce, and the presenter signs it with the leaf key within thirty seconds.
Verdict
200
Checked and valid. Retain the chain — it is your audit record now, and it stays verifiable whether or not the issuer still exists.
Verdict
417
Checked and rejected. It will not become valid until it changes. A 21-bit error bitset says exactly which invariants failed — all of them, not just the first.
Not a verdict
503
Inconclusive. The verifier could not reach something it needed and concluded nothing. The chain may be perfectly good. Neither of these authorizes anything — but only one is worth retrying.
nomoi.applications
The specification works through these scenarios in detail. Each uses the same four primitives; only the scopes and the relying party's policy change.
Supply chain
An automaker delegates audit authority to an audit firm; the firm certifies a lithium mine; the mine signs each shipment; the battery maker extends the chain. A consumer scans the QR on the finished car and verifies the whole graph — without an account, and without contacting any party in it.
com.automaker.goals.sustainability.auditor.mine.chile.atacama.shipment
Spec § B.1
Finance
A clerk presents a ninety-day mandate issued by the CFO under the manufacturer's root authority. The bank verifies the chain, challenges the clerk to sign a nonce, authorizes the wire, and keeps the evidence. Years later, its regulator can audit the record without the manufacturer's help.
com.manufacturer.finance.banking.acmebank
Spec § B.2
Access
At installation, a door controller is given one anchor identifier. HR grants an employee access to a floor; the employee taps NFC; the controller verifies the chain and challenges the employee's key. When the employee leaves, one revocation entry closes every door after its next refresh. No central badge service is required.
org.acme.floor3.east
Spec § B.3
Consumer
A platform issues each user a mandate bound to a key generated on their own device. Logging in means signing a server nonce. A phished password yields nothing. A breached database yields public keys, which authorize nothing. A stolen device is one revocation entry. Different key per platform, so nothing cascades.
com.e-commerce.user.actions
Spec § B.4
Machines
A purchasing agent bids on spot-market freight under a 24-hour mandate. Its context sets a maximum contract value and an approved carrier list. A carrier can verify the agent's authority back to the principal, while the principal can stop it with a single revocation entry.
com.shipco.procurement.agent.spot-market
Spec § B.5
Finance
Each director's approval is a separate mandate with its own chain. The relying application can require two of three approvals today and three of five next quarter. The policy changes without migrating a smart contract; each approval remains independently verifiable.
com.bank.wires.large.authorize
Spec § B.6
Supply chain
A manufacturer attaches a denied-party policy to its root mandate. Three delegations later, a point-of-sale gateway follows the reseller's chain back to that root and retrieves the committed policy. Intermediaries cannot remove it without breaking the chain.
com.manufacturer.resale → … → 3 hops down
Spec § B.7
Social
ActivityPub describes the social graph but not institutional authority. A moderator's standing, a verification badge, or one instance's trust in another usually remains platform state. An actor's existing signing key can receive a mandate, letting moderation actions carry proof of authority and allowing the issuer and host to revoke independently.
social.commons.moderation.reports.de · press.presscorps.verified.journalist
Spec § B.8
Public sector
A product passport may expose restricted sections to repairers, recyclers, and authorities it has never seen before. A national accreditation body issues role mandates, and the passport host grants access by verified scope rather than by a pre-arranged account. Access ends when the accreditation is revoked or expires.
eu.dpp.role.recycler · com.manufacturer.dpp.repair-history
Spec § B.9
Public sector
A product's carbon figure combines measurements from several suppliers. If each tier attests its own batches under a chain that follows the bill of materials, an auditor can trace the total back to its inputs. Revoking a supplier's mandate marks its contribution invalid wherever that chain is checked.
com.oem.bom.battery.cathode.precursor
Spec § B.10
Machines
A mandate can be issued without publishing it. Its address comes from its bytes and stays the same if it is published later. Chains can travel as PEM, QR codes, over NFC, or on paper; with sufficiently fresh anchor states cached independently, verification can run offline.
nomos bundle --chain --qr <cid>
Implementation
nomoi.boundaries
NOMOI stays focused on delegation. Identity claims, business rules, and transport choices remain outside the protocol by design.
NOMOI does not need global consensus or a shared transaction log. Signatures prove who delegated authority, content addressing makes changes evident, and each verifier chooses its own trusted anchors. There is no chain-wide registry of every mandate.
NOMOI does not claim to establish a person's name or attributes. It records which key received authority, from whom, for what scope, and for how long. Applications remain responsible for any real-world identity they attach to that key.
IPFS is the reference binding, because it is mature and makes every abstract operation concrete. The protocol's actual contract is six operations. A private object store with signed manifests, a DASL-style CAR-over-HTTP transport, a different DHT — all conform, and a deployment may even mix bindings across storage and discovery.
A scope carries authority; the relying application decides what that scope means. Spend limits, approval thresholds, and other conditions can live in a context object whose hash the mandate commits to. NOMOI preserves that object without trying to interpret its rules.
nomoi.implementation
nomos is the reference implementation and the quickest way to issue, move, and verify mandates. It includes a CLI and an HTTP verification service, with the protocol kept in a reusable package for other clients and transport bindings.
Go · reference implementation
Create keys and Trust Anchors, issue mandates, carry chains as PEM or QR codes, verify them, prove possession of the leaf key, and audit an anchor's history. The built-in server exposes the verification and challenge flow over HTTP.
go install codeberg.org/nomoi/nomos/cmd/nomos@latest
Apache-2.0 · Go 1.26+ · v1 release candidate · needs a Kubo RPC endpoint for the IPFS reference binding
codeberg.org/nomoi/nomos ↗From nothing to a verified delegation
# the endpoint, and the anchor whose revocations you trust nomos init # a key pair — this is your identity nomos id add alice # your own anchor: who may sign, and for which scope nomos ta init self --ipns k51... nomos ta id add self alice --scope com.acme nomos ta whitelist add self k51... --scope com.acme nomos ta publish self # trust this anchor's whitelist and revocations nomos config edit # delegate, then check it nomos id add bob nomos issue root --issuer alice --subject bob \ --scope com.acme --publish nomos verify <cid> -v
Publishing is optional. Without --publish, issue writes a portable PEM presentation to stdout and its CID to stderr. Publish those same bytes later and the CID remains unchanged.
nomoi.get-started
Inside the organization, a mandate does the job a role assignment does today — who may act, for what, until when — except it is signed, independently verifiable, and withdrawn with a single entry. A door controller needs one anchor identifier instead of a badge platform; standing becomes a delegation rather than a row in an accounts table. Outside the organization, the same chain keeps working, for the counterparty with no account and the auditor asking years later. Install the client, publish an anchor, issue one mandate, and verify it from a machine that has never heard of you.
v1 release candidate — implemented in full, covered by tests, not yet independently reviewed