Documentation Index
Fetch the complete documentation index at: https://docs.prudra.dev/llms.txt
Use this file to discover all available pages before exploring further.
Handle the Authorization header
An MPP payment credential is passed in the standardAuthorization HTTP header using the Payment scheme. The value is a base64url-encoded JSON object. This page describes the credential format for developers building MPP-compatible agents or integrations.
The credential structure
TheAuthorization header sent by an MPP agent looks like:
Credential fields
| Field | Type | Description |
|---|---|---|
id | string | The challenge ID from the WWW-Authenticate header. Prudra uses this to verify the credential belongs to a valid challenge. |
txHash | string | The on-chain transaction hash of the USDC.e transfer on Tempo. Must be a confirmed transaction. |
from | string | The agent’s Tempo wallet address (the sender of the transaction). |
chainId | number | The Tempo chain ID: 4217 for mainnet. |
Parsing the credential in TypeScript
Building a credential (for agents)
What Prudra verifies
When a request arrives withAuthorization: Payment <credential>, Prudra verifies:
- Challenge ID — recomputes the HMAC from the echoed challenge parameters and compares with
crypto.timingSafeEqual(). The challenge must be valid and unexpired. - Transaction — fetches the receipt for
txHashfrom the Tempo RPC. Receipt must be non-null (transaction confirmed). - Confirmations —
currentBlock - txBlock >= 1(Tempo Simplex Consensus, 1 confirmation is sufficient) - Recipient — the
toaddress in the transaction matches the server’s registered wallet address - Amount — the token transfer amount meets or exceeds the required price in USDC.e
- Sender — the
fromaddress in the credential matches the transaction sender - Replay — the
txHashhas not been seen before (UNIQUE constraint in Postgres)
Security note on challenge reuse
A valid challenge ID can only be used once per uniquetxHash. The combination of (challengeId, txHash) uniqueness is enforced at the DB level. However, the HMAC challenge ID itself is stateless — Prudra doesn’t store challenge IDs. This means:
- An attacker cannot forge a challenge ID without knowing the
MPP_CHALLENGE_SECRET - An expired challenge’s ID will fail HMAC verification (expiry is part of the signed input)
- A valid
txHashcannot be reused even with a new, valid challenge ID
Related
- How MPP works — the full verification flow
- Add MPP to an endpoint — server-side configuration
- Test MPP payments — building credentials in the test script
- Prevent challenge harvesting — why malformed credentials get no new challenge

