# ITIP-006: Native Cross Chain Functionality

## Abstract

Index Cooperative products are currently limited to a single blockchain, constraining asset management strategies and confining users to a singular blockchain ecosystem. The absence of native cross-chain functionality in Index Cooperative and other onchain structured products presents a significant market opportunity. Users stand to gain from streamlined and robust asset management solutions that operate across multiple blockchains. This proposal seeks to address this shortfall by evaluating the necessity and impact of integrating cross-chain functionalities into structured products.

## Motivation

**Key Cross-Chain Features for Index Cooperative Products**

+ **Multi-Chain Distribution**: Allows users to access Index Cooperative products on various blockchains, expanding market access and reach.

+ **Cross-Chain Custody**: Allows users to directly bridge Index Cooperative products across different blockchains, eliminating reliance on secondary markets.

+ **Multi-Chain Collateral**: Allows products to combine positions from multiple blockchains into a single, unified product.

+ **Cross-Chain Rebalance** Allows products to rebalance collateral across different blockchains.

## Background Information

### Set Protocol V2

Set Protocol V2 has been separately deployed on multiple chains. This enabled Index Cooperative to create separate deployments of ETH2x-FLI on Ethereum and ETH2x-FLI-p on Polygon. The deployment of ETH2x-FLI-p was designed to serve users on cheaper chain than Ethereum.

### Rhino and Argent

Rhino and Argent bridge Index Cooperative products to Layer 2 networks and are involved in market making on L2 decentralized exchanges. This partnership enables user access to these products chains cheaper than Ethereum.

+ [Rhino Docs](https://docs.rhino.fi/)
+ [Index on Argent Tutorial](https://indexcoop.com/blog/how-to-buy-crypto-indexes-argent-zksync)

### LayerZero

LayerZero is an omnichain interoperability protocol that facilitates lightweight message passing across different chains. It is suitable for implementing cross-chain features for Index Cooperative products and operates on networks including Ethereum, Base, Polygon, Arbitrum, Optimism, Avalanche, Binance Smart Chain.

+ [LayerZero Docs](https://layerzero.gitbook.io/docs/)
+ [LayerZero Supported Chains](https://layerzero.gitbook.io/docs/technical-reference/mainnet/supported-chain-ids)

### Chainlink CCIP

Chainlink's Cross-Chain Interoperability Protocol (CCIP) supports three main capabilities:

+ **Arbitrary Messaging**: The ability to send arbitrary data (encoded as bytes) to a receiving smart contract on a different blockchain.
+ **Token Transfer**: The capability to transfer tokens to a smart contract or directly to an EOA (Externally Owned Account) on a different blockchain.
+ **Programmable Token Transfer**: The functionality to simultaneously transfer tokens and arbitrary data (encoded as bytes) within a single transaction.

It is suitable for implementing cross-chain features for Index Cooperative products and operates on networks including Ethereum, Base, Polygon, Arbitrum, Optimism, Avalanche, Binance Smart Chain.
+ [CCIP Docs](https://docs.chain.link/ccip)

### Maintaining Light Nodes and Relayers

An alternative approach is developing an in-house omnichain messaging solution using relayers. This method could potentially reduce fees but requires ongoing technical maintenance and is complex to implement.

## Open Questions

Pose any open questions you may still have about potential solutions here. We want to be sure that they have been resolved before moving ahead with talk about the implementation. This section should be living and breathing through out this process.

+ What cross-chain risks are we unwilling to accept?
+ *Answer*
+ What cross-chain risks are we willing to accept?
+ *Answer*

## Feasibility Analysis

### Maintaining Relayers

Implementing cross-chain functionalities in an Index Cooperative product could involve deploying smart contracts on various chains which communicate via relayers maintained in-house.

+ Pros
+ Potentially reduces fees by eliminating a third-party fee collector, leading to tighter spreads.
+ Cons
+ The ongoing maintenance of relayers introduces complexity and uncertainty.

### LayerZero Integration

Cross-chain functionalities could be implemented through integration with LayerZero smart contracts.

+ Pros
+ Offloads the requirement of maintaining messaging infrastructure from the Index Cooperative team.
+ Cons
+ Involves dependency on LayerZero as an external service, which includes additional fees.

### CCIP Integration

Cross-chain functionalities could be implemented through integration with CCIP smart contracts.

+ Pros
+ Offloads the requirement of maintaining messaging infrastructure from the Index Cooperative team.
+ Cons
+ Involves dependency on CCIP as an external service, which includes additional fees.

## Recommended Solution

The proposed solution is the development of a new integration with **Chainlink's Cross-Chain Interoperability Protocol (CCIP)**. This integration is aimed at enabling new Index Cooperative products that fulfill all four of the key cross-chain capabilities identified: **Multi-Chain Distribution**, **Cross-Chain Custody**, **Multi-Chain Collateral**, **Cross-Chain Rebalance**.

The decision to choose CCIP over alternatives like LayerZero or maintaining an in-house relayer network is based on several key factors:

+ **Reduced Maintenance**: The integration with CCIP significantly reduces the need for continuous internal maintenance, offering a clear advantage over the complexities associated with operating an independent relayer network.
+ **Established Partnerships and Resources**: The existing partnerships and accessible developer resources with Chainlink make it a more viable option compared to LayerZero.

By adopting CCIP, Index Cooperative not only meets the essential requirements for enhanced cross-chain functionality but also leverages its operational strengths and strategic partnerships effectively.

## Timeline

| Action | End Date | Description |
|--- |--- |--- |
| Checkpoint 1 - Recommended Solution | 12/1 | Finalize and agree on a recommended solution in collaboration with Engineering, Product, Ops, and Growth teams. |
| Checkpoint 2 - Product Requirements | TBD | Establish and agree on detailed product requirements with the Product and Engineering teams. |
| Checkpoint 3 - Implementation | TBD | Complete the development and internal testing of smart contracts. |
| External Audit | TBD | Conduct an external audit of the smart contracts with a selected partner. |
| Deployment | TBD | Deploy the finalized smart contracts onto the blockchains. |

## Checkpoint 1

Before more in depth design of the contract flows lets make sure that all the work done to this point has been exhaustive. It should be clear what we're doing, why, and for who. All necessary information on external protocols should be gathered and potential solutions considered. At this point we should be in alignment with product on the non-technical requirements for this feature. It is up to the reviewer to determine whether we move onto the next step.

**Engineering Reviewer**:

**Product Reviewer**:

**Growth Reviewer**:

**Ops Reviewer**:

## Proposed Architecture Changes

## Requirements

## User Flows

## Checkpoint 2

Before we spec out the contract(s) in depth we want to make sure that we are aligned on all the technical requirements and flows for contract interaction. Again the who, what, when, why should be clearly illuminated for each flow. It is up to the reviewer to determine whether we move onto the next step.

**Engineering Reviewer**:

**Product Reviewer**:

## Specification

### [Contract Name]

#### Inheritance

#### Structs

#### Constants

#### Public Variables

#### Modifiers

#### Functions

## Checkpoint 3
Before we move onto the implementation phase we want to make sure that we are aligned on the spec. All contracts should be specced out, their state and external function signatures should be defined. For more complex contracts, internal function definition is preferred in order to align on proper abstractions. Reviewer should take care to make sure that all stake holders (product, app engineering) have their needs met in this stage.

**Engineering Reviewer**:

## Implementation
[Link to implementation PR]()
## Audit
[Link to Audit on feature]()
## Documentation
[Link to Documentation on feature]()
## Deployment
[Link to Deployment]()