Bug: Operator does not execute withdrawals on Solana (no Solana watcher)

Brouie commented

2026-04-09 05:59:32 +00:00

(Migrated from gitlab.com)

Mainnet v0.1.82 (3803318)

Current behavior: All 3 Solana-destination transfers stuck at Approved. Deposit succeeds on source chain, withdrawSubmit succeeds on Solana, operator approves, but operator never calls withdraw_execute on Solana. Transfers remain stuck at step 3/4 indefinitely.

Affected transfers:

Terra->Solana 1.994 testa nonce 52: 0x12b359b812c0e805f11db39d4e421268134d7e9bc31aefc9ff5b481c245ff7a7
BSC->Solana 0.995 testa: 0x0e2dd145bdff038bbb62abad831ea0f30f2bdf38eb39f19bf7746774cb9e20c9
opBNB->Solana 0.995 testa: 0x4a5d02bf805b91915c14535df9bab12bfd683d6d1c4d3f5cf197cae4570671e7

Expected behavior: Operator should watch Solana bridge program for approved withdrawals and execute them after cancel window, same as it does for EVM and Terra destinations.

Context: Same pattern observed on devnet -- operator watches EVM + Terra only. No Solana watcher or withdraw_execute implementation for Solana destination.

Wallets tested: Backpack (Solana), MetaMask (BSC/opBNB), Terra Station (Terra)

Acceptance criteria:

Operator watches Solana bridge for approved withdrawals
Operator calls withdraw_execute on Solana after cancel window
Solana-destination transfers complete end-to-end

**Mainnet v0.1.82 (3803318)** **Current behavior:** All 3 Solana-destination transfers stuck at Approved. Deposit succeeds on source chain, withdrawSubmit succeeds on Solana, operator approves, but operator never calls withdraw_execute on Solana. Transfers remain stuck at step 3/4 indefinitely. **Affected transfers:** - Terra->Solana 1.994 testa nonce 52: 0x12b359b812c0e805f11db39d4e421268134d7e9bc31aefc9ff5b481c245ff7a7 - BSC->Solana 0.995 testa: 0x0e2dd145bdff038bbb62abad831ea0f30f2bdf38eb39f19bf7746774cb9e20c9 - opBNB->Solana 0.995 testa: 0x4a5d02bf805b91915c14535df9bab12bfd683d6d1c4d3f5cf197cae4570671e7 **Expected behavior:** Operator should watch Solana bridge program for approved withdrawals and execute them after cancel window, same as it does for EVM and Terra destinations. **Context:** Same pattern observed on devnet -- operator watches EVM + Terra only. No Solana watcher or withdraw_execute implementation for Solana destination. **Wallets tested:** Backpack (Solana), MetaMask (BSC/opBNB), Terra Station (Terra) **Acceptance criteria:** - [ ] Operator watches Solana bridge for approved withdrawals - [ ] Operator calls withdraw_execute on Solana after cancel window - [ ] Solana-destination transfers complete end-to-end

Brouie commented

2026-04-09 06:00:08 +00:00

(Migrated from gitlab.com)

mentioned in issue #102

PlasticDigits commented

2026-04-09 06:53:49 +00:00

(Migrated from gitlab.com)

@brouie

I've confrimed these have not been submitted to verification eg
https://bridge.cl8y.com/verify?hash=0x12b359b812c0e805f11db39d4e421268134d7e9bc31aefc9ff5b481c245ff7a7
https://bridge.cl8y.com/verify?hash=0x0e2dd145bdff038bbb62abad831ea0f30f2bdf38eb39f19bf7746774cb9e20c9
https://bridge.cl8y.com/verify?hash=0x4a5d02bf805b91915c14535df9bab12bfd683d6d1c4d3f5cf197cae4570671e7

All show "Hash not submnitted to destination" and "submit hash now" button

@brouie I've confrimed these have not been submitted to verification eg https://bridge.cl8y.com/verify?hash=0x12b359b812c0e805f11db39d4e421268134d7e9bc31aefc9ff5b481c245ff7a7 https://bridge.cl8y.com/verify?hash=0x0e2dd145bdff038bbb62abad831ea0f30f2bdf38eb39f19bf7746774cb9e20c9 https://bridge.cl8y.com/verify?hash=0x4a5d02bf805b91915c14535df9bab12bfd683d6d1c4d3f5cf197cae4570671e7 All show "Hash not submnitted to destination" and "submit hash now" button

PlasticDigits commented

2026-04-09 08:44:12 +00:00

(Migrated from gitlab.com)

@brouie Could you verify the Solana withdrawal flow and help align the Solana QA checklist?

Solana withdraws are different from EVM/Terra: the recipient must call withdraw_execute (it is not the model where the operator runs withdrawExecute after approve on behalf of the user).

Expected flow

Deposit on the source chain.
withdraw_submit on Solana (destination) — submit the withdrawal hash.
Operator calls withdraw_approve on Solana.
Recipient (end user) must sign withdraw_execute (SPL) or withdraw_execute_native (native SOL) using the same Solana wallet that was set as the recipient / destAccount in the original transfer (step 1 / hash).

Please confirm this matches what you see on-chain and in operator tooling.

Request: update or extend the Solana QA checklist for withdrawals so QA explicitly checks that, after operator approval and once the withdraw delay / cancel window has passed, the user completes the leg by calling withdraw_execute from the recipient wallet — not only “operator executed.”

Thanks!

@brouie Could you **verify the Solana withdrawal flow** and help align the Solana QA checklist? **Solana withdraws are different from EVM/Terra:** the **recipient must call `withdraw_execute`** (it is not the model where the operator runs `withdrawExecute` after approve on behalf of the user). **Expected flow** 1. **Deposit** on the source chain. 2. **`withdraw_submit`** on **Solana** (destination) — submit the withdrawal hash. 3. **Operator** calls **`withdraw_approve`** on Solana. 4. **Recipient (end user)** must sign **`withdraw_execute`** (SPL) or **`withdraw_execute_native`** (native SOL) using the **same Solana wallet** that was set as the **recipient / `destAccount`** in the original transfer (step 1 / hash). Please confirm this matches what you see on-chain and in operator tooling. **Request:** **update or extend the Solana QA checklist for withdrawals** so QA explicitly checks that, after operator approval and once the withdraw delay / cancel window has passed, the **user** completes the leg by calling **`withdraw_execute`** from the **recipient** wallet — not only “operator executed.” Thanks!

Brouie commented

2026-04-10 02:39:35 +00:00

(Migrated from gitlab.com)

Retested on build 7cb18b3 (4/10). 3 fresh Solana-destination transfers all stuck at Pending -- operator not approving.

Fresh transfers (4/10):

Terra->Solana 0.997 testa nonce 53: 0xfda305a034140568d70e836b9c2f56c140cc7a06b7905f87f2cd5a6de5e48b4
BSC->Solana 0.995 testa nonce 41: 0xf443ffa5d976107d57072ba52e91bc3f4c10c049d311acf00ae5806a5611d98b
opBNB->Solana 0.995 testa nonce 17: 0x08dfd2dcd71637916e08e839656d4e3cd008d11891fe79160d4a0e69e8b24c1f

All 3: deposit OK, withdrawSubmit OK (auto-submit worked), hash matches on verify page, but State remains Pending. 10+ min elapsed, no operator approval.

Same pattern as the 3 stuck transfers from 4/9 (nonces 52, old BSC, old opBNB). Operator Solana watcher still not picking up submitted withdrawals.

Also noted: Submitted timestamp shows 1/1/1970, 8:00:01 AM on all Solana-destination verify pages (epoch zero).

Additional frontend finding: SolanaRecipientExecutePanel polls api.mainnet.solana.com via setInterval and gets repeated 403s. The bridge Connection RPC works for tx submission but read/polling calls still hit the wallet default RPC. Related to #102.

Retested on build 7cb18b3 (4/10). 3 fresh Solana-destination transfers all stuck at Pending -- operator not approving. **Fresh transfers (4/10):** - Terra->Solana 0.997 testa nonce 53: 0xfda305a034140568d70e836b9c2f56c140cc7a06b7905f87f2cd5a6de5e48b4 - BSC->Solana 0.995 testa nonce 41: 0xf443ffa5d976107d57072ba52e91bc3f4c10c049d311acf00ae5806a5611d98b - opBNB->Solana 0.995 testa nonce 17: 0x08dfd2dcd71637916e08e839656d4e3cd008d11891fe79160d4a0e69e8b24c1f All 3: deposit OK, withdrawSubmit OK (auto-submit worked), hash matches on verify page, but State remains Pending. 10+ min elapsed, no operator approval. Same pattern as the 3 stuck transfers from 4/9 (nonces 52, old BSC, old opBNB). Operator Solana watcher still not picking up submitted withdrawals. **Also noted:** Submitted timestamp shows 1/1/1970, 8:00:01 AM on all Solana-destination verify pages (epoch zero). **Additional frontend finding:** SolanaRecipientExecutePanel polls api.mainnet.solana.com via setInterval and gets repeated 403s. The bridge Connection RPC works for tx submission but read/polling calls still hit the wallet default RPC. Related to #102.

PlasticDigits commented

2026-04-13 03:58:04 +00:00

(Migrated from gitlab.com)

@brouie Triage (repo main): Solana destination payouts are recipient-signed withdraw_execute (see UI copy in SolanaRecipientExecutePanel), not operator-broadcast execute like EVM/Terra. The operator does run withdraw_approve via SolanaWriter (on-chain PendingWithdraw discovery + source verification). SolanaWatcher indexes Solana-as-source deposits only. So the acceptance criterion “operator calls withdraw_execute on Solana” does not match protocol design; the missing approve automation from the report is what SolanaWriter covers. Please confirm approve + recipient execute on your environment and close or narrow the issue if satisfied.

@brouie Triage (repo `main`): Solana **destination** payouts are **recipient-signed** `withdraw_execute` (see UI copy in `SolanaRecipientExecutePanel`), not operator-broadcast execute like EVM/Terra. The operator **does** run `withdraw_approve` via `SolanaWriter` (on-chain `PendingWithdraw` discovery + source verification). `SolanaWatcher` indexes Solana-as-**source** deposits only. So the acceptance criterion “operator calls withdraw_execute on Solana” does not match protocol design; the missing approve automation from the report is what `SolanaWriter` covers. Please confirm approve + recipient execute on your environment and close or narrow the issue if satisfied.

Brouie commented

2026-04-13 04:05:32 +00:00

(Migrated from gitlab.com)

mentioned in issue #105

Brouie commented

2026-04-13 05:05:15 +00:00

(Migrated from gitlab.com)

Confirmed fixed on 4/13. Tested all 3 inbound Solana paths (BSC, opBNB, Terra). Operator auto-discovers and approves all withdrawals. Nonces 42 (BSC), 20 (opBNB), 54 (Terra) all reached Approved state. Commits 4b62f97, 63784df, e89b7ea fixed the on-chain state polling and Base64 memcmp.

Confirmed fixed on 4/13. Tested all 3 inbound Solana paths (BSC, opBNB, Terra). Operator auto-discovers and approves all withdrawals. Nonces 42 (BSC), 20 (opBNB), 54 (Terra) all reached Approved state. Commits 4b62f97, 63784df, e89b7ea fixed the on-chain state polling and Base64 memcmp.

Brouie (Migrated from gitlab.com) closed this issue

2026-04-13 05:05:40 +00:00

PlasticDigits commented

2026-05-01 03:00:11 +00:00

(Migrated from gitlab.com)

mentioned in commit 05d37aaebe

mentioned in commit 05d37aaebeca1438e4ee1cb7ac52f9d47604a800

PlasticDigits commented

2026-05-01 03:00:12 +00:00

(Migrated from gitlab.com)

mentioned in issue #126