When transactions execute nested sub contract calls, the Soroban VM emits errors sequentially. A single failure in a deep sub contract will trigger a cascade of "Trapped" or "Reverted" errors as the execution stack unwinds back to the top level contract. Currently, standard block explorers and basic diagnostic tools tend to surface the very first error they see in the transaction result (which is often the top level, generic "Transaction Failed" error). This hides the actual root cause: the specific mathematical overflow or missing authorization that occurred 4 layers deep.
Issues/what to fix
We must construct an analytical tree traversal algorithm called the DeepestErrorFinder. The algorithm must ingest the chronological list of DiagnosticEvent wrappers. It must utilize an internal integer counter to track the "Call Depth" (incrementing upon a cross contract call event, decrementing upon a return). The algorithm must retain a pointer to the DiagnosticEvent that possesses the absolute highest "Call Depth" integer at the exact moment a failure event is broadcast. By isolating the event that occurred at the absolute deepest layer of the execution stack, the algorithm mathematically guarantees that it has isolated the primary catalyst of the transaction failure, stripping away all the cascading noise.
Files to create / modify
Create: crates/core/src/decode/deepest_error.rs
Expected result
Developers will never again waste hours investigating a top level Router contract for a bug that actually exists inside a deeply nested Liquidity Pool dependency. Grat will automatically bypass the cascading noise and point a massive neon arrow directly at the exact line of code in the exact sub contract that caused the collapse.
Contributor telegram group
https://t.me/+sII7WPhll2liMGNk
When transactions execute nested sub contract calls, the Soroban VM emits errors sequentially. A single failure in a deep sub contract will trigger a cascade of "Trapped" or "Reverted" errors as the execution stack unwinds back to the top level contract. Currently, standard block explorers and basic diagnostic tools tend to surface the very first error they see in the transaction result (which is often the top level, generic "Transaction Failed" error). This hides the actual root cause: the specific mathematical overflow or missing authorization that occurred 4 layers deep.
Issues/what to fix
We must construct an analytical tree traversal algorithm called the DeepestErrorFinder. The algorithm must ingest the chronological list of DiagnosticEvent wrappers. It must utilize an internal integer counter to track the "Call Depth" (incrementing upon a cross contract call event, decrementing upon a return). The algorithm must retain a pointer to the DiagnosticEvent that possesses the absolute highest "Call Depth" integer at the exact moment a failure event is broadcast. By isolating the event that occurred at the absolute deepest layer of the execution stack, the algorithm mathematically guarantees that it has isolated the primary catalyst of the transaction failure, stripping away all the cascading noise.
Files to create / modify
Create: crates/core/src/decode/deepest_error.rs
Expected result
Developers will never again waste hours investigating a top level Router contract for a bug that actually exists inside a deeply nested Liquidity Pool dependency. Grat will automatically bypass the cascading noise and point a massive neon arrow directly at the exact line of code in the exact sub contract that caused the collapse.
Contributor telegram group
https://t.me/+sII7WPhll2liMGNk