Mint page: recover from account sequence mismatch (fetch sequence at sign time + auto-retry on code 32) #499

New issue

Closed

opened 2026-07-16 11:49:12 +00:00 by leonardocolucci · 6 comments

leonardocolucci commented

2026-07-16 11:49:12 +00:00

(Migrated from gitlab.com)

Summary

The mint/faucet page (from #473) surfaces the raw broadcast error when the connected account's on-chain sequence has advanced past the one the page signed with:

account sequence mismatch, expected 133, got 121: incorrect account sequence

Seen on the TOPAZ mint page (mainnet soft launch). The account was concurrently active from another signer (an automated trader on the same wallet), so the page's cached sequence was 12 behind by the time MINT was clicked. The mint stays stuck on this error until the account info is refreshed.

Why this is worth handling in the frontend

This is the standard Cosmos SDK code-32 error and not a contract bug, but any user will hit it whenever the same account transacts from two places (second browser tab, mobile wallet, a bot) — or potentially when clicking MINT repeatedly across the 5-minute cooldown with a stale page. The raw error text gives no hint about what to do next, and "mint N times, paying gas each time" flows are especially exposed since each successful tx bumps the sequence.

Suggested UX improvement

Fetch the account sequence at signing time, immediately before building each mint tx, rather than reusing account info cached at page load / wallet connect.
On a code-32 account sequence mismatch broadcast failure, re-fetch the sequence and retry once automatically before surfacing an error.
If it still fails after the retry, show a friendly message ("Your wallet was used elsewhere — refreshing account state, please try again") with the raw error available as a detail/expandable.

Item 2 alone would resolve the common case invisibly; items 1 and 3 make repeated mints and concurrent-use scenarios robust.

Environment

dex.cl8y.com mint page, TOPAZ, amount per mint 100
columbus-5 mainnet, soft-launch faucet terra1388y0ppe2c3dy4nrmnpqp7e4ggukkrnmpzfjadfeu0pu2rm9cvkslfzcen
Account concurrently in use by another signer at the time of the error

## Summary The mint/faucet page (from #473) surfaces the raw broadcast error when the connected account's on-chain sequence has advanced past the one the page signed with: ``` account sequence mismatch, expected 133, got 121: incorrect account sequence ``` Seen on the TOPAZ mint page (mainnet soft launch). The account was concurrently active from another signer (an automated trader on the same wallet), so the page's cached sequence was 12 behind by the time MINT was clicked. The mint stays stuck on this error until the account info is refreshed. ## Why this is worth handling in the frontend This is the standard Cosmos SDK code-32 error and not a contract bug, but any user will hit it whenever the same account transacts from two places (second browser tab, mobile wallet, a bot) — or potentially when clicking MINT repeatedly across the 5-minute cooldown with a stale page. The raw error text gives no hint about what to do next, and "mint N times, paying gas each time" flows are especially exposed since each successful tx bumps the sequence. ## Suggested UX improvement 1. **Fetch the account sequence at signing time**, immediately before building each mint tx, rather than reusing account info cached at page load / wallet connect. 2. **On a code-32 `account sequence mismatch` broadcast failure, re-fetch the sequence and retry once automatically** before surfacing an error. 3. If it still fails after the retry, show a friendly message ("Your wallet was used elsewhere — refreshing account state, please try again") with the raw error available as a detail/expandable. Item 2 alone would resolve the common case invisibly; items 1 and 3 make repeated mints and concurrent-use scenarios robust. ## Environment - dex.cl8y.com mint page, TOPAZ, amount per mint 100 - columbus-5 mainnet, soft-launch faucet `terra1388y0ppe2c3dy4nrmnpqp7e4ggukkrnmpzfjadfeu0pu2rm9cvkslfzcen` - Account concurrently in use by another signer at the time of the error

PlasticDigits commented

2026-07-25 04:13:37 +00:00

(Migrated from gitlab.com)

Issue verified, all 3 suggestions valid - however for 3 we must minimize text to comply with anti cognitive overload guidelines

PlasticDigits commented

2026-07-25 04:33:09 +00:00

(Migrated from gitlab.com)

mentioned in commit c12918d7db

mentioned in commit c12918d7db2f59bea019ae5f70f94e7391764e14

PlasticDigits commented

2026-07-25 04:33:54 +00:00

(Migrated from gitlab.com)