Soroban resource accounting & on-chain fee estimation (closing a shipped-but-stubbed README promise)

[ibrahimmosouf-png]

Soroban resource accounting & on-chain fee estimation (closing a shipped-but-stubbed README promise)

Labels: performance, dx, feature, priority/medium
Difficulty: High · Effort: M
Backlog slot: 63

Problem Statement

README discrepancy to call out: the README's “💰 Fee Estimation System” section markets a FeeEstimationService with real-time base fees, 4-level surge pricing, multi-currency conversion, and a 5-minute TTL cache. crates/tools does not ship that service today. This ticket closes that promise rather than introducing a new feature.

Soroban resource fees (CPU instructions, memory, ledger reads/writes) are also invisible to developers without explicit metering.

Why it Matters

• Operators can silently pay too much gas.
• A surge pricing integration lets callers avoid network-congested windows.
• Closing a documented-but-undelivered promise is a trust-and-credibility issue; ignoring it leaves the README and code permanently out of sync.

Expected Outcome

1. Implement FeeEstimationService (4-tier surge detection: Normal, Elevated, High, Critical), 10-currency display, 5-minute cache.
2. Expose Soroban resource-model estimates per entrypoint using historical ledger reads + CPU instr. probes.
3. CLI subcommand fee-estimate --method <name> --estimate-count N.

Acceptance Criteria

• Live test against Futurenet returns non-zero estimates.
• Unit tests cover cache-TTL expiry, surge-escalation thresholds.
• Documented docs/fee-estimation.md.

Files Likely Affected

• New: crates/tools/src/fee.rs
• New: docs/fee-estimation.md

Dependencies

Issue #37 (Futurenet CI for live tests).

---

[Faithy5]

Hello. I would love to work on this project as I have hands-on experience on it. After reviewing the scope of this issue, I’m confident in my ability to deliver a complete, well-tested solution.

I’d be grateful for the opportunity to contribute and help advance this project. Thank you.