Transaction fees on the Stellar network are no longer a flat rate; the Soroban implementation introduced a highly complex, multi dimensional fee structure. Fees are now split into the base inclusion fee, refundable resource fees (for compute that wasn't actually used), and non refundable fees (for base operations and state rent). When a transaction fails because the user did not provide a high enough fee, Grat currently just returns an opaque XDR sequence. Developers frequently overpay or underpay because they have no visibility into how their total fee was mathematically distributed across the network's multi layered pricing mechanisms.
Issues/what to fix
The implementation demands a FeeAnalyzer engine capable of dissecting the TransactionEnvelope and TransactionMeta. The engine must extract the base fee defined by the user in the envelope. It must then cross reference this against the fee_charged located within the transaction result. It must meticulously calculate three critical components: The Inclusion Fee (the base cost to get into the ledger), the Non Refundable Resource Fee (the absolute minimum cost required by the Soroban VM to evaluate the transaction), and the Refundable Fee (the buffer the user provided minus the compute actually consumed). The analyzer must handle edge cases where the transaction simulation is successful, but the network base fee surged prior to inclusion, resulting in an InsufficientFee error.
Files to create / modify
Create: crates/core/src/decode/fee_analyzer.rs
Expected result
Grat will completely demystify Soroban's dynamic pricing architecture. Developers will see a crystal clear financial receipt for every transaction, explaining exactly where every single stroke of XLM was allocated, refunded, or rejected, empowering them to optimize their fee strategies.
Contributor telegram group
https://t.me/+sII7WPhll2liMGNk
Transaction fees on the Stellar network are no longer a flat rate; the Soroban implementation introduced a highly complex, multi dimensional fee structure. Fees are now split into the base inclusion fee, refundable resource fees (for compute that wasn't actually used), and non refundable fees (for base operations and state rent). When a transaction fails because the user did not provide a high enough fee, Grat currently just returns an opaque XDR sequence. Developers frequently overpay or underpay because they have no visibility into how their total fee was mathematically distributed across the network's multi layered pricing mechanisms.
Issues/what to fix
The implementation demands a FeeAnalyzer engine capable of dissecting the TransactionEnvelope and TransactionMeta. The engine must extract the base fee defined by the user in the envelope. It must then cross reference this against the fee_charged located within the transaction result. It must meticulously calculate three critical components: The Inclusion Fee (the base cost to get into the ledger), the Non Refundable Resource Fee (the absolute minimum cost required by the Soroban VM to evaluate the transaction), and the Refundable Fee (the buffer the user provided minus the compute actually consumed). The analyzer must handle edge cases where the transaction simulation is successful, but the network base fee surged prior to inclusion, resulting in an InsufficientFee error.
Files to create / modify
Create: crates/core/src/decode/fee_analyzer.rs
Expected result
Grat will completely demystify Soroban's dynamic pricing architecture. Developers will see a crystal clear financial receipt for every transaction, explaining exactly where every single stroke of XLM was allocated, refunded, or rejected, empowering them to optimize their fee strategies.
Contributor telegram group
https://t.me/+sII7WPhll2liMGNk