PriorSeal

PriorSeal

Let Agents prepare EVM, Solana, and bounded HyperCore spot actions while users retain explicit, independently verifiable control.

Live console · MCP adoption guide · TypeScript SDK · PriorSeal MCP · API specification · Pilot collaboration

An Agent can propose a transaction, but a transaction hash alone cannot show who authorized the action, what they approved, whether the observed execution matched it, or whether the user still had a final say. PriorSeal connects a principal-signed, time-bounded authorization to an identified EVM or Solana execution in a portable receipt that another party can verify independently. Its core is the relationship between what an Agent proposed, what was authorized before action, and what was observed afterward.

Agent proposal → Bounded intent → Principal signature → Acceptance + time evidence
                                → EVM / Solana observation → Signed receipt → Independent review

PriorSeal is for teams building EVM and Solana Agents, treasury automation, wallets, trading applications, and transaction infrastructure. It sits beside the system that constructs, signs, and submits transactions; it does not hold wallet keys, move funds, or turn a single authorization into open-ended automation.

Choose your integration path

Insight and PriorSeal work independently. Insight provides oracle transparency and risk intelligence; PriorSeal provides authorization and execution evidence. The combined path links assessment, authorization, execution, and review while keeping each product’s trust checks separate. Start with the offline example before connecting a wallet, RPC endpoint, or API key.

PriorSeal is designed as an Agent-facing, user-controlled, per-use authorization and evidence layer: an Agent can call the service and, where enabled, pay for an eligible evidence export or Fresh Evidence Check, but its service payment never gives it authority over a customer transaction. The principal's explicit single-use signed authorization remains separate. A Fresh Evidence Check re-observes the transaction named by an authorization-bound receipt, then returns a new issuer-signed report; it does not submit an action or make a future-safety claim. The free MCP surface provides discovery and a purchase handoff only—it cannot materialize a paid bundle or check. Live pricing, enabled rails and exact resources are available from GET /v1/capabilities. See the agent usage and payment model.

For x402 API payments, the aligned production rails are Ethereum, OP Mainnet, Polygon PoS, Monad, X Layer, Sei, Base, Arbitrum One, Avalanche C-Chain, and Solana mainnet-beta. A rail is advertised only when its payee is configured and the selected facilitator currently supports it; execution observation still requires that chain's independently configured RPC endpoint.

What the evidence covers

1. Authority. A user or organization signs a time-bounded, single-use EIP-712, ERC-1271, or Solana Ed25519 message authorization for an Agent and executor. An application-declared Agent ID can be bound into the signed authorization but is not an identity or performance proof without separate verification. A deployment policy can bind a reviewed principal identity to an account; without that registry, a human-readable principal ID is self-asserted.
2. Ordering. PriorSeal accepts the authorization before execution. Production deployments require an independent pre-execution proof mode: RFC 3161 timestamp, witness quorum, or EVM anchor. The default development issuer mode provides only an issuer acceptance statement.
3. Execution. PriorSeal observes a specified transaction through configured EVM or Solana RPC sources, or a bounded Hyperliquid HyperCore spot IOC order through its public Info API, and compares supported fields with the signed intent. Solana support binds the complete legacy, v0, or v1 compiled message, including resolved v0 address lookup accounts and v1 resource configuration, and currently observes confirmed mainnet-beta transactions. Hyperliquid support binds a cloid, IOC parameters, and matching fills; it does not submit exchange actions or hold API-wallet credentials. Pending, unavailable, reverted, and reorged states remain explicit.
4. Review. An Ed25519-signed v3 receipt separates evidence validity, execution state, and authorization compliance. A reviewer can download it and verify its hashes, signatures, policy result, and binding locally with an independently confirmed issuer key. A paid x402 receipt-bundle export can additionally carry a signed payment-to-resource evidence statement without conflating the payment rail with the subject execution chain.

For EVM contract calls, the priorseal.intent.v2 exact-call profile binds the transaction envelope: chain, executor, nonce, target, calldata hash, and native value. The Solana transaction profile binds the signed message bytes represented as compiled instruction and account data. Optional context commitments bind digests of external decisions, assessments, or a block-pinned ERC-8004 identity snapshot without claiming that PriorSeal made those decisions. See the evidence relationship levels, the Solana integration guide, and the ERC-8004 integration guide.

For ERC-4337 smart accounts, a second intent.v2 profile binds the canonical UserOperation hash and supports commitments from Insight's signed risk assessments. EIP-7702 observation supports predelegated EntryPoint v0.7 accounts and marker-based v0.8/v0.9 flows, binding a signed authorization tuple when the operation requests a fresh delegation; all profiles pin delegate code and verify exact bundle calldata plus transaction-level delegation state. See the ERC-4337 integration guide for supported scope and the distinction between UserOperation evidence and ordinary bundler transaction observation.

A valid receipt is evidence of signed claims, not a guarantee of economic safety or an infallible RPC view. ERC-1271 authority and EVM anchors require additional chain-state checks for complete verification. A key included in a downloaded bundle is discovery data; the reviewer must establish trust in that key separately.

Try it

Use the hosted console

Open the PriorSeal console. Its quickstart checks the deployment's configured capabilities before wallet signing. You can create an authorization, observe a transaction, export the receipt, and review it in the local verifier. The console's activity list is browser-local; it is not a complete server-side history.

Run the offline example

Repository development requires Node.js 22+. This example generates a temporary key pair and a synthetic execution so you can inspect the receipt and verifier without an RPC endpoint or funds:

npm ci
npm run example:receipt
npm run verify:receipt

The verifier should report valid: true, code: OK, outcome: COMPLETED, executionStatus: CONFIRMED, and complianceStatus: COMPLIANT. These are results for the synthetic fixture, not proof of an on-chain transaction. Confirm the public key independently before relying on a receipt from another issuer.

The artifacts are written to the ignored examples/receipt-artifacts/ directory. To verify a different receipt and trusted public key:

npm run verify:receipt -- /path/to/receipt.json /path/to/public-key.pem

Run the API and console locally

After npm ci, copy .env.example to .env.local, configure development issuer key-file paths and an RPC endpoint for the chain you want to observe, then start the API and UI in separate terminals:

cp .env.example .env.local
npm run start:api

npm --prefix web run dev

The UI uses Vite's displayed local URL and proxies API calls to port 3000. For database setup, key handling, and production configuration, use the operations runbook. Never put private keys, credential-bearing RPC URLs, or database secrets in Git.

Integrate with TypeScript

The published priorseal-sdk supports Node.js 20+ and modern browsers. It prepares wallet authorization, calls the API, resumes durable observations, and verifies receipts locally. It does not sign or broadcast execution transactions.

npm install priorseal-sdk

import { createPriorSealClient } from 'priorseal-sdk'

const priorseal = createPriorSealClient({ baseUrl: 'https://priorseal.xyz' })
const capabilities = await priorseal.capabilities()

const flow = await priorseal.authorizeWithWallet({
  intent,
  audience: capabilities.audience,
  principal: { type: 'user', id: 'user:42' },
  delegate: { agentId: 'agent:treasury', executor: intent.sender },
}, window.ethereum)

// Your execution system submits the authorized transaction and supplies txHash.
const evidence = await priorseal.observeExecutionUntilFinal({
  authorizationId: flow.accepted.authorization.authorizationId,
  chainId: Number(intent.chainId),
  txHash,
  confirmations: 12,
})

This is an integration outline: intent, txHash, and the wallet provider come from your application. For an executable example with no wallet or RPC dependency, use the offline example.

The SDK guide covers intent construction, recovery checkpoints, exact calls, and offline verification. The HTTP contract is available as OpenAPI; the main flow uses POST /v1/authorizations/prepare, POST /v1/authorizations, and POST /v1/executions/observe.

Examples and integrations

These examples have different evidence scopes. Read each example's README before treating its result as an integration or production claim.

Other partner fixtures are under examples/. Insight can be used independently for assessment evidence; PriorSeal can be used independently for authorization and execution evidence; a combined workflow can bind the two without merging their trust roots.

Documentation

Run npm run check for the repository checks, or npm run release:check for the full release gate. Production runs the API and console on Cloudflare Workers with D1 persistence; local Node deployments can use PostgreSQL.

Work with PriorSeal

For a pilot, choose one bounded EVM or Solana execution path and ask an independent reviewer to reproduce the authorization, timing, observation, and compliance result from its exported evidence. Public Issues are only for redacted developer collaboration. See the collaboration guide or open a redacted pilot request. Code contributions follow CONTRIBUTING.md; security reports follow SECURITY.md.

MIT licensed. See LICENSE.