Bug: Terra->Solana withdraw_execute fails -- token_mapping AccountNotInitialized (3012) #104
Labels
No labels
agent:implement
agent:ready
backend
bug
cannot-reproduce
confirmed
desktop
docs
documentation
duplicate
enhancement
feature
frontend
good first issue
help wanted
high-risk
in-review
invalid
mobile
needs-triage
P0-critical
P1-high
P2-medium
P3-low
qa
QA
question
ready
report
responsive
security
security-escalate
smart-contract
solana
tablet
test-pass
ux
wallet-issue
wallet:keplr
wallet:metamask
wallet:station
wallet:walletconnect
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
code/cl8y-bridge-monorepo#104
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Mainnet v0.1.82 (
7cb18b3+ operator hotfix 4/10)Terra->Solana 0.997 testa nonce 53 (hash 0xfda305a034140568...). Deposit OK, withdrawSubmit OK, operator approved, but withdraw_execute simulation fails:
BSC->Solana works fine (same token, same wallet). Likely the token_mapping PDA for the Terra->Solana path was never registered on the bridge program.
Also affects the 4/9 stuck transfer: Terra->Solana 1.994 testa nonce 52 (0x12b359b812c0e805...).
Acceptance criteria:
@brouie Triage (repo
main):token_mappingPDAs use seeds[b"token", src_chain_4, remote_token_32]consistently inwithdraw_submitandwithdraw_execute. The repo already haspackages/contracts-solana/scripts/register-mainnet-tokens.tsregistering BSC, opBNB, and Terra rows (including Terra testa). If mainnet still hits 3012, please verify the on-chain account exists for the failing(src_chain, src_token)pair and re-run that script with the bridge admin signer if needed; also confirm the execute UI resolves the samesrc_tokenbytes as submit (transfer record / Terra encoding). No program change expected from this triage. Please verify and close if resolved.mentioned in issue #105
@PlasticDigits Fresh Terra->Solana 0.997 testa nonce 54 tested today (4/13). Steps 1-3 all pass (deposit, withdrawSubmit, operator approval). Execute fails with same token_mapping AccountNotInitialized (3012).
Hash: 0x50ce0a31c2b2d666d868b13fc02518a6be1f464bda6101f6c8715adc3048e4ea
Terra tx: BAF7C8E784D18825856A1002F2219C672FCAF7D624651AB8F0911DA192385B6B
mentioned in commit
2b2e6f6f8d@brouie Fix merged (frontend): Terra→Solana
withdraw_executewas building thetoken_mappingPDA from the wrong 32-byte value —queryTerraDepositexposesdest_token_address(the destination token word in the V2 hash, e.g. SPL mint), while SolanaTokenMapping/withdraw_submituseencode_token_addressof the locked Terra CW20/denom. The UI now resolves the mapping key viaresolveSolanaMappingSrcTokenKey(prefertransfer.token, skip raw0x+64 deposittokenfor cosmos), and when the record only has the SPL hex it loads the real Terra token id fromqueryTerraBridgeTransactionByNonceon Transfer Status + Verify pages. Please re-test Terra→Solana execute on staging/mainnet with a current build; if simulation succeeds, close #104.Issue is due to incorrect encoding of address when simulating the solana tx, fix incoming
Verified fixed on 4/13. Terra->Solana 1.819026 testa nonce 55 executed successfully with Phantom wallet. Tokens received (7.78903 testa total across 3 paths). Fix: commit
2b2e6f6corrected the token_mapping PDA derivation in the frontend. All 3 inbound Solana paths (BSC, opBNB, Terra) now pass E2E with Phantom.mentioned in commit
a8c2b2ed00