maxAmountRequired appears misnamed

[jasonbcox]

The naming maxAmountRequired is confusing. Normally payments require a minimum and overpayment is not undesirable for a service provider. A more appropriate name is minAmountRequired. I only hesitate to open a PR because the whitepaper doubles down on this naming on page 10:

• The actual payment amount (must be ≤ maxAmountRequired)

It indicates the payment amount can be less than the amount required, so it seems underpayment is explicitly ok. But this doesn't make any sense to me, so I would like to see some feedback from the team before going to the trouble.

[TtheBC01]

ya, i think its confusing too. I just figured it would be for API resources where you might consume a variable amount (like bandwidth or db reads or something), and a variable name like maxAmountRequired means that this caps what you can pay in one request.

[kladkogex]

I think the purpose of maxAmountRequired is to act as a safeguard — to ensure that the AI can’t accidentally overspend (for example, due to a hallucination or a bug).

wontAcceptMoreThan would probably be a better name.

Then the spec needs to state that if the amount is more than this the payment will be explicitly rejected.

If the price is exact and the user pays for a single call, there is arguably no need for all of this, it can be simply "price"

If the user pays for multiple calls, it could be something like two fields: pricePerCall and wontAcceptMoreThan

[zensh]

@jasonbcox

The spec mentions validation for maxAmountRequired:

Amount Validation: Ensure the payment amount meets or exceeds the required amount

While minAmountRequired might seem more fitting, this naming actually anticipates the future upto scheme. Under upto, the server may deduct less than this amount—though the spec hasn't yet defined which field will represent the actual required payment in such cases.

In short, maxAmountRequired is the server telling the client:
"I might deduct up to this amount—ensure your wallet has sufficient balance. Paying more is also acceptable."

[rotilho]

I get the idea behind maxAmountRequired, but having just that field can be a bit limiting and a little tricky to understand without double checking the spec.

What if the spec supported amount, minAmount, and maxAmount instead? That would make it more flexible and easier to express different pricing models: fixed prices, deposits, usage-based billing, tips, and more.

Some examples:

• { amount: "10" } → exact price
• { minAmount: "5" } → pay at least this
• { maxAmount: "20" } → cap payment
• { minAmount: "50", maxAmount: "200" } → deposit range
• { minAmount: "50", amount: "25", maxAmount: "200" } → minimal payment

It opens up more possibilities. You could even keep maxAmountRequired as an alias for minAmount for backwards compatibility and clarity

[kladkogex]

While minAmountRequired might seem more fitting, this naming actually anticipates the future upto scheme. Under upto, the server may deduct less than this amount—though the spec hasn't yet defined which field will represent the actual required payment in such cases.

In short, maxAmountRequired is the server telling the client: "I might deduct up to this amount—ensure your wallet has sufficient balance. Paying more is also acceptable."

The problem with deducting less is that EIP-3009 does not allow charging less than the authorized amount.

I think an alternative is for the client to send a prompt together with the original x402 request.

The server then looks at the prompt and dynamically quotes the price in the Payment Requirements depending on the prompt’s complexity. The scheme can stay “exact”; it’s just that the Payment Requirements are dynamically generated based on the prompt.

[zensh]

EIP-3009 doesn't support the "upto" scheme, which isn't an x402-specific issue.

The ICP blockchain can actually implement the "upto" scheme and even an "escrow" scheme, though neither is currently defined in x402. ICP exact scheme

x402 is still in its early stages. For AI Agent payments, it appears somewhat complex; for conventional use cases, its flexibility still seems limited.

[jasonbcox]

In short, maxAmountRequired is the server telling the client: "I might deduct up to this amount—ensure your wallet has sufficient balance. Paying more is also acceptable."

This does not jive with the description on page 10. The actual payment amount (must be ≤ maxAmountRequired)

It is also unclear how maxAmountRequired will make more sense with (or without) upto.

Fundamentally, the client should be told the minimum amount of money to provide in order for the transaction to go through successfully. Whether this or that blockchain does/doesn't support spending up to an amount should not be baked into x402.

Building further on @rotilho's suggestion, it may be less confusing to separate the requested amount and the possible costs:

• amount - The amount the caller should pay.
• minCost - The minimum the caller will be charged.
• maxCost - "maxAmountRequired" aka The maximum the caller may be charged.

I think amount should always be equal to maxCost in the base case (for the best UX). But I can see how callers may prefer for a request to fail if the cost would exceed an amount they're willing to pay.