Proposal: Adding Flexibility to Bridge Implementations

To be posted to Snapshot on Jun 22, 2025

TL;DR

New Bridge Function: Copied From the Previous Proposal:

  • A new contract associated to each Carbon Vortex will have a new public function called “bridge()”
    • This does not include Ethereum
  • The details of this function on each chain will be different to fit the relevant bridge available for this chain
  • On execution:
    • Indicate amount or send the full currently available budget of the token
    • Submit a transaction to the bridge
    • Destination on Ethereum will always be the carbonVault address

Note 1: This proposal suggests no caller incentive for this Function as it is likely to be triggered by someone in the community who does not require a financial incentive - this also simplifies the contract.

Note 2: For safety, we should enforce minReturn to prevent bridge actions that “leak” funds in the process as a result of low bridge liquidity.

Update

  • This proposal provides additional flexibility beyond what was covered here: Proposal: Bridge Back to the CarbonDeFi
  • This proposal, rather than selecting a specific bridge, gives the right to use any of the following bridges on any chain where the protocol has value to be brought back to mainnet:
    • Native bridge
    • Stargate V1/V2
    • Across
    • Wormhole
    • Layer Zero
    • Axelar
    • Hyperlane
    • Chainlink CCIP

FOR

  • Allow increased flexibility as detailed above

Against

  • Make no changes
2 Likes

I’m ignorant on a lot of the technical side but why isn’t using Chainlink CCIP an option?

1 Like

I added it. Good catch Sneeze

4 Likes

I support this proposal and having multiple options means that we can always have a fallback.

3 Likes

Also I like simplifying the contract by removing the financial incentives; I think you’re totally correct to think a community member will keep an eye on it.

2 Likes

This how now been implemented

1 Like