Verify it yourself
A payment receipt proves that money moved. NOMOS is built to prove more: publicly testable continuity from represented intent through authorization and execution to a signed, verifiable receipt and resulting outcome. On this page you can check that claim on your own machine, for free, in about two minutes — no wallet, no account, no contact with our servers beyond downloading four public files.
The product in 30 seconds
AgentNOMOS (by FeedOracle Technologies) is a governance layer for autonomous agent actions. Before a machine action runs, NOMOS binds together: the represented intent, the selected capability, the offer (price/terms), current security evidence, the authorization decision, the actual execution, an Ed25519-signed execution receipt, and the outcome. The result is one connected evidence chain — so a refusal is as auditable as an approval, and a receipt binds far more than a payment.
There are four distinct surfaces. Do not confuse them:
The interactive demo on the homepage gives explanatory answers only — it executes nothing, signs nothing, settles nothing. Machine discovery (A2A agent card, ai-catalog, x402 manifest) is free metadata. The paid x402 route below runs one real governed action. Inbound payment is supported; NOMOS holds no autonomous outbound-wallet authority — it never spends on its own.
The live paid capability
nomos_full_chain_verification
| Invocation | POST https://tooloracle.io/v2/nomos_full_chain_verification (x402 payment flow: first call returns HTTP 402 with payment requirements) |
|---|---|
| Price | $0.001 USDC per call |
| Network | Base Mainnet (eip155:8453) |
| What it does | Runs one safe, read-only machine action (a registry statistics read) through the complete eleven-stage NOMOS Trust Chain and returns the result plus an Ed25519-signed execution receipt binding payment, intent, offer, admission evidence, execution and response bytes |
| Discovery | A2A agent card · ai-catalog · x402 manifest · capabilities manifest |
| Receipt keys | Public JWKS: feedoracle.io/.well-known/nomos-execution-jwks.json |
This path is optional and paid. Everything below it is free.
Path 1 — Free offline verification (start here)
We publish two reference evidence bundles from production — one ALLOW
(a real settled $0.001 execution) and one DENY (a real production
refusal, HTTP 403 TASK_FIT_MISMATCH, where only the append-only
refusal store advanced and every execution counter stayed at zero) — together
with a stateless ~300-line Python verifier (stdlib; the cryptography
package only for the Ed25519 check).
curl -sO https://agentnomos.com/proof/full-chain/allow-reference.json
curl -sO https://agentnomos.com/proof/full-chain/deny-reference.json
curl -sO https://agentnomos.com/proof/full-chain/nomos_repro_verify.py
curl -s https://feedoracle.io/.well-known/nomos-execution-jwks.json -o jwks.json
python3 nomos_repro_verify.py --allow allow-reference.json \
--deny deny-reference.json \
--jwks jwks.json
Expected final line:
21 checks: 21 PASS, 0 FAIL, 0 NOT_RUN
The checks recompute the intent digest, the capability/offer/evidence bindings, the receipt digest over verbatim JSON number lexemes, and the Ed25519 receipt signature against the public JWKS. The settlement transaction in the ALLOW bundle is a normal USDC transfer on Base — inspect it on any public Base explorer. Full methodology, including which fields are cryptographically verifiable, deterministically recomputable, or operator-attested: verify.md. Tamper with any bound byte and the verifier fails closed — that is the point.
Path 2 — Optional live paid verification
If you want your own receipt rather than our reference one: any
x402-capable client can call the endpoint above. You pay $0.001 USDC on Base,
receive the result of one governed read-only action, and can verify the returned
receipt against the same public JWKS with the same verifier logic. The first
un-paid POST simply returns the HTTP 402 payment requirements — that
alone shows you the offer terms without paying.
The Trust Chain (canonical model)
The NOMOS Machine Economy Trust Chain is eleven stages, S0–S10. In plain terms, one governed action passes through:
- Discovery & identity — who is asking, and which published capability is addressed
- Represented intent — a digest-bound intent document naming capability, action, route, purpose and constraints
- Offer — the priced terms the caller accepted (x402)
- Security evidence — current, freshness-gated evidence about the executing estate, an input to authorization (fail-closed)
- Authorization — an admission decision that can ALLOW or DENY; a DENY is recorded evidence, not a dropped request
- Execution — the actual bounded action
- Signed receipt — Ed25519-signed, binding payment, intent, offer, admission, execution and response bytes
- Outcome & governance context — the result and its append-only stores
Technical stage labels (S0–S10)
The canonical internal labels are S0 through S10 — eleven stages covering discovery, identity, capability, intent, offer, security evidence (S8 freshness), authorization, execution, proof, outcome and governance. The capabilities manifest is the digest-bound machine representation. Earlier public material described a twelve-layer architecture; that model is historical and superseded by the eleven-stage S0–S10 chain described here.
What this proves — and what it does not
| Proven, and you can check it | Not proven, and we do not claim it |
|---|---|
| Continuity: the receipt binds represented intent, capability, offer, security evidence, authorization decision, execution and response bytes into one digest-linked object | That the represented intent was the correct interpretation of the human's underlying meaning |
| The receipt signature verifies against a public Ed25519 JWKS; the settlement is a public on-chain USDC transfer on Base | Independent external proof — no uncontrolled third party has (yet) published their own verification; the reference transaction was our own canary, and we say so |
| Refusals are evidence: the published DENY shows a production 403 where no execution counter moved | Full public reproducibility of the internal policy — the policy's version and digest commitments are public; the policy itself is not |
| Inbound x402 settlement works end-to-end at $0.001 | Any autonomous outbound spending authority — NOMOS has none |
| The digests are deterministically recomputable from the published documents alone | That payment alone proves correct authorization or correct execution — it never does; that is the whole reason the rest of the chain exists |
The claim boundary
NOMOS proves continuity from the represented intent onward. It does not prove that the represented intent was the correct interpretation of the human's underlying meaning.
Everything published on this surface carries the claim ceiling execution-bound proof: it is evidence about what this operator's estate executed and signed, machine-checkable by you — not an independent audit, not a certification, and not a claim of external adoption. Signed offers and receipts as concepts are not our invention — x402 and neighboring protocols already define offer/receipt primitives. What NOMOS adds is the governed binding across intent, capability, offer, security evidence, authorization, execution, receipt and outcome.
How it composes with existing protocols
| Protocol | Role in NOMOS |
|---|---|
| A2A (Agent-to-Agent) | Discovery: agent cards on agentnomos.com / agentnomos.network (card format A2A v1; the live endpoint speaks A2A 0.3) |
| x402 | Paid invocation and settlement of the live capability (HTTP 402 offer → USDC payment on Base → response + receipt) |
| MCP | Metadata and tool surface (MCP 2024-11-05). MCP is not a paid invocation path for this capability |
| AP2 | Mandate/cart concepts map to NOMOS intent+offer binding; extension declared in the agent card |
| XRPL | Earlier governed-payment pilots and anchoring work; see the XRPL page |
| ERC-8004 | Complementary: ERC-8004 can identify an agent and publish validation signals; a NOMOS receipt is an execution-bound evidence object such a validator could evaluate |
These are interoperability descriptions, not endorsements by any protocol organization.
Security & responsible disclosure
Security contact and policy: /.well-known/security.txt.
If you find a way to make a verifier pass on tampered evidence, or any boundary
violation, we want to hear it — and we will document failed external tests as
openly as passed ones.