fix: script to fill jupiter swap #819
Conversation
Signed-off-by: Reinis Martinsons <[email protected]>
Signed-off-by: Reinis Martinsons <[email protected]>
Signed-off-by: Reinis Martinsons <[email protected]>
Signed-off-by: Reinis Martinsons <[email protected]>
| @@ -76,5 +116,33 @@ export async function sendTransactionWithLookupTable( | |||
| versionedTx.sign([sender]); | |||
| const txSignature = await connection.sendTransaction(versionedTx); | |||
|
|
|||
| return { txSignature, lookupTableAddress }; | |||
| // Confirm the versioned transaction | |||
| await confirmTransaction(connection, txSignature); | |||
There was a problem hiding this comment.
This might conflict once #811 is merged in, but seems better to have reusable transaction confirmation helper
There was a problem hiding this comment.
This has some overlaps from #811 as we needed better tx confirmation for filling across+
Signed-off-by: Reinis Martinsons <[email protected]>
| const svmSpokeIdl = require("../../target/idl/svm_spoke.json"); | ||
| const svmSpokeProgram = new Program<SvmSpoke>(svmSpokeIdl, provider); | ||
| const handlerIdl = require("../../target/idl/multicall_handler.json"); | ||
| const handlerProgram = new Program<MulticallHandler>(handlerIdl, provider); |
There was a problem hiding this comment.
might want to simplify this once #806 is in
There was a problem hiding this comment.
not related to this PR, but linter picked these up
There was a problem hiding this comment.
We might also consider passing priority fees to loadExecuteRelayerRefundLeafParams, but that would require some refactor not directly related to this PR
| /* | ||
| * Prepends optional ComputeBudget instructions to the transaction instructions. | ||
| */ | ||
| export function prependComputeBudget( |
| data: Buffer.from(instruction.data, "base64"), | ||
| }); | ||
| const innerCpiLimit = 1280; | ||
| const innerCpiSize = transactionInstruction.keys.length * 34 + transactionInstruction.data.length; |
There was a problem hiding this comment.
nit: const accountMetaSize = 34
| const outputMintInfo = await provider.connection.getAccountInfo(outputMint); | ||
| if (!outputMintInfo) throw new Error("Output mint account not found"); | ||
| const outputTokenProgram = new PublicKey(outputMintInfo.owner); | ||
| const recipientOutputTA = getAssociatedTokenAddressSync(outputMint, recipient, true, outputTokenProgram); |
There was a problem hiding this comment.
Nit: shoud this be called recipientOutputATA?
| if (!outputMintInfo) throw new Error("Output mint account not found"); | ||
| const outputTokenProgram = new PublicKey(outputMintInfo.owner); | ||
| const recipientOutputTA = getAssociatedTokenAddressSync(outputMint, recipient, true, outputTokenProgram); | ||
| const handlerOutputTA = getAssociatedTokenAddressSync(outputMint, handlerSigner, true, outputTokenProgram); |
There was a problem hiding this comment.
Nit: shoud this be called handlerOutputATA?
| const message = new AcrossPlusMessageCoder({ | ||
| handler: handlerProgram.programId, | ||
| readOnlyLen: multicallHandlerCoder.readOnlyLen, | ||
| valueAmount: new BN(valueAmount), // Must exactly cover ATA creation. |
There was a problem hiding this comment.
Question: what happens if handlerATA or recipientATA already exist? Would this error if we send exempt rent x2 and we only create 1 or 0?
I have this question because it seems to me that createAssociatedTokenAccountIdempotentInstruction creates the ATA only if needed, otherwise it does nothing, that's why I consider the scenario of my question possible. is this correct?
| relayer, | ||
| addressLookupTableAccounts | ||
| ); | ||
| console.log("Fill transaction signature:", txSignature); |
There was a problem hiding this comment.
Should we log the new balances after the execution?
| const slippageBps = resolvedArgv.slippageBps || 100; // default to 1% | ||
| const maxAccounts = resolvedArgv.maxAccounts || 24; | ||
| const priorityFeePrice = resolvedArgv.priorityFeePrice; | ||
| const fillComputeUnit = resolvedArgv.fillComputeUnit || 400_000; |
There was a problem hiding this comment.
Is it possible to calculate this on the fly instead of hardcoding it or is it difficult to estimate the Jupiter transactions consumption?
|
given this POC is done, shall we merge it in so we have it within the repo? |
Adds a script to test Across+ fills with Jupiter swap integration on mainnet. Note that all remaining tokens above minimum output amount can be stolen by anyone. This could be improved by either creating a sweeper program that reads actual handler ATA balance and transfers all of them to the recipient ATA or building this functionality in the Multicall handler.
Tested on below mainnet deployments: