let elixir and energy charge the stablecoin the wallet actually holds - #196
Merged
Conversation
Owner: "aku barusan test buy elixir, tapi ko gagal? jujur buy elixir aja yg
gagal, selain itu berhasil semua" — tested in the OKX browser on Celo.
Both dollar purchases in DungeonGame hardcoded USDm:
txHash = await walletRef.current.buyMarketplaceItem(1, 'USDm')
body: { wallet: addr, txHash, token: 'USDm' }
Every other paid flow asks first. MarketplaceScreen:41 and CraftingScreen:112
call pickBestPaymentToken, which reads the wallet's USDm/USDC/USDT balances and
returns whichever it holds the most of. That is also MiniPay's "Dynamic
Adaptation" requirement, recorded in MINIPAY-COMPLIANCE-CHECKLIST.md §2.
So a wallet holding USDC but no USDm sent a USDm transfer that moved nothing,
and /api/elixir/buy then correctly reported "No matching payment to treasury
found in this tx" — it verifies a Transfer(from=buyer, to=treasury,
value>=price) in the named token, and there wasn't one. The failure was honest;
the request was wrong.
That is exactly why only elixir failed while everything else worked: everything
else asked.
Line 156 had the same bug and is ENERGY REFILL, which the owner had not tested
yet. It would have failed on the same wallet for the same reason.
One helper, both call sites, falling back to USDm on a read failure — which is
what pickBestPaymentToken does internally too, so a flaky RPC degrades to the
old behaviour rather than blocking a sale.
Not verifiable from here: this needs a real wallet holding a non-USDm
stablecoin, which is the same limitation the note in lib/contract-abi.ts:48
already records about confirming pickBestPaymentToken.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017A764RdnwpyWnG7uCNhMiQ
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Owner: "aku barusan test buy elixir, tapi ko gagal? jujur buy elixir aja yg gagal, selain itu berhasil semua" — tested in the OKX browser on Celo.
The bug
Both dollar purchases in
DungeonGame.tsxhardcoded USDm:Every other paid flow asks first.
MarketplaceScreen:41andCraftingScreen:112callpickBestPaymentToken, which reads the wallet's USDm/USDC/USDT balances and returns whichever it holds the most of. That's also MiniPay's "Dynamic Adaptation" requirement, recorded inMINIPAY-COMPLIANCE-CHECKLIST.md§2.So a wallet holding USDC but no USDm sent a USDm transfer that moved nothing, and
/api/elixir/buythen correctly reported "No matching payment to treasury found in this tx" — it verifies aTransfer(from=buyer, to=treasury, value>=price)in the named token, and there wasn't one.The failure was honest; the request was wrong. And that is exactly why only elixir failed while everything else worked: everything else asked.
The one you hadn't hit yet
DungeonGame.tsx:156had the same bug and is energy refill. It would have failed on the same wallet for the same reason — you just hadn't tested it.The fix
One helper, both call sites, falling back to USDm on a read failure — which is what
pickBestPaymentTokendoes internally too, so a flaky RPC degrades to the old behaviour rather than blocking a sale.Verification
audit/check:copy/check:market/check:cssvarsbuild:enginenpx tsc --noEmitnpm run buildnpm run lintmainNot verifiable from here. This needs a real wallet holding a non-USDm stablecoin — the same limitation the note at
lib/contract-abi.ts:48already records about confirmingpickBestPaymentToken. Worth retesting elixir and energy refill on the wallet that failed.Generated by Claude Code