feat: Solana relayFeeCalculator and gasPriceOracle #980

bmzig · 2025-04-10T21:56:54Z

This should implement the relayFeeCalculator (and by extension, the gasPriceOracle) for svm. It will contain some other utilities which are used by those structures.

Signed-off-by: bennett <[email protected]>

bmzig · 2025-04-16T18:56:57Z

I can confirm that the gas price oracle is giving reasonable estimates for priority fees/base fees (assuming that the fill transaction only requires a single signature).

The relay fee calculator simulation is still failing somewhere in the fill instruction, and I haven't figured out if this is an issue with how the instruction is being created or if I am just testing with relay data values that would cause the SvmSpoke to revert, but even if it is incorrect, this should at most require a small change in fillRelayInstruction.

bmzig · 2025-04-16T18:58:12Z

src/arch/svm/SpokeUtils.ts

+ * @param extraSeed An optional extra seed. Defaults to 0.
+ * @returns The PDA for the State account.
+ */
+export async function getStatePda(programId: string, extraSeed = 0): Promise<Address> {


I generally just copied the format for these functions from #978

#978 has been merged now so it should be OK to rebase to include those (fingers crossed for no merge conflicts...)

bmzig · 2025-04-16T19:04:25Z

src/gasPriceOracle/adapters/solana.ts

+  const recentPriorityFees = await provider.getRecentPrioritizationFees(instructionAddresses).send();
+
+  const nonzeroPrioritizationFees = recentPriorityFees.map((value) => value.prioritizationFee).filter((fee) => fee > 0);
+  const totalPrioritizationFees = nonzeroPrioritizationFees.reduce((acc, fee) => acc + fee, BigInt(0));


Am definitely open for ideas on how to optimize the priority fee calculation. I can get nonzero priority fees for the most part, presumably since TOKEN_PROGRAM_ADDRESS is one of the instructionAddresses, but a lot of slots suggest a priority fee of zero for one reason for another, and this RPC by default will query 100 slots, so it's possible under this method that we obtain a prioritization fee which is dominated by data from older slots.

The JSON-RPC docs for Solana say they retain fee data for 150 slots - do you only get the last 100 on query?

In any case, would we consider just taking the last n slots - i.e. 25? That'd give 10 seconds of coverage, which is pretty long in relative terms. Is there additionally some minimum priority fee that we might want to set, just so that we don't submit at 0?

Signed-off-by: bennett <[email protected]>

bmzig · 2025-04-17T17:27:15Z

I'm now getting both reasonable gas price estimations and reasonable compute unit estimations.

Signed-off-by: bennett <[email protected]>

pxrl · 2025-04-22T13:48:41Z

src/arch/svm/SpokeUtils.ts

+ * @param extraSeed An optional extra seed. Defaults to 0.
+ * @returns The PDA for the State account.
+ */
+export async function getStatePda(programId: string, extraSeed = 0): Promise<Address> {


#978 has been merged now so it should be OK to rebase to include those (fingers crossed for no merge conflicts...)

src/arch/svm/SpokeUtils.ts

pxrl · 2025-04-23T16:46:20Z

src/arch/svm/SpokeUtils.ts

+): Promise<Address<string>> {
+  const [associatedToken] = await getProgramDerivedAddress({
+    programAddress: ASSOCIATED_TOKEN_PROGRAM_ADDRESS,
+    seeds: [owner.toBuffer(), SvmAddress.from(tokenProgramId).toBuffer(), mint.toBuffer()],


Is the user of Buffer here a hangover from the contracts implementation? Seeds in Kit have to conform to type Seed = ReadonlyUint8Array | string;, so it should be OK to pass strings in; I think this should work:

Suggested change

seeds: [owner.toBuffer(), SvmAddress.from(tokenProgramId).toBuffer(), mint.toBuffer()],

seeds: [owner.toAddress(), tokenProgramId, mint.toAddress()],

I'm actually not too sure how the string encoding is supposed to work here, but each character is treated as a byte, so passing in a string here will have getProgramDerivedAddress interpret the input as 66 byte strings, not 32 bytes.

pxrl · 2025-04-25T07:12:51Z

src/arch/svm/SpokeUtils.ts

+    mint: mint.toV2Address(),
+    delegate: statePda,
+    owner: relayer.toV2Address(),
+    amount: amount.toBigInt(),


Neat - TIL!

pxrl · 2025-04-25T07:14:26Z

src/gasPriceOracle/adapters/solana.ts

+  const { unsignedTx: _unsignedTx } = opts;
+
+  // Cast the opaque unsignedTx type to a solana-kit CompilableTransactionMessage.
+  const unsignedTx = _unsignedTx as CompilableTransactionMessage;


It'd be nice to verify this via superstruct - then we'd inherit type inference as well.

pxrl · 2025-04-25T07:22:31Z

src/gasPriceOracle/adapters/solana.ts

+  const recentPriorityFees = await provider.getRecentPrioritizationFees(instructionAddresses).send();
+
+  const nonzeroPrioritizationFees = recentPriorityFees.map((value) => value.prioritizationFee).filter((fee) => fee > 0);
+  const totalPrioritizationFees = nonzeroPrioritizationFees.reduce((acc, fee) => acc + fee, BigInt(0));


The JSON-RPC docs for Solana say they retain fee data for 150 slots - do you only get the last 100 on query?

In any case, would we consider just taking the last n slots - i.e. 25? That'd give 10 seconds of coverage, which is pretty long in relative terms. Is there additionally some minimum priority fee that we might want to set, just so that we don't submit at 0?

pxrl · 2025-04-25T07:29:47Z

src/gasPriceOracle/oracle.ts

+  const isEthersProvider = provider instanceof providers.Provider;
+  // Exit here if we need to estimate on Solana.
+  if (!isEthersProvider) {


I wonder if we should make chainId a mandatory field in GasPriceEstimateOptions, because we can't resolve the Solana "chain Id" via an RPC call, so this won't scale beyond one non-evm/svm chain.

pxrl · 2025-04-25T07:31:24Z

src/gasPriceOracle/oracle.ts

+      ...opts,
+      chainId: CHAIN_IDs.SOLANA,
+    };
+    return solana.messageFee(provider as SolanaProvider, optsWithDefaults);


Is type inference not working on provider ? It might work if line 60 is changed if (!provider instanceof providers.Provider). We might alternatively want a superstruct discriminator to handle it for us.

pxrl · 2025-04-25T07:33:14Z

src/relayFeeCalculator/chain-queries/baseQuery.ts

@@ -213,7 +213,9 @@ export class QueryBase implements QueryInterface {
        ? Promise.resolve({ maxFeePerGas: _gasPrice })
        : getGasPriceEstimate(provider, { chainId, baseFeeMultiplier, priorityFeeMultiplier, transport, unsignedTx }),
    ] as const;
-    const [nativeGasCost, { maxFeePerGas: gasPrice }] = await Promise.all(queries);
+    const [nativeGasCost, _gasPriceEstimate] = await Promise.all(queries);
+    // It should be safe to cast to an EvmGasPriceEstimate here since QueryBase is only used for EVM chains.


It's probably a good use case for an assert(EvmGasPriceEstimate.is(gasPriceEstimate)). We'd need superstruct defs for this.

pxrl · 2025-04-25T07:42:51Z

src/utils/SpokeUtils.ts

+function _getRelayDataHashSvm(relayData: RelayData, destinationChainId: number): string {
+  const bufferFromHexString = (hex: string, littleEndian: boolean = false) => {
+    const buffer = Buffer.from(hex.slice(2), "hex");
+    if (buffer.length < 32) {
+      const zeroPad = Buffer.alloc(32);
+      buffer.copy(zeroPad, 32 - buffer.length);
+      return littleEndian ? zeroPad.reverse() : zeroPad;
+    }
+    return littleEndian ? buffer.slice(0, 32).reverse() : buffer.slice(0, 32);
+  };
+  const bufferFromInt = (num: BigNumber, byteLength: number, littleEndian: boolean = true) => {
+    const buffer = Buffer.from(num.toHexString().slice(2), "hex");
+    if (buffer.length < byteLength) {
+      const zeroPad = Buffer.alloc(byteLength);
+      buffer.copy(zeroPad, byteLength - buffer.length);
+      return littleEndian ? zeroPad.reverse() : zeroPad;
+    }
+    return littleEndian ? buffer.slice(0, byteLength).reverse() : buffer.slice(0, byteLength);
+  };
+  const contentToHash = Buffer.concat([
+    bufferFromHexString(relayData.depositor),
+    bufferFromHexString(relayData.recipient),
+    bufferFromHexString(relayData.exclusiveRelayer),
+    bufferFromHexString(relayData.inputToken),
+    bufferFromHexString(relayData.outputToken),
+    bufferFromInt(relayData.inputAmount, 8),
+    bufferFromInt(relayData.outputAmount, 8),
+    bufferFromInt(toBN(relayData.originChainId), 8),
+    bufferFromInt(relayData.depositId, 32, false),
+    bufferFromInt(toBN(relayData.fillDeadline), 4),
+    bufferFromInt(toBN(relayData.exclusivityDeadline), 4),
+    bufferFromHexString(getMessageHash(relayData.message)),
+    bufferFromInt(toBN(destinationChainId), 8),
+  ]);
+  return keccak256(contentToHash);
+}


Damn; this one caught me by surprise. Can we stick it in src/arch/svm/SpokeUtils.ts ? We might also want to relocate the EVM part as well, so getRelayDataHash() should be pretty thin as a result.

Co-authored-by: Paul <[email protected]>

Signed-off-by: bennett <[email protected]>

bmzig added 2 commits April 10, 2025 16:51

feat: relayFeeCalculator & gasPriceOracle

5270a3e

Signed-off-by: bennett <[email protected]>

changes

590faee

Signed-off-by: bennett <[email protected]>

bmzig changed the base branch from master to epic/svm-client April 11, 2025 18:22

bmzig added 6 commits April 11, 2025 13:26

Merge branch 'epic/svm-client' into bz/relayFeeSol

734323f

Signed-off-by: bennett <[email protected]>

compile

8259b8d

Signed-off-by: bennett <[email protected]>

remove some spl dependencies

f6a7b25

Signed-off-by: bennett <[email protected]>

some clean up

73c16fa

Signed-off-by: bennett <[email protected]>

wip

f299610

Signed-off-by: bennett <[email protected]>

clean up

1241d80

Signed-off-by: bennett <[email protected]>

bmzig changed the title ~~[wip] feat: relayFeeCalculator & gasPriceOracle~~ feat: Solana relayFeeCalculator and gasPriceOracle Apr 16, 2025

bmzig marked this pull request as ready for review April 16, 2025 18:56

bmzig commented Apr 16, 2025

View reviewed changes

fix relay hash calculations

6a18985

Signed-off-by: bennett <[email protected]>

bmzig requested review from nicholaspai, dohaki and pxrl April 17, 2025 17:27

bmzig added 2 commits April 17, 2025 16:55

remove console.log

915380a

Signed-off-by: bennett <[email protected]>

move little endian check

199535d

Signed-off-by: bennett <[email protected]>

pxrl reviewed Apr 25, 2025

View reviewed changes

bmzig and others added 3 commits April 25, 2025 08:20

Apply suggestions from code review

06c872b

Co-authored-by: Paul <[email protected]>

Merge branch 'epic/svm-client' into bz/relayFeeSol

603f169

Signed-off-by: bennett <[email protected]>

updates

6186021

Signed-off-by: bennett <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: Solana relayFeeCalculator and gasPriceOracle #980

feat: Solana relayFeeCalculator and gasPriceOracle #980

bmzig commented Apr 10, 2025

bmzig commented Apr 16, 2025

bmzig Apr 16, 2025

pxrl Apr 22, 2025

bmzig Apr 16, 2025

pxrl Apr 25, 2025

bmzig commented Apr 17, 2025

pxrl Apr 22, 2025

pxrl Apr 23, 2025

bmzig Apr 25, 2025

pxrl Apr 25, 2025

pxrl Apr 25, 2025

pxrl Apr 25, 2025

pxrl Apr 25, 2025

pxrl Apr 25, 2025

pxrl Apr 25, 2025

pxrl Apr 25, 2025

	seeds: [owner.toBuffer(), SvmAddress.from(tokenProgramId).toBuffer(), mint.toBuffer()],
	seeds: [owner.toAddress(), tokenProgramId, mint.toAddress()],

feat: Solana relayFeeCalculator and gasPriceOracle #980

Are you sure you want to change the base?

feat: Solana relayFeeCalculator and gasPriceOracle #980

Conversation

bmzig commented Apr 10, 2025

bmzig commented Apr 16, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bmzig commented Apr 17, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment