# Crosschain Research Conclusions

To support the GitCoin grants team in improving the user experience, Raid Guild executed an exploration of different cross-chains solutions and their trade-off. Below we will provide a summary of our findings and provide guidance on the prefered setup.

:::success
Want the TLDR? Jump to [Recommendations](#Recommendations)
:::

## Constraints

After several talks with Kevin and Meg we identified several constraints in the design space of the cross-chain solution:

- Low cost
- Low trust assumption
- Support all current AlloV2 chains (bar PGN)
- Support primarily native tokens and stables
- We need Allocate events, or at least a way to determine the msg.sender for the allocate calculations

> Sneak peak: Low cost and low trust assumption is a difficult dilemma simply because batch-bridging of funds is cheaper than bridging funds for every donation vote cast.

## Process

The Raid Party started with a research cycle to identify the most suitable bridging solutions. Ultimately, we decided to investigate Connext, Decent and Li.Fi. The following solutions were excluded:

- CCIP: does not support all current AlloV2 chains
- LayerZero: only bridging but no liquidity (Stargate solves that problem)
- Stargate: implemented in Li.Fi so it's implicitly available

:::warning
We missed that Connext didn't support Fantom
:::

We set up calls and communications channels with all parties that we decided to explore. Kudos to all teams for being supportive, available and thinking along with us in this exploration.

To explore the actual cost of bridging we decided to simulate cross-chain transactions by providing a mocked Allo contract and implementing the required contracts for the respective solutions.

This resulted in the following setup:

| Aspect | Details |
|----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Contracts** | A Connext CrossChainAdapterContract and a MockAllo contract were deployed on Arbitrum, Polygon, and Optimism. [GitHub](https://github.com/grants-stack-frontier/cross-chain-testing-contracts) |
| **Chains** | Forks were made on Tenderly to execute the cross-chain transaction data as provided by the APIs of the bridging solutions |
| **Transaction calls**| To reduce variance in gas cost, slippage, and other classic swap and transfer variables, we programmatically call the bridge APIs with a fixed set of transaction data within a short timeframe. For this, we've set up testing scripts as a CLI app. [GitHub](https://github.com/grants-stack-frontier/cross-chain-test-cli) |
| **Transaction results** | The test scripts write the transaction data to a [Google sheet](https://docs.google.com/spreadsheets/d/171IGuvwm9fbkbq79ef16ltW4mtx18dKz0w1lrTTfqxU/edit?pli=1#gid=0) for reference and data analysis |
| **Test data** | We were provided with a subset of a grants round data to simulate the transactions |

## Comparison

We've created writeups of key findings and the envisioned transaction flow per solution in the following docs:

[Li.Fi report](https://hackmd.io/mFtfjic4RBCGMTE3GwFrvQ)
[Decent Report](https://hackmd.io/HYyGH0_CT7a_dcSwvLw0cg)
[Connect report](https://hackmd.io/OPUzuhBqQgumR6RioVtBEw)

### Feature comparison

| **Feature** | **Li.Fi** | **Decent** | **Connext** |
|---------------------------|------------------------------------------------------|---------------------------------------------------|----------------------------------------------------|
| **Fees/Costs per Bridge** | 0; function of the selected bridge | Fee: 25 bps/tx and a flat fee (~$0.30); Offered flexible fees; 0.5% slippage tolerance | 0.05% router fees |
| **Average cost paid (L2 <> L2)** | $5.66 | $5 | $4.04 |
| **Chains Available** | 20 chains, including Ethereum, Polygon, Base, Optimism, Arbitrum, BSC, Fantom, PolygonZKEvm, Avalanche, Gnosis, etc. [ref](https://docs.li.fi/list-chains-bridges-dexs-solvers) | Ethereum, Optimism, Base, Zora, Arbitrum, Polygon, SOlana, Avalanche, Fantom, Moonbeam [ref](https://docs.decent.xyz/docs/supported-chains) | Ethereum, Polygon, Optimism, Base, BSC, Arbitrum, Gnosis, Linea, Metis [ref](https://docs.connext.network/resources/supported-chains) |
| **Level of Integration** | Integration on both frontend and contracts; messaging cross-chain via zaps **(requires adapter)** | Integration on both frontend and contracts; messaging cross-chain **(requires adapter)** | Smart contract integration via CrossChainAdapter **(requires adapter)** |
| **In Operation** | Over 2.5 years | Over 1 year | ~ 7 Years |
| **Time to Implement** | 1 day PoC, not completely functional | Not completed during trials | 1 day for PoC |
| **Team Support** | Available and willing to provide support | Available and willing to provide support | Available and willing to provide support |
| **Upkeep Requirements** | Custom adapter; light audit(?) | Custom adapter; light audit(?) | Custom adapter; light audit(?) |
| **Benefits (On/Offramping)**| Onramping available via SDK | Onramping available via SDK in the US | No off/on-ramp |
| **Offers Insurance** | Bridge insurance | No | No |

### Cost comparison

Two data set for comparison were created. The first dataset was programmatically created using the test contracts and suite that simulates actual contract calls. Second, because we couldn't get all script functional within our scope, we also used the default apps of the respective solutions.

#### Average costs - simulations
| Strategy | From / To | 10 | 137 | 42161 |
|----------|-----------|------------|-------------|---------------|
| Connext | 10 | - | $0.046 | - |
| Connext | 137 | $7.111 | - | $0.776 |
| Connext | 42161 | - | $0.058 | - |
| LiFi | 10 | - | $0.359 | - |
| LiFi | 137 | $7.564 | - | $3.041 |

|Solution | Average USD |
|---------|-------------|
|Average Connext | $4.05 |
|Average Li.Fi | $5.66|

> [source](https://docs.google.com/spreadsheets/d/171IGuvwm9fbkbq79ef16ltW4mtx18dKz0w1lrTTfqxU/edit?pli=1#gid=667423985)

#### Average costs - manual testing

**Disclaimer: The following tests were down manually over a span of 30 minutes, and gas costs fluctuate minute by minute.**

We used the following apps to route 10, 100 and 1000 USDC cross-chain:

Li.Fi: [jumper.exchange](https://jumper.exchange/)
Connext: [Connext Bridge](https://bridge.connext.network/)
Decent Box: [Decent Checkout](https://checkout.decent.xyz/?app=bridge)

| **Protocol** | **Total Transactions** | **Average Total Cost (USD)** | Transaction efficienty
|--------------|---------------------------|---------|----|
| Li.Fi | 10 | $1.72 | ~99.5% |
| Connext | 10 | $6.96 | ~98%
| Decent | 25 | $5.0 | n/a |

> For more details on the transactions used as input see the write-up per bridging solution.
> Transaction efficiency: Calculated as the ratio of the total received amount to the total amount transferred, expressed as a percentage. This gives an idea of how much value is preserved after accounting for fees.
> Updated March 7th 15:30

## Crosschain Research Conclusions

In general, all bridging solution will require a comparable architecture. The Donor will create a transaction on the target chain, the bridge will route funds to an adapter contract, the adapter contract will call Allo and the regular flow follows. This architecture entails a custom strategy that allows for decoding a signed message to determine the donor address for the QF calculations.

Alternatively, we considered and explored batch-wise bridging and fund allocation. While feasible, this comes with a significant increase in complexity:
- Aggregating funds in -preferably- a multi-sig
- Indexing Allocate events on all chains
- Double distribution of funds 1) the matching funds and 2) the aggregated funds
- Trust assumptions on the multi-sig
- Considerations of deploying a proxy-contract per round instance (trust <> convenience)

### Proposed architecture:

You can find sequence diagrams per solution in the reports linked above. Generally, all solutions require the same pattern:

sequenceDiagram
    participant RO as Round Operator
    participant AC as Allo Contract
    participant SC as Modified Strategy
    participant ACx as Adapter Contract
    participant D as Donor
    participant P as Project
    participant Bridge as Connext Bridge

    RO->>+AC: createPool(...)
    AC-->>-RO: Returns Pool ID

    RO->>+AC: registerRecipient(_poolId, _data)
    AC->>+SC: registerRecipient(...)
    SC-->>-AC: Returns Recipient ID
    AC-->>-RO: Project is Registered

    D->>+ACx: _forwardFunctionCall(allocate, _data, _sender)
    Bridge->>ACx: Deposits Funds & Calls Forwarder
    ACx->>AC: Decodes message & calls allocate
    AC->>SC: Verifies & Executes Checks
    SC->>AC: Allocated Event Emitted
    AC->>P: Transfers Funds to Project
    ACx-->>-D: Vote Recorded & Funds Transferred

    RO->>+AC: fundPool(_poolId, _amount)
    AC-->>-RO: Pool is Funded

    RO->>+AC: updateDistribution(_merkleRoot, _distributionMetadata)
    AC->>+SC: Distribution Data Updated
    SC-->>-AC: Update Confirmed
    AC-->>-RO: Distribution Data Updated

    RO->>+AC: distribute(_poolId, _recipientIds, _data)
    AC->>SC: distribute(...)
    SC->>P: Matching Funds Distributed
    AC-->>-RO: Funds Distributed to Projects

## Recommendations

The definite call on which bridge to implement, and whether to aggregate or bridge every donation vote, lies with the Grants team. We want to offer a few considerations:

### User experience

With the test script we've developed we learned all transactions will be 'built' by the APIs of the bridging providers. The biggest differentiator will be the costs involved for the user.

### Developer experience

*Support*: All bridging solutions are backed by skilled, enthusiastic teams that provide fast support.
*Stack*: They all provide SDKs and API to facilitate integrations.
*Protocol changes*: Because of the design of AlloV2 custom strategies or adapters will be needed to determine the address of the donor.
*Connext*: implementation seemed to be 'closest to the metal' and was therefore easiest to implement and debug, with less surprises.
*Lifi*: SDK wasn't used for our implementation, but offers some nice features such as routing preferences. Requesting a route from their API and then executing it ourselves proved straightforward enough.
*Decent*: Seems to be in an earlier stage of development. Although the support team is very responsive, it might be better to wait for their docs to become more complete, and the API more reliable before choosing this solution.
*Not all chains are equal*: in some cases (for example, arbitrum on lifi) transactions would not come through where as they did on different chains with the same code. this means that the costs of supporting extra chains will not always be 0 (even though most of the time it did not give any extra work).

Connext is the only solution we got fully functional within the timebox provided. Lifi

### One bridge to rule them all
Li.Fi excels with its diverse chain support, its support of multiple bridging solutions and bridge insurance. LiFi support most types of tokens and as a bridge aggregator it's most flexible.

### Decentralised
Connext, with a longer operational history, competitive fees, and broad chain support, is a strong choice. More interesting is the possibility to run your own router for the Connext network.

### Slick
Decent, despite higher fees, may suit users seeking onramping via SDK (i.e. Stripe) and they offered fast support of newer chains.

### Value capture

Li.Fi has not fees, but allows for setting fees and revenue will be split between LiFi and the implementing app.

Connext allows teams to roll out their own router and join in the 0.05% revenue capture of all bridging fees.

### In short

For the short term, LiFi is very interesting because of its wide availability and the services it provides. However, Connext offers participation in the network (as a Router) and has a tendency towards further decentralisation. Li.Fi did an interesting [write-up on Connext](https://blog.li.fi/connext-network-a-deep-dive-13ce31586fe7) that underlines their strengths.

## Learnings and improvements

* We couldn't get all API calls to run programmatically with the time we've had. However, the codebase is relatively simple and for more granular information a full dataset could be added in as testdata.
* We focussed mainly on Layer 2's because most solutions expect gas costs to be paid by the sender and that's a pain with Ethereum mainnet.

## Resources:

### Independent Reports:
[Li.Fi report](https://hackmd.io/mFtfjic4RBCGMTE3GwFrvQ)
[Decent Report](https://hackmd.io/HYyGH0_CT7a_dcSwvLw0cg)
[Connext report](https://hackmd.io/OPUzuhBqQgumR6RioVtBEw)

### Examples, integrations, results:
[Example Connext Integration repository](https://github.com/grants-stack-frontier/cross-chain-testing-contracts)
[LiFi and Connext test results](https://docs.google.com/spreadsheets/d/171IGuvwm9fbkbq79ef16ltW4mtx18dKz0w1lrTTfqxU/edit#gid=0)
[Cross chain test CLI](https://github.com/grants-stack-frontier/cross-chain-test-cli)