The main risk is payment without admission. Cross-order replay and quote substitution depend on how QuoteApproval is constructed and verified; the documentation does not publish that schema. This is a protocol review, not confirmation of deployed implementation bugs. Proxy conclusions below use the x402 reference contract for the specified address, not independently verified deployed bytecode. IMD documentation, x402 specification

1. High — Settlement does not guarantee admission or recovery.
   Attacked step: settlement → admission.

   IMD documents admission_pending and a possible refused outcome after catalog changes, but specifies no refund deadline or enforceable recovery. Consequently, a crash or dishonest server can leave a paid request without admission; polling is not a remedy against permanent refusal. This is a documented guarantee gap, not proof that refunds are absent from the implementation. IMD documentation

   Smallest fix: Before broadcasting payment, durably reserve the validated, immutable order and record its payment authorization. Reconcile settlement after crashes and retry admission idempotently, with one admission per order. Specify automatic refunds after a fixed admission deadline.

   That addresses operational failures. For protection against a dishonest server, a server-controlled refund promise is insufficient: pay into escrow keyed to the order commitment, with payer withdrawal after timeout unless the agreed admission condition is satisfied. An admission receipt alone must not be represented as proof of completed work. This is a proposed protocol change.

2. High, conditional — Cross-order replay or payment reassignment if the approval binding is incomplete.
   Attacked step: signed submission → payment reservation → admission.

   IMD requires two signatures from the same wallet but leaves quoteApprovalTypedData(...) undefined. EIP-712 explicitly says, “It does not include replay protection.” Therefore, the signature format’s name does not establish order binding or one-time application semantics. IMD documentation, EIP-712

   Attack condition: If approval A omits the order identity, requester scope, or exact payment authorization, an attacker possessing a valid submission could try applying it to order B or pairing it with another payment. This is a conditional attack, not an established omission.

   Permit2’s consumed nonce prevents another successful transfer using that nonce; it does not by itself prevent an application crediting one transfer to multiple orders. Uniswap SignatureTransfer documentation

   Smallest fix: Publish and enforce an approval commitment containing:

   • Immutable order ID and requester-scope hash.
   • Quote commitment covering action, canonical input hash, payment terms and expiry.
   • Exact Permit2 typed-data digest, including its domain.
   • An application-specific domain separating service, environment and version.

   Require approval signer = Permit2 owner. Atomically assign (chainId, Permit2 address, owner, nonce) to exactly one order, rejecting conflicting assignments. Return the existing outcome for identical retries. Deduplicate by authorization identity, not signature bytes. If these checks already exist, this finding becomes a documentation and verification gap.

3. High, conditional — Quote substitution before signing.
   Attacked step: quote → 402 challenge → wallet approval.

   The example creates both signatures from challenge-supplied data without showing a comparison to the caller’s original intent. A substituted challenge could therefore obtain a perfectly valid signature for the wrong request or payment terms if the client blindly trusts it. That is a conditional client-validation failure, distinct from altering already-signed data. IMD documentation

   Smallest fix: Before either signature, independently compare the challenge against the locally retained order, action, canonical input, requester scope, expected chain/token/recipient, amount limit and expiry. Pin the expected Permit2 contract and exact proxy. Construct typed data locally using a published schema; have the server reconstruct it from the immutable stored quote.

   This recommendation follows EIP-712’s separation between authenticating structured data and determining whether those data express the intended operation. A signed incorrect quote remains authorized cryptographically. EIP-712

4. Medium — Anyone seeing the Permit2 signature can force settlement; severity rises to High if recovery strands the payment.
   Attacked step: signature disclosure/broadcast → settlement.

   In the reference proxy, settle(...) is externally callable without caller authorization. Its witness contains only to and validAfter; it does not check QuoteApproval, an order ID, or the HTTP bearer token. Thus an observer can submit the copied permit first during its validity window. The reference code fixes the recipient and transfers the signed amount, so this permits forced payment to the intended recipient, not redirection to the attacker. x402 specification

   The observer consumes the nonce; a later server attempt cannot successfully spend it again. A backend that treats its own transaction’s failure as proof of nonpayment could consequently deny admission despite successful payment. The denial is conditional on backend behavior. Uniswap SignatureTransfer documentation

   Smallest fix for griefing: Accept externally submitted settlement of the exact authorized payment. Reconcile successful execution against the stored authorization, regardless of transaction sender. Do not treat a consumed nonce alone as payment proof: verify the successful transfer and match owner, nonce, token, amount, recipient, witness and chain through transaction calldata or execution traces. Preserve the one-payment/one-order assignment from finding 2.

   To prohibit forced settlement itself: use a different, caller-restricted spender/proxy and sign for that spender. An HTTP check or wrapper around the existing publicly callable proxy cannot prevent direct calls. This conclusion follows from the reference call path; extending its witness requires a compatible contract change. x402 specification

5. Medium — Leaked bearer token grants access to its order scope.
   Attacked step: authenticated quote, submit and status requests.

   IMD uses a client-generated bearer secret for order access, while wallet signatures authorize payment. Token theft therefore exposes the associated order access; the token alone is not a fresh payment authorization. IMD documentation

   Plausible leakage paths include request logs, tracing and copied command examples containing a real token. These are threat scenarios, not observed leaks. Bearer authentication requires no additional proof of a key once the credential is obtained. RFC 6750

   Smallest containment: use a separate token per order, redact credentials and payment signatures from telemetry, and provide expiry, revocation and rotation.

   Smallest protocol fix that makes a leaked token insufficient: bind the scope to a client public key and require request signatures covering method, path, body hash, timestamp and replay nonce. Keep that authentication separate from payment authorization. Never place the bearer secret in signed data that may become public on-chain.

This is a review of the documented protocol, not an implementation audit. The largest documentation gap is that the actual QuoteApproval EIP-712 domain and fields are not published, so several security properties cannot presently be verified independently.

Findings, highest severity first

1. High — payment and admission are not atomic

Attacked step: settlement → admission.

The documented state machine allows payment_pending, then admission_pending, then admitted; the successful example separately reports a confirmed payment and an admission result. It also says a request may be refused after payment if the catalog changed. Therefore, once the Permit2 transfer confirms, neither the signature nor the HTTP protocol forces the server to create the job, workflow, or oracle request. A crash, database loss, permanent admission error, or malicious server can leave the customer paid but unserved. Permit2 cannot reverse the completed transfer.

“Retries reuse the order and never charge twice” prevents a second debit, but does not guarantee delivery or refund. IMD paid-request documentation The underlying x402 specification likewise describes exact as transferring a specific amount to the resource server; it does not make that transfer atomic with an application-side resource. x402 exact scheme

Smallest fix: Before broadcasting settlement, durably record an idempotent admission intent containing the final resource ID and full input. After confirmation, retry admission until it succeeds. Add one protocol rule: every confirmed payment must eventually produce either the reserved admission or an automatic on-chain refund, and expose refund_pending/refunded states. “Refused after payment” should result in a refund, not a terminal paid refusal.

This is the most important fix because no signature binding can solve the off-chain atomicity gap.

2. High — a leaked payment signature can be front-run to cause “paid but not credited” griefing

Attacked step: signed payment → proxy settlement.

The Permit2 authorization names the fixed x402 proxy as spender, while the witness fixes the recipient. Consequently, possession of the signature cannot redirect payment to the attacker, but it may let the attacker call the proxy first. The canonical x402 specification explicitly says the spender is the proxy and that the proxy enforces transfer to witness.to. x402 EVM exact specification

The first valid call consumes Permit2’s nonce. The server’s later call then fails as a replay. If IMD recognizes payment only through its own settlement attempt or transaction hash, the attacker has made the customer pay the correct recipient while preventing automatic admission. This is theft only if the recipient refuses reconciliation, but it is a practical, externally triggerable payment/admission grief.

Permit2’s unordered nonce protects against a second debit; it does not prove which HTTP order should receive credit. Uniswap describes signature-transfer nonces as replay protection and the permission as lasting only for the transaction in which it is spent. Uniswap Permit2

Smallest fix: Persist the authorization hash and its intended order before settlement. If settlement reports a used nonce or otherwise fails ambiguously, reconcile on-chain and credit the order when the exact tuple—chain, Permit2 owner, token, amount, nonce, deadline, proxy, witness recipient and witness validity—has already settled. The system must not require the transaction sender to be the server.

For easier deterministic reconciliation, include orderId or quoteHash in the proxy witness and event. That is slightly larger but removes ambiguous matching between equal-price orders.

3. Medium, potentially High — cross-order replay and quote substitution are asserted but not auditable

Attacked step: 402 challenge → QuoteApproval verification.

The documentation says the second signature is an approval “for this quote,” and mentions quote, requesterScopeHash, resourceUrl, and input, but it never publishes:

• The QuoteApproval type string and exact fields.
• Its EIP-712 domain.
• The canonical encoding/hash of input.
• Whether it commits to the complete Permit2 authorization.
• Whether requesterScopeHash is actually inside the signed message.
• Whether the order ID, action, API audience and protocol version are signed.

IMD paid-request documentation

This matters because payment requirements are otherwise interchangeable: current actions have the same price, token and recipient. If QuoteApproval signs only payer plus generic payment terms, an intermediary holding signatures could attach a payment intended for order A to order B, substitute an equal-price quote, or reuse the approval with a fresh Permit2 authorization. Permit2’s nonce prevents replay of one Permit2 signature, but it cannot stop replay or substitution of the separate off-chain QuoteApproval.

This finding is Medium as a documentation/security-assurance defect and becomes High if any of the bindings below are absent in the implementation.

Smallest fix: Publish and enforce one explicit signed struct, for example:

QuoteApproval(
  bytes32 orderId,
  bytes32 requestKeyHash,
  bytes32 actionHash,
  bytes32 inputHash,
  bytes32 requesterScopeHash,
  bytes32 paymentAuthorizationHash,
  bytes32 resourceUrlHash,
  uint256 quoteExpiresAt,
  bytes32 audienceHash,
  uint256 protocolVersion
)

paymentAuthorizationHash should cover the entire Permit2 message: chain, Permit2 contract, proxy spender, owner, token, maximum/exact amount, nonce, deadline, witness recipient, and validAfter. The server must reconstruct these values rather than accept caller-supplied hashes. Use a domain unique to the IMD production service.

4. Medium — bearer-token leakage exposes every order in the requester scope

Attacked step: quote creation, submission and later order reads.

The paid credential is a random 32-byte bearer secret that “names your orders.” The same token is sent when creating a quote, obtaining the challenge, submitting signatures, and polling the order. The documentation also says the 402 JSON repeats the input. Thus a token leaked through shell history, CI output, proxy/access logs, crash telemetry, or a copied command can disclose private job/oracle inputs and order results. It can also let the holder consume rate limits or interact with orders for which it later obtains signatures.

The wallet signature still gates payment, so the bearer token alone does not authorize spending. Nevertheless, it is a long-lived capability with apparently broad scope, and the documentation provides no expiry, rotation, revocation, or order-level attenuation. IMD authentication documentation

Smallest fix: Return a separate random, revocable, order-scoped capability when a quote is created and require it for /requests/:id/*. Keep the master token only for creating and listing orders. Store only hashes of both tokens, support rotation/revocation, set an expiry, and redact Authorization and PAYMENT-SIGNATURE from all logs and traces.

5. Low — replay of the same Permit2 payment across orders is already prevented on-chain, assuming canonical validation

Attacked step: repeated proxy settlement.

A byte-for-byte replay of one permitWitnessTransferFrom authorization should not charge twice because Permit2 signature transfers use one-time unordered nonces. The deadline also bounds the usable period, while the witness binds the recipient. Uniswap Permit2 x402 EVM exact specification

That protection depends on IMD validating the complete payload against the issued challenge: correct Ethereum chain, canonical Permit2, exact proxy spender 0x402085c248EeA27D92E8b30b2C58ed07f9E20001, IMD token, exact amount, recipient, nonce, deadline and validAfter. The IMD error list suggests payment-shape and terms checks exist, but does not specify them normatively.

Smallest fix: Make those equality checks explicit in the public protocol and add conformance vectors. Reject overpayment, alternate proxy addresses, mismatched accepted fields, deadlines past the quote expiry, and any authorization hash already reserved for another order. Keep the existing order-level idempotency rule.

Bottom line

The cryptographic payment leg appears well protected against redirection and duplicate debit by the canonical proxy, recipient witness, deadline and Permit2 nonce. The dangerous boundary is immediately after that: an independently submitted payment can consume the nonce, while admission remains an off-chain promise. Durable pre-settlement admission intent plus on-chain reconciliation/refund is the smallest change that closes the most serious loss and griefing cases. Publishing the complete QuoteApproval schema is necessary before cross-order and quote-substitution resistance can be treated as established rather than assumed.

---

Sources offered but not confirmed by this machine:

• https://imd.fun/docs/ — does not contain the quoted text
• https://imd.fun/docs/ — does not contain the quoted text
• https://github.com/x402-foundation/x402/blob/main/specs/schemes/exact/scheme_exact_evm.md — does not contain the quoted text
• https://github.com/Uniswap/permit2 — does not contain the quoted text

I've finished the review. One caveat first: the public docs don't list the fields of the QuoteApproval type or say what requesterScopeHash is computed from. Several findings below therefore say "if the approval doesn't include X". Each fix is also something the server should check for, whatever the signature covers.

What the docs say (what I relied on)

• There are two credentials. The bearer is "A random 32-byte secret you generate, as 64 hex characters", sent as Authorization: Bearer. It is the only credential for a paid request and for GET /requests/:id (imd.fun/docs).
• The flow: POST /requests/quote with a requestKey you reuse to retry. With no body, the server returns 402 with a PAYMENT-REQUIRED challenge carrying requesterScopeHash, resourceUrl and input. You then resend with a PAYMENT-SIGNATURE header and {quoteSignature} and get 202. "the wallet signs twice, the Permit2 payment and an EIP-712 approval of that payment for this quote".
• Status values are quoted, payment_pending, admission_pending, admitted, payment_failed, expired. "Quotes last 600 seconds." "The server's wallet pays the gas." GET /requests/capabilities is "the live source for price, token, recipient and quote lifetime".
• The x402 exact Permit2 witness has only two fields, address to and uint256 validAfter. The spec's comment says "post-audit: extra removed from Witness". The one-time-use value (nonce) and the expiry time (deadline) are in the Permit2 authorization, not the witness. The proxy's settle has no restriction on who can call it (coinbase/x402 exact EVM spec). The proxy is deployed at the same address on every chain (go pkg docs).

The key structural fact: the Permit2 signature says nothing about which order it pays for. It only says "move 0.5 IMD to to, after validAfter, before deadline, using nonce N." Anything tying the payment to an order has to come from the QuoteApproval and from what the server checks.

---

Findings, most severe first

1. HIGH: The server settles but never admits, and the user has no recourse

Step attacked: from settlement to admission (payment_pending → admission_pending → admitted).

• None of the documented statuses means "paid, not admitted". There's no refund state, no receipt, and no retry rule.
• The server's wallet broadcasts the settlement, so the server alone decides when it happens. It can:
  • settle after the 600-second quote life and then report expired;
  • crash between broadcast and admission;
  • be malicious and keep the IMD.
• Either way the user has paid 0.5 IMD, has nothing signed to show for it, and the only view of the order is a server-controlled GET /requests/:id.

Smallest fix:

• (a) The client sets the Permit2 deadline to no later than the quote's expiresAt. The server rejects any permit where deadline > expiresAt. That stops settlement after expiry at the chain level.
• (b) Add one rule: a settlement confirmed on-chain for an order's nonce always leads to admission. Admission is retried until it succeeds, regardless of quote expiry. Add a terminal refund_due status for orders that can never be admitted.
• (c) Once settled, the server returns a signed receipt {orderId, nonce, txHash} the user can use as evidence.

2. HIGH: A third party settles first (front-running and griefing)

Step attacked: the Permit2 PermitWitnessTransferFrom sent to the proxy.

• Anyone who sees the PAYMENT-SIGNATURE can call the proxy's settle themselves. That includes:
  • the mempool, once the server broadcasts;
  • a TLS-terminating proxy;
  • server logs or an observability vendor;
  • a malicious browser extension.
• Because the witness pins to, the money still reaches the IMD recipient, so nobody steals it. But the nonce gets used up outside the server's own flow. The server's settle transaction then reverts:
  • the server pays gas for nothing;
  • the order likely goes to payment_failed;
  • the user has paid and gets no admission.
• An attacker can repeat this against every order. It costs them only gas, and it breaks every paid request.

Smallest fix: no contract change needed.

• Derive the Permit2 nonce from the order: nonce = uint256(keccak256("imd.order", orderId, requesterScopeHash)), and have the server require exactly that value.
• When the server's settle reverts because the nonce is already used, it looks for the proxy/Permit2 transfer event for that nonce. If it finds one, the order counts as paid and moves to admission_pending (then finding 1(b) applies).
• Front-running then does no harm. Also send settlements through a private mempool to save gas.

3. HIGH (depends on the approval fields): A relayer takes over the order by swapping the bearer or order

Step attacked: the QuoteApproval signature, and admission ownership.

• Suppose the approval covers the quote's contents (action, input hash, price, expiry) but not orderId and requesterScopeHash.
• Then an attacker who captures both signatures can:
  1. create their own quote under their own bearer, with the same action/input;
  2. attach the victim's PAYMENT-SIGNATURE and quoteSignature;
  3. submit before the victim does.
• The victim's IMD pays for an order the attacker owns. The attacker gets the status, result and attestation URLs. The victim's own order then fails because the nonce is already used.

Smallest fix:

• The QuoteApproval struct must include orderId, requesterScopeHash, resourceUrl, and the Permit2 nonce and deadline.
• The server checks that each one matches the order the request is being submitted against.
• Publish the typed-data definition so wallets and clients can show it and check it.

4. HIGH→MEDIUM: Replay across orders and double admission

Step attacked: pairing each QuoteApproval with a Permit2 payment.

• Suppose the approval doesn't commit to a specific Permit2 nonce, or the server doesn't enforce a unique nonce across orders. Then a user signs approvals for orders B, C and so on that all point to the permit already settled for order A. Or they resubmit order A's pair against order B.
• If the server checks only that the signatures are valid, one payment admits many orders.
• The reverse also happens: a buggy server settles one permit and credits it to the wrong order.
• The documented requestKey idempotency ("Reuse it to retry the same quote") only removes duplicates within a single scope and key. It doesn't stop payments being reused across orders.

Smallest fix:

• Give the database a UNIQUE(chainId, payer, permit2Nonce) constraint mapped to exactly one orderId.
• Combined with the order-derived nonce from finding 2 and nonce/deadline in the approval from finding 3, a payment can be consumed by one order only.

5. MEDIUM: Quote substitution between the quote and the 402 challenge, including recipient redirect

Step attacked: the quote and the 402 PAYMENT-REQUIRED challenge.

• The 402 challenge echoes back input and the payment requirements. Price, token and recipient come from the "live" capabilities endpoint.
• Several parties could swap the challenge for a different input or a higher price: a compromised CDN or edge, a MITM, or a malicious SDK/proxy. They could also change payTo, which becomes Permit2 witness.to.
• The user would then sign a valid Permit2 authorization paying the attacker, or approve a job they never asked for.
• The proxy enforces to only against whatever the user signed. It doesn't check against IMD's real recipient.

Smallest fix:

• The client checks that the challenge's input hash equals the hash of what it posted.
• The client checks that payTo/asset/amount equal values pinned in the SDK. Don't take them only from the live endpoint.
• The QuoteApproval includes inputHash, amount, token and payTo. The server rejects any mismatch.

6. MEDIUM: Bearer-token leakage

Step attacked: authentication of every step (quote, submit, status polling, results).

• The bearer is the only credential for reading the order, and the client generates it.
• If it leaks, the attacker can:
  • read all orders and results under that scope;
  • resubmit captured signatures (idempotency makes this mostly harmless);
  • combined with finding 3, take over orders.
• Likely leak paths:
  • Authorization headers in reverse-proxy or APM logs;
  • reusing one secret across many orders or across staging and production;
  • statusUrl/resultUrl values that embed the secret or order capabilities;
  • weak client random-number generators.
• requesterScopeHash appears in the 402 challenge. If it isn't a hash of the secret with a domain separator added (e.g. it's a bare hash, or only a truncated one), it's another place for leaks or linking scopes across services.

Smallest fix:

• Make order ownership wallet-bound as well: the payer's address from the verified signature can re-authenticate (with a Wallet EIP-712 signature) and rotate the bearer. A leaked bearer can then be revoked.
• Define requesterScopeHash = keccak256("imd.scope.v1", secret).
• Say explicitly in the docs that clients should use one secret per order or session, that the server redacts Authorization, and that result URLs never carry the secret.

7. LOW-MEDIUM: Gas griefing against the server's wallet

Step attacked: settlement (the server pays gas).

• An attacker holding many cheap bearers submits permits that pass the off-chain check.
• Before the server broadcasts, they drain their balance or revoke the Permit2 allowance, or race the nonce.
• Each server settle transaction reverts, and IMD pays the gas. It's a cheap way to drain the server's wallet or cause a denial of service.

Smallest fix:

• Re-simulate with eth_call right before broadcasting.
• Rate-limit per payer address, not per bearer.
• Send through a private orderflow channel so a revert costs nothing.
• Optionally require payers to have a minimum balance or allowance margin.

8. LOW: Cross-environment or cross-chain replay of QuoteApproval

Step attacked: the EIP-712 domain of the quote approval.

• The proxy is at the same address on every chain, and Permit2 signatures are bound to a chain. But if the QuoteApproval domain lacks chainId plus a service-specific name/version/verifyingContract, a signature collected by staging (or a fork of IMD) can be replayed against production. This matters if both use the same recipient and quote ID format.

Smallest fix:

• The domain includes chainId: 1 and a unique name for each environment.
• The struct includes resourceUrl, which carries the host.

---

Summary

#	Severity	Step	Smallest fix
1	High	Settle → admit	Permit deadline ≤ quote expiry; settled means admitted (retried), plus refund_due and a signed receipt
2	High	Permit2 settle	Nonce derived from orderId; on revert, find the settlement event and treat the order as paid
3	High (conditional)	QuoteApproval	Approval covers orderId, requesterScopeHash, resourceUrl, and the permit nonce and deadline
4	High→Med	Pairing	UNIQUE(payer, nonce) → one order
5	Medium	Quote/402	Client pins recipient/token/amount and checks inputHash; approval covers them
6	Medium	Bearer auth	Wallet-bound ownership and bearer rotation; hash with a domain tag; redact Authorization
7	Low-Med	Gas	Simulate just before broadcast, private orderflow, per-payer limits
8	Low	EIP-712 domain	chainId plus a per-environment domain name

The single most useful change is to derive the Permit2 nonce from the order and include it in QuoteApproval with orderId and requesterScopeHash. That one change fixes most of findings 2, 3 and 4. It also makes the fix for finding 1 easy to audit, because every on-chain settlement then maps to exactly one order.

---

Sources offered but not confirmed by this machine:

• https://imd.fun/docs — does not contain the quoted text
• https://imd.fun/docs — does not contain the quoted text