iLayer Smart Contract Audit Report

The OrderHub::withdrawOrder function allows users to withdraw their locked tokens if their order has not been executed on the destination chain. The function uses a timeBuffer value to enforce a grace period after the order’s deadline:

function withdrawOrder(
    Order memory order, uint64 orderNonce
) external nonReentrant {
    address user = BytesUtils.bytes32ToAddress(order.user);
    bytes32 orderId = getOrderId(order, orderNonce);
    if (
        user != _msgSender() ||
        // Dedaub: grace period enforcement
        order.deadline + timeBuffer > block.timestamp ||
        orders[orderId] != Status.ACTIVE
    ) {
        revert OrderCannotBeWithdrawn();
    }
    orders[orderId] = Status.WITHDRAWN;
    // transfer input assets back to the user
    // Dedaub: Code omitted for brevity
    // ..
}

This timeBuffer is intended to accommodate delays in message passing between chains, giving time for the order’s status to be updated on the source chain after being filled on the destination. However, if timeBuffer is set too short relative to actual cross-chain message delays, users may be able to withdraw their tokens before the order’s fill status is reported back. This would mean the order filler would not receive the order inputs, despite having filled the order on the destination chain.

This is a real risk as cross-chain messaging protocols such as Axelar and LayerZero, which iLayer uses to relay messages cross-chain, can experience substantial delays due to relayer performance, chain finality, chain congestion, and other factors. According to Axelar documentation and recent Axelar GMP empirical data, the median time to relay a message on EVM chains is currently 20–30 minutes (e.g., Base 27m 28s, Ethereum 18m 46s), with some chains experiencing even longer times (e.g., Scroll 3h 42m 41s).

We recommend regularly reviewing and updating the timeBuffer parameter based on empirical data from the slowest supported cross-chain path, taking into account observed relay times under load. Additionally, a conservative safety margin should be added to account for outliers and exceptional delays.

Client Response: The protocol assumes the trustworthiness of the underlying bridges.

In OrderSpoke::onMessageReceived, the contract sets the order status to PENDING without verifying its current status. While this is safe under the assumption that the underlying bridges never re-transmit (successfully executed) messages, it introduces risk if future versions of the bridge infrastructure contain bugs.

Specifically, a retransmission could cause an already filled order to revert to PENDING, enabling multiple fillers to fulfill the same order. Adding a check before setting the status would alleviate this potential issue and lower the trust assumption on the underlying bridge.

The Axelar router currently does not provide a way to estimate interchain transaction gas fees on-chain. As confirmed by the Axelar documentation, on-chain estimation is not accurate and is also unavailable outside of testnet environments. Most dApps using Axelar rely on the off-chain gas estimation API to calculate and present gas estimates to users.

Whether this is a significant limitation depends on the protocol’s use case. If integrating customers are end-users interacting through the protocol’s dApp, the lack of on-chain estimation is generally not an issue, as the dApp can handle estimation offchain. However, if the protocol is intended to be used entirely on-chain or by other smart contracts, the absence of a reliable on-chain estimation method could cause operational issues or failed transactions due to gas miscalculations.

In OrderHub::withdrawOrder, the if condition can be split into three separate conditions for better error reporting:

if (user != _msgSender()) {
    revert OrderCannotBeWithdrawnByOtherUser();
}
if (order.deadline + timeBuffer > block.timestamp) {
    revert OrderCannotBeWithdrawnTooEarly();
}
if (orders[orderId] != Status.ACTIVE) {
    revert OrderCannotBeWithdrawnNotActive();
}

Client Response: This information is consumed by the off-chain network of solver bots.

The boolean field sponsored in the Root::Order struct is not read on-chain. This suggests it is currently unused and could be removed to simplify the code and reduce storage costs.

There exist the following unnecessary imports:

• OrderHelper.sol
  • MessagingReceipt
• NullRouter.sol
  • BytesUtils
  • IRouterCallable
  • Ownable

When using enums in Solidity, the compiler automatically inserts range checks for values passed into the contract. While this enhances correctness, it introduces challenges for upgradeability.

A key example is the Bridge enum. Although the router implementation can be upgraded/changed to support additional bridges, the OrderHub will reject any bridge value not already defined in the Bridge enum.