.env.example

# Wallet configuration is controlled by the runtime argument:
#   --wallet <secret|mnemonic|privateKey>
#
# SECRET identifies a file containing a mnemonic or private key. The file can
# reside anywhere in the accessible filesystem, and may have more restrictive
# permissions. This is the preferred method of configuring a wallet.
#SECRET="./secret"

# MNEMONIC or PRIVATE_KEY can be specified directly in the .env file. Exercise
# *extreme* caution with these, and *never* share these lines from the
# configuration. Key theft will likely result in loss of funds. Uncomment and
# the configure desired variable, and use the following runtime argument to
# specify which should be used:
#
#MNEMONIC="your twelve or twenty four word seed phrase..."
#PRIVATE_KEY=0xabc123...


# Amount of time to wait (in seconds) between bot loops. This can be set to 0 to
# run once and exit, which is useful for test, or when operating via an
# automated scheduler (i.e. cron).
POLLING_DELAY=60


# Specify RPC provider preferences. The first provider is always used.
# Subsequent providers are used as backups in event of a higher priority
# provider being unavailable, or failing quorum.
# Format: RPC_PROVIDERS=INFURA,ALCHEMY,QUICKNODE
RPC_PROVIDERS=INFURA

# Per-chain overrides are possible. In the example below, LlamaNodes is
# preferred on Ethereum and Polygon.
# RPC_PROVIDERS_1=LLAMANODES,INFURA,ALCHEMY
# RPC_PROVIDERS_137=LLAMANODES,INFURA,ALCHEMY


# Define RPC providers for each chain. One RPC provider is specified per line.
# Format: RPC_PROVIDER_<PROVIDER>_<CHAIN-ID>=<URL>
RPC_PROVIDER_INFURA_1=https://mainnet.infura.io/v3/...
RPC_PROVIDER_INFURA_10=https://optimism-mainnet.infura.io/v3/...
RPC_PROVIDER_INFURA_137=https://polygon-mainnet.infura.io/v3/...
RPC_PROVIDER_INFURA_42161=https://arbitrum-mainnet.infura.io/v3/...
# RPC_PROVIDER_ALCHEMY_1=...
# RPC_PROVIDER_ALCHEMY_10=...
# RPC_PROVIDER_ALCHEMY_137=...
# RPC_PROVIDER_ALCHEMY_42161=...


# NODE_QUORUM controls how many RPC providers per chain must agree on certain
# responses before the result will be used. This protects the relayer bot
# against invalid responses being received from any individual provider.
# NODE_QUORUM defaults to 1. If NODE_QUORUM is greater than 1, there must be at
# least NODE_QUORUM number of providers defined in the corresponding
# RPC_PROVIDERS configuration.
NODE_QUORUM=1

# NODE_QUORUM can also be set per-chain by appending _<CHAIN-ID> to the
# NODE_QUORUM configurable. In this case, the corresponding
# RPC_PROVIDERS_<CHAIN-ID> must have at least that many providers configured.
# NODE_QUORUM_137=2


# NODE_MAX_CONCURRENCY controls the maximum number of concurrent requests that
# can be issued to a single RPC provider. Per-chain overrides are possible by
# appending _<CHAIN-ID>=<VALUE>. In the event that rate-limiting is occurring
# (429 responses to RPC requests) then concurrency can be reduced as an
# alternative to upgrading the RPC provider subscription/quota.
# NODE_MAX_CONCURRENCY_1=40
NODE_MAX_CONCURRENCY=25


# Permit the relayer to fill relays. This is disabled by default and must be
# explicitly enabled for the relayer to send fillRelay() transactions. When
# SEND_RELAYS is not set to "true", the bot will simulate making fills and will
# log the results, but will not submit transactions to the RPC provider. It is
# recommended to test with this before setting SEND_RELAYS to "true".
SEND_RELAYS=false


# Permit the finalizer to submit transactions for finalizing cross-chain actions. 
# This is disabled by default and must be explicitly enabled for the finalizer to
# submit transactions via the MultiCaller client. When SEND_FINALIZATIONS is not
# set to "true", the bot will simulate making finalizations and will log the
# results, but will not submit transactions to the RPC provider. It is recommended
# to test with this before setting SEND_FINALIZATIONS to "true".
SEND_FINALIZATIONS=false


# List of origin and destination chains to be supported by the relayer. If set
# to a non-empty list, only transfers complying with the specified origin and
# destination chains will be filled. For example:
# RELAYER_ORIGIN_CHAINS=[1]  # Only fill deposits that were placed on Optimism.
# RELAYER_DESTINATION_CHAINS=[10] # Only fill deposits destined for Ethereum.
RELAYER_ORIGIN_CHAINS=[1,10,137,324,42161]
RELAYER_DESTINATION_CHAINS=[1,10,137,42161]


# Deposit lookback window, specified in seconds. This is subtracted from the
# current time and is resolved to a block number on each chain, effectively
# controlling how far back in time the relayer will scan for unfilled deposits.
MAX_RELAYER_DEPOSIT_LOOK_BACK=900


# The relayer requires a minimum return on capital when filling relays. The
# minimum return is specified as a multiplier of the amount to be allocated to
# each fill. Minimum fees can also be configured per token(symbol)/route
# combination. Examples:
# Require 1 bps as the global default.
MIN_RELAYER_FEE_PCT=0.0001

# Override: Require at least 1.5 bps on USDC from Arbitrum to Ethereum.
# MIN_RELAYER_FEE_PCT_USDC_42161_1=0.00015
# Override: Require at least 0.8 bps on WETH from Optimism to Arbitrum.
# MIN_RELAYER_FEE_PCT_USDC_42161_1=0.00008


# Gas fees are difficult to estimate correctly, and the strategy for setting gas
# might depends on  the priorities of the relay bot operator. Gas price
# estimates can therefore be scaled on each chain. Note that `ethers` is used
# for sourcing gas price estimates on most chains, and on EIP-1559 chains it
# supplies a default priority fee of 1.5 Gwei. This is especially notable on
# Optimism (chainId 10), and can lead to overpriced transactions. Operators are
# encouraged to tune these scalers to meet their own needs and risk profile.
MAX_FEE_PER_GAS_SCALER=1.1
PRIORITY_FEE_SCALER=0.8
PRIORITY_FEE_SCALER_10=0.1


################################################################################
########################### Advanced Configuration #############################
################################################################################

# Note: This section is intended for advanced users only. It's recommended to
# consult the #relayers channel within the Across Discord server before making
# any changes to this section. See https://discord.across.to.


# A Redis in-memory DB can drastically speed up the performance of the bot.
# This is technically not required, but can reduce the instance of repeated
# RPC queries and therefore reduces the time and network bandwidth required
# for successful relay bot operation.
#
# Install redis and then ensure that redis-server is started:
#     https://redis.io/docs/getting-started/
# Under the hood, the relayer will cache JSON-rpc request data from requests
# like `eth_getBlock` in the Redis DB.
REDIS_URL="redis://127.0.0.1:6379"

# A namespace that will be used to prefix all keys in the Redis DB. This is
# useful if multiple relayers are running on the same Redis instance. This
# ENV variable is optional and defaults to not using a namespace.
# Possible Usage: This ENV variable can be used to effectively clear
#                 the Redis DB for an entire namespace.
GLOBAL_CACHE_NAMESPACE="ACROSS_0"

# The caching duration for a subset of the queries issued to RPC providers can
# be configured. The default time-to-live (TTL) of responses is 3600 seconds (60
# minutes). This is set conservatively to refresh the cache often, to ensure
# that any incomplete or invalid RPC provider responses are ejected within the
# short term. Increasing cache TTL may improve the speed of the bot and lead to
# reduced RPC provider quota utilisation, at the expense of increased resource
# usage (i.e. RAM + disk). Increasing cache TTL may also provide additional
# exposure to invalid or incomplete RPC responses.
PROVIDER_CACHE_TTL=3600


# List of tokens that the relayer is permitted to use for filling relays. These
# are addresses on Etheruem. For example, if only USDC's address is specified,
# the relayer would only fill transfers of USDC. If RELAYER_TOKENS is not set,
# the relayer will fill transfers of any supported token.
RELAYER_TOKENS='["0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2", "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"]'


# How many blocks to look back per request for a chain. Relayer code will bundle
# requests, so a lower number implies that there will be more requests to the
# RPC endpoint. This implies more request overhead and therefore impacts the
# speed at which the bot can operate. Some RPCs, like Infura, limit lookback to
# fixed number of blocks. The example configuration below is also the default
# behaviour of the bot and is known to work with Infura and Alchemy.
#MAX_BLOCK_LOOK_BACK='{ "1": 20000, "10": 20000, "137": 3499, "288": 4990, "42161": 99990 }'


# MIN_DEPOSIT_CONFIRMATIONS protects against Deposit reordering by by requiring
# a minimum Deposit age (block depth) before it will be accepted for a fill. The
# top-level keys (100, 1000) define the maximum USD-value of a Deposit that will
# be accepted. For example, for a Deposit on Ethereum worth up to $100 USD, the
# minimum number of confirmations is 16. Thereafter, a Deposit of up to $1000
# requires a minimum of 32 confirmations would be required. Above the highest-
# specified USD amount, the default finalization criteria is applied:
#
#   Ethereum:  64 blocks
#   Optimism:  60 blocks
#   Polygon:  128 blocks
#   Arbitrum:   0 blocks
#
# Relayer bot operators can adjust the volume thresholds and/or number of
# minimum deposit confirmations in order to tune their potential risk/return.
# Note however that if the relayer fills a Deposit event that is later re-
# ordered due to a fork or re-org on the origin/source chain, then the relayer
# will not be refunded for the fill and will therefore lose funds.
#MIN_DEPOSIT_CONFIRMATIONS='{
#  100: {
#      1: 16,
#      10: 0,
#      137: 100,
#      288: 0,
#      42161: 0,
#  },
#  1000: {
#    1: 32,
#    10: 0,
#    137: 100,
#    288: 0,
#    42161: 0,
#  },
#}'


# This inventory config will be explained in greater detail in a separate
# section, but generally this informs the relayer how it should rebalance token
# inventories across chains. The following simple example tells the bot that it
# should target holding 8% of its WETH on chain 10, 8% on chain 42161, 8% on
# on chain 137, 0.2% on chain 288, and the remainder on Mainnet. The config can
# also be used to specify how much ETH versus WETH to hold.
#RELAYER_INVENTORY_CONFIG='{
#  "tokenConfig": {
#    "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2": {
#      "1": {
#        "targetPct": 100, "thresholdPct": 100,
#        "unwrapWethThreshold": 3.5, "unwrapWethTarget": 5,
#      },
#      "10": {
#        "targetPct": 8, "thresholdPct": 5,
#        "unwrapWethThreshold": 0.75, "unwrapWethTarget": 1.5,
#      },
#      "137": {
#        "targetPct": 8, "thresholdPct": 5,
#      },
#      "288": {
#        "targetPct": 0.2, "thresholdPct": 0.1,
#        "unwrapWethThreshold": 0.65, "unwrapWethTarget": 1,
#      },
#      "42161": {
#        "targetPct": 8, "thresholdPct": 5,
#        "unwrapWethThreshold": 0.75, "unwrapWethTarget": 1.5,
#      },
#    },
#  },
#}'

# The dataworker can be configured to store tertiary bundle data on Arweave 
# for debugging and auditing purposes. This is disabled by default and must be
# explicitly enabled for the dataworker to store bundle data on Arweave. When
# PERSIST_DATA_TO_ARWEAVE is set to "true", the variables ARWEAVE_WALLET_JWK
# and ARWEAVE_GATEWAY must be set to valid values.
PERSIST_DATA_TO_ARWEAVE=false

# This wallet JWK is used to sign transactions intended for permenant storage of bundle
# data on Arweave. Ensure that the wallet has enough AR to cover the cost of storage.
ARWEAVE_WALLET_JWK=$({"kty":"", "e":"", "n":"", "d":"", "p":"", "q":"", "dp":"", "dq":"", "qi":""})

# The Arweave gateway to use for storing bundle data. This is used to connect to the
# Arweave network and store bundle data. The default gateway is the official Arweave
# gateway. This can be changed to a custom gateway if desired.
ARWEAVE_GATEWAY=$({"url":"", "port": 443, "protocol":"https"})

################################################################################
########################### Testing Configuration ##############################
################################################################################

# Note: This section is intended for advanced users only. It ONLY serves to aid
#       developers in testing the relayer bot. It is NOT intended for any relayer
#       or dataworker operator to use in production. It's recommended to consult
#       the #relayers channel within the Across Discord server before making any
#       changes to this section. See https://discord.across.to.
#
# Note: PLEASE DO NOT USE THIS SECTION IN PRODUCTION. IT IS FOR TESTING ONLY.

# Used to include an arbitrary chain ID to the Across Config Store for testing
# new chain additions. Including the block number and the chain ID will cause
# the relayer to include the chain ID in the Config Store. This is useful for
# testing new chains before they are officially supported by the relayer.
# Note: This logic does apply sanitizations so it is not possible to inject
#       a new change prior to the most previous chain ID update within the
#       Config Store.
#INJECT_CHAIN_ID_INCLUSION='{"blockNumber":17876743,"chainId":8453}'

# Used to force a proposal to be attempted regardless of whether there is a
# pending proposal. This is useful for testing the proposal logic.
# Note: This logic ONLY works if `SEND_PROPOSALS` is set to false.
#FORCE_PROPOSAL=false

# This variable can be used to simulate a bundle range that a proposal will be created for.
# This is useful for testing the disputer and proposer logic. The format is:
# [number, number][] where the two numbers are the start and end bundle ranges and the array
# represents the bundle ranges that will be proposed per the chain id indices.
# Note: This logic ONLY works if `SEND_PROPOSALS` and `SEND_DISPUTES` are BOTH set to false.
# FORCE_PROPOSAL_BUNDLE_RANGE = [[1, 2], [1, 3], ...]