feat: working version

Author: georgeroman

.github/workflows/test.yml

@@ -0,0 +1,45 @@
+name: CI
+
+on:
+  push:
+  pull_request:
+  workflow_dispatch:
+
+env:
+  FOUNDRY_PROFILE: ci
+
+jobs:
+  check:
+    strategy:
+      fail-fast: true
+
+    name: Foundry project
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          submodules: recursive
+
+      - name: Install Foundry
+        uses: foundry-rs/foundry-toolchain@v1
+        with:
+          version: nightly
+
+      - name: Show Forge version
+        run: |
+          forge --version
+
+      - name: Run Forge fmt
+        run: |
+          forge fmt --check
+        id: fmt
+
+      - name: Run Forge build
+        run: |
+          forge build --sizes
+        id: build
+
+      - name: Run Forge tests
+        run: |
+          forge test -vvv
+        id: test

.gitignore

@@ -0,0 +1,14 @@
+# Compiler
+cache/
+out/
+
+# Broadcast
+/broadcast
+/broadcast/*/31337/
+/broadcast/**/dry-run/
+
+# Docs
+docs/
+
+# Secrets
+.env*

.gitmodules

@@ -0,0 +1,6 @@
+[submodule "lib/forge-std"]
+	path = lib/forge-std
+	url = https://github.com/foundry-rs/forge-std
+[submodule "lib/solady"]
+	path = lib/solady
+	url = https://github.com/vectorized/solady

README.md

@@ -0,0 +1,46 @@
+## 🌊 Relay Pools
+
+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 chains
+- solvers themselves need to rebalance inventory
+
+Today, both of these are solved by canonical bridges:
+
+- for large / exotic requests, users directly use the bridge instead of solver
+- solvers use the bridge to rebalance
+
+What’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 liquidity
+- solvers can fast rebalance against a pool for higher throughput
+
+While 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.
+
+#### Implementation
+
+The rough idea is that Relay pools are used to “accelerate” any existing bridge:
+
+- users send money over a bridge, but via a proxy contract
+- in parallel, a fast message (e.g. via Hyperlane) is sent to the pool on the destination
+- the pool immediately gives funds to the user, minus a fee, because it knows that repayment is on the way
+- when the bridge completes, the funds arrive in the proxy contract
+  - if the pool successfully filled the request, the funds are used to replenish the pool
+  - if not, then the funds are given to the user
+
+What’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:
+
+- <b>one-sided pools</b>
+  - rather than trying to manage connected pools on two or more chains, and rebalance between them, you can have simple one-sided pools
+  - there’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 pool
+  - LPs choose exactly where to allocate liquidity, and get a simple deposit/withdraw UX
+  - you can still achieve multi-directional flow by deploying multiple (unrelated) pools on different chains, and composing them at the application layer
+- <b>permissionless deployment</b>
+  - because pools are isolated, it’s much easier to let anyone deploy them
+  - this allows faster expansion to new chains
+- <b>yield maximization</b>
+  - toxic orderflow tends to come in bursts, when solvers receive more demand than anticipated
+  - this means that liquidity is often idle, and can be deployed into other protocols to earn a “base yield” when it’s not in use
+  - this also pairs nicely with permissionless deployment, because you can have different pools with different risk / yield profiles

foundry.toml

@@ -0,0 +1,4 @@
+[profile.default]
+src = "src"
+out = "out"
+libs = ["lib"]

lib/forge-std/.gitattributes

@@ -0,0 +1 @@
+src/Vm.sol linguist-generated

lib/forge-std/.github/workflows/ci.yml

@@ -0,0 +1,128 @@
+name: CI
+
+on:
+  workflow_dispatch:
+  pull_request:
+  push:
+    branches:
+      - master
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Install Foundry
+        uses: foundry-rs/foundry-toolchain@v1
+        with:
+          version: nightly
+
+      - name: Print forge version
+        run: forge --version
+
+      # Backwards compatibility checks:
+      # - the oldest and newest version of each supported minor version
+      # - versions with specific issues
+      - name: Check compatibility with latest
+        if: always()
+        run: |
+          output=$(forge build --skip test)
+          if echo "$output" | grep -q "Warning"; then
+            echo "$output"
+            exit 1
+          fi
+
+      - name: Check compatibility with 0.8.0
+        if: always()
+        run: |
+          output=$(forge build --skip test --use solc:0.8.0)
+          if echo "$output" | grep -q "Warning"; then
+            echo "$output"
+            exit 1
+          fi
+
+      - name: Check compatibility with 0.7.6
+        if: always()
+        run: |
+          output=$(forge build --skip test --use solc:0.7.6)
+          if echo "$output" | grep -q "Warning"; then
+            echo "$output"
+            exit 1
+          fi
+
+      - name: Check compatibility with 0.7.0
+        if: always()
+        run: |
+          output=$(forge build --skip test --use solc:0.7.0)
+          if echo "$output" | grep -q "Warning"; then
+            echo "$output"
+            exit 1
+          fi
+
+      - name: Check compatibility with 0.6.12
+        if: always()
+        run: |
+          output=$(forge build --skip test --use solc:0.6.12)
+          if echo "$output" | grep -q "Warning"; then
+            echo "$output"
+            exit 1
+          fi
+
+      - name: Check compatibility with 0.6.2
+        if: always()
+        run: |
+          output=$(forge build --skip test --use solc:0.6.2)
+          if echo "$output" | grep -q "Warning"; then
+            echo "$output"
+            exit 1
+          fi
+
+      # via-ir compilation time checks.
+      - name: Measure compilation time of Test with 0.8.17 --via-ir
+        if: always()
+        run: forge build --skip test --contracts test/compilation/CompilationTest.sol --use solc:0.8.17 --via-ir
+
+      - name: Measure compilation time of TestBase with 0.8.17 --via-ir
+        if: always()
+        run: forge build --skip test --contracts test/compilation/CompilationTestBase.sol --use solc:0.8.17 --via-ir
+
+      - name: Measure compilation time of Script with 0.8.17 --via-ir
+        if: always()
+        run: forge build --skip test --contracts test/compilation/CompilationScript.sol --use solc:0.8.17 --via-ir
+
+      - name: Measure compilation time of ScriptBase with 0.8.17 --via-ir
+        if: always()
+        run: forge build --skip test --contracts test/compilation/CompilationScriptBase.sol --use solc:0.8.17 --via-ir
+
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Install Foundry
+        uses: foundry-rs/foundry-toolchain@v1
+        with:
+          version: nightly
+
+      - name: Print forge version
+        run: forge --version
+
+      - name: Run tests
+        run: forge test -vvv
+
+  fmt:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Install Foundry
+        uses: foundry-rs/foundry-toolchain@v1
+        with:
+          version: nightly
+
+      - name: Print forge version
+        run: forge --version
+
+      - name: Check formatting
+        run: forge fmt --check

lib/forge-std/.github/workflows/sync.yml

@@ -0,0 +1,31 @@
+name: Sync Release Branch
+
+on:
+  release:
+    types:
+      - created
+
+jobs:
+  sync-release-branch:
+    runs-on: ubuntu-latest
+    if: startsWith(github.event.release.tag_name, 'v1')
+    steps:
+      - name: Check out the repo
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+          ref: v1
+
+      # The email is derived from the bots user id,
+      # found here: https://api.github.com/users/github-actions%5Bbot%5D
+      - name: Configure Git
+        run: |
+          git config user.name github-actions[bot]
+          git config user.email 41898282+github-actions[bot]@users.noreply.github.com
+
+      - name: Sync Release Branch
+        run: |
+          git fetch --tags
+          git checkout v1
+          git reset --hard ${GITHUB_REF}
+          git push --force

lib/forge-std/.gitignore

@@ -0,0 +1,4 @@
+cache/
+out/
+.vscode
+.idea