Skip to content

RPC: Add method to get pending transactions #2864

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ManuelBilbao opened this issue May 21, 2025 · 0 comments · Fixed by #2869
Closed

RPC: Add method to get pending transactions #2864

ManuelBilbao opened this issue May 21, 2025 · 0 comments · Fixed by #2869
Assignees
Labels
rpc-api Public rpc-json api for users

Comments

@ManuelBilbao
Copy link
Contributor

Other EL clients have a RPC method to get the pending transactions (i.e. in the mempool), that is used for explorers. Geth call it txpool_content and others like Erigon and Nethermind parity_pendingTransactions

@ManuelBilbao ManuelBilbao added the rpc-api Public rpc-json api for users label May 21, 2025
@mpaulucci mpaulucci moved this to Todo in ethrex_l1 May 21, 2025
@fmoletta fmoletta self-assigned this May 21, 2025
@mpaulucci mpaulucci moved this from Todo to In Progress in ethrex_l1 May 22, 2025
github-merge-queue bot pushed a commit that referenced this issue May 22, 2025
**Motivation**
Adds an RPC method that allows reading all transactions currently in the
mempool.
This endpoint was based off of Geth's `txpool_content` endpoint
([doc](https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-txpool#txpool-content))
and follows the same response logic & format.
As we have no notion of `queued` mempool transactions currenlty, this
field will be permanently left empty
The namescape and endpoint currently uses `txpool` instead of `mempool`
for immediate compatibility with components compatible with geth, we
should consider changing the name back to `mempool` to reflect our own
types as this is not a standard endpoint and names differ between
implementations.
<!-- Why does this pull request exist? What are its goals? -->

**Description**
* Add `Mempool::content` method which returns all transactions
* Add `mempool_content` rpc endpoint which returns all mempool
transactions grouped by sender and indexed by nonce
* (Misc) `RpcTransaction::build` now supports optional transaction index
& block number
<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes #2864
@github-project-automation github-project-automation bot moved this from In Progress to Done in ethrex_l1 May 22, 2025
mpaulucci pushed a commit that referenced this issue May 23, 2025
**Motivation**
Adds an RPC method that allows reading all transactions currently in the
mempool.
This endpoint was based off of Geth's `txpool_content` endpoint
([doc](https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-txpool#txpool-content))
and follows the same response logic & format.
As we have no notion of `queued` mempool transactions currenlty, this
field will be permanently left empty
The namescape and endpoint currently uses `txpool` instead of `mempool`
for immediate compatibility with components compatible with geth, we
should consider changing the name back to `mempool` to reflect our own
types as this is not a standard endpoint and names differ between
implementations.
<!-- Why does this pull request exist? What are its goals? -->

**Description**
* Add `Mempool::content` method which returns all transactions
* Add `mempool_content` rpc endpoint which returns all mempool
transactions grouped by sender and indexed by nonce
* (Misc) `RpcTransaction::build` now supports optional transaction index
& block number
<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes #2864
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rpc-api Public rpc-json api for users
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants