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
:
Call the read-only function
getCurrentTime()
to get the current UNIX timestamp on the origin chain. e.g. this could return: 1665418548.Call the read-only function
depositQuoteTimeBuffer()
to get the buffer around the current time that thequoteTimestamp
must be set to. e.g. this could return: 600.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