PriorSeal MCP Server

PriorSeal

Connect explicit authorization to observed EVM and Solana execution with independently verifiable evidence.

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

An agent can propose and execute a transaction, but a transaction hash alone cannot show who authorized the action, what they approved, or whether the observed execution matched it. 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 was authorized before action and what was observed afterward.

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, and transaction infrastructure. It sits beside the system that constructs, signs, and submits transactions; it does not hold wallet keys or move funds.

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, per-use authorization and evidence layer: an agent can call the service and, where enabled, pay for an eligible evidence export, but its service payment never gives it authority over a customer transaction. The principal's explicit signed authorization remains separate. The currently supported x402 route is a configured read-only receipt bundle export; it is not a public production offering unless the relevant production gates have been completed. 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. 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 and compares the 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. It does not decode arbitrary Solana program semantics. 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. See the collaboration guide or open a pilot request. Code contributions follow CONTRIBUTING.md; security reports follow SECURITY.md.

MIT licensed. See LICENSE.