code/cl8y-bridge-monorepo

Fork 0

Bug: Terra->Solana auto-withdraw fails — token format not recognized as SPL mint #94

New issue

Closed

opened 2026-04-01 04:14:23 +00:00 by Brouie · 8 comments

Brouie commented

2026-04-01 04:14:23 +00:00

(Migrated from gitlab.com)

LocalTerra->Solana Localnet deposit succeeds on Terra, but auto-withdraw on Solana fails with: 'Solana withdrawSubmit requires a 32-byte or 20-byte hex token in the transfer record (EVM source)'

the terra deposit receipt stores the token as a bytes32 hash (0xc0d84a8656abb91b...) which the Solana withdraw path can't parse into an SPL mint address.

same issue seen on both Terra->Solana and (from earlier session) any path where destination is Solana and source is non-EVM.

transfer details:

destChain: Solana Localnet (0x00000005)
nonce: 2
amount: 995000000
token(bytes32): 0xc0d84a8656abb91bf2d70e969939c78c81a605898aa8b5949e03d18800827ad9

LocalTerra->Anvil and LocalTerra->Anvil1 both work fine (4/4). Solana->Anvil also works (4/4 via Backpack).

commit 003bf31, laptop Vite workflow.

LocalTerra->Solana Localnet deposit succeeds on Terra, but auto-withdraw on Solana fails with: 'Solana withdrawSubmit requires a 32-byte or 20-byte hex token in the transfer record (EVM source)' the terra deposit receipt stores the token as a bytes32 hash (0xc0d84a8656abb91b...) which the Solana withdraw path can't parse into an SPL mint address. same issue seen on both Terra->Solana and (from earlier session) any path where destination is Solana and source is non-EVM. transfer details: - destChain: Solana Localnet (0x00000005) - nonce: 2 - amount: 995000000 - token(bytes32): 0xc0d84a8656abb91bf2d70e969939c78c81a605898aa8b5949e03d18800827ad9 LocalTerra->Anvil and LocalTerra->Anvil1 both work fine (4/4). Solana->Anvil also works (4/4 via Backpack). commit 003bf31, laptop Vite workflow.

Brouie commented

2026-04-01 04:55:08 +00:00

(Migrated from gitlab.com)

mentioned in issue #67

Brouie commented

2026-04-01 04:55:41 +00:00

(Migrated from gitlab.com)

mentioned in issue #96

PlasticDigits commented

2026-04-01 11:42:22 +00:00

(Migrated from gitlab.com)

mentioned in commit ca3c6eb045

mentioned in commit ca3c6eb045c3c9146b4f4413916fc29f51256496

PlasticDigits commented

2026-04-01 11:42:28 +00:00

(Migrated from gitlab.com)

Fix pushed on feat/solana-integration (commit ca3c6eb).

Cause: TransferRecord.token for Terra deposits is a denom string (e.g. uluna) or CW20 terra1…, while useAutoWithdrawSubmit only treated 0x EVM-style tokens as valid for Solana srcToken.

Change: resolveWithdrawSrcTokenBytesForSolana maps EVM hex + Terra encode_token_address rules (shared with terraTokenEncoding). Terra receipt denom is preferred when recording the transfer.

Fix pushed on `feat/solana-integration` (commit ca3c6eb). **Cause:** `TransferRecord.token` for Terra deposits is a denom string (e.g. `uluna`) or CW20 `terra1…`, while `useAutoWithdrawSubmit` only treated `0x` EVM-style tokens as valid for Solana `srcToken`. **Change:** `resolveWithdrawSrcTokenBytesForSolana` maps EVM hex + Terra `encode_token_address` rules (shared with `terraTokenEncoding`). Terra receipt denom is preferred when recording the transfer.

Brouie commented

2026-04-02 04:33:12 +00:00

(Migrated from gitlab.com)

still reproducing on 02d8e6a. tested Terra->Solana with TKNA via Keplr->Backpack.

deposit on Terra succeeds (step 1 done), but submit hash fails with: "Solana withdrawSubmit requires a 32-byte or 20-byte hex token in the transfer record (EVM source)".

console shows destToken=0x836b1c00488e2cb1... which is a keccak hash, not a raw Solana mint pubkey (32 bytes). the resolveWithdrawSrcTokenBytes fix (ca3c6eb) cant resolve this because the underlying token mapping is encoded wrong.

same root cause as #89 -- token registration writes keccak256(address_string) instead of raw bytes (bech32-decoded left-padded for CW20, raw pubkey bytes for Solana mints). needs the registration encoding fix first, then both #89 and #94 should resolve together.

still reproducing on 02d8e6a. tested Terra->Solana with TKNA via Keplr->Backpack. deposit on Terra succeeds (step 1 done), but submit hash fails with: "Solana withdrawSubmit requires a 32-byte or 20-byte hex token in the transfer record (EVM source)". console shows destToken=0x836b1c00488e2cb1... which is a keccak hash, not a raw Solana mint pubkey (32 bytes). the resolveWithdrawSrcTokenBytes fix (ca3c6eb) cant resolve this because the underlying token mapping is encoded wrong. same root cause as #89 -- token registration writes keccak256(address_string) instead of raw bytes (bech32-decoded left-padded for CW20, raw pubkey bytes for Solana mints). needs the registration encoding fix first, then both #89 and #94 should resolve together.

PlasticDigits commented

2026-04-02 12:05:13 +00:00

(Migrated from gitlab.com)

mentioned in commit bc288606e3

mentioned in commit bc288606e3471a7486a779518b846a490eaf37b5

Brouie commented

2026-04-04 01:57:23 +00:00

(Migrated from gitlab.com)

VERIFIED on 84c8df3. Terra->Solana deposit succeeds, submitOnSolana returns successful tx (3QHANbz...). the token encoding fix resolved the format mismatch. pending cancel window + operator execution to confirm full 4/4.

VERIFIED on 84c8df3. Terra->Solana deposit succeeds, submitOnSolana returns successful tx (3QHANbz...). the token encoding fix resolved the format mismatch. pending cancel window + operator execution to confirm full 4/4.

Brouie commented

2026-04-04 03:19:50 +00:00

(Migrated from gitlab.com)

closing -- verified on 84c8df3, token format fix works. Terra->Solana deposits resolve correctly now.

closing -- verified on 84c8df3, token format fix works. Terra->Solana deposits resolve correctly now.

Brouie (Migrated from gitlab.com) closed this issue

2026-04-04 03:19:51 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

code/cl8y-bridge-monorepo#94

No description provided.

Rows
Columns