XIP-6

Cross Chain Architecture

authorbilby, axe, kmao, Ray Zhu
typecore-upgrade
networkEthereum & Base
statusApproved
created2023-12-13
updated2023-12-13

Proposal Summary

This XIP proposes how Infinex will handle user cross-chain deposits and withdrawals within the Infinex Platform.

Specification

Overview

Infinex is solving the UX pain points of accessing Synthetix PerpsV3. One of these pain points is needing to bridge to Optimism (or Base) to deposit funds. This proposal offers a solution to this problem using a multi-chain architecture centred around a central ‘smart account’ (AKA trading account) on Base.

To work, the Infinex smart contracts need to perform three core actions trustless-ly:

  1. Accepting user deposits
  2. Bridging user funds
  3. Processing user withdrawals

This XIP outlines the architecture that allows Infinex to perform these actions and the initial accepted coins and chains.

Using the Circle CCTP bridge, users can deposit USDC into their trading account address on the Ethereum chain and have it automatically bridged to their Trading Account on the Base chain. The same CCTP bridge will also be used to withdraw USDC from their Trading account on the Base chain to a specified address on the Ethereum chain.

Rationale

Infinex will then provide the UX benefit of cross-chain deposits. For now, Ethereum or Base can be used as entry points for USDC deposits into the user's trading account (AKA smart account) on Base. This will open Infinex up to new customers who may be hesitant or unable to use bridges due to their UX burden, enabling them to transfer funds in and out of their trading account using their chain of choice seamlessly, with bridging facilitated under the hood by the Infinex protocol in a trustless manner.

An alternative architecture using USDC pools and wormhole cross-chain queries was considered for managing the bridging of USDC, which may be proposed for future releases when tokens other than USDC need to be supported.

This XIP proposes the use of the Circle CCTP bridge for the following reasons:

  • It follows a trustless architecture with 3rd party (Circle) attestation across chain.
  • Supports a non-custodial Infinex architecture.
  • Bridging transactions can be fulfilled independently of Infinex protocol (the caller will pay the gas).
  • CCTP was the most straightforward and most gas-efficient integration.
  • CCTP has a good balance between finality and providing settlement assurance (Base native bridge has a 7-day finality on withdrawals, CCTP ~12 minutes).

Technical Specification

Deposits

Lazy-creation of deposit accounts

Infinex is creating an L1 smart contract for each user. This is an expensive process, and to prevent Sybil attacks, it should only be done once some minimum value has been deposited. To allow for this, deposit contracts are monitored for balances by the create2 keeper and lazy-created with the create2 function once a balance has been detected.

This means a create2 salt must be stored off-chain by the contract creator (i.e. Infinex). If this salt were lost, the funds would be lost.

Create2 allows a contract address to be predicted by providing a salt value. Infinex will be creating the same address on both Ethereum and Base chains.

If a created account has a USDC balance on Ethereum, the keeper service will call a function on the Ethereum contract that will cause the contract to call the Circle CCTP bridge. This burns the tokens in exchange for a message that can be redeemed on the target chain: Base.

Redemption of the message can be facilitated by anyone, and is secure as it will automatically mint USDC into the target address in the message. This can not be altered. Infinex will run a service that will, on receipt of the CCTP message, call the Circle attestation service. The Circle attestation is required for processing a message and protects against fraudulent message processing and replay protection. The Infinex service will process the message and attestation on Base, resulting in the funds being deposited into the user's Trading account. For more details on the Trading Account, please refer to XIP-7: Infinex Accounts.

This diagram details the cross-chain flow for a deposit:

Circle Bridge Deposit Flow

Withdrawals

A user initiates a withdrawal to a specified Ethereum address. On Base, this results in a call from their Base Trading Account to the CCTP bridge. Just like the deposit flow, the CCTP bridge burns the tokens in exchange for a message that can be attested by Circle and processed on Ethereum, resulting in the minting of USDC, this time into an address specified by the user.

The amount that gets withdrawn will be the specified amount minus withdrawal fees. For more details on withdrawal fees, please see XIP-7: Infinex Accounts.

This diagram details the cross-chain flow for a withdrawal:

Circle Bridge Withdrawal Flow

Test Cases

This flow has been tested on Ethereum Goerli and Base Goerli, with funds correctly being deposited cross-chain and amounts (minus fees) being correctly withdrawn to the specified address cross-chain.

Risk

Mitigation

The Circle attestation service is down; tokens would be burnt without the ability to mint them to the user account.

No mitigation is currently proposed. Potential improvements would be to support different bridges or integrate on-chain insurance.

The Infinex contracts point to a contract that is not the circle bridge; funds could be stolen.

The proxy architecture and Infinex Protocol Config Beacon with opt-in upgrades means that users can scrutinize any changes prior to (optionally) explicitly approving the change with their browser key.

The create2 keeper does not detect a deposit; the keeper doesn't create the accounts.

The client could allow the user to fetch the create2 salt that would be used by the create2 keeper service, deploy their own Infinex smart account, and upgrade their contract to withdraw funds via the Infinex council and a browser key approval.

Accounts on L1 and L2 do not have matching addresses; deposited funds get transferred to an address the user does not control.

The create2 strategy and the proxy architecture ensures that contracts are created at the same address on both chains.

Copyright

Copyright and related rights waived via CC0.

Contribute to Proposals on GitHub