Across is now live on Lens Chain!
Bridge Now
Across Documentation
V2 Developer Docs
V2 Developer Docs
  • How Across Works
    • Overview
      • Roles within Across
      • Fee Model
      • Validating Root Bundles
      • Disputing Root Bundles
  • Developers
    • Across API
    • Across SDK
    • Contract Addresses
      • Mainnet (Chain ID: 1)
      • Arbitrum (Chain ID: 42161)
      • Optimism (Chain ID: 10)
      • Base (Chain ID: 8453)
      • zkSync (Chain ID: 324)
      • Polygon (Chain ID: 137)
    • Selected Contract Functions
    • Running a Relayer
    • Integrating Across into your application
    • Composable Bridging
    • Developer notes
    • Migration from V2 to V3
  • ADDITIONAL INFO
    • Support Links
    • Bug Bounty
    • Audits
Powered by GitBook
LogoLogo
On this page
  • SpokePool state-modifying functions
  • deposit
  • speedUpDeposit
  1. Developers

Selected Contract Functions

Explanation of most commonly used smart contract functions

PreviousPolygon (Chain ID: 137)NextRunning a Relayer

Last updated 1 year ago

SpokePool state-modifying functions

The contract is where deposits are originated and fulfilled.

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 approvals: the caller must approve the SpokePool to transfer amount of tokens.

Note on amount limits: If the amount is set too high, it can take a while for the deposit to be filled depending on available relayer liquidity. If the amount is set too low, it can be unprofitable to relay regardless of the relayer fee %. Query the suggested max and min limits . The contracts will not revert if the amount is set outside of the recommended range, so it is highly recommended to set amount within the suggested limits to avoid locking up funds for an unexpected length of time.

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.

Type
Name
Explanation

address

recipient

Receiver of bridged funds on destination chain.

address

originToken

Bridged token address on origin chain.

uint256

amount

Amount of tokens to send on origin chain. Receiver receives this amount minus fees on destination chain.

uint256

destinationChainId

uint64

relayerFeePct

uint32

quoteTimestamp

bytes

message

uint256

maxCount

This parameter can be set to protect against front-running in the new UBA fee model. Stay tuned for updates about this feature. For now, set this to UINT256.MAX_UINT to avoid deposit reverts.

speedUpDeposit

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.

Successfully calling this function will emit an event RequestedSpeedUpDeposit which can be used by relayers to fill the original deposit with the new parameters. Depositors should assume that the parameters emitted with the highest relayerFeePct will be used, since they are incentivized to use the highest fee possible.

Any relayer can use updated deposit parameters by calling fillRelayWithUpdatedDeposit instead of fillRelay.

Type
Name
Description

address

depositor

Sender of deposit to be sped up. Does not need to equal msg.sender

int64

updatedRelayerFeePct

New relayer fee % that relayers can use when calling fillDepositWithUpdatedDeposit

uint32

depositId

UUID of deposit to be sped up

address

updatedRecipient

New recipient of deposit.

bytes

updatedMessage

Updated data that is sent to updatedRecipient. As described in section above, this should be set to 0x for the forseeable future.

bytes

depositorSignature

Where bridged funds should be sent to recipient. Recipient will receive the equivalent of the originToken on the destination chain. The mapping of destination and origin tokens can be queried .

% of amount to pay to relayer. Must be less than 0.5e18 (i.e. 50%). Suggested fees can be queried . Be careful: if this % is set too low, relayers could be disincentivized to fill this deposit quickly. This can be sped up by calling speedUpDeposit.

Timestamp of deposit. Used by relayers to compute the for the deposit. Must be withindepositQuoteTimeBuffer() of the current time.

Data that can be passed to the recipient if it is a contract. If no message is to be sent, set this field to an empty bytes array: ""(i.e. bytes` of length 0, or the "empty string"). See for examples on how messaging can be used.

We use the standard for hashing and signing typed data. Specifically, we use the , as implemented by the JSON RPC method eth_signedTypedDataV4 in MetaMask.

You can see how the message to be signed is reconstructed in Solidity .

Signed message containing contents

EIP-712
version of the encoding known as "v4"
here
LP fee %
Composable Bridging
here
spoke pool
here
here
here