Selected Contract Functions

Detailed contract interfaces for depositors.

SpokePool state-modifying functions

The contract is where deposits are originated and fulfilled and is deployed on all chains that Across supports.

Using deposit will not allow the caller to specify a different outputToken than inputToken. This means that following the CCTP upgrade, deposit callers will not be able to set inputToken = USDC and outputToken = Bridged USDC.

This function is backwards compatible with the existing function with the same name. The main difference in how to use this function is that the relayerFeePct should now be set equal to the LP fee + relayer fee.

This is because the concept of the realizedLpFeePct is no longer brought on-chain by the relayer who used to call fillRelay() to fill this deposit. deposit() now emits a V3FundsDeposited event which can only be filled by fillV3Relay() and these fills get charged the LP fee at refund time. Therefore, the caller of deposit() is responsible for setting the relayerFeePct high enough that it covers both the relayer fees and the LP fees when converted into an outputAmount.

See Tracking Events to understand more how the new events are emitted by deposit().

This triggers a deposit request of tokens to another chain with the following parameters. The originChainId is automatically set to the chain ID on which the SpokePool is deployed. For example, sending a deposit from the Optimism_SpokePool will set its originChainId equal to 10.

Note on sending ETH: deposit is a payable function meaning it is possible to send native ETH instead of wrapped ETH (i.e. WETH). If you choose to send ETH, you must set msg.value equal to amount.

Note on receiving ETH: EOA recipients will always receive ETH while contracts will always receive WETH, regardless of whether ETH or WETH is deposited.

Note on setting inputToken and outputToken: the list of currently supported tokens is available on our API, which you can test in-browser here. These values generally must be set equal to ERC20 addresses on the origin and destination chain respectively, so in the case of bridging ETH this should be set to a WETH address.

Note on approvals: the caller must approve the SpokePool to transfer amount of tokens.

Note on inputAmount limits: If the inputAmount is set too high, it can take a while for the deposit to be filled depending on available relayer liquidity. If the outputAmount is set too high, it can be unprofitable to relay. Query the suggested max and min limits . The contracts will not revert if the outputAmount is set outside of the recommended range, so it is highly recommended to set outputAmount within the suggested limits to avoid locking up funds for an unexpected length of time. The recommended outputAmount will be equal to inputAmount * ( 1 - relayerFeePct - lpFeePct).

If you are using the API to set the outputAmount then you should set it equal to inputAmount * (1 - fees.totalRelayFee.pct) where fees.totalRelayFee is returned by the /suggested-fees endpoint.

Note on setting quoteTimestamp:

  1. Call the read-only function getCurrentTime() to get the current UNIX timestamp on the origin chain. e.g. this could return: 1665418548.

  2. Call the read-only function depositQuoteTimeBuffer() to get the buffer around the current time that the quoteTimestamp must be set to. e.g. this could return: 600.

  3. quoteTimestamp must be <= currentTime + buffer and >= currentTime - buffer.

Some of a pending deposit's parameters can be modified by calling this function. If a deposit has been completed already, this function will not revert but it won't be able to be filled anymore with the updated params.

It is the responsibility of the depositor to verify that the deposit has not been fully filled before calling this function.A depositor can request modifications by signing a hash containing the updated details and information uniquely identifying the deposit to relay. This information ensures that this signature cannot be re-used for other deposits.We use the EIP-712 standard for hashing and signing typed data. Specifically, we use the version of the encoding known as "v4", as implemented by the JSON RPC method eth_signedTypedDataV4 in MetaMask.You can see how the message to be signed is reconstructed in Solidity here.

Successfully calling this function will emit an event RequestedSpeedUpV3Deposit which can be used by relayers to fill the original deposit with the new parameters.

Depositors should assume that the parameters emitted with the lowest updatedOutputAmount will be used, since they are incentivized to use the highest fee possible. (Recall that the relayer's fee is derived by the difference between the inputAmount and the outputAmount). Any relayer can use updated deposit parameters by calling fillV3RelayWithUpdatedDeposit instead of fillV3Relay.

Last updated