https://docs.across.to/">

Across is a secure and instant asset-transfer bridge between EVM networks.

Across V3 Relayer

This code implements UMIP-157 and interacts with these smart contracts. The contracts were audited by OpenZeppelin.

How to run a Relayer

Check out this guide for detailed bot instructions!

Prerequisites

To install dependencies successfully, node version should be higher or equal to v20.18.0 && lower than v22. After installing dependencies and building the repository, be sure to install RedisDB, an in-memory storage layer that is required to make the bots work. The bots query blockchain RPCs for a lot of smart contract events so it's important that the bot cache some of this data in order to maintain its speed.

The first time that the bot runs, it might be slower than usual as the Redis DB fills up. This slowdown should disappear on subsequent runs.

Start the redis server in a separate window:

redis-server

When running the bot, be sure to set the following environment variable

REDIS_URL=redis://localhost:6379

Installation

# install dependencies
yarn install

# build relayer bot
yarn build

Community

General discussion happens most frequently on the Across discord.

License

All files within this repository are licensed under the GNU Affero General Public License unless stated otherwise.

Developers

Contributing

# run test suite
yarn test

# apply stylistic changes (e.g. eslint and prettier)
yarn lint-fix

Read through CONTRIBUTING.md for a general overview of our contribution process. These guidelines are shared between the UMA and Across codebases because they were built originally by the same teams.

Testing

Local SDK Development

This repository depends on functionality from other across libraries such as @across-protocol/sdk.

To test local changes to the SDK alongside this repository you can use yalc:

1. Install yalc globally:

npm install -g yalc

1. Inside the @across-protocol/sdk directory, watch for changes and publish the local SDK to your local yalc server:

yalc yalc:watch

1. Add/Link the local SDK in this repository:

yalc add @across-protocol/sdk

use yalc link @across-protocol/sdk if you don't want yalc to modify package.json file

Any changes to the SDK will be automatically published to your local yalc server.

Once you are done testing, you can remove the local SDK by running yalc remove @across-protocol/sdk in this repository.

Bug Bounty

Here's the official Across bug bounty program. The bug bounty only applies to the master branch and is agnostic of release versions.

Integration tests

You can conveniently run the dataworker, relayer, and finalizer functions via the hardhat task integration-tests which sets safe configurations like PROPOSER_ENABLED=false and prevents the user from accidentally sending an on-chain transaction. The test will complete successfully if no functions throw an error, which can be used as an additional source of confidence (in addition to the unit tests) that code has not broken the production bots.

If you want to read more about the three different agents in the Across system, check out the docs.

LOG_IN_TEST=true yarn hardhat integration-tests --wallet mnemonic

Branching Model

Active Branches

Overview

Longer term we'd ideally like to follow this Git branching model, but for now we manually trigger GitHub releases to demarcate features that we'd like to "release" for public usage.

Production branch

Our production branch is master and releases are only made from master.

Release Process

Merge all features into master that you want to include in the new release. We use GitHub's native release feature to manually trigger releases, follow this documentation for more information.

When selecting a tag, select "Create a new tag: on publish" to have GitHub default to a tag, and set the "target" to master.

We use Semantic Versioning for naming releases and we aim to publish major and minor releases very rarely (and with very detailed notes).

NPM

.github/workflows/publish.yml will automatically publish a new NPM package whenever a GitHub release is made. This will not happen for pre-releases.

Pre-releases

We publish pre-releases to signal to users about potential releases that are risky to use in production setups.

Documenting changes

Every merged PR into master should be following the conventional commit format, as documented in CONTRIBUTING.md.