DEV Community: imokokok

Confirmations Are a Policy Threshold, Not a Finality Guarantee

imokokok — Mon, 12 Oct 2026 07:31:12 +0000

A transaction reaches 12 confirmations. Can a reviewer call it final?

Only if the system defined what “final” means and recorded evidence for that claim.

A confirmation count answers one question

A confirmation floor tells us how many blocks have been built on top of an inclusion. It is a useful policy threshold, but it is not a universal statement about consensus finality.

The requirement should be part of the signed intent, before execution. For example:

{
  "constraints": {
    "minConfirmations": 12,
    "maxToleratedReorgDepth": 2,
    "finalityRequirement": "RPC_FINALIZED"
  }
}

These fields express separate constraints. A reorg depth of N requires at least N + 1 confirmations, so the effective floor must satisfy both the configured minimum and the reorg buffer. The buffer does not guarantee that a deeper reorg is impossible.

What `RPC_FINALIZED` means here

PriorSeal’s observer checks the configured RPC endpoint for the inclusion block, the current canonical block at that height, the head, and the endpoint’s finalized block.

It records FINALIZED only when:

the inclusion hash is still canonical;
the finalized height covers the inclusion block; and
the configured confirmation floor is met.

If the endpoint cannot provide finalized data, the execution remains PENDING. If the canonical inclusion hash changes, it becomes REORGED.

That wording matters: RPC_FINALIZED records an endpoint’s observation. It is not an embedded consensus proof.

Keep uncertainty distinct from a policy violation

PENDING and REORGED describe evidence status. Neither one, by itself, proves that an agent violated its authorization.

An offline verifier can check the issuer’s signature and replay the recorded evidence and arithmetic. It does not refetch historical RPC state. A reviewer who needs independent assurance must separately assess or corroborate the RPC source and its claim.

If a later reorg changes the outcome, the system should preserve that event as a separate signed receipt rather than silently rewriting the earlier record.

Questions to settle before signing

What confirmation floor does the policy require?
Is an RPC-reported finalized block also required?
What reorg depth is tolerated, and what happens if it is exceeded?
Which endpoint supplied the finality observation?
How will later changes be represented in the evidence record?

Finality criteria belong in the authorization policy before execution. A status label added afterward cannot tell a reviewer what the user actually approved.

For the implementation details, see the temporal finality design and the PriorSeal SDK guide.

ERC-4337 Has Two Execution Results. Your Dashboard Should Show Both.

imokokok — Sun, 11 Oct 2026 14:11:47 +0000

A block explorer shows a successful transaction. A wallet dashboard marks the operation as successful too.

For an ERC-4337 flow, those may be two different results.

A bundler submits an outer EVM transaction to an EntryPoint contract. That transaction can contain one or more UserOperations. The outer transaction status tells you whether the EVM transaction succeeded. It does not, by itself, tell you whether every operation inside the bundle succeeded.

Check the operation-level event

When handleOps completes successfully, the EntryPoint emits a UserOperationEvent for each processed operation. The event includes the operation’s success flag and gas information.

That means an outer transaction can succeed while one UserOperation fails. The operation can still incur gas.

If the outer transaction itself reverts, the expected operation event and operation-level result are absent. The operation’s bytes appearing in the reverted transaction calldata do not establish that the UserOperation executed.

A bundler-returned UserOperation hash is also not inclusion evidence. It identifies an operation for tracking. To establish inclusion, find the matching event in the transaction receipt and verify the event against the operation that was authorized.

Bind the operation before submission

PriorSeal’s ERC-4337 adapter binds the canonical UserOperation hash into a normal authorization intent. Its observer checks the matching EntryPoint event in the outer transaction receipt. The documented adapter supports EntryPoint versions 0.6 through 0.9.

Here is an integration outline:

import {
  bindERC4337UserOperation,
  buildERC4337UserOperationIntent,
} from 'priorseal-sdk'

const operationInput = {
  chainId,
  entryPoint: verifiedEntryPointAddress,
  entryPointCodeHash: verifiedEntryPointCodeHash,
  entryPointVersion: '0.7' as const,
  userOperation: walletUserOperation,
}

const binding = bindERC4337UserOperation(operationInput)

const intent = buildERC4337UserOperationIntent({
  ...operationInput,
  intentId: `withdrawal-${binding.userOpHash.slice(2, 14)}`,
  validUntil,
})

// Authorize this intent before submitting the UserOperation.
// After the bundler includes it, observe the outer transaction hash.

The wallet supplies the UserOperation. The EntryPoint address and code hash should come from the operator’s independently reviewed deployment configuration. This snippet binds and authorizes the operation; the final observation still needs the outer transaction hash and a matching event.

Know what the binding proves

The canonical hash ties the authorization to one UserOperation. The matching event ties that operation to an observed EntryPoint transaction.

Those checks do not necessarily decode the smart account’s inner call. A Safe-specific profile can provide more detail within its documented scope; without an applicable account profile, do not claim that the receipt independently proves every inner call’s meaning or business effect.

I keep three results separate in the application:

Outer transaction status
UserOperation success and gas
Whether the observed operation matches its authorization

That distinction matters for both success and failure paths. An outer transaction can succeed while an operation fails. A reverted outer transaction can contain operation calldata without establishing that the operation ran.

The PriorSeal ERC-4337 guide documents the supported EntryPoint and account-specific profiles. The SDK README covers the broader authorization and receipt flow.

Does your transaction UI show the bundler transaction and the UserOperation as separate records?

ERC-4337 Has Two Execution Results. Your Dashboard Should Show Both.

imokokok — Sat, 10 Oct 2026 09:32:17 +0000

A block explorer shows a successful transaction. A wallet dashboard marks the operation as successful too.

For an ERC-4337 flow, those may be two different results.

Check the operation-level event

When handleOps completes successfully, the EntryPoint emits a UserOperationEvent for each processed operation. The event includes the operation’s success flag and gas information.

That means an outer transaction can succeed while one UserOperation fails. The operation can still incur gas.

Bind the operation before submission

Here is an integration outline:

import {
  bindERC4337UserOperation,
  buildERC4337UserOperationIntent,
} from 'priorseal-sdk'

const operationInput = {
  chainId,
  entryPoint: verifiedEntryPointAddress,
  entryPointCodeHash: verifiedEntryPointCodeHash,
  entryPointVersion: '0.7' as const,
  userOperation: walletUserOperation,
}

const binding = bindERC4337UserOperation(operationInput)

const intent = buildERC4337UserOperationIntent({
  ...operationInput,
  intentId: `withdrawal-${binding.userOpHash.slice(2, 14)}`,
  validUntil,
})

// Authorize this intent before submitting the UserOperation.
// After the bundler includes it, observe the outer transaction hash.

Know what the binding proves

The canonical hash ties the authorization to one UserOperation. The matching event ties that operation to an observed EntryPoint transaction.

I keep three results separate in the application:

Outer transaction status
UserOperation success and gas
Whether the observed operation matches its authorization

The PriorSeal ERC-4337 guide documents the supported EntryPoint and account-specific profiles. The SDK README covers the broader authorization and receipt flow.

Does your transaction UI show the bundler transaction and the UserOperation as separate records?

A Valid Signature Is Not Yet a Trusted Receipt

imokokok — Fri, 09 Oct 2026 16:13:53 +0000

A local verifier returns valid: true for an execution receipt.

That answers a cryptographic question: does the receipt’s signature match the public key supplied to the verifier, and do the signed fields pass the supported checks?

It does not answer a separate identity question: why should the reviewer trust that this key belongs to the expected issuer?

A signature proves control of a private key. The reviewer still needs an independently established link between that key and the issuer they intended to trust.

This is why a key registry included in the same downloaded bundle should be treated as discovery data. If a verifier accepts a receipt’s bundled key as its own trust source, a party could create a new key, sign a fabricated receipt, and satisfy that verifier’s signature check.

The trust configuration should come from a separate, reviewed source. It should identify the expected issuer and key, the deployment audience, and the key’s validity or revocation status.

Here is the shape of a local verification call with priorseal-sdk:

import { verifyReceiptLocally } from 'priorseal-sdk/verifier';

const result = await verifyReceiptLocally(receipt, {
  trustedKeys: independentlyConfirmedKeyRegistry,
  expectedAudience: 'your-deployment-audience',
});

if (!result.valid) {
  throw new Error(`Receipt verification failed: ${result.code}`);
}

console.log({
  verificationScope: result.verificationScope,
  outcome: result.outcome,
  executionStatus: result.executionStatus,
  complianceStatus: result.complianceStatus,
  requiredExternalChecks: result.requiredExternalChecks,
});

The application supplies the receipt, the independently confirmed key registry, and the expected audience. The verifier performs no network requests. It checks signatures and receipt relationships within its supported scope.

The result keeps several claims distinct:

valid reports whether verification passed with the supplied trust configuration.
outcome reports the execution result recorded in the receipt.
complianceStatus reports whether the correlated execution matched the authorization, when assessable.
requiredExternalChecks lists checks the offline verifier cannot complete, such as ERC-1271 state or EVM anchor inclusion.

A local result that requires external checks should remain visibly incomplete until those checks are handled. Offline verification does not mean every chain-dependent claim has been independently re-established.

The same principle applies when connecting Insight and PriorSeal. Insight’s oracle assessment and PriorSeal’s authorization and execution receipt keep separate trust roots. A commitment can show that a digest was included in an authorization; it does not make PriorSeal the issuer of Insight’s assessment.

Before displaying one green “Verified” badge, ask what your verifier actually established:

Did the signature match?
Was the signing key trusted independently?
Did the receipt target the expected audience?
Did the verifier finish all required checks?

A signature is a strong piece of evidence. Its meaning depends on the trust configuration around it.

References

Insight: a pre-trade safety oracle API for AI agents — paid per call via x402 on Base

imokokok — Wed, 07 Oct 2026 13:30:23 +0000

TL;DR: Insight gives AI agents a pre-trade safety check for DeFi — oracle-manipulation-aware PASS/WARN/BLOCK verdicts, each check optionally backed by an EIP-712 signed attestation that anyone can verify from the signature bytes alone. Paid per call with USDC via x402 on Base mainnet. No signup, no API key for the paid path — the payment IS the auth.

Why

If you're building an agent that swaps or borrows on-chain, price-feed integrity is the attack surface you don't control. Flash-loan oracle manipulation is still one of the most common exploit patterns. Insight checks the trade before execution: consensus price across providers, cross-provider agreement, stale-data risk, manipulation risk score, and a recommended max position — returned as a single verdict.

Integration

REST (x402, $0.02/call in USDC):

curl "https://www.oracleinsight.xyz/api/v1/safety/pre-trade?asset=ETH&chainId=1&action=swap&tradeAmountUsd=1000"

The 402 response carries a standard x402 v2 challenge; any x402 client library (e.g. the official x402-fetch wrapper) signs and retries automatically. Gasless for the caller (EIP-3009 transferWithAuthorization).

Keyless verification (free):

curl -X POST https://www.oracleinsight.xyz/api/v1/safety/attestation/verify \
  -H "Content-Type: application/json" \
  -d '{ ...attestation... }'

MCP (40 tools, streamable HTTP):

https://www.oracleinsight.xyz/api/mcp

Anonymous initialize / tools/list — browse the whole catalog with no credentials. Single tools/call is metered on-chain via x402, priced by tool class ($0.002–$0.04); failed calls are never charged (settlement only happens after a successful tool result).

Discovery

Everything is self-describing, so agents can find and use it without a human:

/.well-known/x402 — x402 resource manifest
/.well-known/mcp/server-card.json — SEP-1649 static server card (40 tools)
/llms.txt, /openapi.json

Also listed on the official MCP Registry (io.github.imokokok/insight-oracle), Smithery (@imokokok123/insight-oracle), agent402.tools, and the CDP Bazaar.

Feedback welcome

Particularly interested in: agent-framework integrations (LangChain / Eliza / GAME), additional chains, and what other pre-trade signals you'd want checked. Repo is at github.com/imokokok/Insight.

Why a Successful Agent Transaction Can Still Fail Authorization Checks

imokokok — Sat, 03 Oct 2026 16:17:23 +0000

An AI agent submits a transaction. It executes without reverting, and the dashboard displays “Success.”

That label leaves an important question unanswered: did the agent execute the call the user authorized?

Consider a hypothetical swap. The user approves calldata that sends the output to wallet A. The observed transaction uses the same chain, executor, and nonce, but different calldata directing the output to wallet B.

The execution can complete while the authorization comparison fails.

A transaction review needs three separate results:

Evidence validity: do the receipt, signatures, hashes, and supported relationships pass verification under the reviewer’s trusted configuration?
Execution outcome: what execution state does the evidence report?
Authorization compliance: does the correlated execution match the signed authorization within the supported checks?

In PriorSeal receipt v3, a verifier summary can therefore look like this:

{
  "valid": true,
  "code": "OK",
  "outcome": "COMPLETED",
  "executionStatus": "CONFIRMED",
  "complianceStatus": "NON_COMPLIANT"
}

This is an illustrative result, not a record of a live transaction.

The issuer signed a record of the mismatch. The verifier can accept that record while confirming that the observed call differed from the authorization. In the calldata example, the receipt’s compliance reasons include CALLDATA_MISMATCH.

Editing the receipt after signing would be a different problem: its integrity verification would fail.

Keep those results separate in the application.

Here is a small integration outline using the local verifier:

import { verifyReceiptLocally } from 'priorseal-sdk/verifier';

const result = await verifyReceiptLocally(receipt, {
  trustedKeys: confirmedKeys,
  expectedAudience: confirmedAudience,
});

if (!result.valid) {
  throw new Error(result.code);
}

if (result.requiredExternalChecks.length > 0) {
  throw new Error('Complete the required external checks first');
}

console.log({
  evidence: 'VERIFIED_WITHIN_LOCAL_SCOPE',
  execution: result.outcome,
  authorization: result.complianceStatus ?? 'NOT_ASSESSABLE',
});

The application supplies the exported receipt, independently confirmed issuer keys, and the expected deployment audience. A key included in an imported bundle does not establish its own trustworthiness.

The SDK verifier documentation describes the supported checks. ERC-1271 authorization and EVM anchor evidence can require additional chain-state verification. The local verifier reports those requirements explicitly.

“Not assessable” also needs its own place in the interface.

Missing evidence, insufficient finality, a reorg, or an unrelated transaction may prevent the verifier from assessing authorization compliance. Those cases should remain NOT_ASSESSABLE.

A confirmed transaction with the expected chain, executor, and nonce but changed calldata provides a different result: an attributable mismatch.

These distinctions also explain why authorization review and market risk assessment remain separate. An authorized trade can still produce a poor economic result. Insight supplies oracle and risk assessments; PriorSeal supplies authorization and execution evidence. Their combined workflow preserves both scopes.

A receipt records the evidence available for review. Preventing an unauthorized transaction also requires the signing and submission paths to enforce the authorization checks.

If your application currently displays one “Success” badge, what would a user see when execution completes but the authorization comparison fails?

When an AI Agent’s Swap Times Out, What Can It Safely Retry?

imokokok — Fri, 02 Oct 2026 10:56:11 +0000

An AI agent submits a WETH → USDC swap. The RPC request times out immediately afterward.

The application did not receive a transaction hash. That does not establish that the transaction was never broadcast. A retry routine that simply builds and signs another swap may create a second action while the first is still pending.

The useful question is: which operation are we retrying?

1. Observe the original attempt

Persist the prepared call and its identifiers before dispatch. Record the chain, sender, nonce, target, calldata hash, authorization ID, and transaction hash whenever one becomes available.

After a timeout, query the known hash and sender nonce through your configured chain observers. Keep these outcomes separate:

Pending: continue observing; do not infer failure.
Not found or RPC unavailable: the result is still uncertain. One missing response is not proof that nothing was broadcast.
Confirmed: recover the evidence for that execution. Do not submit another swap to fix a missing receipt.
Reverted: the transaction reached the chain but failed. A new swap is a new decision.
Reorged: preserve the earlier observation and reassess the canonical chain and required finality.

PriorSeal’s lifecycle documentation keeps pending, unavailable, reverted, and reorged states explicit. A confirmed or reverted transaction correlated with a single-use authorization consumes that authorization; an action mismatch does not reopen it.

2. Retry evidence collection without executing again

If the transaction hash is known and the combined Insight–PriorSeal workflow has saved a checkpoint, the application can resume evidence recovery:

import { InsightGuard } from 'oracle-insight-guard';

const guard = new InsightGuard({
  apiKey: process.env.INSIGHT_API_KEY!,
});

const checkpoint = JSON.parse(await loadCheckpoint());

const recovered = await guard.resumeAssessedSwapExecution(
  checkpoint,
  { client: priorSealClient }
);

await saveCheckpoint(JSON.stringify(recovered.checkpoint));

The application supplies loadCheckpoint, saveCheckpoint, and priorSealClient. This recovery path has no transaction signing or submission callback. It retains existing evidence, checks the existing observation job, and requests missing artifacts. Insight’s SDK guide also provides an evidence-only receipt retry for its independent execution flow.

This code does not resolve a lost broadcast response when no transaction hash or checkpoint was recorded. That attempt remains uncertain until it is reconciled against chain and signer state.

3. Treat a new execution as a new decision

Only consider another trade after assessing whether the original could still execute. Rebuild and review the exact call, refresh the oracle and route evidence, and obtain a new time-bounded authorization when the previous single-use authorization has been consumed or the call has changed.

Insight’s transaction-specific review describes a simulated quote at one observed block. Changed calldata or expired evidence requires a fresh review. A past favorable assessment cannot approve a later transaction by itself.

The central recovery rule is simple: retry observation and missing evidence; never turn an uncertain response into automatic permission for another trade.

What does your agent persist before it asks a signer to broadcast?

One AI Swap, Three Prices: What Each Number Can Actually Prove

imokokok — Thu, 01 Oct 2026 10:29:47 +0000

An AI agent proposes a WETH → USDC swap. Before execution, it may see an oracle reference price and a simulated route quote. After execution, it can observe the actual fill.

Those are three different numbers backed by three different kinds of evidence. Treating them as interchangeable can hide a bad route, an overbroad authorization, or an unexpected execution result.

1. Oracle reference: the comparison point

An independent oracle assessment answers a question about market data: what reference price and risk signals were available for WETH and USDC at that time?

It gives the agent a basis for reviewing a proposed trade. It does not say that a particular router will deliver that price.

2. Simulated quote: this call at this block

A route quote needs to be tied to the transaction the agent actually intends to submit: chain, sender, router, calldata, token amounts, recipient, minimum output, and deadline.

Insight's assessV3Swap() reviews a prepared Uniswap V3 exactInputSingle call against two signed pre-trade oracle assessments. It checks the router's reviewed runtime code hash, decodes the call, and simulates it from the intended sender at one RPC block. It then compares the simulated output with the oracle reference and the transaction's minimum output.

A simplified integration looks like this:

import { InsightGuard } from 'oracle-insight-guard';

const guard = new InsightGuard({
  apiKey: process.env.INSIGHT_API_KEY!,
});

const { transactionRisk } = await guard.assessV3Swap({
  source: {
    asset: 'WETH',
    destinationAsset: 'USDC',
    chainId: 1,
    action: 'swap',
    tradeAmountUsd: 1000,
  },
  destination: {
    asset: 'USDC',
    destinationAsset: 'WETH',
    chainId: 1,
    action: 'swap',
    tradeAmountUsd: 1000,
  },
  receipt: { settlementChainId: 1 },
  transaction: preparedExactCall,
  routerCodeHash: reviewedRouterCodeHash,
  reader: publicClient,
});

if (transactionRisk.status !== 'ACCEPTABLE') {
  throw new Error(
    `${transactionRisk.status}: ${transactionRisk.reasonCodes.join(', ')}`
  );
}

Here, preparedExactCall and publicClient come from the integration. The expected router code hash must come from an independently reviewed deployment configuration, not from the agent proposing the trade. The USD amount is illustrative; a real integration must use the intended trade scope.

The result has three possible statuses:

ACCEPTABLE: the exact call met the configured policy at the observed block.
RISK_REJECTED: available evidence showed a policy or minimum-output failure.
UNASSESSABLE: required evidence was missing or could not be checked. This is never approval.

The transaction review is local, unsigned SDK output. The signed Insight proofs cover the oracle assessment; they do not turn an RPC simulation into a guaranteed future fill.

3. Actual fill: what happened after submission

The simulated quote describes one block. Between review and inclusion, pool state can change. A post-trade check therefore needs the observed transaction, receipt, relevant token movements, and the finality level appropriate to the application.

Compare the actual input and output with the authorized call and the earlier evidence. Preserve the original review even if the transaction fails, is reorganized, or remains uncertain. A transaction hash by itself is not a complete account of the fill.

Where authorization fits

Price review and permission review answer different questions. If PriorSeal is used alongside Insight, it can bind user or organizational authorization to the exact call and produce evidence relating authorization to observed EVM execution. It does not make the oracle price correct or guarantee the output amount.

The operational rule is simple: review the prepared call immediately before authorization, authorize that exact call, and examine the observed result afterward. If calldata changes or evidence expires, review again.

The current assessV3Swap() adapter covers the original Uniswap V3 SwapRouter exactInputSingle path described in the documentation. Other routers need separately reviewed adapters.

Technical references:

A Healthy Oracle Sample Shouldn’t Automatically Resume an AI Agent

imokokok — Wed, 30 Sep 2026 08:54:49 +0000

A long-running AI agent checks oracle conditions and receives a halt recommendation. Its strategy pauses.

The next sample looks healthy. Should the agent immediately resume?

I would treat recovery as a separate decision. A single healthy response does not establish that an incident has ended, and a process restart should not erase the pause.

Here is how I approach that boundary with Insight Oracle Watch.

Keep the halt across restarts

Oracle Watch can retain states such as halted, recovering, and monitor_unavailable through a stateAdapter.

The adapter must use storage appropriate for your deployment. An in-memory map will lose its state on restart; multiple workers need a shared, coordinated store.

This example accepts the store and application actions as dependencies:

import {
  InsightGuard,
  type OracleWatchTarget,
  type WatchStateAdapter,
} from 'oracle-insight-guard';

const target: OracleWatchTarget = {
  symbol: 'ETH',
  chain: 'ethereum',
};

export function startGuardedWatch(
  guard: InsightGuard,
  stateAdapter: WatchStateAdapter,
  pauseNewActions: (reason: string) => Promise<void>,
  notifyOperator: (message: string) => Promise<void>,
) {
  return guard.watch(target, {
    stopOnHalt: false,
    recoveryHealthySamples: 2,
    stateAdapter,

    onHalt: async (signal) => {
      await pauseNewActions(`Oracle Watch: ${signal.reason}`);
    },

    onIncident: async (state) => {
      await pauseNewActions(`Watch incident: ${state.incidentKind}`);
      await notifyOperator(`Watch incident: ${state.incidentId}`);
    },

    onRecoveryReady: async () => {
      await notifyOperator('Fresh samples are ready for review');
    },
  });
}

export function assertCanStartNewAction(
  guard: InsightGuard,
): void {
  if (guard.isHalted(target)) {
    throw new Error('Oracle Watch requires operator review');
  }
}

Connect pauseNewActions to your strategy controller. Call assertCanStartNewAction() at the application’s execution boundary. If you use the Guard’s swap execution flow, pass the same watchTarget so its Watch halt is applied there too.

Callbacks provide notifications and application behavior. The execution boundary must still check the halt state.

Recovery has two steps

With stopOnHalt: false, Watch continues collecting signals after a halt.

In this example, two consecutive fresh healthy samples make recovery ready for review. They do not clear the execution halt.

After the operator reviews the incident and current conditions, the application can call:

await watch.acknowledgeRecovery();

Here watch is the handle returned by startGuardedWatch(). Acknowledgement clears the Watch halt when its recovery conditions are satisfied. It does not call a wallet, submit a trade, or resume your strategy on its own.

The application must make its own subsequent execution decision, including any current pre-trade assessment and authorization requirements.

Treat monitoring availability as a state

A failed Watch request, exhausted API budget, or storage failure also matters to a running strategy.

Preserve the incident reason and make monitoring availability visible. The SDK retains a local halt when durable state cannot be saved. Your execution path should check its gate instead of assuming that missing monitoring means healthy conditions.

Oracle Watch’s default cadence is 15 minutes, matching Insight’s published snapshot cadence. It provides scheduled monitoring, not second-by-second market observation.

The design question

A useful state machine separates:

Halted: a signal or monitoring incident stopped new actions.
Recovering: fresh healthy samples have arrived; the halt remains active.
Acknowledged: recovery conditions were reviewed and the Watch halt was explicitly cleared.

For an automated strategy, what evidence should be required before a halted agent can take its next action?

References

A Public Key Inside a Receipt Bundle Is Not a Trust Root

imokokok — Tue, 29 Sep 2026 10:10:41 +0000

A portable transaction-evidence bundle may contain both a signed receipt and a public key.

That makes the bundle convenient to inspect. It also creates a question for the reviewer: how was that key confirmed as the expected issuer’s key?

This post shows how to keep bundle validation and issuer trust separate when verifying a PriorSeal receipt locally.

Start with a synthetic receipt

PriorSeal’s repository includes an offline example. With Node.js 22 or later:

git clone https://github.com/imokokok/PriorSeal.git
cd PriorSeal
npm ci
npm run example:receipt
npm run verify:receipt

The example creates a temporary key and synthetic execution evidence. It needs no wallet, RPC endpoint, or funds.

The expected verification output includes valid: true, code: OK, and separate execution and compliance statuses.

Because the example generates its own temporary key, it demonstrates the mechanics of verification. Reviewing a receipt from another issuer adds a separate task: establish which issuer key you trust.

The bundle and the trust profile have different jobs

A portable bundle supplies the evidence to examine. Its embedded key registry is useful discovery information.

The reviewer’s trust profile supplies independently confirmed keys and the expected audience. Its provenance must be checked outside the bundle. Merely placing copied bundle data in a second file does not establish independent trust.

PriorSeal’s trust-profile parser checks the profile’s structure. Parsing alone cannot confirm its source.

Verify using independently confirmed trust

Install the SDK and a TypeScript runner:

npm install priorseal-sdk@0.8.0
npm install --save-dev tsx

Save this as verify-bundle.mts:

import { readFile } from 'node:fs/promises';
import {
  parseTrustProfile,
  verifyVerificationBundleLocally,
} from 'priorseal-sdk/verifier';

const [bundlePath, trustPath] = process.argv.slice(2);
if (!bundlePath || !trustPath) {
  throw new Error(
    'Usage: verify-bundle.mts bundle.json confirmed-trust-profile.json',
  );
}

const bundle: unknown = JSON.parse(
  await readFile(bundlePath, 'utf8'),
);
const trustValue: unknown = JSON.parse(
  await readFile(trustPath, 'utf8'),
);

const trust = parseTrustProfile(trustValue);

// Confirm the profile's source and expected issuer independently.
// Its source and confirmedAt fields do not prove provenance by themselves.
const result = await verifyVerificationBundleLocally(bundle, {
  trustedKeys: {
    schema: 'priorseal.keys.v1',
    issuer: trust.issuer,
    keys: trust.keys,
  },
  expectedAudience: trust.audience,
});

console.log(JSON.stringify({
  valid: result.valid,
  code: result.code,
  verificationScope: result.verificationScope,
  requiredExternalChecks: result.requiredExternalChecks,
}, null, 2));

if (!result.valid) process.exitCode = 1;
else if (result.requiredExternalChecks.length) process.exitCode = 2;

Run it with an exported bundle and a trust profile whose issuer, audience, and keys you have confirmed independently:

npx tsx verify-bundle.mts bundle.json confirmed-trust-profile.json

The verifier checks the bundle structure and hash, then checks the receipt using the keys supplied by the reviewer. It does not promote bundle.keyRegistry into trusted configuration.

Read the result within its scope

Inspect valid, code, and verificationScope together.

If requiredExternalChecks contains entries, further chain-state checks remain. ERC-1271 contract-wallet authority and EVM anchors are examples that can require external verification.

A locally valid receipt supports the signed claims and relationships checked within that verification scope. Review the execution state and authorization-compliance result separately. The receipt does not establish that a trade was profitable or that every external data source was economically correct.

Review checklist

Before accepting a third-party evidence bundle, ask:

Where did the trusted issuer key and expected audience come from?
Did the bundle and receipt pass local verification?
What authorization and execution relationship was actually checked?
Are external chain-state checks still required?

How does your team distribute and confirm trusted issuer keys for offline review?

References

An AI trading agent paused. Can you tell why?

imokokok — Mon, 28 Sep 2026 08:42:36 +0000

Imagine an agent preparing an ETH to USDC swap. It cannot complete its price check, so it pauses.

Six months later, an auditor finds an empty price field. What happened?

Perhaps the agent retrieved quotes, but too few met its freshness or independence requirements. Perhaps a provider timed out and the quotes were never retrieved. Those are different events, yet a nullable field makes them look the same.

I would model the outcomes explicitly:

type PriceCheckResult =
  | {
      kind: "passed";
      policyId: string;
      evidenceDigest: string;
    }
  | {
      kind: "insufficient_evidence";
      policyId: string;
      reasonCodes: string[];
    }
  | {
      kind: "retrieval_failed";
      policyId: string;
      source: string;
      errorCode: string;
    };

The policyId matters because “insufficient” is a judgment against a particular set of requirements. The same observations might pass one policy and fail another. A reviewer needs the policy that applied at decision time, not just the agent’s final verdict.

I would keep this assessment separate from two later records: what exact action the user authorized, and what execution was observed. A valid price check does not authorize a transaction. A transaction hash alone does not explain the decision or the authorization that preceded it.

This separation guides my work on Insight for oracle evidence and PriorSeal for EVM authorization and execution evidence.

How do you preserve policy context in an audit trail: a full snapshot, an immutable reference, or both?

Recovering an AI Agent’s Transaction Observation After a Timeout

imokokok — Sun, 27 Sep 2026 10:50:31 +0000

An agent submits a transaction, receives a transaction hash, and starts waiting for execution evidence.

Then the client’s wait expires.

What should the application preserve, and how can it continue observing the original transaction after a restart?

Here is a small recovery example using PriorSeal’s TypeScript SDK.

1. Persist the operation identifiers

Save the original transaction hash, chain ID, and authorization ID when they become available.

When observeExecution() returns an observationJob, persist its jobId before continuing to wait.

These identifiers let a restarted process locate the original operation. Store them in durable storage appropriate for your deployment.

If the initial observation response was lost before a job ID was saved, the example below cannot resolve that missing identity. Reconcile the original operation using its known transaction and authorization references.

A timeout alone should never trigger a new trade.

2. Resume an existing observation job

This example requires an observation job that already exists. It only polls that job; it does not create an authorization, sign a transaction, or broadcast one.

Use Node.js 22 or later:

npm install priorseal-sdk
npm install --save-dev tsx

Save this as resume-observation.mts:

import {
  createPriorSealClient,
  PriorSealApiError,
} from 'priorseal-sdk';

const jobId = process.env.PRIORSEAL_JOB_ID?.trim();
if (!jobId) {
  throw new Error('Set PRIORSEAL_JOB_ID to an existing observation job');
}

const priorseal = createPriorSealClient({
  baseUrl: 'https://priorseal.xyz',
});

try {
  const job = await priorseal.waitForObservationJob(jobId, {
    timeoutMs: 30_000,
    pollIntervalMs: 2_000,
  });

  console.log(JSON.stringify({
    jobId: job.jobId,
    jobState: job.state,
    observation: job.observation,
    result: job.result,
    error: job.error,
  }, null, 2));
} catch (error) {
  if (
    error instanceof PriorSealApiError &&
    error.code === 'OBSERVATION_WAIT_TIMEOUT'
  ) {
    console.error(
      'Wait expired. Preserve this job ID for another observation attempt:',
      jobId,
    );
    process.exitCode = 2;
  } else {
    throw error;
  }
}

Run it with your saved job ID:

PRIORSEAL_JOB_ID='your-existing-job-id' npx tsx resume-observation.mts

The polling interval and wait duration are example settings.

If the wait expires again, preserve the same job ID. Schedule another observation attempt according to your application’s recovery policy.

3. Inspect the returned state

waitForObservationJob() returns when the job reaches COMPLETED, UNDETERMINED, or FAILED.

Those are observation-job states. Your application must inspect the execution observation, available result, receipt, and error separately.

A completed observation job does not by itself establish that a trade succeeded or complied with its authorization. A receipt may also require independent verification against trusted issuer keys and additional chain-state checks.

Keep pending, reverted, reorged, and uncertain execution states explicit in your records.

4. Keep new execution behind its own authorization checks

Recovering historical evidence does not extend an authorization window.

If the business needs a new transaction, the executor must apply the relevant submission-time policy and obtain valid authorization for that action.

The recovery worker above has a narrower responsibility: continue investigating an existing operation.

A small recovery checklist

Before deploying an agent, check that:

Transaction and authorization identifiers survive a restart.
Observation job IDs are saved as soon as they are returned.
Client wait timeouts preserve the existing operation identity.
Observation-job state and execution outcome are evaluated separately.
New transactions require their own applicable policy and authorization checks.

Which part of your agent’s recovery state currently exists only in memory?

DEV Community: imokokok

Confirmations Are a Policy Threshold, Not a Finality Guarantee

A confirmation count answers one question

What RPC_FINALIZED means here

Keep uncertainty distinct from a policy violation

Questions to settle before signing

ERC-4337 Has Two Execution Results. Your Dashboard Should Show Both.

ERC-4337 Has Two Execution Results. Your Dashboard Should Show Both.

A Valid Signature Is Not Yet a Trusted Receipt

Insight: a pre-trade safety oracle API for AI agents — paid per call via x402 on Base

Why

Integration

Discovery

Feedback welcome

Why a Successful Agent Transaction Can Still Fail Authorization Checks

When an AI Agent’s Swap Times Out, What Can It Safely Retry?

1. Observe the original attempt

2. Retry evidence collection without executing again

3. Treat a new execution as a new decision

One AI Swap, Three Prices: What Each Number Can Actually Prove

1. Oracle reference: the comparison point

2. Simulated quote: this call at this block

3. Actual fill: what happened after submission

Where authorization fits

A Healthy Oracle Sample Shouldn’t Automatically Resume an AI Agent

Keep the halt across restarts

Recovery has two steps

Treat monitoring availability as a state

The design question

References

A Public Key Inside a Receipt Bundle Is Not a Trust Root

Start with a synthetic receipt

The bundle and the trust profile have different jobs

Verify using independently confirmed trust

Read the result within its scope

Review checklist

References

An AI trading agent paused. Can you tell why?

Recovering an AI Agent’s Transaction Observation After a Timeout

1. Persist the operation identifiers

2. Resume an existing observation job

3. Inspect the returned state

4. Keep new execution behind its own authorization checks

A small recovery checklist

References

What `RPC_FINALIZED` means here