Intermittent "unable to estimate gas" errors on /settle endpoint - Base Mainnet USDC payments

[cybertheory]

Summary

We're experiencing intermittent unable to estimate gas errors when calling the CDP x402 Facilitator /settle endpoint on Base mainnet. The failures are non-deterministic - identical requests sometimes succeed and sometimes fail, even with fresh signatures and nonces each time.

Environment

• Network: Base Mainnet (chainId: 8453)
• Asset: USDC (0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913)
• Scheme: exact (ERC-3009 TransferWithAuthorization)
• Payment Amount: 1000 atomic units (0.001 USDC)
• CDP SDK Version: Latest (@coinbase/cdp-sdk)

Error Details

{
  "error": "facilitator_settle_failed",
  "debug": {
    "error": "Facilitator settle failed (400): {\"errorMessage\": \"failed to send transaction: error (status 400): invalid_request: unable to estimate gas\", \"errorReason\": \"invalid_payload\", \"network\": \"base\", \"payer\": \"0x9A95677Df6ED534bbb2521936eEca92B268B94Db\", \"success\": false}"
  }
}

Reproduction Pattern

Running 5 identical API requests with 3-second delays between each:

Test #	Result
1	FAILED
2	SUCCESS
3	FAILED
4	FAILED
5	SUCCESS

Success rate: ~40% with identical code and configuration.

What We've Verified

Fresh Nonce Each Request

Each request generates a cryptographically random 32-byte nonce:

TypeScript:

const randomBytes = new Uint8Array(32);
crypto.getRandomValues(randomBytes);
const nonce = '0x' + Array.from(randomBytes)
  .map(b => b.toString(16).padStart(2, '0'))
  .join('');

Python:

import secrets
nonce = '0x' + secrets.token_hex(32)

Confirmed via logs - each request has a unique nonce:

Request 1: 0xd56eed5c3460dd37ded5a77fd228142997c2613f...
Request 2: 0x691c9ed5ab4cc628de537fcce4bddb81f3cf8c9e...
Request 3: 0xef7d9741968707e660ed9f0c89d00d0a98935c5b...

Correct EIP-712 Domain

Using the official USDC contract domain parameters:

const domain = {
  name: "USD Coin",
  version: "2",
  chainId: 8453,
  verifyingContract: "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"
};

Sufficient Balance

• USDC Balance: ~2.99 USDC (verified via balanceOf)
• ETH Balance: Sufficient for any fees
• Each payment: 0.001 USDC

/verify Passes

The /verify endpoint returns isValid: true before /settle fails:

{
  "isValid": true,
  "invalidReason": null
}

On-Chain Transactions Succeed When They Work

Successful payments are confirmed on-chain. Balance decreases correctly. The USDC transfers complete to the payTo address.

Code Examples (From our own SDK implementation for https://waterfall.finance)

TypeScript SDK Usage

import { WaterfallClient } from 'waterfall-ts';

const client = new WaterfallClient({ apiKey: 'wf_xxx' });
await client.configureWallet({ walletName: 'My Wallet' });

// This works ~40% of the time
const response = await client.chat.send({
  model: 'openai/gpt-3.5-turbo',
  messages: [{ role: 'user', content: 'Hello' }]
});

// Multi-turn conversations fail on subsequent calls
const response2 = await client.chat.send({
  model: 'openai/gpt-3.5-turbo',
  messages: [
    { role: 'user', content: 'Hello' },
    { role: 'assistant', content: response.choices[0].message.content },
    { role: 'user', content: 'Follow up question' }
  ]
});

Python SDK Usage

from waterfall import WaterfallClient

client = WaterfallClient(api_key='wf_xxx')
client.configure_wallet(wallet_name='My Wallet')

# First call - works ~40% of the time
response1 = client.chat.send(
    model='openai/gpt-3.5-turbo',
    messages=[{'role': 'user', 'content': 'Hello'}]
)

# Second call - often fails with "unable to estimate gas"
response2 = client.chat.send(
    model='openai/gpt-3.5-turbo',
    messages=[
        {'role': 'user', 'content': 'Hello'},
        {'role': 'assistant', 'content': response1.choices[0].message.content},
        {'role': 'user', 'content': 'Follow up'}
    ]
)

x402 Gateway Payment Flow

// 1. Receive 402 Payment Required
const paymentRequired = {
  scheme: 'exact',
  network: 'base',
  asset: '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913',
  payTo: '0x6e560Fd994dA2f434E95Cde3CAA868FB0bbCA8Ba',
  maxAmountRequired: '1000',
  extra: { name: 'USD Coin', version: '2' }
};

// 2. Generate ERC-3009 Authorization
const authorization = {
  from: walletAddress,
  to: paymentRequired.payTo,
  value: paymentRequired.maxAmountRequired,
  validAfter: Math.floor(Date.now() / 1000).toString(),
  validBefore: (Math.floor(Date.now() / 1000) + 600).toString(),
  nonce: generateRandomNonce()
};

// 3. Sign with EIP-712
const signature = await wallet.signTypedData({
  domain: { name: 'USD Coin', version: '2', chainId: 8453, verifyingContract: asset },
  types: { TransferWithAuthorization: [...] },
  primaryType: 'TransferWithAuthorization',
  message: authorization
});

// 4. Call Facilitator
// /verify returns isValid: true
// /settle returns "unable to estimate gas" (intermittent)

Expected Behavior

All valid payment signatures with fresh nonces should settle successfully, especially when:

• /verify returns isValid: true
• Wallet has sufficient USDC balance
• EIP-712 domain matches the token contract
• Nonce has never been used before

Actual Behavior

~60% of valid, verified payments fail at /settle with unable to estimate gas, despite:

• Passing verification
• Using fresh nonces
• Having sufficient balance
• Using correct domain parameters

Questions

1. Is there internal rate limiting on the facilitator that could cause this pattern?
2. Are there multiple facilitator instances, some of which may be unhealthy?
3. Is there a recommended retry strategy for handling these intermittent failures?
4. Could there be RPC node issues on the facilitator's side affecting gas estimation?

Workaround Attempted

Adding delays (2s, 10s, 30s) between requests does not resolve the issue. The failures appear random regardless of timing.

Impact

This makes multi-turn conversations unreliable for production use, as subsequent API calls in a session frequently fail even though the payment signatures are valid.

Additional Context

• First request in a session has the same ~40% failure rate as subsequent requests
• Failures are not correlated with time of day
• Same behavior observed across TypeScript and Python SDKs
• On-chain transaction history shows successful payments when /settle succeeds

[cybertheory]

Update: Root Cause Identified & Fixed

Discovery

After extensive testing, we identified the actual root cause. It's NOT any of the following:

• EIP-712 domain mismatch
• Nonce reuse
• validAfter timing issues
• Insufficient balance
• Signature format problems

Actual Root Cause: CDP State Propagation Delay (Race Condition)

After the CDP wallet signs an ERC-3009 authorization, Coinbase's internal systems require approximately 1 second to propagate the signature state before the facilitator can successfully settle the payment.

When payments are submitted immediately after signing (typical SDK behavior), the facilitator intermittently fails because its internal verification hasn't synced yet.

Evidence

We tested with varying delays between signature generation and payment submission:

Delay After Signing	Success Rate
0 seconds	40%
0.5 seconds	60%
1.0 seconds	100%
1.5 seconds	100%
2.0 seconds	100%

Test code:

# Get signature from CDP wallet
signature = wallet.sign_payment(payment_requirements)

# Without delay: ~40% success rate
# response = retry_with_signature(signature)  # Often fails

# With 1 second delay: 100% success rate
time.sleep(1.0)
response = retry_with_signature(signature)  # Always succeeds

Fix Applied

We added a 1-second delay in our SDKs after receiving the signed payment authorization:

Python SDK:

# Sign the payment via backend
signature = self._sign_payment(payment_data)

# Wait for CDP infrastructure state propagation
import time
time.sleep(1.0)

# Now retry with payment signature
new_headers["PAYMENT-SIGNATURE"] = signature

TypeScript SDK:

// Sign the payment via backend
const signature = await this.client.signPayment(paymentData);

// Wait for CDP infrastructure state propagation
await new Promise(resolve => setTimeout(resolve, 1000));

// Now retry with payment signature
headers["PAYMENT-SIGNATURE"] = signature;

Results After Fix

Multi-turn conversations now work reliably:

=== Multi-Turn Conversation Test ===

Turn 1: "What is 2 + 2?"
Response: "4" ✓

Turn 2: "Multiply that by 3"  
Response: "12" ✓

Turn 3: "What was the original number?"
Response: "4" ✓

All turns completed successfully!

Recommendation for CDP Team

Consider documenting this behavior or implementing internal queuing/synchronization so that:

1. Signatures are immediately usable after generation
2. Or the /settle endpoint gracefully retries internally if state hasn't propagated

The 1-second delay workaround is acceptable but adds latency to every payment. Understanding why this propagation delay exists could help optimize the payment flow.

Summary

• Issue: Intermittent "unable to estimate gas" errors (~60% failure rate)
• Root Cause: CDP internal state propagation delay after signing
• Solution: Add 1-second delay between signing and settlement
• Status: Resolved with workaround

[cybertheory]

Why does the facilitator's settle endpoint sometimes fail with 'unable to estimate gas' immediately after signing succeeds, but works after a 1-second delay?

[CarsonRoscoe]

Hey @cybertheory, thank you for the report and apologies for this frustrating experience,

I do want to call out, in case this was just an unfortunate timing issue, that the base network had congestion issues over the weekend related to including transactions in blocks. Getting transactions on chain was difficult during this time, as gas prices were extremely volatile. It has since cooled down, however we still see some volatility in gas prices today.

Regarding your report, there should be no hidden "propagation" between signing typed data and calling /settle on CDP's backend. I don't see any obvious reason why your sleep would have an impact on x402 success rate, so I will be looking into that.

Couple questions please:

1. Can you double check your testing today now that the incident has been mitigated to see if this is a reoccuring issue? If everything is working fine today, you were impacted by the incident
2. It seems you are using CDP wallets. Were you signing typed data with a server, smart, or embedded wallet?

If the issue persists, I will reach out to the relevant wallet team and get to the bottom of this,

Thank you

[cybertheory]

Alright thank you so much - I will re-run tests today. The "propagation" error was claude's best guess lol - but totally makes sense. I was very confused why there would need to be a delay after singing but it was probably just a error on chain.

[mkmkkkkk]

Good catch on the workaround — the 1-second delay between signing and submission strongly suggests a state propagation lag inside the CDP signing pipeline, not a gas estimation issue per se. Here's what's likely happening:

ERC-3009 transferWithAuthorization requires the from address to have sufficient balance and the nonce to be unused at the point of eth_estimateGas. If the CDP signer hasn't fully propagated the signed authorization to its internal state, the RPC node sees the call as "from an address that hasn't authorized this transfer yet" — which makes estimateGas revert, producing the generic error.

Why this matters beyond the workaround:

A fixed delay is fragile — under CDP load spikes, 1 second may not be enough. A more resilient pattern is exponential backoff on estimateGas failure with classification:

async function settleWithRetry(payload: PaymentPayload, maxRetries = 3) {
  for (let i = 0; i < maxRetries; i++) {
    try {
      return await facilitator.settle(payload);
    } catch (err) {
      if (isGasEstimationError(err) && i < maxRetries - 1) {
        await sleep(Math.pow(2, i) * 500); // 500ms, 1s, 2s
        continue;
      }
      throw err; // non-retryable or exhausted retries
    }
  }
}

function isGasEstimationError(err: unknown): boolean {
  const msg = (err as Error)?.message?.toLowerCase() ?? '';
  return msg.includes('unable to estimate gas') ||
         msg.includes('execution reverted');
}

Broader suggestion for the facilitator: The /settle endpoint should classify errors into retryable vs. terminal categories in its response body. Right now clients get a raw error string and have to guess. Something like { "errorClass": "TRANSIENT_GAS_ESTIMATION" | "INVALID_SIGNATURE" | "INSUFFICIENT_BALANCE" | "NONCE_ALREADY_USED" } would let clients implement proper retry logic without parsing error messages.

We've been building an error classification layer in PaySentry's protect module for exactly this — mapping raw RPC errors to actionable settlement states. The pattern of "verify passes but settle fails" is the #1 source of user confusion we've seen across x402 integrations.

[lbank456]

[tomismeta]

Thanks for the writeup and potential solutions (still unable to resolve).

I'm seeing a persistent settle failure on CDP x402 for Base mainnet EIP-3009 payments, even when signatures and authorization data are valid.

• Flow: x402 v2 client payload (exact, Base USDC, assetTransferMethod: eip3009) -> server adapts for CDP facilitator.
• Verify behavior: payload validates and local transfer simulation succeeds.
• Settle behavior: CDP returns HTTP 400 with invalid_payload and unable to estimate gas.
• Repro: persists across fresh nonces, fresh signatures, and fresh timestamps.

What I Validated

• Correct EIP-712 domain for USDC on Base:
  • name: USD Coin
  • version: 2
  • chainId: 8453
  • verifyingContract: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
• Authorization fields valid:
  • from, to, value, validAfter, validBefore, nonce
• Nonce is 32-byte hex and unused.
• Payer has sufficient USDC balance.
• Local transferWithAuthorization simulation succeeds on Base RPC.
• Server canonicalizes method branch to avoid mixed Permit2/EIP-3009 payloads.

Two Delay/Retry Attempts We Made

1. Delay after signing (client-side workflow)

I tested the recommendation to wait before submitting settlement after signature generation.
Result: did not resolve the failure pattern in our environment.

2. Server-side delay + retry logic

I implemented two rounds server-side:

• Attempt A: transient retry backoff on settle failures (500ms, 1000ms, 2000ms) for gas-estimation-class errors.
• Attempt B: added an initial 1-second wait before first settle attempt for EIP-3009, and retried both returned failures and thrown exceptions.

Result: still fails with the same CDP settle error.

Current Status

Multiple fresh runs still end with:

failed to send transaction ... unable to estimate gas

Given successful validation + successful local simulation + failed CDP settle, this appears to be a facilitator-side settle/gas-estimation issue for this route rather than a wallet nonce/signature/balance issue on our side.

Unable to resolve still. Opened case with CDP support.

[CarsonRoscoe]

Quick update: I’m actively investigating this and will share more as soon as I have a concrete update.

I haven’t been able to reproduce the exact issue you’re seeing. However, while attempting to do so, I identified a bug that appears either related or potentially the underlying cause.

Since you’re not using the official x402 SDKs, it’s possible you’re encountering the same root issue, but surfaced differently due to implementation differences.

Appreciate your patience, I’ll follow up soon!

[lbank456]

Ok. TySent from my iPhoneOn Feb 12, 2026, at 5:44 PM, Carson Roscoe ***@***.***> wrote:CarsonRoscoe left a comment (coinbase/x402#1065) Quick update: I’m actively investigating this and will share more as soon as I have a concrete update. I haven’t been able to reproduce the exact issue you’re seeing. However, while attempting to do so, I identified a bug that appears either related or potentially the underlying cause. Since you’re not using the official x402 SDKs, it’s possible you’re encountering the same root issue, but surfaced differently due to implementation differences. Appreciate your patience, I’ll follow up soon! —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[tomismeta]

Thanks so much for looking at this Carson. If you DM me on X, I can share the url of the web app I built where this issue has been encountered. I enabled full tracing in case that helps.

If you have an agent, can have it read the webmcp markdown and follow the process. That should show you more.

Looking forward to hearing more. Let me know if you need any support while you’re triaging this.