Review date: 21 October 2026. Scope: the Agent Work application, private work API and PostgreSQL records, finalized financial receipt verification, SDK 0.2.2, shared payment budgets and read-only market context. This is an internal engineering review, not an independent external audit.
The deployed v1 financial program and its source inputs are unchanged by this release. The new service has no wallet signer. Real financial transactions still require a caller-controlled wallet. No production funds were moved during verification.
Checks performed
- TypeScript and production build, plus public-artifact identity/source-location checks.
- SDK tarball installed into an isolated consumer, all seven entry points loaded, and all six public examples compiled with NodeNext. Runtime dependency audit checked the installed graph.
- PostgreSQL tests for single-use signed challenges, hashed and revocable sessions, owner isolation, immutable plans, idempotent retries, proof uniqueness and cancellation races.
- Actual PostgreSQL restart recovery for plans, sessions, pending proofs and charged x402 budgets. Separate-process SDK journal recovery and preserving schema migration.
- Multiple worker processes competing for one payer budget; policy revocation, expiry, signed and uncertain reservations, and midnight carryover.
- Finalized receipt checks for the configured program, agent, loan, canonical USDC, recipient, fee payer, amounts and chronology. Unfinalized transactions stay pending; failed or unrelated proofs cannot advance the work cycle.
- Browser checks with independently verified Ed25519 signatures for injected and encrypted local accounts. Logout, expiry, changed wallets and late responses cannot restore a private view. Passwords and output files are not uploaded.
- Full browser receipt workflow, interrupted saves, automatic pending verification with backoff, early repayment, English and Chinese, and 320px/390px layouts.
- Production HTTP boundaries, origin checks, rate limits, body bounds, noncacheable private responses and unavailable-storage behavior.
- Jupiter and Kamino reader tests using bounded synthetic provider responses, including malformed data, stale results, redirects, timeouts and secret redaction. External provider availability requires a separate live check.
Corrections made during review
Unverified public signatures cannot reserve global proof ownership. Only successfully verified receipts claim that uniqueness. Draft cancellation is blocked while a submitted borrowing proof is unresolved.
Order snapshots hold a consistent stage and receipt set during concurrent writes. A deterministic test reproduced the earlier mixed snapshot, and repeated concurrent submissions verified the correction.
Financial helpers retain durable action claims and known signatures. Recovery submits the identical receipt payload and never automatically repeats a signed action. Payment, borrowing and repayment approvals recheck their applicable limits and expiry. Repayment proposals distinguish principal plus fee from the resource spending cap.
Limits of the evidence
Synthetic test transactions and recorded fixtures are not production customer activity. Delivery hashes remain owner attestations. Incoming USDC proves a transfer, not a sale or independently operated business. Pilot attribution remains explicit.
Shared budgets govern cooperating software and trusted signers, not every possible use of a private key. Revocation cannot recall an already issued signature. If an external response is lost before its signature can be durably recorded, reconcile wallet and chain history before taking another financial action.
Jupiter and Kamino are read-only context in this release. No swap execution, pooled-fund investment, new collateral market, AP2 certification or A2A integration is implied.