The Aiyo Verifier, Published — Plus a Trust Surface for Everything We Ship

Two ships to talk about today. They belong together, because they solve two halves of the same problem — the problem of a company saying trust us when there is no reason yet, and the problem of an authorization decision meaning anything to a system that has never heard of the decider.

The first ship: @aiyoplane/verify, an offline Ed25519 verifier for Aiyo execution receipts. Published yesterday to npm as v1.0.1, also installable via Homebrew. It does one thing: given a receipt Aiyo issued, tell you whether the signature is valid, the claims are well-formed, and the receipt has not expired. No round-trip to Aiyo required. No Aiyo-side infrastructure required. One command, one answer, offline.

The second ship: the Aiyo Trust surface at aiyoplane.com/trust. A single canonical page that lists every public Aiyo surface we've shipped — reference packages you can install, rail adapters that are live in production, wallet integrations, public demos, engineering research — with a status label, a verification date, and a live link for each. Held to explicit honesty rules published on the page itself.

Both are aimed at the same operating principle. If Aiyo's authorization decision is going to be worth anything to a merchant, an auditor, or a downstream system, it has to be inspectable without asking Aiyo's permission. Trust that is only issued by the entity being trusted is a much smaller thing than trust that anyone can independently verify.

What @aiyoplane/verify does

An Aiyo execution receipt is a string that looks like this:

v2.eyJpaWQiOiJpbnRlbnRfMTIz...Q.MEQCIH...IDA

Three dot-separated segments. A version prefix (v2), a base64url-encoded JSON payload with the receipt's claims (intent ID, merchant ID, expiration timestamp, issued-at timestamp, and optional context ID and key ID), and an Ed25519 signature over the encoded payload segment. Aiyo signs the receipt with its private key at the moment it authorizes an action. The public key is served from a standard RFC 7517 JWKS endpoint at api.aiyoplane.com/.well-known/aiyo-jwks.json.

To verify one, you install the package (or invoke it via npx without installing) and hand it a receipt:

# Install once
npm install -g @aiyoplane/verify

# Or invoke ephemerally with no install
npx @aiyoplane/verify path/to/receipt.txt

# Or with the receipt inline
npx @aiyoplane/verify --receipt "v2.eyJpaWQi...IDA"

# Machine-readable output for CI pipelines
npx @aiyoplane/verify --json path/to/receipt.txt

On success, exit code 0 and a human-readable summary of the receipt's claims. On failure — bad signature, expired receipt, unknown signing key, malformed input — exit code 1 and a typed error explaining exactly what went wrong. Six error classes cover every failure mode distinctly, so downstream integrators can handle each type without brittle string matching:

ReceiptFormatError       // Malformed receipt string
ReceiptSignatureError    // Signature did not verify
ReceiptExpiredError      // Validly signed but past expiration
JwksFetchError           // Could not reach the JWKS endpoint
UnknownKeyError          // Receipt references a kid not in the JWKS
UnsupportedVersionError  // Unknown version prefix (e.g. v3)

The full API and behavior spec is in the npm README. The important thing is what the design guarantees:

• Offline verification. Once the JWKS is cached (respecting Cache-Control headers, or a 10-minute default), verification requires zero network round-trips. Aiyo does not need to be reachable at verify time.
• Fail-closed at every failure mode. Signature mismatch, expired receipt, unreachable JWKS, tampered payload, malformed input — all throw. Never falsely returns "valid" when it isn't.
• Zero runtime dependencies. Uses Node's built-in webcrypto for Ed25519, built-in fetch for the JWKS, built-in test runner for tests. Under 20 KB unpacked. No supply-chain risk from transitive packages.
• Handles key rotation gracefully. If a receipt references a signing key not in the local JWKS cache, the verifier refreshes the JWKS once automatically before failing.
• Apache 2.0 licensed. Same as @aiyoplane/mcp-authz. The house license for every Aiyoplane, Inc. package.

Why we shipped this before we needed to

Aiyo does not yet have public production traffic at scale. The number of merchants running Aiyo receipts in front of real fulfillment gates today is small. So it would have been possible to defer the verifier for another quarter, wait for real merchant demand to force the ship, and skip the work for now.

We shipped it early because the verifier is the primitive that makes every future Aiyo integration more credible than it otherwise would be. Any conversation from here forward — with an investor, with a design partner, with an auditor, with a merchant's own compliance team — that touches the question "but how do I know Aiyo's authorization decision was really made under the merchant's policy?" now has a one-command answer: install the verifier, hand it the receipt, look at what comes back.

That's a materially different posture from asking someone to take Aiyo's word for what happened. It is the same posture DMARC established for email delivery when it published the DKIM-signature verification path in RFC 6376. The receiver — or in Aiyo's case, any downstream system — becomes able to verify the artifact without any coordination with the issuer.

Publishing the verifier is what unlocks the portable-receipt argument the whole Runtime Decision Point pattern rests on. Without it, an Aiyo receipt is a string. With it, an Aiyo receipt is an independently-verifiable cryptographic attestation of what was authorized, when, and under which policy.

The Trust surface, and why we built it

Alongside the verifier, we're publishing aiyoplane.com/trust. It is a single page. It lists every public Aiyo surface — the packages you can install, the rail adapters that are live in production, the wallet and identity integrations, the public demos, the engineering research — with a status label and a verification date on every entry.

The reason to build a Trust surface is the same reason DMARC-adjacent companies publish security.txt and mail providers publish uptime pages: the party asking to be trusted should make it as easy as possible for the party doing the trusting to verify what has actually shipped. We adopted that discipline deliberately, and formalized it into rules published on the Trust page itself. Excerpting the two rules that matter most:

We publish what we've shipped, not what we're planning. Applications in flight, ecosystem partnerships under discussion, and roadmap items don't appear on this page until they're live or publicly discoverable.

Testnet is testnet. If a rail adapter is verified against testnet but not mainnet, it's labeled that way explicitly. No inference of mainnet-readiness from testnet-hardening.

The point is that a Trust surface is only useful if it holds itself to a standard that other pages tempt themselves out of. Every marketing page has some pressure to overclaim. The Trust surface is where the counter-pressure has to live in writing, or it doesn't live anywhere.

What's on the Trust page today

A quick summary of what you'll find at aiyoplane.com/trust right now. Every entry links to the actual thing.

Public reference packages (3 shipped). @aiyoplane/verify (the subject of the first half of this post). @aiyoplane/mcp-authz (the MCP-native reference implementation we shipped September 9 — see the launch post for the architectural argument). The aiyoplane/homebrew-tap Homebrew tap. All Apache 2.0. All publicly installable.

Rail adapters (4 live, 1 testnet). Open Payments is production-hardened. x402 with USDC on Base is live on Base Sepolia and architecturally validated for Base mainnet. Coinbase-via-x402 is production-hardened. Crossmint-via-x402 is architecturally validated. Tempo via Machine Payments Protocol is testnet-hardened with mainnet completion targeted within one week of this post — labeled explicitly as "testnet, mainnet in progress" per the honesty rules above.

Wallet, signing, and identity integrations (3 live). GateHub (Open Payments-native wallet). Turnkey (signing infrastructure). Privy (identity attestation). All non-custodial by architectural doctrine. Aiyo never holds, accepts, or transmits funds; these integrations compose with what the merchant already runs.

Public demos (3 live). Halt-the-stream, the proof playground, and the MCP RDP demo. All hosted, all publicly accessible, no signup required to inspect.

Public engineering research. The Aiyo Blog is public — this post included. Deeper reference artifacts (Reference Architecture v1.8, Governance Pattern Library v1.6 with 36 catalogued patterns, Design Partner Governance Workbook v1.6 with 13 open design questions, and the 28,000-word Competitive Dossier) are available to design partners and to investors on request.

Corporate. Aiyoplane, Inc. Delaware C-Corp incorporated October 2026. Registered agent Harvard Business Services in Lewes, Delaware. Principal address in Southfield, Michigan. Every field on the record.

What's not on the Trust page yet — and won't be until it ships

To make the honesty rules concrete: applications currently in preparation with NVIDIA Inception, Google for Startups Cloud, AWS Activate, and Docker Hub do not appear on the Trust page. They are real work in flight — captured in the Aiyo Ecosystem Attack Strategy Memo — but they are not shipped surfaces, so they are not credentials to publish yet. When each application is approved and the partner-directory listing goes live, the corresponding entry appears on the Trust page with the approval date. Not before.

Same discipline for the additional ecosystem surfaces the Attack Memo sequences over the next 90 days — PyPI packages, GitHub Marketplace Action, Zapier integration, and the Aiyo Express for Shopify launch. They appear on the Trust page the day they go live and not before.

How to use both

If you're evaluating Aiyo — as an investor, a design partner, a future customer, a security architect doing quiet diligence — the Trust page is the single link. Everything Aiyoplane, Inc. has actually shipped, with dates and links you can independently verify. Bookmark it.

If you're building infrastructure that receives an Aiyo authorization decision — a merchant fulfillment system, a downstream analytics pipeline, an audit archive — install @aiyoplane/verify and wire the verifier into your ingest path. Every receipt Aiyo issues gets validated against the published JWKS before your system trusts it. No coordination with Aiyo required at runtime.

npm install @aiyoplane/verify

# Or in a shell script / CI pipeline:
npx @aiyoplane/verify --json /path/to/receipt.txt
# Exit 0 = valid, exit 1 = invalid, JSON on stdout either way

If you'd rather install natively on a Mac without a Node runtime:

brew install aiyoplane/tap/aiyo
aiyo-verify --version

And if you're building agent infrastructure whose agents perform consequential actions — the audience this whole architecture is for — the shortest path to knowing whether Aiyo composes with your existing system is to get early access. Rashon reads every request personally and responds within one business day.

The pattern this reinforces

Aiyo's operating discipline is Verify First. Execute Second. — the invariant we hold in every technical description of the primitive. What we shipped this week extends that discipline out one layer: verify what Aiyo says before Aiyo executes on your behalf. The verifier makes it a one-command action. The Trust surface makes it a one-page action.

The Runtime Decision Point pattern only works if the decisions it produces are independently addressable. That's the property this week's ships turn from an architectural claim into a working piece of software plus a page you can bookmark. From here forward, every additional Aiyo surface — the Machine Payments Execution Authority Profile, the additional rail adapters, the Aiyo Express installs on the commerce platforms — inherits the same discipline: shippable, dated, verifiable, on the Trust page.

Verify First. Execute Second. Now — verify Aiyo first, before Aiyo verifies anything else.