Improve fees display on send

[leofelix077]

closes #2475

Screen.Recording.2026-03-13.at.11.42.36.mov

Screen.Recording.2026-03-13.at.11.43.27.mov

[Copilot]

Pull request overview

This PR improves the resource fee display on the send flow by adding a detailed fee breakdown pane to the review transaction screen, showing inclusion fee and resource fee separately for Soroban transactions.

Changes:

• Added a new "Fee breakdown" pane in ReviewTransaction showing inclusion fee, resource fee, and total fee with contextual descriptions for classic vs Soroban transactions
• Propagated inclusionFee and resourceFee from simulation results through both send and collectible flows
• Added "Calculating..." loading state for fees and a loading indicator on the continue button during simulation

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
extension/src/popup/components/InternalTransaction/ReviewTransaction/index.tsx	New fees breakdown pane with fee detail rows and info button
extension/src/popup/components/InternalTransaction/ReviewTransaction/styles.scss	Styles for the fees breakdown pane and info button
extension/src/popup/components/send/SendAmount/index.tsx	Show "Calculating..." during simulation, loading state on button
extension/src/popup/components/send/SendAmount/hooks/useSimulateTxData.tsx	Pass inclusionFee and resourceFee from simulation
extension/src/popup/components/sendCollectible/SelectedCollectible/hooks/useSimulateTxData.ts	Pass inclusionFee and resourceFee from simulation
extension/src/popup/locales/en/translation.json	New i18n keys for fee breakdown UI
extension/src/popup/locales/pt/translation.json	Portuguese translations for new keys (with one regression)
@shared/api/internal.ts	Added network_url to simulate-tx request body
extension/e2e-tests/reviewTxFees.test.ts	E2E tests for fee breakdown in token, classic, and collectible sends

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 14 out of 14 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[sdfcharles]

@leofelix077 looks nice! few notes:

1. should this be Inclusion fee?

2. lets match the top/bottom padding here

3. lets move the copy button next to the text

4. i like the idea of the buttons here but lets drop them for now for consistency

[leofelix077]

@sdfcharles applied the adjustments to the UI parts now. thanks for checking!

[piyalbasu]

why was this change needed? It's actually only used for Soroswap, which is disabled right now

[leofelix077]

it was throwing an error when trying to submit a collectible, mentioning it's a required field by the backend. on my MP collectibles

[CassioMG]

Adding supporting evidence on Piyal's question, since it's still open:

Checked the current freighter-backend master — /simulate-tx in src/route/index.ts L1294-1337:

schema: {
  body: {
    type: "object",
    required: ["xdr", "network_passphrase"],   // network_url NOT required
    properties: {
      xdr: { type: "string" },
      network_passphrase: { type: "string" },  // network_url not even listed
    },
  },
},
handler: async (request) => {
  const { xdr, network_passphrase } = request.body;  // network_url not read
  // ... server derived from network_passphrase via getServer(networkName, stellarRpcConfig)
}

No additionalProperties: false on the schema, so unknown fields are silently accepted and dropped — the handler never sees network_url. /simulate-token-transfer L1352-1383 also doesn't list it.

@leofelix077 — worth double-checking: the backend error you saw about "required field" might have been from a different field (e.g. a required entry you were missing), from a stale/fork backend, or a different endpoint. On current freighter-backend/master this field is dead on the wire. If the error was reproducible, a backend stack trace or the exact error payload would help pin it down before we land the client change.

Either the freighter-backend needs a companion PR to actually use network_url, or this line can be removed.

[piyalbasu]

1 small UX improvement we can make here. I noticed if you edit the fee, then click the inclusion fee i bubble, it resets the fee field. A user would lose any change they've made in this field

Screen.Recording.2026-03-25.at.12.01.33.PM.mov

[leofelix077]

nice one!

I adjusted the fee persistence inside the flow, so if user manually edits it, it's kept inside the context (soroban vs classic) and won't change again after explicit user input, unless user exits the transaction flow

Screen.Recording.2026-04-02.at.13.47.14.mov

[CassioMG]

PR Review: Improve fees display on send (Extension)

Cross-reference: This review covers this PR alongside the mobile counterpart at stellar/freighter-mobile#774. A comparison section is included at the bottom.

---

Individual Review of Extension PR

Overall: Clean, well-structured implementation. The FeesPane component is simple and reusable, the pane state machine extension is elegant, and the E2E test coverage is excellent.

Things I Like

• Comprehensive E2E tests (358 lines) covering token send, classic send, collectible send, EditSettings flow, auto-simulation, and re-simulation with destination change. This is significantly stronger test coverage than the mobile PR.
• SimulateTxData consolidated into types/transactions.ts — removes duplicate interface definitions from two separate hooks.
• lastInclusionFeeRef pattern — persists the inclusion fee across re-simulations so the EditSettings input doesn't flash back to the total fee. Well thought out.
• Base fee reset before re-simulation in both handleContinue and the auto-simulate useEffect — prevents the compounding fee inflation bug where total gets used as baseFee.
• simulationDataRef for change detection — clean approach to detect destination/asset changes without watching simulationState.data (which would cause loops).
• FeesPane takes simulationState directly — it can determine Soroban vs classic from the data itself (resourceFee presence), which is simpler than the mobile's dual isSoroban/isSorobanContext approach.
• enableReinitialize on Formik — ensures EditSettings reflects updated fee values on re-open.

Issues & Suggestions

1. Auto-simulation useEffect depends on simulationState.state ⚠️

useEffect(() => {
  if (simulationState.state === RequestState.LOADING) return;
  // ...
  if (destChanged || assetChanged) {
    fetchSimulationData();
  }
}, [destination, asset, isToken, isCollectible, simulationState.state]);

Including simulationState.state in deps means this effect re-runs on every state transition (IDLE → LOADING → SUCCESS). The simulationDataRef guard prevents duplicate calls in the happy path, but if a simulation fails (ERROR state), the effect re-runs, sees the same destination/asset (already tracked in the ref), and does nothing — the user is stuck without a retry mechanism. Consider adding ERROR handling or a manual retry path.

2. FeesPane determines Soroban vs classic based on simulationState.data?.resourceFee 📝

{simulationState.data?.resourceFee
  ? t("Fees description soroban")
  : t("Fees description classic")}

This works for the fee breakdown description, but has a subtle issue: while loading (data is null), the description shows the classic text even for a Soroban transaction. For the mobile PR, an explicit isSorobanContext prop solves this. Consider passing a similar hint so the description is correct during loading states too.

3. FeesPaneOverlay style class is defined but unused 🧹
In styles.scss, the .FeesPaneOverlay class is defined (13 lines) but never referenced in any component. Looks like a leftover from an earlier approach — can be removed.

4. Info button always shown on ReviewTransaction fee row 📝

<button
  className="ReviewTx__Details__Row__FeesInfoBtn"
  data-testid="review-tx-fee-info-btn"
  onClick={() => setActivePaneIndex(paneConfig.feesIndex)}
>
  <Icon.InfoCircle />
</button>

The info circle button is always rendered (both Soroban and classic). This is fine since the FeesPane adapts its content, but it's a design choice worth confirming — the mobile PR only shows the info icon for Soroban transactions on the review screen.

5. network_url added to simulate-tx API call 📝

body: JSON.stringify({
  xdr,
  network_passphrase: networkDetails.networkPassphrase,
  network_url: networkDetails.sorobanRpcUrl,
}),

Small but important change in @shared/api/internal.ts. Worth noting this is a backend contract change — if the backend doesn't expect network_url, it should be harmless (ignored), but worth confirming the backend accepts this field.

6. Fee display shows "Calculating..." only for Soroban ✅
Good UX — classic transactions don't need this since they don't require simulation. The isLoading check in the FeesPane also correctly treats IDLE as loading.

---

Cross-Platform Comparison: Extension (#2649) vs Mobile (#774)

Both PRs implement the same feature (Soroban fee breakdown: Inclusion Fee + Resource Fee + Total Fee) across the two Freighter platforms. Here's how they differ:

Aspect	Extension (#2649)	Mobile (#774)
State management	Redux + useRequest pattern (simulationState with RequestState enum)	Zustand store (useTransactionBuilderStore) with isSoroban, sorobanResourceFeeXlm, sorobanInclusionFeeXlm
Fee data location	SimulateTxData interface (shared type) carries inclusionFee? and resourceFee?	Stored directly in Zustand store; computed in components via BigNumber
Soroban detection (FeesPane)	Inferred from simulationState.data?.resourceFee presence	Dual system: isSoroban from store + isSorobanContext prop from parent context
Fee breakdown component	FeesPane — SCSS-styled, integrated into MultiPaneSlider	FeeBreakdownBottomSheet — NativeWind/Tailwind, uses @gorhom/bottom-sheet
Auto-simulation trigger	useEffect watching destination + asset with simulationDataRef for dedup	useEffect with lastAutoSimulatedKey ref; uses amount "0" for early estimation
Fee estimation approach	Simulates with the real amount; auto-triggers when destination changes	Simulates with amount "0" to get fees before user enters amount; skipAmountValidation flag
Base fee inflation prevention	lastInclusionFeeRef + explicit saveTransactionFee reset before re-simulation	Inclusion fee derived from params.transactionFee || MIN_TRANSACTION_FEE in the store
Total fee computation	Computed in simulateTx → recommendedFee = baseFee + minResourceFee; single source of truth	Computed independently in both FeeBreakdownBottomSheet and SendReviewBottomSheet (duplicated)
EditSettings fee label	"Inclusion Fee" for Soroban, "Transaction Fee" for classic; info button opens FeesPane	"Inclusion fee" for Soroban, "Transaction fee" for classic; info button opens FeeBreakdownBottomSheet
Info icon on review screen	Always shown (classic and Soroban)	Only shown for Soroban transactions
Simulation return type	Unchanged — useSimulateTxData hook returns data via existing pattern	Breaking change: simulateContractTransfer and simulateCollectibleTransfer now return { preparedTransaction, minResourceFee } instead of raw XDR string
Error handling	Existing patterns	New extractErrorMessage helper for plain-object API errors
Test coverage	358-line E2E test suite (6 test cases including re-simulation)	Unit tests updated for store + service changes; no E2E tests
i18n	EN + PT translations	EN + PT translations (matching keys/descriptions)
Loading state	"Calculating..." text in FeesPane and fee display	ActivityIndicator spinner in bottom sheet and fee row

Key Architectural Differences Worth Aligning

1. Total fee computation: The extension computes the total fee in one place (recommendedFee in the simulation hook). The mobile computes it in two components independently. The extension approach is DRY-er — consider centralizing this in the mobile's Zustand store.

2. Fee estimation with amount 0: The mobile PR introduces a feeEstimationAmount parameter and skipAmountValidation to simulate with amount 0 before the user enters a value. The extension doesn't do this — it only simulates when the destination changes (using the real amount). This is a meaningful UX difference: the mobile user sees estimated fees earlier, but the extension approach avoids the complexity of dummy builds.

3. Soroban detection strategy: The extension's FeesPane infers Soroban from the data (resourceFee presence), which is simpler but shows classic text during loading. The mobile uses an explicit isSorobanContext prop, which is more correct during loading but adds complexity. Consider aligning on one approach.

4. Breaking vs non-breaking simulation API: The mobile changes simulateContractTransfer's return type (breaking), while the extension adds inclusionFee/resourceFee to the existing SimulateTxData type (non-breaking). The extension approach is safer.

5. Review screen info icon visibility: The extension always shows the fee info icon; the mobile only shows it for Soroban. Worth deciding on a consistent approach across platforms.

6. Unrelated change in mobile PR: The cancel button logic change in SendReviewFooter (tertiary/destructive conditions) doesn't appear in the extension PR and seems unrelated to fee breakdown.

---

Generated by Claude Code

[leofelix077]

@CassioMG @piyalbasu I adjusted the last points on the code and checked the Claude comments

most of the comments are related to data source and state management, which are inherently different on mobile vs extension, and some of the UI parts that are also different on Mobile (e.g. on mobile we have the info sheet for the transaction fee, on extension we always show the fees breakdown)

Funcionality-wise they should be in parity now

[Copilot]

Pull request overview

Copilot reviewed 16 out of 16 changed files in this pull request and generated 4 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

.FeesPaneOverlay appears to be unused (no references outside this stylesheet). If it’s leftover from an earlier approach, removing it would reduce dead CSS; otherwise, wire it up where FeesPane is rendered so it’s not orphaned.

Suggested change

	.FeesPaneOverlay {
	position: absolute;
	top: 0;
	left: 0;
	width: 100%;
	height: 100%;
	overflow-y: auto;
	z-index: var(--z-index--banner);
	background: var(--sds-clr-gray-01);
	padding: pxToRem(24px);
	box-sizing: border-box;
	}

[Copilot]

This file imports BlockAidScanTxResult as a value import, but it’s only used as a type. Prefer import type { BlockAidScanTxResult ... } to ensure the import is elided in emitted JS and avoid accidentally pulling runtime code into the extension bundle.

[Copilot]

The fee info icon is rendered as a <button> without an explicit type. To avoid defaulting to type="submit" if this component is ever rendered inside a form, set type="button" (consistent with the other icon buttons in this PR).

[Copilot]

feesPaneTotal is captured only when opening the FeesPane. If the pane is opened while a Soroban simulation is still loading (so simulationState.data?.resourceFee is unavailable), the FeesPane will later render inclusion/resource rows but the Total Fee row can remain stuck at the pre-simulation value. Consider deriving the total in render (or in FeesPane) from the current draft inclusion fee plus simulationState.data.resourceFee, or updating feesPaneTotal via an effect while the pane is open and simulation data arrives.

[CassioMG]

Critical — FeesPane renders a misleading Total on RequestState.ERROR

const isLoading =
  simulationState.state === RequestState.IDLE ||
  simulationState.state === RequestState.LOADING;

ERROR is neither IDLE nor LOADING, so !isLoading is true — but simulationState.data is null. The Inclusion Fee row (line 48) and Resource Fee row (line 62) gate on simulationState.data?.inclusionFee / .resourceFee and hide, while the Total Fee row at line 76-82 hits the ${fee} XLM branch.

Result: when Soroban simulation fails, FeesPane silently renders a "Total Fee" that is just the base inclusion fee (≈ 0.00001 XLM), with no breakdown rows and no error indication. The user thinks that's the real cost of a ~0.5 XLM Soroban tx.

This is exactly the failure mode the feature is supposed to eliminate, appearing in the opposite direction. Fix: add an explicit error branch. For example:

const isError = simulationState.state === RequestState.ERROR;

// in the Total row:
{isLoading ? t("Calculating...") : isError ? "—" : `${fee} XLM`}

And render an error message in the card body so the user knows the breakdown is unavailable rather than "0.00001 XLM".

[CassioMG]

this may also be present on mobile's PR

[CassioMG]

Critical — send-amount-fee-display shows a misleading total on Soroban simulation failure

This block handles LOADING ("Calculating…") but not ERROR. On RequestState.ERROR, control falls through to the inputType === "crypto" ? \${fee} ${t("XLM")}` : recommendedFeeUsdbranch, wherefee = transactionFee || recommendedFee. If the user hasn't edited the inclusion fee, they see 0.00001 XLM` (the base inclusion) as the "Fee" for a Soroban tx whose real cost is much higher.

Compounding: the Review-Send button at line 615 only adds isLoading for LOADING, so on ERROR the button stays enabled — user can proceed to review and sign, still seeing the wrong fee.

Fix: either treat ERROR the same as LOADING for display (show Calculating... or an em-dash) and disable the Continue button, or surface an inline error next to the fee with a retry affordance.

[CassioMG]

this may also be present on mobile's PR

[CassioMG]

Important — No component tests for FeesPane

FeesPane is a new 97-line component with distinct rendering branches for:

• RequestState.IDLE / LOADING (spinner row + Calculating... total)
• RequestState.SUCCESS with Soroban data (inclusion + resource + total)
• RequestState.SUCCESS classic (only total)
• RequestState.ERROR (currently broken — see C1)
• Soroban vs. classic description copy via isSoroban prop

The 823-line e2e test (reviewTxFees.test.ts) is thorough for the happy path and custom-fee lifecycle, but it doesn't cover the failure states or the branching logic directly — and it exercises through the whole flow, which is expensive and slow compared to a unit test.

Please add Jest/RTL component tests for FeesPane covering at least the five branches above. These would have caught C1 immediately, and would also guard against future regressions when the pane is reused in other flows (Swap already uses it today, Soroban-swap will need the breakdown fields later).

[CassioMG]

this may also be needed on mobile's PR