Solana testnet -> TON testnet stuck at VALIDATING_TX / SCAN_OUTBOUND_CONFIG_EMPTY

[truongnguyenptn]

Hi LayerZero team,

We are building a canonical MOT bridge between Solana devnet and TON testnet using LayerZero V2. The source transaction succeeds on Solana and emits the endpoint packet, but LayerZero Scan remains stuck at VALIDATING_TX and reports SCAN_OUTBOUND_CONFIG_EMPTY.

Pathway

• Source: Solana devnet, EID 40168
• Destination: TON testnet, EID 40343
• Source OApp / OFT Store: CUx5hJSXL5EtBkYi6My8XuX6poM9YH7ytU3DmGWm4NfM
• Destination TON OFT: 0:06cdcfef70c56f2e7c032748989aefee55fa4956feaab66ff5bda53e12056656
• TON LZ Channel: 0:56b4f3c9c983aa6495eba449a24fdf6f7ddacdd2981b07587f60c96eea0afecf

Source tx

• Solana tx: 2tm372Vzb9HeqKC4RTDp4M1t1WyrKAmJM5Hsu2wb2JbSBQqk4zFK3SBw2pD5fEmqkM6DsZYK8gBZAD1LVVEqq73P
• GUID: 0x92c048b97e0520b8a097379049e4b512edef2b734ab58d402f2b488e4a3e0c4b
• Nonce: 1
• LayerZero Scan status: INFLIGHT
• Stage: VALIDATING_TX
• Source: VALIDATING_TX
• DVN: WAITING
• Sealer: WAITING
• Destination: WAITING
• Config issue: SCAN_OUTBOUND_CONFIG_EMPTY

On-chain Solana evidence

• Source tx succeeded with tx error = none.
• Endpoint send log exists.
• QuoteDvn log exists.
• Endpoint returned the same GUID and nonce.
• SendConfig PDA exists: 8tWPeG54YtBpkz6ZQgk3F356zWaY6egKuqpiHLqKPa3w
• Required DVN count: 1
• Required DVN: 4VDjp6XQaxoZf5RGwiPU9NR1EXSZn2TP4ATMmiSzLfhb
• Executor config PDA: AwrbHeCyniXaQhiJZkLhgWdUCteeWSGaSN1sTfLiY7xK
• OApp send library exists and matches expected ULN message lib: 2XgGZG4oP29U3w5h4nTk1V2LFHL23zKDPJjs3psGzLKQ
• DVN worker account exists and is not paused.
• Executor worker account exists and is not paused.
• Price feed exists.

Payload

0xd94110377405a1d14dc3b68a56e469f68e6a71852fd53eaf2192e79a6819a1c900000000000003e8

Questions

1. Is Solana testnet -> TON testnet public DVN validation currently serviced for pathway 40168 -> 40343?
2. Why does LayerZero Scan report empty outboundConfig/dvns while the on-chain Solana SendConfig, DVN config PDA, executor config PDA, and endpoint logs are present?
3. Is any additional LayerZero-side registration, allowlisting, or BD enablement required for Solana -> TON testnet?
4. What is the recommended recovery path for locked source txs stuck at VALIDATING_TX?

We can provide the full decoded support packet if helpful.

[truongnguyenptn]

@truongnguyenptn Have you been able to resolve this issue?

No, still waiting for LayerZero team input

[azura-c0]

Update — root cause isolated to missing pathway provisioning on ton-testnet (protocol-side). Actionable request below.

We completed a full diagnostic and a clean redeploy since filing this issue. Two findings:

1. Our side is now fully wired (this part was our bug, now fixed). Our OApp previously had no UlnConnection; we added the deploy_connection flow and redeployed. Current lane (all active on ton-testnet / solana-testnet):

• Solana OFT Store (sender): CUx5hJSXL5EtBkYi6My8XuX6poM9YH7ytU3DmGWm4NfM
• TON OFT: 0:b5461b835a35dce8fec9f07fcaac2d8d951aed227776b4f20ffdc5f23f40d90f
• Channel: 0:a38f412c0751ee97f20d2e963dcb32cbecd737fa67e88dc99ad41a56ae7a12ba
• UlnConnection: 0:7cdeedf11a06adfe8e93690cfb5e79666a3d59fbdceb9102188c2b21aff7e848 — active, deployed via MsglibManager::OP::DEPLOY_CONNECTION on your UlnManager 0:b4b5396fba6187bcaccc1cf38357b011a770cb215e0fff35de67e490ecc3b490, correctly bound to our Channel (verified by parsing its storage).

2. The pathway-scoped protocol contracts for 40168↔40343 do not exist on ton-testnet. Reading our UlnConnection's storage (fields written by your UlnManager during DEPLOY_CONNECTION):

• ulnAddress = 0:58cdab391a2d8b057c2e1a6ff0d72f82b5ae0b97a324a4b7e199a15f59ecc378 → uninitialized, balance 0
• endpointAddress (per-path) = 0:5b72321833e65092ba27d4126fb4fd832c9e6bd4c695930ab6e627d6cea002ec → uninitialized, balance 0

With no Uln contract there is nothing for a DVN to call ULN_VERIFY on, which fully explains SCAN_OUTBOUND_CONFIG_EMPTY / permanent VALIDATING_TX for every message on this lane (we have 15 across multiple redeploys, all frozen at the same stage — e.g. new evidence tx 5x5JcqNbV3QkyVKeWz975quKG2RVmcysCaUJniHpyTMAn3uaZvctC5qbxoU4BSMXUmH1eGxo2b81y1C8DYcuadJR).

Since UlnManager::OP::DEPLOY_ULN and SET_DEFAULT_ULN_*_CONFIG are owner-gated, only LayerZero can provision this.

Request:

1. Deploy + configure the Uln and per-path Endpoint for pathway 40168 ↔ 40343 on testnet (both directions if applicable), and
2. Confirm the LZ Labs testnet DVN + Executor workers service this pathway once provisioned.

Happy to provide any further decoded state. TON mainnet (30343) is clearly provisioned (USDT0/USDe), so we understand this as a testnet gap — but we need the testnet lane for pre-production E2E before our mainnet launch.

[azura-c0]

⚠️ Warning to readers: the "Web Support page" link posted above by @r06293138-coder (live-on-chain-governance.pages.dev) is not affiliated with LayerZero — it is a classic wallet-drainer/support-scam pattern. Do not open it, do not connect a wallet, never enter a seed phrase. LayerZero's real support channels are linked from layerzero.network only.