feat: socket cctp, across scripts #1
Conversation
src/contracts/socket/index.ts
Outdated
| encodedFunctionData, | ||
| 4, // first 4 bytes are the function selector | ||
| 32, // first 32 bytes of the params are the amount | ||
| sourceAmountIncludingSurplusBytes |
There was a problem hiding this comment.
How does this work?
We update the sell amount, but does it increase the buy amount too so we get more tokens?
There was a problem hiding this comment.
We're not updating the sell amount here. We check the cowshed balance and use it to update the input amount for the bridge contract function call here.
There was a problem hiding this comment.
Output amount on the destination chain depends on this bridge input amount
There was a problem hiding this comment.
Output amount on the destination chain depends on this bridge input amount
If we just modify the input amount, what guarantees the rate the user receive?
There was a problem hiding this comment.
If we show the user a quote where they can bridge 100 DAI in ethereum and receive 100 DAI in Arbitrum (1:1).
If we get 110 DAI instead, does the user have any guarantees they get at least 10 extra DAI in Arbutrum?
There was a problem hiding this comment.
In case of CCTP:
CCTP will mint whatever amount of input token is burned on the source chain. And we're only cutting a small standard fee on source. So, since the burned amount includes swap surplus, the surplus will be included in the minted amount in dest chain
In case of Across:
We've pushed a few changes that also updates the outputAmount param for depositV3(). We calculate the % diff bw original input amount and the new input amount including surplus and apply the same % diff on the original outputAmount at runtime. This helps avoid any issues due to decimals or price bw the src and dest tokens
Commit: 10eb739
There was a problem hiding this comment.
Sample Across swap txns:
-
Sample 1
-
Sample 2
src/contracts/socket/index.ts
Outdated
| planner.add(approvalTokenContract.approve(allowanceTarget, allowanceToSet)); | ||
| } | ||
|
|
||
| const bytesLibContractAddress = '0x8f6BA63528De7266d8cDfDdec7ACFA8446c62aB4'; |
There was a problem hiding this comment.
Will this contract be the same in every network?
There was a problem hiding this comment.
I don't see anuything in Ethereum for example https://etherscan.io/address/0x8f6BA63528De7266d8cDfDdec7ACFA8446c62aB4
There was a problem hiding this comment.
This is currently only deployed on Arbiturm for this PoC. Need to deploy on all chains and will share a mapping or deploy at a deterministic address everywhere
| const txData = await getBungeeRouteTransactionData(route); | ||
| const { routeId, encodedFunctionData } = decodeBungeeTxData( | ||
| txData.result.txData | ||
| ); |
There was a problem hiding this comment.
Will we be able to verify this data to guarantee we don't ask users to blind-sign on something returned from the API?
There was a problem hiding this comment.
We've added a calldata verification step in our PoC script
Basically we have a verifier contract which you could input the encoded calldata received from our backend and the expected values for key params like the input amount, recipient, destination chain id, token contract etc. and the verifier will validate if the encoded calldata does match the expected values.
You'll find it implemented in this commit: b16b3ff
These are the relevant verified contracts:
SocketVerifier: https://arbiscan.io/address/0x69D9f76e4cbE81044FE16C399387b12e4DBF27B1#code
AcrossV3Verification: https://arbiscan.io/address/0x2493Ac43A301d0217abAD6Ff320C5234aEe0931d#code
CCTPVerification: https://arbiscan.io/address/0xF58Db19f264359D6687b5693ee516bf316BE3Ba6#code
There was a problem hiding this comment.
Let us know if this helps the verifiability of the bridge txn calldata
There was a problem hiding this comment.
That's great, thank you!
BTW, there's a typo in this contract function: validateRotueId
Better to fix it while it still in a single chain IMO :)
There was a problem hiding this comment.
Actually SocketVerifier is already deployed on a few chains like arbitrum, optimism, polygon at the same address for a few other bridges and actively used for similar purposes
There was a problem hiding this comment.
Oh I see! I guess I'll have to fight with my OCD and accept rotue then 😅
| } | ||
| */ | ||
|
|
||
| export async function run() { |
There was a problem hiding this comment.
Have added a script that shows three ways to fetch bridge status from our indexer based on cowswap order id
Commit: 3436c8f
3 participants
No description provided.