Relay Pools

Screenshots

Problem Statement

Relay’s vision for cross chain liquidity is that a network of solvers fill user requests instantly with their own capital. That said, not all cross chain orderflow can be filled by solvers:solvers won’t always have enough liquidity, especially for large orders, or long tail chainssolvers themselves need to rebalance inventoryToday, both of these are solved by canonical bridges:for large / exotic requests, users directly use the bridge instead of solversolvers use the bridge to rebalanceWhat’s nice about canonical bridges is that they are low cost and support unlimited size. The main downside is speed, sometimes taking up to 7 days.We think there is an opportunity for something in the middle. Not everyone who holds capital can run a solver, but they can contribute it to a pool, resulting in more available liquidity. Due to the onchain nature of pools, it’s hard to make them as fast as a solver, but they can definitely be much faster than the canonical bridge. And so you unlock improvements for both users and solvers:users get more tolerable speed (30 seconds) when there’s no instant solver liquiditysolvers can fast rebalance against a pool for higher throughputWhile there are already other pool based bridges available (Stargate, Across, etc), the idea is that none of these fully optimize for a world dominated by sophisticated solvers and long tail chains, so there is a big gap in the market.The rough idea is that Relay pools are used to “accelerate” any existing bridge:users send money over a bridge, but via a proxy contractin parallel, a fast message (e.g. via Hyperlane) is sent to the pool on the destinationthe pool immediately gives funds to the user, minus a fee, because it knows that repayment is on the waywhen the bridge completes, the funds arrive in the proxy contractif the pool successfully filled the request, the funds are used to replenish the poolif not, then the funds are given to the userWhat’s interesting about this pool design is that effectively 100% of volume is getting rebalanced over a bridge. At first glance, this might seem inefficient, because it’s not able to do “netting” of bi-directional flow, as seen in most pool-based bridges. But this is deliberate. The assumption is that if there’s any netting available, solvers will take it. And the only volume that will come to the pool is the “toxic” orderflow, i.e. the one-directional excess. This design embraces that reality and optimizes for it:one-sided poolsrather than trying to manage connected pools on two or more chains, and rebalance between them, you can have simple one-sided poolsthere’s no need to manage how liquidity is allocated between pools on different chains, because each pool is isolated, and 100% of volume replenished back to the poolLPs choose exactly where to allocate liquidity, and get a simple deposit/withdraw UXyou can still achieve multi-directional flow by deploying multiple (unrelated) pools on different chains, and composing them at the application layerpermissionless deploymentbecause pools are isolated, it’s much easier to let anyone deploy themthis allows faster expansion to new chainsyield maximizationtoxic orderflow tends to come in bursts, when solvers receive more demand than anticipatedthis means that liquidity is often idle, and can be deployed into other protocols to earn a “base yield” when it’s not in usethis also pairs nicely with permissionless deployment, because you can have different pools with different risk / yield profiles

Solution

users send money over a bridge, but via a proxy contractin parallel, a fast message (via Hyperlane) is sent to the pool on the destinationthe pool immediately gives funds to the user, minus a fee, because it knows that repayment is on the waywhen the bridge completes, the funds arrive in the proxy contractif the pool successfully filled the request, the funds are used to replenish the poolif not, then the funds are given to the user