A user could transfer XLM, mint an NFT, and invoke a Soroban smart contract all in one payload. Currently, Grat's decoding architecture is implicitly biased toward transactions containing a single InvokeHostFunctionOp. If a developer passes a transaction hash that contains 50 different Soroban invocations interspersed with classic Stellar payments, the system will completely break down or, at best, only decode the very first operation it encounters, ignoring the remaining 49.
Issues/what to fix
The core execution orchestrator must be overhauled to implement the MultiOpDecoder. The logic must ingest the entire TransactionEnvelope. Instead of assuming a single operation, it must utilize an iterator to map over every single Operation defined in the envelope. For each operation, it must determine if it is a classic Stellar operation (e.g., Payment, SetOptions) or a Soroban operation (InvokeHostFunction, ExtendFootprintTTL). The decoder must then execute the appropriate FunctionCallDecoder or XDR extraction logic for each operation in parallel or sequence, aggregating the results into a massive Vec. The diagnostic report must then be updated to visually demarcate the results of Operation 1 vs Operation 2 vs Operation N.
Files to create / modify
Create: crates/core/src/decode/multi_op_decoder.rs
Modify: crates/core/src/decode/mod.rs
Expected result
Grat will fully support the vast complexities of enterprise grade, batch operation transactions. Developers utilizing complex algorithmic trading bots or bulk minting scripts will be able to trace the exact success or failure of every individual operation within their massive atomic envelopes.
Contributor telegram group
https://t.me/+sII7WPhll2liMGNk
A user could transfer XLM, mint an NFT, and invoke a Soroban smart contract all in one payload. Currently, Grat's decoding architecture is implicitly biased toward transactions containing a single InvokeHostFunctionOp. If a developer passes a transaction hash that contains 50 different Soroban invocations interspersed with classic Stellar payments, the system will completely break down or, at best, only decode the very first operation it encounters, ignoring the remaining 49.
Issues/what to fix
The core execution orchestrator must be overhauled to implement the MultiOpDecoder. The logic must ingest the entire TransactionEnvelope. Instead of assuming a single operation, it must utilize an iterator to map over every single Operation defined in the envelope. For each operation, it must determine if it is a classic Stellar operation (e.g., Payment, SetOptions) or a Soroban operation (InvokeHostFunction, ExtendFootprintTTL). The decoder must then execute the appropriate FunctionCallDecoder or XDR extraction logic for each operation in parallel or sequence, aggregating the results into a massive Vec. The diagnostic report must then be updated to visually demarcate the results of Operation 1 vs Operation 2 vs Operation N.
Files to create / modify
Create: crates/core/src/decode/multi_op_decoder.rs
Modify: crates/core/src/decode/mod.rs
Expected result
Grat will fully support the vast complexities of enterprise grade, batch operation transactions. Developers utilizing complex algorithmic trading bots or bulk minting scripts will be able to trace the exact success or failure of every individual operation within their massive atomic envelopes.
Contributor telegram group
https://t.me/+sII7WPhll2liMGNk