Open 0xAurelius opened 3 months ago
Overview:
nativeUsdcDefaultRetirement()
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:
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:
Constructing the retirement data:
retirementData
argument above must properly formatted InputData
for a default BCT retirement retireExactCarbonDefault
Shown here on polygonscan
const iface = new ethers.utils.Interface(retireCarbonAbi)
const retirementData = iface.encodeFunctionData('retireExactCarbonDefault', [
USDC['polygon'],
poolToken,
maxAmountIn,
retireAmount,
retiringEntityString,
beneficiaryAddress,
beneficiaryString,
retirementMessage,
0
])
maxAmountIn
value (USDC).Remaining work to be done on the Contract side:
@0xMakka please checkin with @Atmosfearful before you start on this because he did some work in a local PR related to completing this work
@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?
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:
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-carbonFor 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:
![offset2](https://github.com/KlimaDAO/klimadao/assets/91024694/2c070cc2-dec8-4bb6-8013-169a2e5613f3)
Other notes on requirements:
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 upnpm i --package-lock-only
to update the lock file