Forta Monitors: Across v2 Specifications
Overview of the Across Protocol
The Across Protocol is a cross-chain bridge that uses UMA’s Optimistic Oracle to validate deposits on the sending chain and the validity of relays on the receiving chain. Relayers, generally bots, who see a deposit on the sending chain, can advance funds to the depositer on the receiving chain, minus fees.
After relaying the funds, the relayer can seek reimbursement from a passive liquidity pool. This request for reimbursement can be disputed with UMA’s oracle if the relay was incorrect in some way. The passive liquidity pool receives the original deposit via the sending chain’s slower native bridge to Ethereum L1, completing the circuit.
The process overview for Across v1 is a good way to understand the original system.
Across v2: Similarities and Differences
-
Across v1 only supported bridging from optimistic roll-ups (Optimism, Arbitrum, and Boba) to Ethereum L1, solving the slow withdrawal problem. Across v2 allows for bridging directly between L2 networks and EVM compatible chains like Polygon.
-
Passive liquidity in Across v2 is still concentrated in a single pool on Ethereum L1. To reimburse relayers, funds must be sent from this L1 liquidity pool to the chain(s) where the relayers requested reimbursement. These transactions bundle multiple relays for gas efficiency. Relayers can request reimbursement on any Across-supported chain.
-
Deposits from the sending chains are still sent to the passive liquidity pool on L1 through slower native bridges. This L1 liquidity pool is the clearinghouse for all of the capital in the system.
Our Goals with Forta
Risk Labs, the developers of Across, runs bot infrastructure to monitor relevant transactions and wallet balances, execute relays, and so on. Partners and third parties also run relayer bots, generally based on Risk Labs’ open source software. Our bots have some redundancy built in, including connections to different cloud node providers in case one provider goes down.
However, we run the risk of those bots failing due to their own unexpected technical issues or a failure of one of our data providers or software dependencies. If that happens, we want back-up monitoring infrastructure built by an independent person or team that will surface relevant details so that we or others can manually relay deposits, dispute invalid relays, rebalance capital and so on.
The contracts for Across v2 are currently being audited and can be viewed on GitHub. Although there will inevitably be some code changes during the audit process, the design and interfaces should be fairly stable, which allows work to begin on monitoring bots.
We would like this monitor infrastructure to surface details related to the following:
- Deposits by users on sending chains.
- Slow and fast relays executed by relayers on the receiving chains.
- Disputes of relays on the receiving chains.
- Transfers of funds from the HubPool, which is the L1 liquidity pool, to spoke pools for relayer reimbursement.
- Changes to the configuration of the hub and spoke pools.
These monitors are intended to be run by Forta’s decentralized smart contract security network and should follow the SDK for Forta agents.
HubPool and SpokePool
Most of the action is in the HubPool contract on Ethereum L1 and the various SpokePool contracts on L2 networks, Ethereum L1, and EVM sidechains.
(Note: Ethereum L1 needs a spoke pool of its own to handle relayer reimbursement logic if the destination chain is Ethereum L1.)
(Note x2: Boba is a fork of Optimism and can use the same spoke pool contract code.)
Main contracts:
Specific SpokePool Contracts:
Full contract list:
Key Events to Monitor
We would like the monitors to show us to relevant events emitted by the HubPool, SpokePool, and various X_SpokePool contracts, providing all of the information necessary to execute relays, dispute relays, understand disputes from third parties, track funds moving through the system, and changes to the system. We believe that data from these events should be sufficient for us and third parties to continue to manually relay transactions if the main bot infrastructure is down.
At a minimum, monitor notifications should be sent by e-mail as soon as events are detected, but ideally we would also be able to receive running notifications on Slack, which would make it much easier to triage manual relays, disputes, and capital rebalancing.
Nice-to-Haves
We do not necessarily need to track addition or removal of liquidity from the HubPool (i.e., the LiquidityAdded and LiquidityRemoved events).
However, it would be useful to get notifications about certain types of events for our data analysis and customer support teams:
- If liquidity in a HubPool drops by more than 10% in a 24-hour period.
- Notifications about large relays, such as those over 250 ETH, 1,000,000 USDC, 20 WBTC, and so on. These numbers should be re-configurable after launch and it should be easy to add additional pools we want to monitor and custom configuration for those pools.
- If the same wallet address triggers multiple relays in quick succession, such as three relays in a period of ten minutes. These numbers should be configurable.
- Large changes in specified wallet balances, similar to how we would monitor large changes in the liquidity pool. We would use this monitor known relayer addresses and better understand relayer liquidity.
- If a wallet address from a configurable list uses the bridge. We could use this to track targets for customer acquisition and major users.
Contact for Proposals
Proposals in response to this RFP should be sent to John Shutt at john@umaproject.org.