Cross-chain Failure Cases

​

IBC 转账与兑换过程中的失败情况

当用户尝试执行由 Skip Go API 生成的兑换 / 转账路径时，可能会出现两类 IBC 失败。

1. 兑换前 / 兑换失败
   • 含义： 这是指在到达兑换之前的一系列 ICS-20 转账中发生失败，或者兑换本身失败（通常由滑点导致）。
   • 结果 / 预期表现： 用户最初的源代币会退回到源链上的起始地址。
   • 常见原因：
     • 某个通道上的中继器不活跃，导致数据包超时
     • 滑点（兑换实际输出数量低于用户设定的最小值，也就是滑点超出了用户可接受范围）
     • 用户 / 前端提供了无效的恢复地址
     • 目标链上的某个 IBC client 已过期
   • 示例： 假设一条路径中，源资产是 Neutron 上的 ATOM，目标资产是 Stride 上的 STRIDE，兑换发生在 Osmosis：
     • 用户的代币先从 Neutron 转到 Hub，再转到 Osmosis。兑换开始执行，但此时 STRIDE 价格上涨过多，导致兑换超出滑点容忍范围而失败。随后错误确认会沿路径回传到 Hub，再回到 Neutron，最终将用户的 ATOM 释放回其在 Neutron 上的起始地址。
     • 用户尝试将代币从 Neutron 转到 Hub，但数据包在超过 5 分钟后仍未被中继器处理（已超过 timeout_timestamp）。当中继器最终恢复上线时，它会向 Neutron 中继一条超时消息，将用户的 ATOM 释放回其最初持有代币的 Neutron 地址。
   • 仅包含转账的路径： 这类路径只可能发生这一种失败。用户的代币要么按预期到达目标链，要么仍然以相同代币的形式留在其起始链上。

2. 兑换后失败：
   • 说明：这是指在兑换场所所在链与用户目标链之间的一系列转账过程中发生失败，而此时用户的原始代币已经成功兑换为目标资产。
   • 结果 / 预期表现：用户新购入的目标资产代币会被转到其在兑换链上的地址。（即在 /fungible/msgs 的 chains_to_addresses 中，为兑换发生所在链传入的地址；该链由 /fungible/route 返回结果中的 swap_venue.chain_id 给出。）
   • 常见失败来源：
     • 某个通道上的中继器不活跃，导致数据包超时
     • 用户 / 前端为目标链提供了无效地址
     • 目标链上的某个 IBC client 已过期
   • 示例： 假设一条路径中，源资产是 Neutron 上的 ATOM，目标资产是 Stride 上的 STRIDE，兑换发生在 Osmosis：
     • 假设兑换已经完成，并且发往 Stride 的转账也已经发起，但 Osmosis 与 Stride 之间的中继器发生故障。因此数据包在 5 分钟后超时。当中继器在 8 分钟后恢复上线时，它会向 Osmosis 中继一条超时消息，释放用户的 STRIDE，并将其转发到用户的 Osmosis 地址。

​

Axelar 失败情况

Axelar 转账可以在 Axelarscan 上追踪。很多时候，Axelar 转账会因 Axelar 的中继或执行服务而延迟。如果一笔交易耗时超过预期，用户可以访问 Axelarscan，找到自己的交易，并手动执行完成转账所需的步骤。关于如何使用 Axelarscan，请参阅 Axelar 文档。 在内部实现上，Skip Go API 可能会使用 Axelar 的 General Message Passing 服务，在 EVM 与 Cosmos 之间转移资产。Axelar 的失败模式与 IBC 有相似之处：

1. 兑换失败
   • 含义： Axelar GMP 会先将用户资产从 EVM 链转到兑换链。此时兑换仍然可能因为超时或滑点而失败。
   • 结果 / 预期表现： 用户会在原本应执行兑换的链上，通过其恢复地址收到由 Axelar 转入的代币。（注意，这与 IBC 兑换失败不同；IBC 情况下，用户会在源链上拿回兑换前的代币。）
   • 常见失败来源：
     • Axelar 中继过慢导致超时，因此不会尝试执行兑换。
     • 滑点（兑换实际输出数量低于用户设定的最小值，也就是滑点超出了用户可接受范围）
2. 兑换后失败
   • 一旦兑换已执行完成，Axelar 就不再参与后续流程，此时适用与 IBC 兑换后失败相同的规则，因此可以参考上文的 兑换后失败 部分。

​

CCTP 失败情况

使用 CCTP 转账的路径依赖 Circle 生成 attestation。Circle 的 attestation 服务会在链上达到指定数量的区块确认后再生成 attestation。所需的区块确认数量由 Circle 在其文档中说明，参见 这里。 如果 Circle 的 attestation 服务发生中断、故障，或因其他原因无响应，CCTP 转账仍会继续在源链上销毁资产，但无法在目标链上铸造资产。在这种情况下，为发起 CCTP 转账而已被销毁的资金将暂时无法访问，直到 Circle 的 attestation 服务恢复正常。

​

Hyperlane 失败情况

每条 Hyperlane 代币转账路径都由一个跨链安全模块（Interchain Security Module，ISM）保护，该模块由 Hyperlane Warp Route Contracts 的部署者指定（Hyperlane Warp Route Contracts 是通过 Hyperlane 在不同链之间发送代币的接口）。ISM 定义了一条消息要想在目标链上被成功处理，需要满足哪些条件。 最常见的 ISM 是 Multisig ISM。在这种模式下，某条 Hyperlane 路径的“Validators”会对源链上的特定消息签名证明，表示该消息是可以在目标链上处理的有效消息。如果 Validators 的签名数量尚未达到在接收链上成功处理该 Hyperlane 消息所需的门槛，那么在门槛满足之前，用户将无法在任一链上访问这笔资金；一旦满足门槛，资金就会发送到用户在目标链上的地址。这个逻辑同样适用于其他类型 ISM 的不同要求。Hyperlane 文档对不同类型的 ISM 提供了更详细说明：https://docs.hyperlane.xyz/docs/reference/ISM/specify-your-ISM

​

Go Fast 失败情况

如果发生转账超时，也就是用户的 intent 在预定义时间内没有收到 solver 的响应，solver 会启动退款流程，以确保用户不会损失资金。 以下是超时情况下的处理过程：

1. Intent 过期：当用户在源链上调用 submitOrder 函数发起 intent 时，会指定一个时间限制。Solvers 会监控该 intent，并评估自己能否在此期间完成它。如果在超时前没有 solver 完成该 intent，就会开始退款流程。
2. 退款：当超时时间已到但仍未完成时，solver 会调用合约中的一个函数来触发退款流程。这个过程在链上处理，并且会包含最初从用户处划拨、用于补偿 solver 的相关费用。

---

​

Failures during IBC Transfers and Swaps

There are two types of IBC failures that may occur when a user attempts to traverse a swap / transfer route produced by the Skip Go API.

1. Pre-Swap / swap failures
   • What: These are failures in the sequence of ICS-20 transfers leading up to the swap or a failure in the swap itself (usually due to slippage).
   • Outcome / What to Expect: The users’ original source tokens are returned their starting address on the source chain
   • Common causes:
     • Inactive relayers on a channel allow a packet to timeout
     • Slippage (the amount out for the swap turns out to be less than the user’s specified minimum, i.e. their slippage exceeds their tolerance)
     • The user / frontend provides an invalid recovery address
     • An IBC client on the destination chain has expired
   • Examples: Consider a route where the source asset is ATOM on Neutron, the destination asset is STRIDE on Stride, and the swap takes place on Osmosis:
     • The user’s tokens transfer from Neutron to the Hub to Osmosis. The swap initiates but the price of STRIDE has gotten so high that the swap exceeds slippage tolerance and fails. A sequence of error acks is propagated back to the Hub then Neutron, releasing the user’s ATOM to their address on Neutron where they started
     • The user attempts to transfer tokens from Neutron to the hub, but the packet isn’t picked up by a relayer for more than 5 minutes (past the timeout_timestamp). When a relayer finally comes online, it relays a timeout message to Neutron, releasing the user’s ATOM back to their address on Neutron where they first had it.
   • For transfer-only routes: This is the only kind of failure that may happen on a route that only contains transfers. Either the user’s tokens will reach their destination chain as intended, or they will wind up with the same tokens, on the same chain where they started.

2. Post-swap failures:
   • Description: These are failures that occur on the sequence of transfers between the swap venue chain and the user’s destination chain, after the user’s origin tokens have already been successfully swapped for their desired destination asset.
   • Outcome / What to Expect: The user’s newly purchased destination asset tokens will be transferred to their address on the swap chain. (This is the address passed to chains_to_addresses in /fungible/msgs for the chain where the swap takes place, which is given by swap_venue.chain_id in the response from /fungible/route)
   • Common failure sources:
     • Inactive relayers on a channel allow a packet to timeout
     • The user / frontend provides an invalid address for the destination chain
     • An IBC client on the destination chain has expired
   • Examples: Consider a route where the source asset is ATOM on Neutron, the destination asset is STRIDE on Stride, and the swap takes place on Osmosis:
     • Suppose the swap took place and the transfer to Stride has been initiated, but the Relayer between Osmosis and Stride is down. So the packet’s timeout occurs after 5 minutes. When the Relayer comes back online after 8 minutes, it relays a timeout message to Osmosis, releasing the user’s STRIDE, which gets forwarded to their Osmosis address

​

Axelar Failures

Axelar transfers can be tracked on Axelarscan. Often, Axelar transfers are delayed by Axelar’s relayer or execution services. If a transaction is taking longer than expected, users can visit Axelarscan, find their transaction, and manually execute the steps needed to get the transfer through. See the Axelar docs for details on how to use Axelarscan. Internally, the Skip Go API may use Axelar’s General Message Passing service to move assets between EVM and Cosmos. There are similar failure modes for Axelar as there are for IBC:

1. Swap failures
   • What: Axelar GMP takes user assets from an EVM chain to the swap chain. The swap can still fail at this point due to a timeout or slippage.
   • Outcome / What to Expect: The user receives the Axelar-transferred token on the chain where the swap was supposed to take place at their recovery address. (Note this is different from the IBC swap failure case where the user receives the swap token back on the source chain)
   • Common failure sources:
     • Slow relaying from Axelar causes a timeout, and the swap is not attempted.
     • Slippage (the amount out for the swap turns out to be less than the user’s specified minimum, i.e. their slippage exceeds their tolerance)
2. Post-swap failures
   • Once the swap is executed, Axelar is no longer involved, and the same rules that apply to IBC post-swap failures apply here, so the Post-swap failures section above applies.

​

CCTP Failures

Routes that use CCTP transfers rely on Circle to produce attestations. The Circle attestation service waits for a specified number of on-chain block confirmations before producing an attestation. The number of block confirmations required is specified by Circle in their documentation here. If Circle’s attestation service experiences an outage, malfunction, or otherwise becomes unresponsive, CCTP transfers will continue to burn assets on the source chain, but will not be able to mint assets on the destination chain. In this case, funds that have been burned to initiate a CCTP transfer will be inaccessible until the Circle attestation service recovers.

​

Hyperlane Failures

Each Hyperlane token transfer route is secured by an Interchain Security Module (ISM) designated by the deployer of the Hyperlane Warp Route Contracts (the interface to send tokens across chains using Hyperlane). The ISM defines the requirements for a message to be successfully processed on the destination chain. The most common ISM is a Multisig ISM where “Validators” of a specific Hyperlane route sign attestations that a specific message on an origin chain is a valid message to be processed on the destination chain. In the case where the set of Validators have not hit the required signature threshold to successfully process a Hyperlane message on the receiving chain, funds will not be accessible by the user on either chain until the threshold is met (once met, funds will be sent to the user on the destination chain). This generalizes to the different requirements for different ISMs. The Hyperlane documentation explains the different types of ISMs in more detail: https://docs.hyperlane.xyz/docs/reference/ISM/specify-your-ISM

​

Go Fast Failures

If a transfer timeout occurs, meaning a user’s intent does not receive a response from solvers within a predefined time frame, the solver initiates a refund process to ensure that users do not lose funds. Here’s a breakdown of what happens in the event of a timeout:

1. Intent Expiration: When a user initiates an intent by calling the submitOrder function on the source chain, a time limit is specified. Solvers monitor the intent and assess whether they can fulfill it within this period. If no solver fills the intent before the timeout, the refund process begins.
2. Refunds: Once the timeout period is reached without fulfillment, the solver calls a function on the contract to trigger a refund process. This is handled on-chain, and includes any fees initially allocated from the user for solver compensation.