# Debugging v0.14 transactions 

**URL:** <https://community.starknet.io/t/debugging-v0-14-transactions/116142>\
**Category:** 📜 Development Proposals\
**Tags:** tooling\
**Created:** [February 23, 2026, 8:35am UTC](https://community.starknet.io/t/debugging-v0-14-transactions/116142 "2026-02-23T08:35:28Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mateja3m](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/mateja3m/32/85960_2.png) [@Mateja3m](https://community.starknet.io/u/Mateja3m)\
**Post date:** [February 23, 2026, 8:35am UTC](https://community.starknet.io/t/debugging-v0-14-transactions/116142/1 "2026-02-23T08:35:28Z")

</div>

Hi,

I’ve noticed that since the introduction of mempools in Starknet v0.14, debugging transactions has become quite a headache. New finality statuses like `RECEIVED` and `CANDIDATE` are often confusing, and the rules for **fee escalation** (the 10% bump) and **TTL** (5-minute window) add a whole new layer of complexity.

To help with this, I’ve been building Starknet Transaction Lifecycle & Fee Escalation Advisor ( **STLFA** ) - a lightweight advisor tool that analyzes a `tx_hash` and provides actionable recommendations: whether you should wait, perform a deterministic fee bump, or if there’s a potential nonce conflict.

I have a **functional PoC running on Sepolia**. Before I open it up fully to the public, I’d love to get some feedback from fellow dApp developers:

1. Which transaction status is currently causing you the most “support hell”?
2. Would it be useful to have an exportable report you can share with users who reach out about a stuck transaction?

Here is the link to github repo [GitHub - Mateja3m/starknet-tx-advisor](https://github.com/Mateja3m/starknet-tx-advisor)

I expect your honest feedback and opinion.