Simple Cross-chain Retirement Interface

[0xAurelius]

Is your feature request related to a problem? Please describe.
Simple UX for retiring pool tokens using $KLIMA from any chain using pre-populated parameters as much as possible

Describe the solution you'd like
A new app, integrating latest cross-chain functionality via Axelar to issue retirements from multiple chains to underlying Polygon carbon credit tokens.

As a first pass, simply retire the default project from BCT pool, meaning we hard-code those addresses into the function call:

• BCT pool: https://polygonscan.com/address/0x2f800db0fdb5223b3c3f354886d907a671414a7f
• default project token address: 0xb139C4cC9D20A3618E9a2268D73Eff18C496B991

This initial implementation should pre-populate as many fields as possible in the retireExactCarbonDefault function: https://docs.klimadao.finance/developers/contracts/retirement/v2-diamond/generalized-retirement#retire-exact-carbon

For retirement message, offer the user a generic pre-filled value (e.g. "Doing my part to support climate action") with the opportunity to override if they want

Screenshots from optima about requirements:

Other notes on requirements:

• At top right a typical “multichain toggle” , including major chains supported out of the box by Axelar, e.g. Optimism, Base, Arbitrum
• Example testnet retirement here: https://testnet.axelarscan.io/gmp/0xb347fa5d5ecda828983df076ac01a99bb40dee8bd9cdc330756a59270c55d8d4
• Coordinate with @cujowolf on deployment of Axelar contract to additional chains, see solidity repo PR for Axelar code: Add initial Axelar cross-chain retirement contract klimadao-solidity#57

Describe alternatives you've considered
This doesn't really fit into Carbonmark's roadmap so having it as a standalone application within the KlimaDAO app is the quickest path forward - but we won't offer the full marketplace functionality that Carbonmark has as that's way too much scope

Additional context
To create and deploy a new app within this repo:

• npx create-next-app to get it set up
• add it to the package.json workspaces array, add some build scripts for convenience
• npm i --package-lock-only to update the lock file
• in vercel it should "Just Work"TM using the same config as our other apps
• reach out to @Atmosfearful when ready for a subdomain

[Atmosfearful]

Overview:

• This will be a new contract ("Infinity Cross-chain Retire Contract") on Base that Axelar interacts with.
• This user is calling a method on the Infinity cross-chain contract - nativeUsdcDefaultRetirement()
• Supports Base USDC 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 as payment method
  Method may be subject to change but here is the current signature:

function nativeUsdcDefaultRetirement(
    string memory destinationChain,
    uint256 usdcAmount,
    bytes memory retirementData,
    bytes32 traceId,
    address fallbackRecipient
) external

Notes:
We don't know if the final polygon retirement transaction will succeed or fail until after:

1. Confirmed in a block on Base
2. Communicated across the Axelar network
3. Initiated (via the Axelar relayer) on Polygon
   This can take between 5-20 minutes.

• When a txn fails it is funded to the fallbackRecipient on polygon. So we must make sure to prefill that address, and the beneficiary address, as the connected users wallet (not configurable).

User needs a way to track the above 3 steps:

• We can construct a link to Axelarscan by using the same Base transaction hash
• We can link the user to /retirements and let the user know that their retirement will appear there when they are confirmed

Constructing the retirement data:

• The data that is passed in to the retirementData argument above must properly formatted InputData for a default BCT retirement retireExactCarbonDefault
  Shown here on polygonscan
  
  This can be accomplished by encoding in ethers using the Aggregator ABI

    const iface = new ethers.utils.Interface(retireCarbonAbi)
    const retirementData = iface.encodeFunctionData('retireExactCarbonDefault', [
        USDC['polygon'],
        poolToken,
        maxAmountIn,
        retireAmount,
        retiringEntityString,
        beneficiaryAddress,
        beneficiaryString,
        retirementMessage,
        0
    ])

• Add default max slippage of 2%, the client converts this to a maxAmountIn value (USDC).
• indicate this 2% max slippage in the UI and let the user know failed transactions are refunded on Polygon to the same wallet address.

Remaining work to be done on the Contract side:

1. Make $KLIMA bridgeable to and from base via Axelar
2. Update contract to use $KLIMA as payment in addition to $USDC (the frontend will only support Base Native USDC)

[jabby09]

@0xMakka please checkin with @Atmosfearful before you start on this because he did some work in a local PR related to completing this work

[0xMakka]

@Atmosfearful @cujowolf a few quick questions

1. Max slippage requirements - in the legacy offset app, the slippage/aggregation fee looks to be 1%, should this slippage be 1% or 2% for base? Also this still needs to be included right, the fact we are only supporting KLIMA as the payment token and not USDC?

2. Approvals - does the Axelar contract still require an approval step? i.e. approval to spend the users Base KLIMA?

3. @Atmosfearful On the UI, it's mentioned above that a retirement can take up to 20 minutes. After submitting the transaction, we receive a transaction hash from axelar. Is it enough to display this axelar transaction link to the user or should we be putting both this link and a link to the /retirements page on carbonmark with the user address?