This code implements UMIP-157 and interacts with these smart contracts. The contracts were audited by OpenZeppelin.
Check out this guide for detailed bot instructions!
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 its 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-serverWhen running the bot, be sure to set the following environment variable
REDIS_URL=redis://localhost:6379# install dependencies
cd relayer
yarn install
# build relayer bot
yarn buildGeneral discussion happens most frequently on the Across discord.
All files within this repository are licensed under the GNU Affero General Public License unless stated otherwise.
# run test suite
yarn test
# apply stylistic changes (e.g. eslint and prettier)
yarn lint-fixRead 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.
Here's the official Across bug bounty program. The bug bounty only applies to the master branch and is agnostic of release versions.
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| Branch | Status |
|---|---|
| master | Accepts all PRs. |
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.
Our production branch is master and releases are only made from master.
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).
.github/workflows/publish.yml will automatically publish a new NPM package whenever a GitHub release is made. This will not happen for pre-releases.
We publish pre-releases to signal to users about potential releases that are risky to use in production setups.
Every merged PR into master should be following the conventional commit format, as documented in CONTRIBUTING.md.