Aiyo + Tempo — a Verified Adapter, an Upstream Bug, and Why We're Piloting It Free

Aiyo is quadruple-agnostic. What that means is that any actor (human or AI), any wallet, any rail, and any action can flow through Aiyo's Runtime Decision Point. A journey that initially began with Open Payments has since seen Aiyo add multiple rails — and in the process of adding Tempo, we discovered an open bug in the reference client library that anyone building on Tempo should probably know about. It is issue #395 in the wevm/mppx GitHub repo (an issue tracked publicly there, filed by another developer in April), and we walk through what it is, why it matters, and how Aiyo contains it further down. We also put together a robust, free downloadable memo — for anyone, design partner or not — that covers the same ground in more depth, plus how teams running consequential agent traffic on Tempo can put Aiyo above their integration today.

What's Tempo and how do Aiyo + Tempo work together

Tempo is a payments-optimized blockchain co-designed by Stripe and Paradigm, with the Machine Payments Protocol (MPP) as its agent-facing payment layer. Tempo settles value; MPP standardizes the HTTP challenge-and-response flow agents use to pay for services.

Aiyo is the Economic Execution Authorization plane. Aiyo sits between an autonomous agent's intent and the action it wants to take, and evaluates — at the exact moment before that action executes — whether the action should be allowed to run under the merchant's declared policy and available evidence.

When Aiyo is deployed above a Tempo/MPP integration, the composition looks like this:

• An agent decides it wants to take a consequential action (call a paid API, unlock a browser session, execute a query, negotiate a purchase).
• The agent's request lands at a merchant's endpoint that returns a 402 with an MPP challenge.
• Aiyo's Runtime Decision Point evaluates the intent against the merchant's policy — budget, per-agent attribution, action-type permissions, evidence signals — and issues an authorization decision.
• If the RDP allows, the agent proceeds to satisfy the MPP challenge. Aiyo's Tempo/MPP adapter handles the signing and submission, with the #395 mitigation applied at the boundary: validBefore is set to the challenge's actual expires window, signing happens as close to submission as possible, and a bounded re-sign fires on any timing-expired error.
• Once the pathUSD (or other Tempo stablecoin) Transfer confirms on-chain, Aiyo's adapter verifies it, and Aiyo issues a portable HMAC-signed authorization artifact.
• The merchant's downstream service invokes the action, reports back via /execution-result, and Aiyo closes the lineage.

Every step is captured in a queryable, auditable event stream — intent.created, decision.allowed, proof.verified with rail metadata, unlock_token issuance, execution.completed. An auditor could reconstruct exactly why any specific action was permitted to run, down to the on-chain proof reference.

Exact pain points Tempo users experience that Aiyo addresses

Running consequential agent traffic on Tempo/MPP surfaces a set of governance questions the payment layer alone does not answer:

• Per-agent budgets. When multiple agents share a merchant account, which one is allowed to spend how much? Aiyo's policy engine consumes rolling windows (daily, weekly, monthly) at the merchant level and per attribution unit (workflow, agent).
• Approval workflows. Consequential actions above a threshold may require human approval before proceeding. Aiyo composes evidence signals from approval systems (Slack, PagerDuty, custom webhooks) into the RDP decision.
• Execution lineage for audit. After the fact, who authorized what, under which policy version, against which evidence? Aiyo's lineage panel reconstructs this per-intent, per-transaction.
• Rail fault isolation. When a rail-side failure occurs (a #395-shape timing bug, an RPC outage, a chain reorg), the failure must not corrupt the authorization decision or leak into downstream systems. Aiyo's adapter boundary contains rail failures inside the adapter; the RDP is unaffected.
• Portable authorization artifacts. Once the RDP allows an action, the artifact that represents the decision is portable and verifiable by any downstream execution surface. That's how Aiyo can compose with any wallet, any rail, any actor without changing shape.

None of these questions are Tempo-specific. All of them are more acute in agent-scale environments where no human is in the loop for every transaction. Aiyo is built to answer them at the primitive level.

Tempo's upstream bug

In August 2026, Aiyo shipped a wallet adapter for Tempo and the Machine Payments Protocol (MPP) and manually verified it end-to-end against Tempo testnet — a real on-chain pathUSD transfer, accepted by the adapter, unlock token issued, execution completed. The adapter carries a boundary-level mitigation for a live upstream bug (wevm/mppx issue #395) that has been breaking agent-driven flows on Tempo mainnet since April.

That being said, the rest of this post is for anyone building on Tempo, MPP, or mppx, as it explains what the bug is, what it means for people running consequential agent traffic on Tempo, why we shipped a memo alongside the adapter, and why we're inviting Tempo-native teams into a design-partner pilot at no cost right now.

What others identified as an issue with Tempo

The bug is wevm/mppx issue #395, filed on April 26, 2026 by beckitrue. When mppx.sign produces a transaction-type credential for a tempo.charge challenge, the signed transaction's validBefore field is hardcoded to approximately 45 seconds after signing — regardless of what the challenge's actual expires field says (typically 5 minutes per MPP server defaults).

On Tempo mainnet (chainId 4217), this causes on-chain rejection with a "transaction expired" error whenever the sign → submit → verify round trip exceeds ~45 seconds. On Tempo testnet (Moderato, chainId 42431), the behavior is not reproduced.

The failure mode matters most in agent-driven flows. Each MCP tool call routinely takes 30–90 seconds of overhead — LLM inference latency, tool orchestration, application-layer retries. A payment sign step that lives inside that flow can easily miss the 45-second window and hit the chain-side rejection. The reporter characterized this as "consistently breaks agent-driven MCP flows" and rated it "high severity for any agent-driven flow on Tempo mainnet."

What Aiyo came across while researching the adapter

During August 2026, Aiyo's research program opened a rail due diligence study on Tempo and MPP. The study asked five questions: why should Aiyo support this rail, what does MPP expose that Open Payments and x402 don't, does Tempo/MPP give Aiyo a meaningful new architectural property, what would the adapter boundary look like, and which customer would actually benefit.

The study surfaced #395 as a live upstream defect during the "what would the adapter boundary look like" question. It also confirmed that Aiyo had zero exposure at the time — no mppx dependency, no Tempo adapter in the shipped registry, no code path that would encounter the bug. What the study's clean-exposure finding raised was a sharper strategic question: should Aiyo be exposed? Aiyo's architectural thesis is rail-agnostic execution authorization. Integrating a materially different machine-payment protocol like MPP would demonstrate that thesis in a way Open Payments and x402 alone cannot.

What this means for individuals, companies, and organizations using Tempo

If your product or platform runs autonomous agents through Tempo/MPP via the mppx client, you have three practical options for handling #395 today:

• Do nothing. Accept that a percentage of your agent-driven flows will silently fail on-chain with "transaction expired" errors. Retry logic at the application layer masks some of this. It doesn't fix it.
• Roll your own containment. Patch mppx locally, override the validBefore field before signing, add a bounded re-sign retry on timing-expired errors. Legitimate engineering work; costs your team the same hours we spent building our version.
• Adopt Aiyo above your Tempo integration. Aiyo's Runtime Decision Point becomes the authorization layer for your agent traffic; Aiyo's Tempo/MPP adapter handles the boundary-level mitigation for you, and the RDP adds governance surfaces (policy enforcement, budget checks, execution lineage, per-agent attribution, portable authorization artifacts) your application layer does not currently have. We are currently piloting this with interested design partners and more details are below.

The "Aiyo & Tempo — a Research-to-Design-Partner Note"

This memo exists because Aiyo knows that ecosystem work is not zero-sum. Aiyo's research turned up a pattern (Rail Fault Isolation, Rail Semantics Normalization) that any Tempo-integrator engineering team can adopt in their own architecture — with or without Aiyo. Publishing the pattern openly is the honest thing to do, because the pattern is not proprietary to us. It's a way to isolate rail-side timing failures from an authorization layer above.

The memo also exists because ecosystem awareness is uneven. #395 has been open for four months and is well-documented in the wevm/mppx repository, but teams integrating Tempo don't always find it in time. A short, hostile-read-safe memo — with no marketing hype and clear technical detail — lets us contribute what we've learned without asking anyone to become a customer to receive it.

What the memo covers: what the bug actually is, in plain language; where Aiyo sits (Economic Execution Authorization plane, not a payment rail); what Aiyo shipped (the two governance patterns as a free contribution, plus the adapter with its four boundary-level mitigations); what we're inviting from Tempo-native teams; and — importantly — what we are not claiming (Aiyo did not discover, did not fix upstream, does not guarantee any particular outcome).

Join the Aiyo ecosystem — why we're piloting free for design-partner help in hardening

Every serious infrastructure product ships this way. Unit tests and manual verification can prove that code paths connect and correct data flows through them. What they cannot prove is that the code works under the specific timing, volume, and edge-case profile of real production agent traffic. That kind of hardening only comes from real traffic, and real traffic only comes from real customers.

The design-partner pilot Aiyo is offering to Tempo-native teams has a simple shape:

• Joint architectural review of the partner's current Tempo/MPP integration and where Aiyo would sit above it.
• Shared debugging on a first production integration — Aiyo engineering works alongside the partner's team as the first real-traffic sessions flow.
• Published case study once the integration hardens, co-authored and consent-gated.
• No fees during the design-partner period. Any structural agreement about pricing, revenue share, or SLA commitments is a later conversation, not a design-partner conversation.

What Aiyo asks in return is what design partners always give: patience with a not-yet-hardened adapter, willingness to have specific technical conversations, and permission to reference the engagement publicly once the integration is stable. The mutual benefit is real. Aiyo gets the traffic profile no laptop can produce. Partners get a governance layer whose engineering conversations they've helped shape, plus the boundary-level containment for #395 running for free while it matters most.