Issue 12: Pre-Flight Resource Fee Projection Modal for Complex Operations

[elizabetheonoja-art]

Scope

File: src/components/wallet/TxModal.tsx

Problem

Users are prompted to sign transactions without seeing the estimated resource fee (gas) in XLM. This leads to signature rejections due to insufficient balances or unexpected fee amounts, creating a poor UX where users must approve blindly or cancel and re-enter the flow.

Requirements

1. The modal must display the following before the user signs:
   • Operation name (e.g., "Update Tariff", "Deposit Collateral")
   • Estimated resource fee in XLM (7-decimal precision)
   • Current account balance
   • A visual warning (insufficient state) if balance < fee
2. The confirm button must be disabled when insufficient is true.
3. Add a loading spinner on the confirm button during submission.
4. Accept props: open, onClose, onConfirm, operation, resourceFee, balance.
5. Accessibility: focus trap, Escape to close, aria-modal="true", role="dialog".

Resolution Strategy

• Stateless modal — parent owns state and passes props.
• Use BigNumber comparison inside useEffect for insufficiency check.
• useCallback for confirm handler to avoid re-renders.
• Fixed positioning with backdrop blur for focus isolation.

Tags

wallet, modal, fees, ux

[BarryArinze]

I’d like to work on this issue.

After reviewing the requirements, I understand that the primary goal is to improve transaction-signing transparency by showing users the estimated resource fee before they approve a transaction. Currently, users are asked to sign without visibility into the fee cost, which can result in failed transactions, unexpected charges, and unnecessary signature rejections.

Proposed Implementation

1. Enhance TxModal UI

I will update src/components/wallet/TxModal.tsx to display:
• Operation name (e.g., Update Tariff, Deposit Collateral)
• Estimated resource fee formatted in XLM with 7-decimal precision
• Current wallet/account balance
• Clear visual indication when available balance is lower than the required fee

This information will be presented prominently before the user confirms the transaction.

2. Insufficient Balance Detection

Using BigNumber for accurate decimal handling, I will implement a comparison check between:
• balance
• resourceFee

The modal will automatically determine an insufficient state whenever:

balance < resourceFee

This avoids floating-point precision issues and ensures reliable validation for Stellar/XLM values.

3. Confirmation Protection

When the user does not have sufficient balance:
• The Confirm button will be disabled
• A visible warning message/state will be displayed
• Users will receive immediate feedback before attempting submission

This prevents avoidable transaction failures.

4. Submission Loading State

To improve user feedback during transaction processing:
• A loading spinner will be shown on the Confirm button
• Multiple submissions will be prevented while processing
• Button state will reflect the ongoing transaction request

5. Stateless Component Architecture

The modal will remain fully controlled by the parent component and accept the required props:

open
onClose
onConfirm
operation
resourceFee
balance

This keeps the component reusable, predictable, and easy to test.

6. Performance Optimization

I will:
• Use useCallback for the confirm handler to prevent unnecessary re-renders
• Use useEffect to update the insufficiency state whenever balance or fee changes
• Keep computations lightweight and localized

7. Accessibility Compliance

The dialog will follow accessibility best practices:
• role="dialog"
• aria-modal="true"
• Escape key support to close the modal
• Focus trapping while the modal is open
• Proper keyboard navigation

8. Styling & UX

The modal will use:
• Fixed positioning
• Backdrop blur for visual isolation
• Clear warning styling for insufficient balance states
• Responsive layout compatible with desktop and mobile screens

Deliverables
• Updated TxModal.tsx
• Fee visibility before signing
• Insufficient balance detection and warning state
• Disabled confirmation when funds are insufficient
• Loading spinner during submission
• Accessibility improvements
• Clean, reusable, stateless implementation aligned with project requirements

I can begin immediately and will ensure the implementation follows existing project conventions and code quality standards.

Thank you for your consideration.

[grantfox-oss]

🦊 GrantFox — @BarryArinze has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #12)
2. Your PR will be reviewed by the Utility-Protocol maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign campaign!

@BarryArinze's PR #77 was approved and merged by @elizabetheonoja-art.

🏆 @BarryArinze: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (83 total points). Track your full progress on GrantFox.

👏 Great work, @BarryArinze! Keep contributing to Utility-Protocol.