## Crosschain Checkout - Gitcoin Donations

The purpose of the current document is to explore different solution for the cross-chain solution outlined by GitCoin. Ideally, we identify a subset of strategies that we can explore further in the next cycle.

The goal is to aim for a one-click experience where donors can route funds to grantees in an frictionless experience with the lowest cost as possible while optimising for decentralised strategies.

## Requirements check-in

### Constraints
To address these challenges, we need to consider various solutions within our set constraints:

1. **Round operator flexibility**: Round operators should be able to deploy on any network that we support.
2. **Simplified donor experience**: The UX for donors must be straightforward and user-friendly.
3. **Minimized bridging costs**: Donors should not pay excessive fees when bridging tokens before the actual donations.
4. **Decentralized donations for project owners**: funds should be transferred directly to the project owners in a fully decentralized way, like we currently do, or they could be securely held in a vault that allows only project owners to withdraw later, without giving any permissions to round operator to withdraw the single donations.
5. **Donations transparency**: donations must be processed through a contract that emits an event to signal the donation's attributes, including the donor's address, the round ID, the project application ID, and the donated amount.
6. **No Fees Sponsorships**: We want to avoid solutions that rely on external entities sponsoring transaction fees. While doable on a round-by-round basis, such sponsorship cannot be the foundation of our long-term self-served solution.

### Nopes
Things We’ve Ruled Out:
1. **Centralized Backend Approach**: One idea is to have a centralized backend that processes messages signed by users and forwards donations across chains. However, this goes against our commitment to decentralized, censorship-resistant donations. Moving to a fully centralized server would be a step away from our primary goal of the new decentralized platform.
2. **Single Network Deployment**: We could consider deploying rounds only on a single network. Yet, this approach seems impractical as it restricts the autonomy of round operators, who come from different ecosystems like Ethereum (with all its L2 solutions), Fantom, Avalanche, etc. We aim to allow operators the freedom to choose their deployment networks.
3. **Donors Education**: Another strategy could be to educate donors to keep funds across multiple chains, instead of bridging the minimum amount needed each time they vote. However, this might not be a feasible solution for new donors, and the challenge escalates with the ever-increasing number of supported chains.

### Overview
| Solution | Round Operator Flexibility | Simplified Donor Experience | Minimized bridging costs | Decentralized donations | Donations transparency | No Fees Sponsorships | Comments |
| -------- | --------------------------- | --------------------------- | ------------------------ | --------------------------------------- | ------------------------------ | -------------------- | -------------------------- |
| 1 | ✅ | 🤷 | ✅ | ✅ | ✅ | 🤷🏼 (EOA or Safes?) | Many-to-many accounts |
| 2 | 🤷🏼 (only matching chains) | ✅ | 🤷🏼 | ✅ | 🤷🏼 (who sends?) | ✅ | Application level bridging |
| 3 ⭐️ | ✅ | 🤷🏼 | ✅ | 🤷🏼 (single token or bridge and swap?) | ✅ | ✅ | Educating on another token |
| 4 ⭐️ | ✅ | ✅ | tbd | ✅ | ✅ | 🤷🏼 (send gas) | |
| 5 | ✅ | ✅ | tbd | ✅ | 🤷🏼 (off-chain indexing) | ✅ | |
| 6 | 🤷🏼 (Safe) | ⛔️ | tbd | 🤷🏼 (additional steps needed) | 🤷🏼 (additional steps needed) | ✅ | Hits the Nopes |
| 7 | | | | | | | |
| 8 | | | | | | | |

### Open Questions

- On what level would you prefer the solution? Close to the protocol layer, close to the FE level, or something in between?
- For context: In an ideal world, any user could take the Allo Vx stack, create a round and enable cross-chain donations? Or would providing a n app suffice?
- Tokens:
- Would adding in a liquidity token (e.g. xERC20) be an option for you?
- What tokens do you want to support? ERC20s + natives?
- Proposing an incremental solution

### Threads to pull

- Application or protocol level?
- Explore bridging protocols/applications and submit them to thorough review as outlined under 'Research Proposal'
- Tradeoffs
- Direct transfer between accounts or escrow
- Gas cost (batch transfers or per tx)
- Voting data (who is msg.sender)
- Bridging solutions (xERC20, Connext, LayerZero, CCIP)

### Research Proposal:

Define top 2/3 most interesting strategies in 2/3 cycles.

- Review UX
- Review Gas cost
- Review decentralisation
- Review lock-ins/dependencies
- Review info:
**User sends the funds into a Safe on chain A for a round on chain B**
*Accounts*
e.g. User on chain A, Safe on chain A, Safe on chain B
*Funds*
e.g. Funds will be received and transfered via Safes. The voting information will follow a different path.
*Timing*
e.g. For cost efficiency, bridging funds between Safe can be daily/weekly/per round.
*Centralization*
e.g. Who controls the Safes? Are there escape hatches?
*Products*
e.g. Safe & message bridging (calculations can be off-chain, preferably message bridging)

### Application layer solutions:

Based on the constraints outlined by the Allo team, we've found 3 realistic solutions which can be pursued, tested or improved on.

### **1. Round Grantee address minting:**

#### How it could work

When a round starts, and a grantee/round admin creates a project, a set of addresses are **created**, or **inputted** for each chain the grantee wants to suppport.

#### Grantee side:

In the project creation phase, a table with a list of chains is displayed to the creator, by default all chains will be toggled on, with a list of tokens accepted for each chain: stables, and gas tokens.

Based on the Grantees requirements they can disable chain specific addresses for any reason, examples:

- The chain is banned in the grantees country
- Lack of methods to withdraw funds in the grantees location
- Loyalty or alignment with specific chains or ecosystems

#### Donors side:

When a donor wants to support a specific project, it will be added to their basket, and the receiver address will be chosen automatically based on the Donators' current chain.

- If the chain the donator uses is not supported by the grantee, a warning will be issued to the donor and the project cannot be added to the basket.

- If the chain of the donor is supported, they can proceed to checkout, a signature will be requested which gives allowance to the preferred token:
- A check is done to see if the token used is an approved stable/gas token, and if not a swap will be routed to the valid token.
- The funds will be sent to the grantee specific address

| Pros | Cons |
| -------- | -------- |
| The responsibility of bridging/swapping is not on the donator | The responsibility of bridging, swapping, withdrawing is on the grantee |
| This solution requires a minimal development efforts and can be improved incrementally based on findings and user behaviour | Grantee is responsible for managing the keys, or the addresses |
| Gas is no longer an issue as donator is prioritised | The grantees funds will be spread over multiple chains, and it might hurt grantees who receive amounts not worth paying bridge fees for |
| Maximises decentralisation, does not rely on too many third party contracts | Data analysis will be trickier due to increased amounts of addresses to track |

### **2. Cross Chain Bridging and Swapping:**

#### How it could work

When a round starts and a project is created, the grantee selects one of 10 to 20 chains supported (based on Contracts used) LiFi / SushiSwap / CCIP

The donator sees projects based on chains compatible with theirs, on checkout an automated batch transaction is created for the checkout.

#### An example transaction:

##### User:

| Token Balance | Chain | Gas Amount |
| -------- | -------- | -------- |
| 3000 USDC | Polygon | 22 MATIC |

##### Basket:

| Project | Donation | Chain | Receiver Gets |
| -------- | -------- | -------- | ------ |
| Raid Guild | 15.2 USDC | Gnosis | 15.2$ in XDAI |
| Superfluid | 100 USDC | Polygon | 100$ in MATIC |
| Optimism | 55 USDC | OP | 55$ in OP |

##### Batched Transaction:

1. User signs 1 tx
2. Swaps USDC on Polygon to Gas token on each of the specified chains, then sends to grantees/receivers

If Li.Fi is used gas could be sponsored, but in most scenarios the donor will not be on mainnet and gas should be negligible

| Pros | Cons |
| -------- | -------- |
| Swapping/Bidging is batched and automated, user only needs to sign 1 tx | Based on amount of chains, and donor's networks, gas could be costly |
| Grantee receives gas tokens or stables on their selected chai | Bridging could take some time |
| Grantee & Donor use their preferred chain | Restricted to up to 20 chains |
| Good battle tested tooling already exists | Best to limit which tokens can be donated to avoid liquidity incompatabilities between chains |

### **3. Create a new [xERC20](https://ethereum-magicians.org/t/erc-7281-sovereign-bridged-tokens/14979) token:**

Donors and Grantees deal in a single crosschain token which can be swapped with 0 slippage across 6 to 12 chains:


xERC20 tokens are supported by Connext bridge, although plans are in motion to make these tokens compatible with any bridge.

- Donors can use any tokens on a supported chain which will automatically be swapped for stables, and LPed into the new token,when the donor and grantees chains match, it is either sent to the grantee, or bridged to the grantees chosen chain

-----------------


### Resources & References:

| Product | Documentation | Type | Example |
| -------- | -------- | -------- | -------- |
| Li.Fi | [ SDK Documentation ](https://docs.li.fi/integrate-li.fi-js-sdk/install-li.fi-sdk/?utm_source=lifi&utm_medium=header_developers_get_started&utm_campaign=lifi_to_docs) | CrossChain Swap | [Jumper Swap Checkout](https://jumper.exchange/) |
| [xERC2O - Connext](https://www.connext.network/xerc20) | [ Token Standard](https://docs.connext.network/concepts/how-it-works/architecture) | CrossChain Custom Token | [Demo: Fraction Token](https://fraction.fyi/v1/) |

## Protocol layer solutions

### Unified Transaction for Multiple Bridges

4. **Central account; bridge message and/or funds; same address**
During the vote, funds are bridged and a message is transmitted to transfer funds from to the grantee
* Accounts
* User keeps same address on both the send and receive chain
* Funds
* Tokens will either be [locked](https://docs.optimism.io/builders/dapp-developers/bridging/basics) or [burned](https://docs.layerzero.network/explore/contract-standards)
* Funds will be transfered at the speed of the bridging
* After the transfer of the funds, a signed message is executed that executes the vote
* Timing
* The bridging of funds can be slow to execute, so some margins need to be taking into account when tallying the votes for matching funds distribution
* Centralization
* Depending on the implementation; there's a dependency on either a single bridge ([OP Standard Bridge](https://docs.optimism.io/builders/dapp-developers/bridging/standard-bridge)) or a group of verifiers ([Layer0](https://docs.layerzero.network/explore/decentralized-verifier-networks))
* Bridges enable communication between one-to-many chains and different bridges could be utilized depending on the required networks
* Messages
* The user would need to sign for both the bridging and the transfer to the grantee
* Products
* Native bridges (SuperChain, Arbitrum, etc..)
* [Layer0](https://layerzero.network/)
* [Sygma](https://docs.buildwithsygma.com/sdk/quickstart/transfertoken)
* [CCIP](https://chain.link/cross-chain
* [OZ Defender](https://www.openzeppelin.com/defender?utm_campaign=Defender&utm_source=docs&utm_content=oz)

5. **Central account; bridge message and/or funds; different address**
During the vote, funds are bridged to the address of the grantee
* Accounts
* User sends the funds via a bridge or a swap into a different account
* Funds
* Funds will be directly received by the grantee from the bridge
* Timing
* The bridging of funds can be slow to execute, so some margins need to be taking into account when tallying the votes for matching funds distribution
* Centralization
* Depending on the implementation; there's a dependency on either a single bridge ([OP Standard Bridge](https://docs.optimism.io/builders/dapp-developers/bridging/standard-bridge)) or a group of verifiers ([Layer0](https://docs.layerzero.network/explore/decentralized-verifier-networks))
* Bridges enable communication between one-to-many chains and different bridges could be utilized depending on the required networks
* The user would need to sign for bridging
* Products
* Native bridges (SuperChain, Arbitrum, etc..)
* [Layer0](https://layerzero.network/)
* [Sygma](https://docs.buildwithsygma.com/sdk/quickstart/transfertoken)
* [CCIP](https://chain.link/cross-chain)
* [OZ Defender](https://www.openzeppelin.com/defender?utm_campaign=Defender&utm_source=docs&utm_content=oz)
6. **Central account; bridge funds; same address**
This is not an option because we need to get the funds to the grantees with minimal friction to the user. Only bridging funds would require a) education, b) additional action and/or c) keeping funds on multiple chains.

### User-Selected Donation Chains
7. Asynchronous donations cross-chain
User sends the funds into a Safe on chain A for a round on chain B
* Accounts
User on chain A, Safe on chain A, Safe on chain B
* Funds
* Funds will be received and transfered via Safes. The voting information will follow a different path.
* Timing
* For cost efficiency, bridging funds between Safe can be daily/weekly/per round.
* Centralization
* Who controls the Safes? Are there escape hatches?
* Products
* Safe
* Message bridging (calculations can be off-chain, preferably message bridging)
8. Syncronous grants rounds cross-chain
Taking into account the purpose of Allo V2 this would break with decentralized voting and the possibility to run rounds in a flexible manner. Not prefered.