chore: added gas estimation api to planner #11953

frazarshad · 2025-09-18T11:04:31Z

Description

Includes code to add gas estimation in planner. It estimates two different types of gas values. Outgoing as well as incoming.

For the outgoing txs i.e Agoric -> EVM. We have a record of gasLimitEstimates that are representative of real world gas amounts used during makeAccount / supply / withdraw tx.

At the moment there are only two types of gas limits we've added. one for the execution of the factory contract. the other for the execution of the wallet contract.
In the future in place of the Wallet gas limit, we would have a list of gas Limits representing each item in the matrix {supply, withdraw} x {Aave, Compund, Beefy} since each is silghtly different and it would be more efficient to have the minimum possible value for each

For incoming, the API call the estimation seems to be off according to our testing. The API gives an esitmate which is 20x higher than the value we use in testnet (0.0002 vs 0.005)

Testing Considerations

Tested in this Tx: https://testnet.axelarscan.io/gmp/0xa1b399894a97b70bf38302d1297fa1f6b2fd198b1fffc0529c0bb1e5c89725af-4
It supplied the build amount for the outgoing tx but also calculated the eth amount for the incoming tx

cloudflare-workers-and-pages · 2025-09-18T11:05:50Z

Deploying agoric-sdk with Cloudflare Pages

Latest commit:	`6e44475`
Status:	✅ Deploy successful!
Preview URL:	https://14f75664.agoric-sdk.pages.dev
Branch Preview URL:	https://fraz-gas-estimation.agoric-sdk.pages.dev

View logs

dckc

I'm not clear on how close to done this is supposed to be.

dckc · 2025-09-22T17:13:32Z

packages/portfolio-contract/tools/portfolio-actors.ts

 };

-export const planTransfer = (
+type GasEstimator = (chainName: AxelarChain) => {


a GasEstimator is a function that takes a chainName and gives back a thing with methods? maybe call it...

Suggested change

type GasEstimator = (chainName: AxelarChain) => {

type MakeGasEstimator = (chainName: AxelarChain) => {

dckc · 2025-09-22T17:17:27Z

packages/portfolio-contract/tools/portfolio-actors.ts

+      const evmGasEstimator = gasEstimator(evm);
+      const [gmpAccountFee, gmpWalletFee, gmpReturnFee] = await Promise.all([
+        evmGasEstimator.getFactoryContractEstimate(),
+        evmGasEstimator.getWalletEstimate(),


How much padding/slippage is in the estimate? There has to be some just to account for things changing between the time of the estimate and the time of execution.

IIUC, The consequences of estimating too low (customer's stuff doesn't work) are drastically worse than guessing too high (Agoric spends some extra BLD; I think we even get a refund).

So I'd like the padding to be around 3x.

OTOH, I gather the padding is already 20x in some cases. hm.

dckc · 2025-09-22T17:18:50Z

packages/portfolio-contract/tools/portfolio-actors.ts

-        // TODO: Rather than hard-code, derive from Axelar `estimateGasFee`.
-        // https://docs.axelar.dev/dev/axelarjs-sdk/axelar-query-api#estimategasfee
-        fee: make(feeBrand, 15_000_000n),
+        fee: make(feeBrand, gmpAccountFee),


I suggest adding a TODO to skip the account fee if the account already exists (which we can tell from accountIdByChain in the portfolio node)

dckc · 2025-09-22T17:20:13Z

services/ymax-planner/src/gas-estimation.ts

+  'function executeFactory(bytes32 commandId, string sourceChain, string sourceAddress, bytes payload)',
+  'function executeWallet(bytes32 commandId, string sourceChain, string sourceAddress, bytes payload)',
+];
+const GAS_ESTIMATOR_OWNER = 'agoric1owner';


why is it ok to not use a real bech32 address? add a comment?

this is what was provided in the consructor argument owner for the GasEstimator contract so thats what we're using here. technically it can be any arbitrary value

i'll add a comment to the code as well

dckc · 2025-09-22T17:20:54Z

services/ymax-planner/src/gas-estimation.ts

+  '0x' + bytes.map(n => n.toString(16).padStart(2, '0')).join('');
+
+const gasEstimatorContracts = {
+  mainnet: {},


I take it there's an implicit TODO here.

is this PR supposed to be DRAFT?

should this PR only be merged when we have all contracts set up on mainnet and testnet? or do we take the approach of merging this with some contracts deployed, and add more as we go?

Any PR that is forward progress without regressions is fine to merge, provided we're clear about the scope and we keep track somewhere of any remaining essential work.

I'd like to understand better what would happen if we ran this code in production. If we would hit critical problems, please add a TODO. A (draft) issue might help too.

rabi-siddique

In progress

rabi-siddique · 2025-09-23T05:09:17Z

services/ymax-planner/src/gas-estimation.ts

+      evmRpcMap[
+        `${chainConfig.chainInfo.namespace}:${chainConfig.chainInfo.reference}`
+      ];
+


We're recomputing all these things to get access to the relevant EVM chain provider. Instead you can pass evmCtx.evmProviders when calling makeGasEstimatorKit in plan-deposit.ts

rabi-siddique · 2025-09-23T05:10:12Z

services/ymax-planner/src/gas-estimation.ts

+        params: any[] = [],
+        fromAddress?: string,
+      ): Promise<bigint> => {
+        const provider = new ethers.JsonRpcProvider(rpcUrl);


This should be obtained from evmCtx.evmProviders.

rabi-siddique · 2025-09-23T05:13:54Z

services/ymax-planner/src/gas-estimation.ts

+    const axelarConf =
+      clusterName === 'mainnet' ? axelarConfig : axelarConfigTestnet;
+    const chainConfig = axelarConf[chainName];
+


I think this should happen in main.ts. That's where we setup all the configs based on the network before the planner.

rabi-siddique · 2025-09-23T05:15:26Z

services/ymax-planner/src/gas-estimation.ts

+          sourceChain,
+          destinationChain,
+          gasLimit: gasLimit.toString(),
+          sourceTokenSymbol: gasToken,


Would it fail if the gasToken is not defined? Perhaps gasToken should not be optional?

its not required in all cases where this function is used. specifically the eth -> agoric tx

rabi-siddique · 2025-09-23T05:20:26Z

services/ymax-planner/src/gas-estimation.ts

+
+      const data = await response.json();
+      return data;
+    };


I think data should be typed. Based on docs for estimateGasFee, the response seems to have this shape:

{ "totalFee": "BigNumber", "isExpressSupported": "boolean", "baseFee": "BigNumber", "expressFee": "BigNumber", "executionFee": "BigNumber", "executionFeeWithMultiplier": "BigNumber", "gasLimit": "BigNumber", "gasLimitWithL1Fee": "BigNumber", "gasMultiplier": "float", "minGasPrice": "BigNumber" }

thats in case we pass the showDetailedFees to the api, otherwise its just a number

rabi-siddique · 2025-09-23T05:41:24Z

services/ymax-planner/src/gas-estimation.ts

+
+    const generateAaveSupplyPayload = (
+      contractAddress: string,
+      payment: string,


shouldn't payment be bigint? I think in the contract code amounts are usually in bigint

rabi-siddique · 2025-09-23T05:44:32Z

services/ymax-planner/src/plan-deposit.ts

+  const gasEstimator = makeGasEstimatorKit({
+    alchemyApiKey: evmCtx.alchemyApiKey,
+    clusterName: evmCtx.clusterName,
+  });


It should be setup in main.ts and then passed to startEngine via it's powers object.

rabi-siddique · 2025-09-23T06:48:52Z

@frazarshad I’m trying to understand the flow:

We have getWalletEstimate, which calls generateAaveSupplyPayload to produce the ABI-encoded payload for the supply call.
Then we call ethGasEstimator, which seems to take the contract function name and its parameters. Internally, ethGasEstimator calls queryEstimateGas.

What I’m unclear on is: where exactly is the payload from generateAaveSupplyPayload used?
Is it being passed as the params argument in queryEstimateGas?

rabi-siddique · 2025-09-23T06:52:49Z

services/ymax-planner/src/gas-estimation.ts

+  mainnet: {},
+  testnet: {
+    Avalanche: '0x0010F196F5CD0314f68FF665b8c8eD93531112Fe',
+  },


Would be helpful to include the snowtrace link for this contract

rabi-siddique · 2025-09-23T06:53:48Z

services/ymax-planner/src/gas-estimation.ts

+const GAS_ESTIMATOR_CONTRACT_ABI = [
+  'function executeFactory(bytes32 commandId, string sourceChain, string sourceAddress, bytes payload)',
+  'function executeWallet(bytes32 commandId, string sourceChain, string sourceAddress, bytes payload)',
+];


@frazarshad where is the source code for this contract? Add a comment to share the source code link?

rabi-siddique · 2025-09-23T06:56:01Z

services/ymax-planner/src/gas-estimation.ts

+
+// arbitrary value. it just mimicks a valid command id for axelar
+const COMMAND_ID =
+  '0xddea323337dfb73c82df7393d76b2f38835d5c2bda0123c47d1a2fc06527d19f';


Include the tx link which has this command id.
Also this is a testnet transaction I think? Perhaps we would create a map to command id(s) for different chains and networks?

this is an arbitrary value it is not linked to any contract and not specific for any chain.
in actuality this is a randomly generated key created by axelar assigned to each individual transaction

since we cant generate our own, we use a value that looks like it

rabi-siddique · 2025-09-23T06:59:09Z

services/ymax-planner/src/engine.ts

+                readPublished: query.readPublished,
+                spectrum,
+                cosmosRest,
+              },


I think stuff in evmCtx should be spread out in the powers object:

{ readPublished: query.readPublished, spectrum, cosmosRest, ...evmCtx }

frazarshad · 2025-09-23T13:48:39Z

Is it being passed as the params argument in queryEstimateGas?

@rabi-siddique yes that is accurate it is being put into the params arg. these args are passed to the estimateGas API to provide it the arguments with which to execute the contract function

dckc · 2025-09-23T19:05:57Z

packages/portfolio-contract/tools/portfolio-actors.ts

  amount: NatAmount,
  feeBrand: Brand<'nat'>,
  makeGasEstimator: MakeGasEstimator,
+  accountIdByChain: Record<string, `${string}:${string}:${string}`>,


Suggested change

accountIdByChain: Record<string, `${string}:${string}:${string}`>,

accountIdByChain: Record<string, AccountId>,

and in fact the record key is not just any string. Unless there's something I'm not seeing, I suggest:

Suggested change

accountIdByChain: Record<string, `${string}:${string}:${string}`>,

accountIdByChain: StatusFor['portfolio']['accountIdByChain'],

dckc · 2025-09-23T19:06:52Z

packages/portfolio-contract/tools/portfolio-actors.ts

-        fee: make(feeBrand, gmpWalletFee), // KLUDGE.
+        fee: make(feeBrand, gmpWalletFee * padding), // KLUDGE.


is it still a KLUDGE?

rabi-siddique · 2025-09-25T15:11:10Z

services/ymax-planner/src/support.ts

+export const gasLimitEstimates: GasLimitEstimates = {
+  WALLET: 1_209_435n,
+  AAVE_SUPPLY: 276_809n,
+};


Just confirmed with @frazarshad
WALLET has the gasLimit for makeAccount flow.
AAVE_SUPPLY is the limit used for these operations: supply / withdraw / deposit for burn

Maybe change AAVE_SUPPLY name to something generic

rabi-siddique · 2025-09-25T15:12:30Z

services/ymax-planner/src/gas-estimation.ts

+      sourceChain: AxelarChain | 'agoric',
+      destinationChain: AxelarChain | 'agoric',
+      gasLimit: bigint,
+      gasToken?: string,


Why not including the destinationContractAddress or field similar to that

rabi-siddique · 2025-09-25T15:13:51Z

services/ymax-planner/src/gas-estimation.ts

+
+    const getFactoryContractEstimate = async () => {
+      const gasLimit = gasLimitEstimates['AAVE_SUPPLY'];
+


This tx will be executed by the smart wallet so maybe it should be renamed to geSmartWalletEstimate instead getFactoryContractEstimate?

that would make me think of "SmartWallet" in the sense of the Agoric walletFactory. But maybe it would help other readers.

rabi-siddique · 2025-09-25T15:15:05Z

services/ymax-planner/src/main.ts

    cosmosRest,
    signingSmartWalletKit,
    now: Date.now,
+    axelarApiAddress,


maybe axelarApiAddress should be part of evmCtx.

rabi-siddique · 2025-09-25T15:17:43Z

services/ymax-planner/src/plan-deposit.ts

  if (errors.length) {
    throw AggregateError(errors, 'Could not get balances');
  }
+  const makeGasEstimator = prepareGasEstimator(powers);


I think we should have one makeGasEstimator instance maybe instantiated in main.ts instead of creating a new one everytime handleDeposit is called

services/ymax-planner/src/gas-estimation.ts

services/ymax-planner/src/plan-deposit.ts

gibson042 · 2025-09-25T16:06:39Z

packages/portfolio-contract/tools/portfolio-actors.ts

+  makeGasEstimator: MakeGasEstimator,
+  accountIdByChain: Record<string, `${string}:${string}:${string}`>,


These last two parameters are not like the others; I think they should be bundled into a record.

export const planTransfer = async ( dest: PoolKey, amount: NatAmount, feeBrand: Brand<'nat'>, { gasEstimator, accountIdByChain }: PlanTransferPowers, ): MovementDesc[] => {

packages/portfolio-contract/tools/portfolio-actors.ts

services/ymax-planner/src/gas-estimation.ts

gibson042 · 2025-09-25T16:47:41Z

services/ymax-planner/src/gas-estimation.ts

+      const data = Number(await response.json());
+      return data;


Suggested change

const data = Number(await response.json());

return data;

const body = await response.json();

return BigInt(body);

Also: https://docs.axelarscan.io/gmp#estimateGasFee shows "BigNumber" in its output, but doesn't explain what that is. If it's not guaranteed to be an integer for us, then this will fail. Should we be prepared for that by e.g. rounding up?

Suggested change

const data = Number(await response.json());

return data;

const body = await response.json();

try {

return BigInt(body);

} catch (err) {

log('⚠️ Axelar gas API non-integer response, trying to round up', body);

const parts = `${body}`.trim().match(/^([0-9]+)([.]0*|[.]([0-9]+))?$/);

if (!parts) throw err;

const intPart = BigInt(parts[1]);

return parts[3] ? intPart + 1n : intPart;

}

i think its safe as is. as BigNumber is most likely this type https://docs.ethers.org/v5/api/utils/bignumber/

That page also doesn't document a restriction to integers, but the documentation about migrating from ethers v5 to v6 does:

Keep in mind, just like BigNumber, a ES2020 BigInt can only operate on integers.

So I'm convinced that a non-integer value would be sufficiently surprising to merit propagating the resulting exception without special handling.

services/ymax-planner/src/gas-estimation.ts

gibson042 · 2025-09-25T16:55:09Z

services/ymax-planner/src/support.ts

+export const gasLimitEstimates: GasLimitEstimates = {
+  WALLET: 1_209_435n,
+  AAVE_SUPPLY: 276_809n,
+};


How were these values determined?

avg of values observed when these txs were run on mainnet as well as testnet. e.g here you can observe the Gas Limit & Used by Txn section. This value represents the "Used by Txn" part of this section.
They varied across txs but not my a large enough margin to indicate they will have a significant effect on the gasEstimate

My point is that we should have an explanation here (or link to one), in case things do change in the future.

gibson042 · 2025-09-25T16:57:49Z

services/ymax-planner/test/mocks.ts

+// Mock fetch
+globalThis.fetch = async (url: string, options?: any) => {
+  if (url.includes('estimateGasFee')) {
+    return {
+      ok: true,
+      json: async () => JSON.parse(options.body).gasLimit,
+    } as Response;
+  }
+  throw new Error(`Unmocked fetch call to: ${url}`);
+};


This is a huge smell. Library code should not be accessing an ambient fetch, but rather requiring it as an inbound power passed down from startEngine.

Also, passing all of fetch around when you only need read-only access to a certain part of web space is excess authority. Consider using makeWebRd.

services/ymax-planner/src/engine.ts

services/ymax-planner/src/main.ts

services/ymax-planner/src/engine.ts

gibson042 · 2025-09-25T21:40:30Z

packages/portfolio-contract/src/plan-solve.ts

+        case 'withdraw':
+          details = {
+            fee: AmountMath.make(
+              graph.feeBrand,
+              gasEstimator
+                ? (await gasEstimator.getWalletEstimate(
+                    chainOf(edge.dest) as AxelarChain,
+                  )) * padding
+                : 30_000_000n,
+            ),
+          };
+          break;
+        case 'supply':
+          details = {
+            fee: AmountMath.make(
+              graph.feeBrand,
+              gasEstimator
+                ? (await gasEstimator.getWalletEstimate(
+                    chainOf(edge.dest) as AxelarChain,
+                  )) * padding
+                : 30_000_000n,
+            ),
+          };
+          break;


As noted, these cases appear to be identical:

Suggested change

case 'withdraw':

details = {

fee: AmountMath.make(

graph.feeBrand,

gasEstimator

? (await gasEstimator.getWalletEstimate(

chainOf(edge.dest) as AxelarChain,

)) * padding

: 30_000_000n,

),

};

break;

case 'supply':

details = {

fee: AmountMath.make(

graph.feeBrand,

gasEstimator

? (await gasEstimator.getWalletEstimate(

chainOf(edge.dest) as AxelarChain,

)) * padding

: 30_000_000n,

),

};

break;

case 'withinEvmViaAxelar': {

const estimate = await gasEstimator.getWalletEstimate(

chainOf(edge.dest) as AxelarChain,

);

details = {

fee: AmountMath.make(graph.feeBrand, padFeeEstimate(estimate)),

};

break;

supply and withdraw are currently have the same estimate but will be different in the future, collapsing the switch cases but keeping them as distinct feeModes

You said in another reply that fees for same-chain transactions are calculated based on a message from Agoric to that chain, so why would the calculations differ for into vs. out of a pool on the other chain?

the total fee is for both fee_for_agoric_to_evm + execution_fee_on_evm
the first part is the same but the second part varies because supply and withdraw executions will run different code on evm

the total fee is for both fee_for_agoric_to_evm + execution_fee_on_evm the first part is the same but the second part varies because supply and withdraw executions will run different code on evm

That reads to me like different inputs to the same calculation rather than different calculations—perhaps the gasEstimator method should take src and dest inputs? Please add a TODO to revisit this (even if the final determination is that it should not change).

services/ymax-planner/src/gas-estimation.ts

gibson042 · 2025-09-25T21:56:31Z

packages/portfolio-contract/src/plan-solve.ts

+        case 'cctpReturn':
+          details = {
+            fee: AmountMath.make(
+              graph.feeBrand,
+              gasEstimator
+                ? (await gasEstimator.getWalletEstimate(
+                    chainOf(edge.src) as AxelarChain,
+                  )) * padding
+                : 30_000_000n,
+            ),
+          };
+          break;


Shouldn't this case use getReturnFeeEstimate?

getReturnFeeEstimate is (a bit confusingly) the detail.evmGas on the makeAccountEvm feeMode. It represents the gas amount required for the return trip to get the new account address back to agoric

I must be missing something, because I don't see any calls to getReturnFeeEstimate at all.

yes we're not using it at the moment, since its estimate is unreliable at the moment. we have instead hardcoded to 200_000_000_000_000n

I wonder what it would cost to move the hard-coded value to a config file / environment...
for example, getReturnFeeEstimate could look it up there.

gibson042 · 2025-09-25T21:57:48Z

services/ymax-planner/src/gas-estimation.ts

+  const getWalletEstimate = async (chainName: AxelarChain) =>
+    queryAxelarGasAPI(
+      AGORIC_CHAIN,
+      chainName,
+      gasLimitEstimates.Wallet,
+      BLD_TOKEN,
+    );


Given that getWalletEstimate is used by rebalanceMinCostFlowSteps for transactions that don't leave a host EVM chain, why is this call involving AGORIC_CHAIN at all?

this is basically the estimate for the tx that will send the message to the remote evm account.
Once the message has been received it will execute a tx within the evm ecosystem.

so while the tx is bounded to the chain. the message (for which we're making the estimate) comes from agoric

services/ymax-planner/test/mocks.ts

gibson042 · 2025-09-26T12:10:39Z

packages/portfolio-contract/src/network/network-spec.ts

+ * details which vary by the traversed link.
+ * - toUSDN: transferring into USDN transfer reduces the *payload* (e.g., $10k
+ *   might get reduced to $9995)
+ * - makeEvmAccount: the fee for executing the factory contract to create a new


Where is "factory account" defined/described? There should be a link here.

packages/portfolio-contract/src/network/network-spec.ts

gibson042 · 2025-09-26T12:14:27Z

packages/portfolio-contract/src/plan-solve.ts

+/**
+ * Gas estimation interface - mirrors services/ymax-planner/src/gas-estimation.ts
+ * - getWalletEstimate: Estimate gas fees for remote wallet operations on the specified chain
+ * - getFactoryContractEstimate: Estimate gas fees for executing the factory contract on the specified chain


Here too, provide a reference for "factory contract".

gibson042 · 2025-09-26T12:22:36Z

packages/portfolio-contract/src/plan-solve.ts

+        case 'cctpReturn':
+          details = {
+            fee: AmountMath.make(
+              graph.feeBrand,
+              gasEstimator
+                ? (await gasEstimator.getWalletEstimate(
+                    chainOf(edge.src) as AxelarChain,
+                  )) * padding
+                : 30_000_000n,
+            ),
+          };
+          break;


I must be missing something, because I don't see any calls to getReturnFeeEstimate at all.

packages/portfolio-contract/src/plan-solve.ts

services/ymax-planner/src/config.ts

rabi-siddique · 2025-09-26T17:02:08Z

services/ymax-planner/test/snapshots/deposit-tools.test.ts.md

        fee: {
          brand: Object @Alleged: fee brand (BLD) {},
-          value: 30000000n,
+          value: 3628305n,


Seems like gas value is reduced?

this is a mock value. its not an accurate estimate of what we will see in testnet and mainnet

rabi-siddique

The gas estimate logic looks good for now. The hardcoded values should help avoid manual intervention during testing. LGTM.

After addressing Richard's comments we should merge this PR. I suggest we create issues for the enhancements we need to do later on.

gibson042

Thanks for the responsiveness. Final suggestions attached.

gibson042 · 2025-09-26T17:25:27Z

packages/portfolio-contract/src/plan-solve.ts

+ * Link to Factory and Wallet contracts:
+ * https://github.com/agoric-labs/agoric-to-axelar-local/blob/cd6087fa44de3b019b2cdac6962bb49b6a2bc1ca/packages/axelar-local-dev-cosmos/src/__tests__/contracts/Factory.sol


This is decent, but I see no description here or there of what the Factory and Wallet contracts are/what they do/etc. Please take an action item to provide documentation of that.

agoric-labs/agoric-to-axelar-local#30 made a ticket for later

packages/portfolio-contract/src/network/network-spec.ts

packages/portfolio-contract/src/plan-solve.ts

gibson042 · 2025-09-26T17:34:11Z

packages/portfolio-contract/src/plan-solve.ts

+        case 'withdraw':
+          details = {
+            fee: AmountMath.make(
+              graph.feeBrand,
+              gasEstimator
+                ? (await gasEstimator.getWalletEstimate(
+                    chainOf(edge.dest) as AxelarChain,
+                  )) * padding
+                : 30_000_000n,
+            ),
+          };
+          break;
+        case 'supply':
+          details = {
+            fee: AmountMath.make(
+              graph.feeBrand,
+              gasEstimator
+                ? (await gasEstimator.getWalletEstimate(
+                    chainOf(edge.dest) as AxelarChain,
+                  )) * padding
+                : 30_000_000n,
+            ),
+          };
+          break;


the total fee is for both fee_for_agoric_to_evm + execution_fee_on_evm the first part is the same but the second part varies because supply and withdraw executions will run different code on evm

That reads to me like different inputs to the same calculation rather than different calculations—perhaps the gasEstimator method should take src and dest inputs? Please add a TODO to revisit this (even if the final determination is that it should not change).

packages/portfolio-contract/src/plan-solve.ts

services/ymax-planner/src/gas-estimation.ts

Ref #11953 ## Description * Simplify validation of `axelarApiAddress` * Improve `gasEstimator` error output * Define type GasEstimator in solver code (where it is needed) * Make better use of existing utility functions * Clean up import ordering

frazarshad force-pushed the fraz/gas-estimation branch from 7dd7769 to e2b88d2 Compare September 19, 2025 09:01

frazarshad marked this pull request as ready for review September 22, 2025 16:13

frazarshad requested a review from a team as a code owner September 22, 2025 16:13

frazarshad requested a review from AgoricTriage September 22, 2025 16:13

frazarshad self-assigned this Sep 22, 2025

frazarshad added the ymax IOU label Sep 22, 2025

frazarshad requested a review from rabi-siddique September 22, 2025 16:39

dckc reviewed Sep 22, 2025

View reviewed changes

dckc mentioned this pull request Sep 22, 2025

feat(ymax-planner): Calculate steps by linear programming over a model of the blockchain network #11932

Merged

rabi-siddique reviewed Sep 23, 2025

View reviewed changes

rabi-siddique requested a review from gibson042 September 23, 2025 07:12

dckc mentioned this pull request Sep 23, 2025

chore: bump hard-coded fee in planTransfer from 15BLD to 20BLD #11975

Closed

dckc reviewed Sep 23, 2025

View reviewed changes

frazarshad force-pushed the fraz/gas-estimation branch from 246196e to e1a4a98 Compare September 25, 2025 14:51

rabi-siddique reviewed Sep 25, 2025

View reviewed changes

gibson042 requested changes Sep 25, 2025

View reviewed changes

frazarshad force-pushed the fraz/gas-estimation branch from e1a4a98 to 66a3a6e Compare September 25, 2025 19:28

frazarshad requested review from dckc and gibson042 September 25, 2025 19:28

gibson042 requested changes Sep 25, 2025

View reviewed changes

frazarshad requested a review from gibson042 September 25, 2025 22:57

gibson042 reviewed Sep 26, 2025

View reviewed changes

frazarshad requested a review from gibson042 September 26, 2025 12:58

rabi-siddique reviewed Sep 26, 2025

View reviewed changes

rabi-siddique approved these changes Sep 26, 2025

View reviewed changes

gibson042 approved these changes Sep 26, 2025

View reviewed changes

frazarshad mentioned this pull request Sep 26, 2025

Add documentation for Factory and Wallet contract agoric-labs/agoric-to-axelar-local#30

Open

chore: added gas estimation api to planner

6e44475

frazarshad force-pushed the fraz/gas-estimation branch from 79423f8 to 6e44475 Compare September 26, 2025 18:20

frazarshad added the automerge:rebase Automatically rebase updates, then merge label Sep 26, 2025

mergify bot added the queued label Sep 26, 2025

mergify bot merged commit 2dc434e into master Sep 26, 2025
126 of 128 checks passed

mergify bot removed the queued label Sep 26, 2025

mergify bot deleted the fraz/gas-estimation branch September 26, 2025 19:28

gibson042 mentioned this pull request Sep 27, 2025

chore(ymax-planner): Minor cleanup #12013

Merged

dckc mentioned this pull request Sep 28, 2025

ymax: gas estimation for cctp + axelar #11468

Closed

	type GasEstimator = (chainName: AxelarChain) => {
	type MakeGasEstimator = (chainName: AxelarChain) => {

	accountIdByChain: Record<string, `${string}:${string}:${string}`>,
	accountIdByChain: Record<string, AccountId>,

	accountIdByChain: Record<string, `${string}:${string}:${string}`>,
	accountIdByChain: StatusFor['portfolio']['accountIdByChain'],

		fee: make(feeBrand, gmpWalletFee), // KLUDGE.
		fee: make(feeBrand, gmpWalletFee * padding), // KLUDGE.


		const getFactoryContractEstimate = async () => {
		const gasLimit = gasLimitEstimates['AAVE_SUPPLY'];

		makeGasEstimator: MakeGasEstimator,
		accountIdByChain: Record<string, `${string}:${string}:${string}`>,

-      const data = Number(await response.json());
-      return data;
+      const body = await response.json();
+      try {
+        return BigInt(body);
+      } catch (err) {
+        log('⚠️ Axelar gas API non-integer response, trying to round up', body);
+        const parts = `${body}`.trim().match(/^([0-9]+)([.]0*|[.]([0-9]+))?$/);
+        if (!parts) throw err;
+        const intPart = BigInt(parts[1]);
+        return parts[3] ? intPart + 1n : intPart;
+      }

		* Link to Factory and Wallet contracts:
		* https://github.com/agoric-labs/agoric-to-axelar-local/blob/cd6087fa44de3b019b2cdac6962bb49b6a2bc1ca/packages/axelar-local-dev-cosmos/src/__tests__/contracts/Factory.sol

chore: added gas estimation api to planner #11953

chore: added gas estimation api to planner #11953

Uh oh!

Conversation

frazarshad commented Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Testing Considerations

Uh oh!

cloudflare-workers-and-pages bot commented Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Deploying agoric-sdk with Cloudflare Pages

Uh oh!

dckc left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rabi-siddique left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

frazarshad Sep 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rabi-siddique commented Sep 23, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

frazarshad Sep 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

frazarshad commented Sep 23, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

frazarshad commented Sep 18, 2025 •

edited

Loading

cloudflare-workers-and-pages bot commented Sep 18, 2025 •

edited

Loading

frazarshad Sep 23, 2025 •

edited

Loading

frazarshad Sep 23, 2025 •

edited

Loading