Important design aspects for users

The points outlined below are intended to highlight key aspects of the protocol’s design that may affect user experience. These are not security vulnerabilities, but they are important for understanding how the protocol behaves in certain situations and where user awareness is critical for successful interaction.

Misconfigured hookData leads to unprocessed bridging or failed swap after bridging

The Across contract relies on the user to configure the hookData correctly. The executeOdosHook function on the sending side performs minimal validation, so the user can provide arbitrary or incorrect data — for example, an unsupported chain ID or an unreasonable outputAmount, and the function execution will not revert.

However, in particular, due to the SpokePool design, if unreasonable output amount is provided, relayers may never bridge the user’s funds and message, leaving them unprocessed on the source chain. Or, if invalid output token or mismatched amounts of tokens were specified, the swap on the destination chain will fail. So it is the user’s responsibility to ensure that the hookData is valid and correctly structured to avoid failed swaps or unprocessed bridging.

Available funds can be used by other users

Funds bridged to the destination chain but not claimed due to misconfigured swap data remain on the AcrossHandler contract. These funds are not locked or isolated and may be used by other users in subsequent swap executions. This behavior is part of the current design and should be clearly communicated to users.

Only wrapped native tokens are transferred to the recipient when it is a smart contract

When performing cross-chain swaps involving native tokens, the SpokePool contract on the destination chain only provides the wrapped version of the native token to the recipient, when it is a smart contract. As a result, the recipient is responsible for manually unwrapping the token if they need native assets after bridging.

Dummy data in the deposit function

When calling the deposit function in the SpokePool contract, the AcrossHook contract appends the dummy data 0x1dc0de0080 to the calldata. While this data does not affect the function's execution, it could confuse users. In response, Odos clarified that

hex"1dc0de0080" is an integratorId that across requested us to append to the end of the calldata to track our txs.

        bytes memory callData = abi.encodeWithSelector(
            SPOKEPOOL_DEPOSIT_SELECTOR,
            params.depositor,
            params.recipient,
        // [...]
        );
@>        return bytes.concat(callData, hex"1dc0de0080");