Skip to content

Use order-snapshotted uiFeeFactor in existing-order fee estimations (FEDEV-3968)#2632

Draft
divhead wants to merge 1 commit into
qwinndev/update-v22c-contractsfrom
fedev-3968-sdk-uifeefactor
Draft

Use order-snapshotted uiFeeFactor in existing-order fee estimations (FEDEV-3968)#2632
divhead wants to merge 1 commit into
qwinndev/update-v22c-contractsfrom
fedev-3968-sdk-uifeefactor

Conversation

@divhead

@divhead divhead commented Jul 9, 2026

Copy link
Copy Markdown
Collaborator

What

Parse the snapshotted uiFeeFactor from Reader order responses, expose it on the Order type, and use it instead of the live factor when estimating execution outcomes for existing orders.

Part of FEDEV-3968 (SDK slice). Targets qwinndev/update-v22c-contracts — the ABI there already carries the field; this PR makes the client consume it.

Why

Since v2.2c (gmx-synthetics ce3cc0ae) contracts snapshot uiFeeFactor at order creation and charge the snapshot at execution. updateOrder never re-snapshots it (verified: OrderHandler.updateOrder mutates only size/prices/minOutput/validFrom/autoCancel/executionFee, and ce3cc0ae touched no update path). Estimating an existing order with the live factor can diverge from what execution will actually charge.

Changes

  • sdk/src/utils/orders/types.tsuiFeeFactor: bigint | undefined on Order (0n = snapshotted as zero, incl. pre-upgrade orders; undefined = data source doesn't provide it).
  • sdk/src/clients/v1/modules/orders/utils.ts, src/domain/synthetics/orders/useOrders.ts — extract the field from order.numbers in both Reader parsers (the decoded tuple already carries it via the updated ABI).
  • src/domain/synthetics/orders/useOrders.ts — API-fallback orders get an explicit uiFeeFactor: undefined placed before the spread, so the field flows automatically once gmx-api starts serving it.
  • src/domain/synthetics/orders/utils.tsxgetIsMaxLeverageError simulates the collateral swap with order.uiFeeFactor ?? live.
  • src/context/SyntheticsStateContext/selectors/orderEditorSelectors.ts — OrderEditor previews (swap fees / increase / decrease amounts) prefer the order's snapshot; nullish coalescing keeps a legitimate 0n snapshot (no falsy-zero loss).
  • sdk/src/clients/v1/modules/orders/utils.spec.ts — offline unit spec for the parser: value round-trip and 0n preservation.

New-order previews (TradeBox, TP/SL sidecar, LP deposits) intentionally keep the live factor — the contract snapshots the current value at creation, so live is the correct estimate there.

Checks

yarn build-sdk, yarn tscheck:ci, yarn lint:ci, yarn test:ci, targeted vitest run sdk/.../orders/utils.spec.ts — all green.

Out of scope (rest of FEDEV-3968)

  • gmx-api serving the snapshot on /orders (then the API-fallback path picks it up automatically).
  • Withdrawal/Shift/GlvDeposit/GlvWithdrawal struct consumers — no SDK read path decodes those structs today.
  • Squid slice: gmx-io/gmx-squid#181 (merged data live on the v2.2c testnet slot).
  • SDK docs in gmx-docs.

Since v2.2c contracts snapshot uiFeeFactor at order creation and charge
the snapshot at execution (updateOrder never re-snapshots it). Parse the
field from Reader responses, expose it on the Order type, and prefer it
over the live factor in max-leverage checks and OrderEditor previews.
API-sourced orders carry undefined until gmx-api serves the field and
fall back to the live factor.
@cloudflare-workers-and-pages

Copy link
Copy Markdown

Deploying gmx-interface with  Cloudflare Pages  Cloudflare Pages

Latest commit: 8ccf2b2
Status: ✅  Deploy successful!
Preview URL: https://f73dfe8c.gmx-interface.pages.dev
Branch Preview URL: https://fedev-3968-sdk-uifeefactor.gmx-interface.pages.dev

View logs

@cloudflare-workers-and-pages

Copy link
Copy Markdown

Deploying gmx-interface-home with  Cloudflare Pages  Cloudflare Pages

Latest commit: 8ccf2b2
Status: ✅  Deploy successful!
Preview URL: https://dc736c48.gmx-interface-home.pages.dev
Branch Preview URL: https://fedev-3968-sdk-uifeefactor.gmx-interface-home.pages.dev

View logs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant