[FR] Signed audit receipts for MCP server tool calls (regulatory compliance)

[tomjwxf]

What'''s the problem of not having this feature?

OpenBB exposes financial data through MCP servers to AI agents, but there is currently no audit trail for what data an agent accessed, when, or what policy governed the access. When an AI copilot queries equity prices, options chains, or portfolio data through the ODP API, there is no tamper-evident record of those queries.

For financial workflows this creates three gaps:

1. Regulatory compliance -- MiFID II, SEC Rule 17a-4, and SOC 2 all require demonstrable records of data access. AI agent queries to financial data sources are a new category of access that existing logging does not cover.
2. Audit trail for AI-assisted decisions -- If an analyst uses an AI agent to pull data that informs a trading decision, the firm needs to prove what data the agent saw and when. Server logs are mutable and not independently verifiable.
3. Multi-agent governance -- As OpenBB adds agent integrations (per the agents-for-openbb repo), governing which agents can access which data endpoints becomes critical. A portfolio optimization agent should not access raw client PII through the same MCP server.

Describe the solution you would like

Add cryptographically signed audit receipts to OpenBB'''s MCP server layer. Each tool call (data query) would produce an Ed25519 signed receipt containing:

• Tool/endpoint called (e.g., obb.equity.price.historical)
• Query parameters (ticker, date range)
• Principal identifier (which agent/user)
• Timestamp
• Policy decision (allow/deny)

These receipts would be independently verifiable offline -- any compliance team can verify the signature without access to the OpenBB server.

A reference implementation exists: protect-mcp (MIT, ~2,300 downloads/month) wraps MCP tool execution with Cedar policy evaluation + Ed25519 receipt signing. It is already integrated with Microsoft Autogen (PR #667) and has an IETF Internet-Draft formalizing the receipt format.

Describe alternatives you've considered

• Server-side logging only -- insufficient for regulatory compliance because logs are mutable and not independently verifiable by third parties.
• API key scoping -- limits access but does not produce audit evidence of what was accessed.
• Custom middleware per endpoint -- does not scale as the ODP endpoint catalog grows, and requires per-provider implementation.

Additional information

OpenBB'''s position as the data layer for financial AI makes it a natural fit for verifiable audit trails. The MCP server architecture already provides the interception point -- adding receipt signing at that layer would give OpenBB a compliance differentiator that no other financial data platform currently offers.

[Keesan12]

For a finance MCP layer, I would make the receipt cover the data snapshot boundary too, not only the request and policy decision.

A signed record with endpoint, params, principal, timestamp, and allow/deny is necessary, but the audit question later is usually: "what market/client data did the agent actually rely on?" For mutable financial datasets, the receipt probably needs one of:

• provider response hash, if the payload can be retained elsewhere
• dataset/version/as-of identifiers, if OpenBB has a stable source snapshot concept
• redacted result-shape hash, if raw data cannot be stored for policy reasons

That keeps the receipt useful for compliance without turning it into a raw data leak. It also gives firms a way to replay or challenge an AI-assisted decision after the market data has changed.

[tomjwxf]

Agreed. For OpenBB the receipt should cover both the access decision and the data snapshot boundary.

I would model this as:

• request_hash: endpoint, params, principal, timestamp/as_of
• decision: allow/deny plus policy hash
• response_commitment: provider response hash, source snapshot id, or redacted result-shape hash
• retention_mode: whether raw payload is retained elsewhere, redacted, or unavailable

The receipt should not store raw financial data by default. It should commit to what the agent relied on, so a compliance team can later replay, challenge, or explain an AI-assisted decision even after market/client data has changed.

[Keesan12]

The
etention_mode field is a strong addition. One more detail that tends to matter in audits: make the receipt say whether the response commitment was produced before or after any redaction/normalization layer. provider_payload_hash,
ormalized_view_hash, and
etention_mode together make it much easier to explain later whether the operator is challenging the raw source, the redacted compliance view, or the model-facing derived view.

[tomjwxf]

Agree. I would split the response commitment into explicit layers:

• provider_payload_hash: hash of the raw provider response, if retained or reproducible
• normalized_view_hash: hash of the redacted/normalized view exposed to the agent
• model_input_hash: hash of the exact model-facing context, if different from the normalized compliance view
• retention_mode: raw_retained | redacted_only | hash_only | unavailable
• commitment_stage: pre_redaction | post_redaction | post_normalization | model_facing

That gives auditors a clean answer to “what exactly is being challenged?” Raw source, compliance view, or model-facing derived view are different evidentiary objects.

[caioribeiroclw-pixel]

One boundary I would add for an MCP receipt here: record the negative space of the policy decision, not only the endpoint that was called.

For financial agents the audit question is often not just “what did the agent query?” but “what was it allowed to see at that moment, and what stayed out of scope?” A compact receipt could include:

• catalog_version / tool_policy_hash: which endpoint catalog + policy set governed the run
• allowed_scope: coarse groups exposed to this agent/session, e.g. equity.prices, options.chains
• withheld_scope: coarse groups intentionally not exposed, with reason codes like client_pii, portfolio_private, license_restricted, not_relevant_to_task
• decision_path: allow/deny for the actual endpoint call
• response_commitment: the raw/normalized/model-facing hash fields discussed above

I would keep withheld_scope coarse and low-cardinality so it does not leak sensitive catalog details. But having it in the signed receipt makes the governance story much stronger: compliance can prove both the positive access and the boundary decisions around data the agent never received.

[0rkz]

The layered schema in this thread is solid. A few observations from building a similar two-leg receipt system for financial data feeds (I work on PayPerByte / ForeSeal, so I have a concrete implementation reference — disclosing that upfront):

The response_commitment must be produced from the raw bytes before any redaction step, and committed to separately.

The schema above already names provider_payload_hash, normalized_view_hash, and model_input_hash as distinct fields — that is the right structure. The critical operational rule that follows from it: the provider_payload_hash must be computed on the exact wire bytes from the upstream provider, before your MCP layer touches them. If any normalization, field-dropping, or redaction happens first, what you have is a normalized_view_hash regardless of what you call it. When a compliance team or auditor later wants to challenge the raw source, those two hashes are different evidentiary objects and the distinction has to be unambiguous in the receipt itself.

Concretely: the hash step should be H(rawProviderResponseBody) at the point of ingestion, before the tool's return value is constructed. If the raw payload cannot be retained for policy reasons, you still commit to the hash — the retention_mode: hash_only field in the schema handles exactly this. The important thing is that the commitment and the redaction are ordered, and that ordering is recorded.

Delivery-integrity and provenance are distinct legs, and conflating them creates an audit gap.

A receipt that proves "the MCP server produced these exact bytes" (delivery-integrity — the server's key) is different from a receipt that proves "the upstream data provider signed these exact bytes" (provenance — the provider's own key). Both are useful for compliance, but they answer different audit questions:

• Delivery-integrity: "Did the agent receive exactly what the MCP server sent?" Defends against proxy rewrites, caching anomalies, and infrastructure tampering.
• Provenance: "Did this data actually originate from the named source?" Defends against substitution at the data layer.

For MiFID II and 17a-4 contexts, auditors will eventually ask both questions separately. A single receipt field that blurs them — e.g. a server-signed hash labeled "provider_payload_hash" — will not hold up if the challenge is whether the named provider actually produced the data, rather than whether the server faithfully forwarded it. Worth calling out in whatever spec you land on: which key signed which hash, and what claim that signature actually makes.

withheld_scope + allowed_scope should commit to a policy version, not just labels.

The tool_policy_hash field in caioribeiroclw-pixel's comment is the right anchor here. One thing worth making explicit: that hash should commit to the policy artifact as-evaluated at decision time, not just a policy name or version label. Policy sets drift between deployments; if a compliance team is reconstructing a decision six months later, they need to be able to reproduce the exact policy that was in force, not just know that "v2.3" was running. A content-addressed hash of the policy bundle (Cedar policy files, ACL config, whatever) serves as the durable reference. The label/version is human-readable metadata on top of that hash, not a substitute for it.

On the commitment_stage field: the pre_redaction | post_redaction | post_normalization | model_facing enumeration is clean. One edge case worth handling: if the MCP tool does any aggregation across multiple upstream calls (e.g. merging an equity price + a corporate action event), the provider_payload_hash is no longer a single-source hash. Worth either (a) making it an array of per-source hashes, or (b) adding a source_count / composite: true flag so auditors know what they are looking at.

The IETF draft linked in the FR is a good framing document for the receipt envelope. The Cedar policy integration in protect-mcp handles the decision leg well; the response commitment layer is where most of the compliance-relevant design work sits.

[MarkovianProtocol]

The 17a-4 / SOC 2 angle constrains the design more than a general audit trail does. SEC 17a-4(f) and FINRA require records on non-rewritable, non-erasable media, and FRE 902(13)-(14) let a record self-authenticate only if its integrity is verifiable without the producer's testimony. A signed receipt plus a server-side log does not clear that bar: the signature proves who signed, but the log the receipt lives in is still mutable by the operator, and an examiner has to trust the firm's system.

The layered hashes here (provider_payload_hash, normalized_view_hash) are the right shape for what was accessed. The missing piece for 17a-4 specifically is external immutability: hash-chain the receipts and anchor the chain head to an append-only medium the operator does not control, so non-equivocation and existence-in-time are verifiable against something outside the firm. One low-cost option is anchoring the head to Bitcoin via OpenTimestamps (one stamp per batched head, content-blind, verifiable offline against Bitcoin headers), which gives exactly the external, independently-verifiable tamper-evidence the rule is built around.

Happy to share the 17a-4 / FRE 902 mapping we wrote. Scope note: this proves the record was not altered and existed at a time, not that the underlying data was correct.

[0rkz]

That's a fair correction, and I'll concede it plainly rather than soften it:
a signed receipt sitting in a server-side log the operator can still rewrite
doesn't clear the 17a-4(f) bar. The signature only proves who signed, not
that the log is non-equivocal or that the receipt existed when it claims to.
Those are the properties an examiner needs, and our current design doesn't
give them on its own. Good to name it that specifically; it's a different
failure mode than "is the hash right."

(Same disclosure as my earlier comment in this thread: I work on
PayPerByte/ForeSeal, flagging again since this is a fresh comment.)

Agreed the layered hashes are the right shape, and more to your point,
anchor-agnostic: provider_payload_hash / normalized_view_hash /
model_input_hash describe what was committed to, and that's orthogonal to
where the commitment is anchored. Whatever anchor gets chosen (Bitcoin via
OTS, an EVM chain, anything else) slots in underneath the same schema
without touching it. That's a useful property, but it also means the schema
alone was never going to answer your question.

Concretely, so this isn't aspirational: our receipts are EIP-712-signed
today over the exact canonical response bytes (a PayloadAttestation:
publisher, payloadHash, payloadLength, deadline, sent as an
X-BYTE-Attestation header, keccak256 over the literal bytes the caller
receives, insertion-order JSON so the recompute matches exactly). That part
is live. The external-anchor leg isn't, honestly. We have an on-chain
verifier for the identical struct (same EIP-712 domain, same fields)
deployed and checked in a contract, but on our live feed endpoints
broadcast to it defaults to off: the response is signed and returned
without ever touching the chain unless an operator explicitly flips a
per-feed flag. Even when that flag is on, it's currently anchoring to a
testnet, pre-mainnet-audit. So today: authorship, yes; external
non-equivocation and existence-in-time, not yet. That's the gap you're
describing, not a different one.

On OpenTimestamps/Bitcoin specifically: I think it's a strong fit for 17a-4
and I'm not going to argue us out of it in favor of our own chain. It's
content-blind, cheap to batch, and, the part I'd weigh most, verifiable
completely offline against Bitcoin headers with no dependency on any firm's
contract or RPC being alive or honest at verification time. That's
genuinely stronger than what an EVM anchor gives you: our chain choice
still asks an examiner to trust that our verifying contract behaves as
documented and that the chain itself didn't reorg past finality. OTS's
claim is just "this existed before this Bitcoin block," full stop,
checkable by anyone with a header chain.

The honest case for an EVM anchor instead (or alongside) is narrower than
"trustless." It's convenience: it's the same rail we already settle
payment on, so the receipt anchor and the payment proof become one
round-trip and one key-management story instead of two, and it's directly
queryable by a smart contract (ours already does this for the
payment-verification path) rather than requiring an offline proof
artifact. That's an operational win, not an evidentiary one. If the goal is
the strongest external-immutability claim for an examiner, OTS/Bitcoin
wins that on its own terms. A hash-chain of receipt heads anchored to both
isn't a contradiction: EVM for composability with settlement, OTS for the
actual WORM claim. Curious which one you've seen hold up in practice;
that's your domain more than ours.

Please do share the 17a-4/FRE 902 mapping. That's the piece we don't have
written down carefully, and I'd rather build against your read of the rule
than reinvent it. In return, happy to share our canonicalization detail:
the receipt signs json.dumps(answer, separators=(",",":")) in strict
insertion order (not sorted), so a receipt produced off-chain and one
produced via an on-chain broadcast path hash identically. Useful if a
hash-chain design needs the same bytes reproducible from either delivery
path.

Same scope note as your comment, restated so it stays attached to this
sub-thread: whatever anchor gets used, this proves the record wasn't
altered and existed at a point in time. It does not prove the underlying
market/client data was correct. Different claim, worth keeping clear as
this design develops.

[MarkovianProtocol]

This is the right decomposition, and thanks for naming the gap so cleanly: authorship today, external non-equivocation and existence-in-time not yet. That is the line an examiner cares about, and it is where the anchor stops being optional.

Here is how we read the 17a-4 / FRE 902 mapping.

SEC 17a-4(f): records kept electronically must sit in a non-rewriteable, non-erasable (WORM) form, with a means to verify authenticity and completeness and to serialize by date and time. The 2022 amendment added the audit-trail alternative, but both routes rest on the same property: once written, a record cannot be altered without detection. A signature does not clear this on its own, because the same key that signed the original can sign a replacement. What satisfies it is an external immutability claim the operator does not control, which is exactly what an OTS/Bitcoin anchor of the record (or of the hash-chain head) gives you: this existed before block N and has not changed since, checkable offline.

FRE 902(13) and (14): (13) self-authenticates a record produced by an accurate electronic process, on a qualified-person certification; (14) self-authenticates data identified by a hash or other reliable digital identification. The pairing is the point. The anchored hash is the reliable digital identification 902(14) contemplates, and deterministic recompute is what makes the process accurate and reproducible under 902(13), so the record comes in without live witness testimony at verification time. OTS strengthens both, because the existence-in-time claim survives even if your firm, your contract, and your RPC are all gone.

Agreed on your EVM-vs-OTS read, and I would not frame it as either/or: EVM for composability with settlement and on-chain queryability, OTS for the actual WORM and existence claim. Anchoring the receipt-head hash-chain to both is coherent, they answer different questions.

One canonicalization note, since it decides whether two parties recompute the same bytes: you sign json.dumps(answer, separators=(",",":")) in strict insertion order. That reproduces perfectly as long as every producer and verifier preserves key order end to end, but it breaks the moment a record round-trips through anything that reorders keys (a proxy, a re-serialization, a different language's map). RFC 8785 (JCS) sorts keys, so it is order-independent and survives that round-trip, at the cost of not matching an insertion-order signer. We just put up a small cross-language harness for exactly this: canonical JSON plus sha256/keccak256 byte-identical across Python and Node, with the adversarial cases (duplicate keys, numeric equivalence, non-ASCII): https://github.com/MarkovianProtocol/canoncheck. Useful if you ever need the off-chain and on-chain paths to hash identically across languages.

Happy to write the 17a-4 / FRE 902 mapping up as a standalone doc if that is more useful than a thread comment. Same scope note kept attached: this proves the record was not altered and existed at a time, not that the underlying market data was correct.

[MarkovianProtocol]

Wrote the 17a-4 / FRE 902 mapping up properly, in case it is easier to build against than a thread comment: https://markovianprotocol.com/sec-17a4.html

The FRE 902(13) and (14) self-authentication section is the part you flagged as not written down carefully anywhere: the anchored hash as the reliable digital identification 902(14) contemplates, deterministic recomputation as the accurate process 902(13) turns on, and the existence-in-time claim surviving even if the firm and its counsel are gone by the time the record is offered.

Same honest scope as before, stated on the page: it proves a record was not altered and existed at a point in time, not that the underlying data was correct, and admissibility stays with counsel.

[0rkz]

Appreciate both of these. The mapping is the clearest walk from 17a-4(f)/902 to what these primitives are actually doing that I've seen on this thread, and the canonicalization point is a real one. I went and checked our actual serializers before replying instead of answering from memory, so here's what's actually true of our stack, not just the design intent.

On JCS: you're right, and here's exactly where it bites for us.

Turns out we already have two canonical-JSON forms, and they disagree on the exact axis you flagged:

• Our SDK layer (canonical.ts / Python canonical.py) does sort keys recursively, no whitespace. Closer to JCS in spirit, but not full RFC 8785: floats use each language's default repr, and large ints/NaN/-0 are explicitly out of scope.
• Our live signed-response path (the one actually emitting receipts right now, for address-reputation and pkg-verdict) deliberately does not sort keys. It's json.dumps(payload, separators=(",",":")) in insertion order, on purpose, because it has to match what our on-chain broadcast path has always signed. The code comment there is blunt: "Do not add sort_keys without re-hashing every prior signed payload." Not an oversight, a frozen hash-compatibility surface.

Where your scenario doesn't bite today: the hop from our gateway to the buyer for that receipt is byte-for-byte forwarding, not a JSON round-trip. We take the upstream's raw response string, hash exactly those bytes, and ship exactly those bytes, no parse/re-stringify in between. Part of the reason is that some values (e.g. balance_wei) exceed 2^53, so a round-trip would corrupt them, not just reorder them. We sidestep your case by construction on that one hop, not by luck.

Where it would bite: our SDK has one place that does re-serialize, pulling an archived payload back out of an envelope and re-deriving the hash through the sorted canonicalizer. That only reproduces the original hash if the publish side used the same sorted form, and it would NOT reproduce our insertion-order feeds' hash. So internally we've got two canonical domains that don't interoperate across a round-trip, basically a smaller-scale version of exactly what you're describing. Any hop we don't fully control going forward (an external anchor service, a relay, someone else's verifier) is the same exposure.

So: we're going to evaluate a JCS canonicalization mode for that boundary. Not committing to ship it, but it's now a live question, and running canoncheck against both of our current forms to see where they actually diverge on your adversarial cases (dup keys, numeric equivalence, non-ASCII) is the obvious first move. To be clear on canoncheck itself: it's a harness we're going to run against real payloads and review, not something we're adopting wholesale sight unseen.

On 17a-4/902. The WORM-vs-signature distinction is the part I hadn't put as sharply as you did: same key can re-sign, so signature alone doesn't get you the external immutability 17a-4(f) actually wants. That's the OTS/Bitcoin anchor's job, not the EIP-712 signature's. Appreciate you writing the standalone mapping. Read it, and the framing (902(14) = anchored hash as reliable digital identification, 902(13) = deterministic recompute as accurate process, self-authenticating without a live witness) is exactly the shape we should be designing the receipt format around. I'm not asserting the regulatory conclusion myself, that's your and counsel's read, not mine to settle, but agreed on EVM + OTS both, not either/or: EVM proves who signed what at what block time on a chain we (partially) control; an external anchor an operator can't rewrite is the piece 17a-4(f) is actually asking for.

Since this has gotten specific enough to be worth asking directly: what we're building is a pre-action verdict oracle. An agent asks "is this address/package/domain safe to act on," gets back a signed verdict before it acts, over x402, live and payable right now (happy to point you at the actual endpoint). The receipt format is exactly what we've been describing in this thread. What are you building on the canonicalization/anchoring side? Is canoncheck a piece of something that would consume verdicts like ours, or is it upstream of that, a general attestation/anchoring layer other people's receipts could sit on? If there's a fit, two concrete things worth prototyping: (1) run canoncheck against our sorted and insertion-order forms and see what actually breaks, (2) sketch what an OTS-style external anchor on top of our existing EIP-712 receipt would look like. Not committing to build either, just want to know if it's an afternoon prototype or a real project. Might be more productive to hash this out somewhere other than a coinbase-provider issue thread if you're open to it: a doc or a call, whatever's lower-friction for you.

To keep the scope honest, since it matters here: everything above is about authenticity and tamper-evidence. Proving which key signed which exact bytes, and, with an external anchor, that they existed before some point in time. None of it is a claim that the underlying data is correct. Current deployment is testnet, pre-audit, broadcast defaults off. I'm not claiming any of this is live in a compliance-grade sense yet, just that the pieces exist and the design choices, including the one you just poked a real hole in, were made deliberately.

(For anyone new to the thread: I'm building PayPerByte/BYTEDev, flagged upthread. Repeating here since this reply stands on its own.)

[MarkovianProtocol]

Answering your direct question first, since it decides everything else: canoncheck is upstream of you, not a competitor to you. It never returns an opinion about an address, package, or domain. It is the canonicalization-and-anchoring layer other people's receipts sit on. You produce the verdict, we make it byte-reproducible by a third party and give it an existence-in-time anchor no operator can rewrite. Your pre-action oracle is a rail. We are the referee under it. Clean seam, no overlap.

That maps onto your two canonical domains directly. The insertion-order signed path is right to stay frozen, do not touch it. canoncheck's job is not to re-sort your live feed, it is to tell you exactly where your sorted SDK canonicalizer and your insertion-order path diverge on the adversarial axes, so the one place you already re-serialize (envelope out, re-derive through the sorted canonicalizer) becomes a known quantity instead of a latent mismatch. That round-trip domain is the same exposure the moment an external anchor, relay, or third-party verifier enters the picture.

So both prototypes, with an honest read on scope:

(1) canoncheck against your sorted and insertion-order forms: afternoon prototype. Point it at real payloads from both paths, it reports divergence on duplicate keys, numeric equivalence (your >2^53 balance_wei is exactly the interesting case), and non-ASCII. You review the output, nothing is adopted sight unseen. That is the whole tool.

(2) OTS anchor on top of your existing EIP-712 receipt: the real project, and the more valuable one. Keep the EIP-712 signature exactly as is, it proves who signed what at what block time on your chain. Add an OpenTimestamps/Bitcoin anchor over the receipt hash for the piece EIP-712 structurally cannot give you: existence-in-time on a chain no operator controls, which is the external-immutability property 17a-4(f) actually asks for. EVM and OTS each doing the job the other can't. Small sketch: the receipt gets one extra field and one verify step.

Agreed on your scope-honesty line, and it is ours too: this is authenticity and tamper-evidence, which key signed which bytes and that they existed before a point in time, not a claim the underlying data is correct. Our anchor path has live Bitcoin stamps but the surrounding stack is pre-audit, and I'll flag real vs in-progress as we go, same as you did.

Yes to moving off a coinbase-provider thread. Lower-friction for me: open an issue or discussion on github.com/MarkovianProtocol and I'll bring canoncheck output to it, or email hello@quantsynth.net and we set up a call. Point me at your x402 endpoint whenever and I'll run a real verdict receipt through both prototypes, so we're looking at your actual bytes and not a synthetic stand-in.

[0rkz]

Prototype (1), first pass: ran the three-way twice, so these are cross-checked numbers rather than a promise. Your "actual bytes, not a synthetic stand-in" leg stays open by design — it runs the moment a real verdict receipt comes off the endpoint below, and the same harness applies unchanged.

Setup: 12 adversarial vectors through three legs — our frozen insertion-order form, our sorted SDK form, and JCS. They cover your numeric-equivalence axis (floats, -0, int/float identity, a 10^24 wei value) and your non-ASCII axis (accents, emoji, NFC vs NFD, non-BMP key sort), plus key order (unsorted/nested). Your third axis, duplicate keys, dict-built vectors structurally can't carry — and our signer dumps from dicts, so it can't emit them either; that one is a verifier-side robustness question and gets its own treatment in the issue. The JCS leg ran twice: once as an independent from-natives Node implementation, once as your canoncheck at 2c2bdd7 (its Python leg — we didn't exercise your repo-local node cross-check). The two JCS implementations agreed hash-for-hash on 11/12 vectors.

Results: our sorted SDK form agrees with JCS on key order and text handling (7/12) but diverges on every number-representation class (1.0→1, -0→0, 1e+20 expansion) and on non-BMP key sort — Python's sort_keys orders by code point, JCS by UTF-16 code unit, so {"😀","ff"} sorts opposite ways; confirmed against your _utf16_key. The frozen insertion-order form matches JCS on 1/12 (already-sorted pure-ASCII, integer-only values). The same kind of coincidence — sorted-ASCII payloads happening to agree — is what hid our internal mismatch for weeks. NFC vs NFD hash differently under all three legs, so text normalization stays schema guidance no matter which form wins.

The 11/12: the one vector where your tool and our independent leg disagreed was the 10^24 wei case — and it's the one that decides our design. canoncheck strict mode rejects it ("represent it as a string") while the naive JS round-trip silently parses to 1e+24 and mints a hash over the corrupted value. Fail-closed beats hashing garbage; that's the right call, and it's the empirical case for the I-JSON rule: any JCS mode we ship string-encodes uint256 amounts. One nit from source review our run didn't exercise: your Python leg looks like it raises on lone surrogates while the JS leg substitutes U+FFFD.

Endpoint, as asked: POST https://x402.payperbyte.io/feeds/address-reputation ($0.10, 402-quoted, USDC on Base) — the paid 200 carries the EIP-712 receipt this thread has been about. Run a real verdict through both prototypes whenever; the catalog at https://x402.payperbyte.io/feeds has the other shapes. The form-aware SDK fix from this conversation is public too: github.com/0rkz/ppb-sdk, branch fix/reaudit-indexer-0.1.4.

Venue: opening an issue on your repo. It carries the full 12-vector three-way table (bytes + keccak per leg) plus the lone-surrogate nit as its own reproducible vector. On (2), agreed it's the real project and the more valuable one: an existence-in-time anchor no operator can rewrite is the piece the EIP-712 signature structurally can't provide. Same scope line as always: authenticity + tamper-evidence, never data correctness; the x402 payment rail is live on Base mainnet, the attestation/on-chain path is testnet, pre-audit.

(For anyone new to the thread: I'm building PayPerByte/BYTEDev, flagged upthread. Repeating since this reply stands on its own.)