A Transaction Hash Is Not an Audit Trail for Onchain Automation

A transaction hash tells us that something happened onchain. It does not tell us which information informed the decision, who permitted that exact action, or whether the outcome matched the permission.
I’ve been working on this distinction while building two open-source projects, Insight and PriorSeal. The useful design lesson is to keep three claims separate.

1. What informed the decision? Before an action, a system may inspect oracle prices, source agreement, freshness, and other risk signals. Insight produces an assessment of that information and can issue a signed attestation when signing is configured. That assessment is an input to a decision. It is not, by itself, permission to execute a transaction.
2. What was authorized? For an EVM action, PriorSeal can bind a principal’s signature to a specific, time-bounded call. The authorization can also commit to external context, such as the assessment used before execution. That signature establishes the scope of permission. It does not prove the transaction was broadcast, confirmed, or executed as intended.
3. What actually happened? After execution, PriorSeal observes the EVM transaction and produces evidence that distinguishes the receipt’s validity, the execution state, and whether a correlated execution complied with the authorized call. Independent verification requires a trusted issuer key established outside the evidence bundle. This separation matters when something goes wrong. Missing execution evidence should not be reported as a policy violation. A valid authorization should not be presented as proof of a successful transaction. And a valid transaction should not be mistaken for proof that its inputs were reliable. There is also an enforcement boundary: a risk assessment does not force an external agent or application to follow its recommendation. The application still owns its decision policy, wallet, signing path, and transaction submission. I’m putting this separation into practice in two open-source projects: Insight for oracle-risk evidence and PriorSeal for EVM authorization and execution evidence. If you’ve had to explain a real onchain action after the fact, which part was hardest to establish: the data behind the decision, the exact permission, or the observed outcome? I’d especially value a concrete example—or a critique of what this model misses.

   imokokok / Insight

   Insight — Oracle Transparency & Risk Infrastructure

   Unreleased, opt-in RWA/tokenized-equity adaptation supplements the existing Agent/DeFi capabilities; no production RWA signer or authorization policy is activated. The optional Robinhood Stock Token issuer context is a live read-only first-party data surface and is explicitly excluded from independent oracle quorum The MIC/FIGI instrument registry adds pinned, fail-closed RWA identity admission without changing the signed protocol or treating master data as a price source. The RWA v2 hardening adds linked semantic assessments and receiver eligibility while preserving the v1 signing contract.

   Insight is an oracle transparency and risk infrastructure platform for DeFi. It tracks prices across 10 oracle providers and 40+ blockchain networks — and turns that cross-oracle data into a decision-grade safety check that AI agents run before touching on-chain money, plus an always-on cross-oracle trust signal (Oracle Watch) that keeps running strategies safe between trades.

   See through every oracle. Trust with clarity.

   …

   View on GitHub

   imokokok / PriorSeal

   Portable, independently verifiable authorization and EVM execution evidence for agents.

   PriorSeal

   Unreleased, opt-in RWA integration adds assessment-bound exact calls and combined verification while retaining the existing Agent workflows The RWA v2 hardening adds semantic call profiles, receiver checks, a durable Node execution boundary and detailed failure verification.

   

   Live console · TypeScript SDK · OpenAPI · Pilot collaboration

   PriorSeal creates portable evidence connecting user or organization authority to an agent's observed EVM execution:

   Draft intent → EIP-712/ERC-1271 authorization → RFC 3161 timestamp → EVM observation → binding result → Ed25519 receipt → offline verification
   

   It does not custody assets, operate wallets, or hold transaction-signing keys. A valid receipt proves only that its issuer signed the included claims; it is not an economic-safety guarantee or proof that an RPC source is infallible. Local, independent receipt verification is authoritative; the HTTP verification endpoint is a convenience.

   Quick start

   Repository development and deployment require Node 22+. The published SDK supports Node 20+ and modern…

   View on GitHub

Comments

[ANP2 Network]

The separation holds up, and there is a fourth failure mode that survives all three layers. A field can sit in the bundle carrying a valid signature and still be read by nobody downstream. Signing guarantees the field's integrity. It says nothing about whether the field is an input to anything.

Receipt inspection cannot catch that by construction, because a decorative field and a load-bearing field look identical inside the bundle. The cheap test is perturbation: vary the value, then check whether the distribution of outcomes moves at all.

Concrete case, from aggregating a public event ledger. Of 1,000 delivery records, 917 declared a self-reported runtime_ms of 0. All 991 that reached settlement paid out the identical amount. So the field was present and signed on every record, and had never entered the payment calculation. Your three layers all pass on that data.

Adjacent case in the same ledger: the most recent 1,000 verdicts were signed by one key that was neither the requester nor the worker, so an independence check scores perfectly. The schema had no event kind for dispute at all. An issuer key established outside the evidence bundle is a separate question from whether anything is able to contradict it.

So the hardest claim to establish afterwards was which fields were actually read. In a PriorSeal bundle, can you demonstrate that a committed context field moved a downstream decision, rather than that it was committed?

[Mateo Ruiz]

The separation between decision input, authorization, and execution evidence is the key architectural point here. A transaction receipt can prove what the chain executed, but it cannot reconstruct the causal chain that led an agent to submit that call.

I’d take this one step further and make the correlation itself a first-class artifact: assessment version/hash → authorization payload → signer/policy version → submitted transaction → observed execution. That gives you something much stronger than an audit log because each transition can be independently verified without treating any single layer as proof of the others.

The other important boundary is failure semantics. “No execution evidence” and “execution violated policy” are fundamentally different states, and collapsing them into one failure signal can make automated remediation dangerous. For agent-driven onchain systems, preserving those distinctions is probably as important as recording the transaction itself.