[FEAT] Implement Stellar Transaction Fee Estimation and User Notification

[Queenode]

🟡 Priority: High
Difficulty: Hard
Estimated Effort: 2-3 days
Relevant Files: src/services/stellar.service.ts, src/services/message-processor.service.ts
Labels: enhancement, priority:high, stellar, ux

Requirements

1. Dynamic Fee Estimation

   • Before executing any Stellar transaction, estimate the fee:
     • Call server.fetchBaseFee() for the current network base fee
     • Call server.feeStats() for fee percentile data
     • Use the p70 (70th percentile) fee for standard transactions
     • Use the p90 (90th percentile) fee for time-sensitive transactions (payouts)
   • Display the estimated fee to the user before they confirm:

     📊 Transaction Summary:
     Amount: 50.00 USDC
     Network Fee: ~0.00001 XLM ($0.0001)
     Total: 50.00 USDC + 0.00001 XLM fee
     
     Reply CONFIRM to proceed or CANCEL to abort.
     

2. Confirmation Flow

   • Create a PendingTransaction model in Redis (not Prisma — ephemeral):
     • Key: pending_tx:{userId}:{txType}
     • Value: serialized transaction details (amount, recipient, fee, etc.)
     • TTL: 5 minutes
   • When the user replies CONFIRM, look up the pending transaction and execute it
   • When the user replies CANCEL, delete the pending transaction
   • If the pending transaction expires, notify: "⏰ Your transaction has expired. Please try again."

3. Insufficient Fee Detection

   • Before submitting, verify the user has enough XLM to cover:
     • The transaction fee
     • The minimum account balance (1 XLM + 0.5 per trustline + 0.5 per offer)
   • If insufficient, inform: "⚠️ You need at least {amount} XLM to cover the network fee. Your XLM balance is {balance}."

4. Fee Surge Protection

   • If the current base fee is >10x the normal base fee (100 stroops), warn the user:
     "⚠️ Network fees are unusually high right now ({fee} XLM). Consider waiting and trying again later."
   • Allow the user to proceed anyway by replying CONFIRM ANYWAY

5. Fee History Caching

   • Cache fee stats in Redis with a 1-minute TTL
   • Don't call feeStats() for every transaction — reuse cached values

6. Testing

   • Unit test: fee estimation picks correct percentile
   • Unit test: confirmation flow works (CONFIRM, CANCEL, expiry)
   • Unit test: insufficient fee detection
   • Unit test: fee surge warning triggers at correct threshold
   • Integration test: submit a transaction with estimated fee on testnet
   • Target: >85% coverage

---

[jchinedu]

let me work on this issue

[adrianapdl11-tech]

I’d like to take this issue because I’m interested in working on the Stellar transaction flow and can focus on implementing the requirements carefully, including dynamic fee estimation, Redis-based confirmation, fee validation, surge protection, and testing. I’m ready to learn the existing codebase and deliver the feature with attention to correctness and user experience.

[Akatenvictor]

I’d like to take on this issue. I understand the requirements around dynamic Stellar fee estimation, user confirmation, Redis-based pending transactions, insufficient-balance checks, fee surge protection, and fee-stat caching.

I can implement the solution across stellar.service.ts and message-processor.service.ts, using the appropriate p70/p90 fee strategy and ensuring transactions are only submitted after explicit user confirmation.

I’ll also add comprehensive unit and integration tests covering confirmation, cancellation, expiry, fee estimation, insufficient XLM, fee surges, and caching, with a target of 85%+ test coverage.

I’m confident I can deliver this as a reliable, user-friendly, and well-tested enhancement.

[grantfox-oss]

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

Next steps:

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

Good luck! Track your progress on GrantFox.