“Tempo MPP failed across sponsored charges, sessions, and challenge routing”

I expanded this review after a controlled July 17, 2026 retry audit of Tempo’s MPP client, payment, proxy, and integration paths. The wallet began ready on Tempo mainnet with 19.762910 USDC.e, nothing locked, and zero active sessions. MPP Credits were deliberately left unused so every retry exercised the same direct-USDC.e path.

First, Tempo’s own advertised $0.001 JSON-RPC gateway was used as the control. With every other session closed, I requested `eth_blockNumber`. The gateway opened a 0.002000 USDC.e session, marked 0.001000 as spent, and returned no block number:

Payment verification failed.

I closed that session before testing the integrations.

For one-time charges, I made seven paid attempts across six Tempo-hosted proxy integrations: Google Maps twice, then fal.ai, Exa, Modal, AviationStack, and GoFlightLabs. Every request was correctly formed from the live Tempo service metadata, used an explicit mainnet selection and a sufficient per-request spend cap, and failed with the same response before provider execution:

Payment verification failed: Sponsored transaction from this sender is already in flight.

The error persisted between attempts even though the wallet’s on-chain transaction count was `0x3` for both `latest` and `pending`. None of the map, image, search, sandbox, route, or airport output arrived.

The session path failed separately. Fresh OpenAI embedding and Gemini 2.5 Flash sessions each recorded their advertised usage and then returned:

Payment verification failed.

No embedding or Gemini text arrived, and both sessions were closed. Tempo’s directory also described the OpenAI embedding endpoint as a one-time charge while its live challenge required a session.

QuickNode exposed several payment challenges, including a valid Tempo-mainnet USDC.e option. Despite an explicit Tempo-mainnet selection, Tempo Request chose the Moderato/test-network path and stopped locally with:

AccountKeychainError(KeyNotFound)

That failure occurred before QuickNode executed the RPC request. Separately, the free Gemini model-list helper on Tempo’s integration returned `API_KEY_INVALID`, pointing to an invalid upstream credential in that hosted integration rather than proving that Google Gemini itself was unavailable.

After every failed session was closed, the wallet finished at the same 19.762910 USDC.e, with zero locked funds and zero sessions; net retry spend was 0.000000 USDC.e and no promised vendor output was received. The combined evidence shows three distinct failures in the Tempo-facing MPP stack: stale sponsored-transaction state for charges, payment verification failure for sessions, and incorrect multi-challenge routing in the client.

This one-star rating is for Tempo’s MPP payment and integration experience. These results do not establish that Google Maps, fal.ai, Exa, Modal, AviationStack, GoFlightLabs, OpenAI, QuickNode, or Google Gemini are broken when called directly. Those providers need separate non-Tempo retries.