The mempool seen by a node is not a list of all transactions pending across the entire network
Special note in the Dusk HTTP API documentation: `mempoolTxs` returns the current node’s local in-memory pool and sorts results by gas price. It is not a global view and it does not include future-nonce transactions that are temporarily stored in the prequeue. This boundary directly affects how monitoring tools determine whether a “transaction has disappeared.”
If a node does not see a queried transaction, it may be because it has not yet propagated, has been received by another node, or is kept in the prequeue due to a nonce that is too far in the future. If users are prompted to resend immediately, it may lead to replacement and unintended duplicate intent. A more robust approach is to combine the transaction hash, the sending node, the account nonce, and the final on-chain block state to provide a source-based assessment.
For transaction venues, mempool data still cannot be used directly as evidence of network-wide congestion or fee levels. A node’s ordering only indicates its local candidate set; the sampling node, time window, and prequeue exclusions must all be included in the metric definitions. When the counting methodology is unclear, the more “precise” a dashboard seems, the easier it is to mislead.
I read the developer documentation for @Dusk and I really like sentences that actively limit the meaning of an API. A reliable data product should first explain what it cannot see, then tell users what it does see—especially it should not use the absence of data from a single node to infer that the whole network discarded the transaction. $DUSK #DUSKARMY.
Special note in the Dusk HTTP API documentation: `mempoolTxs` returns the current node’s local in-memory pool and sorts results by gas price. It is not a global view and it does not include future-nonce transactions that are temporarily stored in the prequeue. This boundary directly affects how monitoring tools determine whether a “transaction has disappeared.”
If a node does not see a queried transaction, it may be because it has not yet propagated, has been received by another node, or is kept in the prequeue due to a nonce that is too far in the future. If users are prompted to resend immediately, it may lead to replacement and unintended duplicate intent. A more robust approach is to combine the transaction hash, the sending node, the account nonce, and the final on-chain block state to provide a source-based assessment.
For transaction venues, mempool data still cannot be used directly as evidence of network-wide congestion or fee levels. A node’s ordering only indicates its local candidate set; the sampling node, time window, and prequeue exclusions must all be included in the metric definitions. When the counting methodology is unclear, the more “precise” a dashboard seems, the easier it is to mislead.
I read the developer documentation for @Dusk and I really like sentences that actively limit the meaning of an API. A reliable data product should first explain what it cannot see, then tell users what it does see—especially it should not use the absence of data from a single node to infer that the whole network discarded the transaction. $DUSK #DUSKARMY.