Problem
Mppx.create() registers each method by name/intent as the key. This means you can only register one tempo.charge() and one solana.charge() — any additional instance with the same name/intent silently overwrites the previous one.
This makes it impossible to accept more than one stablecoin per chain as payment. For example, on Tempo mainnet there are multiple live stablecoins (USDC.e, pathUSD, etc.) and on Solana there are multiple USDC variants. Operators may reasonably want to accept any of them.
Example
// Desired — accept USDC.e OR pathUSD on Tempo:
Mppx.create({
methods: [
tempo.charge({ currency: USDC_E }), // "tempo/charge"
tempo.charge({ currency: PATH_USD }), // silently overwrites the above
],
})
Currently only the last one wins. The first is dropped with no warning.
Expected Behavior
One of:
-
Multi-currency support on a single method — accept a currency array and let the server verify any matching transfer:
tempo.charge({ currency: [USDC_E, PATH_USD], recipient: '0x...' })
-
Allow multiple methods with the same name/intent — present all of them as separate WWW-Authenticate challenges, disambiguated by the request payload (different currency field). The client picks whichever token it holds.
-
Warn loudly — at minimum, throw or warn when a duplicate name/intent is registered rather than silently dropping the earlier entry.
Context
Building a pay-per-download CSV export on a Tempo analytics explorer. We want to accept either stablecoin a user might hold on Tempo, but currently have to pick just one. Ended up going with USDC.e as the single accepted token for now.
Problem
Mppx.create()registers each method byname/intentas the key. This means you can only register onetempo.charge()and onesolana.charge()— any additional instance with the same name/intent silently overwrites the previous one.This makes it impossible to accept more than one stablecoin per chain as payment. For example, on Tempo mainnet there are multiple live stablecoins (USDC.e, pathUSD, etc.) and on Solana there are multiple USDC variants. Operators may reasonably want to accept any of them.
Example
Currently only the last one wins. The first is dropped with no warning.
Expected Behavior
One of:
Multi-currency support on a single method — accept a
currencyarray and let the server verify any matching transfer:Allow multiple methods with the same name/intent — present all of them as separate
WWW-Authenticatechallenges, disambiguated by therequestpayload (differentcurrencyfield). The client picks whichever token it holds.Warn loudly — at minimum, throw or warn when a duplicate
name/intentis registered rather than silently dropping the earlier entry.Context
Building a pay-per-download CSV export on a Tempo analytics explorer. We want to accept either stablecoin a user might hold on Tempo, but currently have to pick just one. Ended up going with USDC.e as the single accepted token for now.