DEV Community

imokokok
imokokok

Posted on

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

#ai #web3

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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;
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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:

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

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

References

Top comments (0)