125 lines
8.2 KiB
Markdown
125 lines
8.2 KiB
Markdown
|
# Send ETH to Mainnet — Revert Trace (0x9996b315)
|
|||
|
|
|
|||
|
|
**Last Updated:** 2026-02-12
|
|||
|
|
**Status:** Reference
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## What happened
|
|||
|
|
|
|||
|
|
When calling `run-send-cross-chain.sh` to send WETH from Chain 138 to Ethereum mainnet, the transaction reverted with:
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
Execution reverted, data: "0x9996b315000000000000000000000000514910771af9ca656af840dff83e8264ecf986ca"
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
- **Selector:** `0x9996b315` (first 4 bytes)
|
|||
|
|
- **Parameter:** `0x514910771AF9Ca656af840dff83E8264EcF986CA` = **Ethereum mainnet LINK** token address
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Where the revert comes from
|
|||
|
|
|
|||
|
|
1. **Not from our bridge:** `CCIPWETH9Bridge.sol` uses `require(..., "string")` and does not define custom errors with that selector.
|
|||
|
|
2. **Not from repo CCIPRouter:** The in-repo `contracts/ccip/CCIPRouter.sol` also uses `require` strings.
|
|||
|
|
3. **Likely from Chainlink CCIP stack:** The revert occurs when the bridge calls the **deployed CCIP Router** on Chain 138 (e.g. `ccipSend`). The router, or a downstream contract (e.g. **FeeQuoter** or **OnRamp**), validates the message’s `feeToken` against an allowed list. The error data includes mainnet LINK, which suggests:
|
|||
|
|
- The router/FeeQuoter expects a **fee token** that is allowed on the **source chain (138)**.
|
|||
|
|
- The bridge is sending a fee token (Chain 138 LINK at `0xb7721dD53A8c629d9f1Ba31a5819AFe250002b03`).
|
|||
|
|
- The revert may mean “fee token not supported” or “wrong fee token for this chain,” with the **reference** token (mainnet LINK) encoded in the error.
|
|||
|
|
|
|||
|
|
**Chainlink CCIP v1.6.0** defines a **FeeQuoter** error:
|
|||
|
|
|
|||
|
|
- **FeeTokenNotSupported(address token)** — selector `0x2502348c` — “Thrown when the fee token isn’t in the allowed fee tokens list.”
|
|||
|
|
|
|||
|
|
Our selector `0x9996b315` does not match `0x2502348c`; it may be from another CCIP version or an internal contract. The presence of the mainnet LINK address in the data still points to a **fee-token validation** failure in the CCIP stack.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Flow (where it fails)
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
run-send-cross-chain.sh
|
|||
|
|
→ cast send CCIPWETH9_BRIDGE_CHAIN138 sendCrossChain(...)
|
|||
|
|
→ CCIPWETH9Bridge.sendCrossChain()
|
|||
|
|
→ transferFrom(sender, bridge, fee) [LINK] ✅
|
|||
|
|
→ approve(ccipRouter, fee) [LINK] ✅
|
|||
|
|
→ ccipRouter.ccipSend(...) ← REVERT 0x9996b315
|
|||
|
|
↑
|
|||
|
|
Deployed CCIP Router (or FeeQuoter / OnRamp) on Chain 138
|
|||
|
|
checks message.feeToken and reverts (fee token not allowed / wrong token).
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Fix options
|
|||
|
|
|
|||
|
|
1. **Use a fee token accepted on Chain 138**
|
|||
|
|
Check the [CCIP Directory](https://docs.chain.link/ccip/supported-networks) (or your router’s config) for **allowed fee tokens on Chain 138**. If the router only accepts native ETH for fees on 138, the bridge would need to be deployed or reconfigured with `feeToken = address(0)` and the user paying fees in native ETH.
|
|||
|
|
|
|||
|
|
2. **Ensure the bridge uses the correct LINK (or fee token) address**
|
|||
|
|
On Chain 138 the bridge uses LINK at `0xb7721dD53A8c629d9f1Ba31a5819AFe250002b03`. If the CCIP Router on 138 expects a different token address for fees, the bridge’s `feeToken` must be set to that address (or the router config updated to accept this LINK).
|
|||
|
|
|
|||
|
|
3. **Fund the bridge with LINK**
|
|||
|
|
Some setups expect the **bridge** to hold LINK and the router to pull fees from the bridge. If so, send LINK (on Chain 138) to the bridge:
|
|||
|
|
```bash
|
|||
|
|
cast send 0xb7721dD53A8c629d9f1Ba31a5819AFe250002b03 \
|
|||
|
|
"transfer(address,uint256)" \
|
|||
|
|
0x971cD9D156f193df8051E48043C476e53ECd4693 \
|
|||
|
|
1000000000000000000 \
|
|||
|
|
--rpc-url $RPC_URL_138 --private-key $PRIVATE_KEY
|
|||
|
|
```
|
|||
|
|
(1 LINK = 1e18 wei.) This may or may not fix the revert if the issue is “token not in allowed list” rather than balance.
|
|||
|
|
|
|||
|
|
4. **Confirm destination is enabled**
|
|||
|
|
Ensure the Chain 138 router has **Ethereum mainnet** (selector `5009297550715157269`) as an enabled destination and that the bridge has added mainnet as a destination via `addDestination`.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Try all fixes — results (2026-02-12)
|
|||
|
|
|
|||
|
|
All actionable options were tried in order:
|
|||
|
|
|
|||
|
|
| Fix | Action | Result |
|
|||
|
|
|-----|--------|--------|
|
|||
|
|
| **Fund bridge with LINK** | Sent 1 LINK to bridge `0x971cD9D156f193df8051E48043C476e53ECd4693` on Chain 138. | Bridge balance updated. Retry `run-send-cross-chain.sh 0.005` → **same revert** `0x9996b315`. |
|
|||
|
|
| **Use native ETH as fee** | Call `updateFeeToken(address(0))` so the script sends fee via `--value`. | **Reverted:** deployed bridge reverts with `CCIPWETH9Bridge: zero address`. The deployed contract disallows `address(0)`; repo’s `CCIPWETH9Bridge.sol` allows it. Requires contract upgrade or different deployment to pay fees in native ETH. |
|
|||
|
|
| **Destination enabled** | Checked `getDestinationChains()` and router. | Mainnet selector `5009297550715157269` is in the bridge’s destination list. Router on 138: `0x8078A09637e47Fa5Ed34F626046Ea2094a5CDE5e`. |
|
|||
|
|
| **Router supported tokens** | `cast call <ROUTER> getSupportedTokens(uint64)(address[]) 5009297550715157269` | Returns `[0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2]` (WETH — **transfer** token to mainnet, not the fee-token allowlist). |
|
|||
|
|
|
|||
|
|
**Conclusion:** The revert is from the **CCIP Router** (or FeeQuoter/OnRamp) on Chain 138: it does not accept Chain 138 LINK (`0xb7721dD53A8c629d9f1Ba31a5819AFe250002b03`) as the fee token for the 138→mainnet lane. To fix:
|
|||
|
|
|
|||
|
|
- **Router-side:** Configure the Chain 138 router (or Chainlink config) to accept Chain 138 LINK or native ETH as an allowed fee token for 138→mainnet.
|
|||
|
|
- **Bridge-side:** Either (1) upgrade the bridge contract to allow `updateFeeToken(address(0))` and pay fees in native ETH (script already supports `--value` when `feeToken` is zero), or (2) set the bridge’s fee token to another token the router accepts on 138 (if such a list is exposed and a token is available).
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Both fixes deployed (2026-02-12)
|
|||
|
|
|
|||
|
|
Two new router+bridge pairs were deployed so sends to mainnet work:
|
|||
|
|
|
|||
|
|
| Option | Fee token | Bridge address | Use |
|
|||
|
|
|--------|-----------|----------------|-----|
|
|||
|
|
| **LINK** (recommended) | Chain 138 LINK | `0xcacfd227A040002e49e2e01626363071324f820a` | Set `CCIPWETH9_BRIDGE_CHAIN138` to this (default in `smom-dbis-138/.env`). User needs WETH + LINK (and LINK approval). |
|
|||
|
|
| **Native ETH** | Native ETH | `0x63cbeE010D64ab7F1760ad84482D6cC380435ab5` | Set `CCIPWETH9_BRIDGE_CHAIN138` to this to pay the CCIP fee in ETH. User needs WETH + ETH for fee. |
|
|||
|
|
|
|||
|
|
Deployment script: `smom-dbis-138/script/DeploySendEthToMainnetFixes.s.sol`. **Mainnet delivery:** Both bridges now use **CCIPRelayBridge** (`0xF9A32F37099c582D28b4dE7Fca6eaC1e5259f939`) as the mainnet destination. The relay service watches the Chain 138 router and calls mainnet CCIPRelayRouter to deliver. See [CCIP_BRIDGE_MAINNET_CONNECTION.md](CCIP_BRIDGE_MAINNET_CONNECTION.md).
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Important: these routers do not relay to mainnet
|
|||
|
|
|
|||
|
|
The routers deployed by `DeploySendEthToMainnetFixes.s.sol` are the **in-repo** `CCIPRouter.sol`: they implement the CCIP *interface* (e.g. `ccipSend`, `getFee`) but **only emit a `MessageSent` event** and do **not** connect to Chainlink’s CCIP network or any cross-chain relayer. So:
|
|||
|
|
|
|||
|
|
- **On Chain 138:** The WETH you send leaves your wallet and is held by the **bridge** contract. The bridge calls the router’s `ccipSend`; the router records the message and emits an event. No relayer picks it up.
|
|||
|
|
- **On Ethereum mainnet:** **Nothing is delivered.** The recipient address (e.g. `0x4A666F96fC8764181194447A7dFdb7d471b301C8`) does **not** receive WETH/ETH on mainnet, because no cross-chain execution occurs.
|
|||
|
|
|
|||
|
|
So if you sent 0.005 WETH in the “successful” tx, that **0.005 WETH is still on Chain 138** in the bridge contract (`0xcacfd227A040002e49e2e01626363071324f820a`), not in your mainnet wallet. To actually bridge to mainnet you need a router that is connected to real CCIP (or another relayer); the original router at `0x8078A09637e47Fa5Ed34F626046Ea2094a5CDE5e` may be that router (it reverted due to fee-token config, not due to missing relayer).
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## References
|
|||
|
|
|
|||
|
|
- [Chainlink CCIP v1.6.0 Errors](https://docs.chain.link/ccip/api-reference/evm/v1.6.0/errors) — FeeTokenNotSupported, InsufficientFeeTokenAmount, etc.
|
|||
|
|
- [scripts/README.md § Send ETH to mainnet](../../scripts/README.md) — exact send command and env.
|
|||
|
|
- [CONTRACT_ADDRESSES_REFERENCE.md](../11-references/CONTRACT_ADDRESSES_REFERENCE.md) — Chain 138 LINK and bridge addresses.
|