feat: build cross swap tx #1274
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
dohaki
requested review from
nicholaspai,
mrice32,
gsteenkamp89,
bmzig and
pxrl
| ? getMultiCallHandlerAddress(destinationChainId) | ||
| : crossSwapQuotes.crossSwap.recipient, | ||
| inputToken: crossSwapQuotes.bridgeQuote.inputToken.address, | ||
| outputToken: crossSwapQuotes.bridgeQuote.outputToken.address, |
There was a problem hiding this comment.
In the case of outputToken bridged USDC on a CCTP chain, would we short-circuit the destination swap?
There was a problem hiding this comment.
yep, we do the check here https://github.com/across-protocol/frontend-v2/blob/8ac1e952dee670245ffd52501e469f6b6b5e2c49/api/_dexes/cross-swap.ts#L129
and if it's a normal bridge route we don't populate a destination swap quote
| async function getFillDeadline(spokePool: SpokePool): Promise<number> { | ||
| const calls = [ | ||
| spokePool.interface.encodeFunctionData("getCurrentTime"), | ||
| spokePool.interface.encodeFunctionData("fillDeadlineBuffer"), | ||
| ]; | ||
|
|
||
| const [currentTime, fillDeadlineBuffer] = | ||
| await spokePool.callStatic.multicall(calls); | ||
| return Number(currentTime) + Number(fillDeadlineBuffer); | ||
| } |
There was a problem hiding this comment.
This also exists in src/utils/bridge.ts - is there anywhere common for generic utilities to be placed here, or do we have to upstream that to the sdk?
There was a problem hiding this comment.
Yea, we are currently in a weird state with API and FE source code... We can not share unfortunately because our current folder structure is not optimized for sharing utilities between API and FE without blowing up the bundle size.
So upstreaming to the SDK would prob make sense
api/_dexes/uniswap.ts
Outdated
| amount: destinationSwapQuote.maximumAmountIn | ||
| .mul( | ||
| ethers.utils.parseEther( | ||
| (1 + Number(crossSwap.slippageTolerance) / 100).toString() |
There was a problem hiding this comment.
This is still some old design decision from our original swap implementation. There the 1inch API required slippage to be set like that, e.g. 1 = 1%. So what I am doing here is parsing that to our internal BigNumber percent representation.
I agree though that this is a bit confusing 🤔 The parsing should probably already happen at a higher level. Will refactor this
There was a problem hiding this comment.
I will tackle that in a separate PR though... Because the required changes are a bit more than expected
Closes ACX-3286
This adds cross swap tx building. Here are some example tx for the different cases: