Is this the whole Ethereum mempool?

No. There is no single network mempool to subscribe to: every node keeps its own pool and hears transactions in its own order. The stream carries the pending transactions seen by the nodes that serve your subscription. A transaction can be missing from it, can appear and never be mined, or can be replaced by another transaction with the same nonce.

What does a notification contain?

A transaction hash. To see the sender, recipient, value or input, call eth_getTransactionByHash on the JSON-RPC endpoint of the same network. That call is a normal read and uses the plan's read budget.

Which plan includes newPendingTransactions?

Every plan, from the 7-day trial up, on both Ethereum and Polygon. Paid plans raise the read budget you use for the follow-up lookups, and Pro adds newHeads, which is how you confirm that a transaction you saw pending was included in a block.

Can I read the pool with txpool_content instead?

Yes, as a separate capability: txpool_status, txpool_inspect and txpool_content on Ethereum and Polygon from Pro return the pool of the node that served the request, not the whole network mempool. This page is the push stream only.

What happens to transactions I miss while disconnected?

They are gone. The stream has no replay and no cursor. After a reconnect you subscribe again, receive a new subscription id, and continue from that moment. If you need to know what happened in between, read blocks and receipts over JSON-RPC.

Is it billed per notification or in credits?

No. Plans are a flat monthly price with no credits or overage; the stream is gated by plan, and the follow-up reads count against the per-second read limit shown in the table.

Mempool stream: pending Ethereum and Polygon transactions as nodes announce them

Last updated: November 1, 2026

Key facts

eth_subscribe newPendingTransactions streams pending transaction hashes on wss://triport.io/ws/eth (Ethereum) and wss://triport.io/ws/poly (Polygon), with an API key. (Triport capability registry, as of 2026-09-16)
newPendingTransactions is included on every plan, from the 7-day trial up, on both networks. (Triport plan matrix (tier-matrix.yaml), as of 2026-10-13)
newHeads starts at Pro on Ethereum and Polygon. (Triport plan matrix (tier-matrix.yaml), as of 2026-10-13)
Follow-up eth_getTransactionByHash lookups count against the read budget: Ethereum 10/20/100/250 and Polygon 15/20/100/250 requests per second on the 7-day trial, Basic, Pro and Business. (Triport plan matrix (tier-matrix.yaml), as of 2026-10-13)
The stream has no replay: subscriptions end with their connection, and notifications missed while disconnected are not resent. (Ethereum WebSocket reference, as of 2026-09-16)

Is this the right tool?

It fits when you need to act on transactions while they are still pending:

showing a “pending” state for transactions your users just sent;
noticing activity for addresses or contracts you watch, then checking each hash with one read;
researching pending flow, such as gas prices offered or contract calls that are waiting.

It does not fit when you need a complete, ordered record of the pool, full transaction bodies pushed to you, or history after a disconnect. See what it does not do.

How it works

Open a WebSocket to wss://triport.io/ws/eth (Ethereum) or wss://triport.io/ws/poly (Polygon) with your API key in the x-token header.
Send eth_subscribe with ["newPendingTransactions"]. The reply is a subscription id.
Each eth_subscription frame carries that id and one transaction hash.
For the details of a hash, call eth_getTransactionByHash on https://triport.io/eth or https://triport.io/polygon.

wscat -c "wss://triport.io/ws/eth" -H "x-token: $TRIPORT_API_KEY" \
  -x '{"jsonrpc":"2.0","id":1,"method":"eth_subscribe","params":["newPendingTransactions"]}'
# < {"jsonrpc":"2.0","id":1,"result":"0x…subscription id"}
# < {"jsonrpc":"2.0","method":"eth_subscription","params":{"subscription":"0x…","result":"0x…tx hash"}}
# Polygon: the same request on wss://triport.io/ws/poly

2× burst buffer, included. Finite request-rate limits show sustained RPS and short burst capacity. A full buffer at 20 RPS can absorb up to 40 requests at once and refills at 20 requests per second. There is no quota on the number of bursts and no extra charge for them. Size ongoing traffic to sustained RPS. Categories with no per-category cap have no numeric burst ceiling. How burst capacity works.

Plans and limits

From tier-matrix.yaml, the same source as RPC pricing. The per-second read limits allow a 2× burst.

What	Free trial (7 days)	Basic $20/mo	Pro $249/mo	Business $499/mo	Enterprise from $999/mo
`newPendingTransactions` on Ethereum	Included	Included	Included	Included	Included
`newPendingTransactions` on Polygon	Included	Included	Included	Included	Included
Ethereum reads (eth_getTransactionByHash and other reads)	10 RPS sustained · up to 20 burst	20 RPS sustained · up to 40 burst	100 RPS sustained · up to 200 burst	250 RPS sustained · up to 500 burst	No per-category cap
Polygon reads (eth_getTransactionByHash and other reads)	15 RPS sustained · up to 30 burst	20 RPS sustained · up to 40 burst	100 RPS sustained · up to 200 burst	250 RPS sustained · up to 500 burst	No per-category cap

A flat monthly price, no credits or overage: only the per-second limits above. newHeads, the subscription you use to confirm inclusion, starts at Pro.

What it does not do

It is not the whole mempool. You get what the serving nodes see. A missing hash proves nothing, and two subscriptions may not see the same set.
Pending is not included. A transaction can be dropped or replaced (same sender and nonce). Confirm with a receipt, or with newHeads on Pro and above.
Arrival order means nothing. Hashes arrive in the order the nodes heard them, not in fee order and not in the order a block will contain them.
Hashes only. A notification carries a transaction hash and nothing else. Getting the body costs one eth_getTransactionByHash read per hash, counted against the read limit above.
No replay. Nothing is buffered for you while you are disconnected.
No pool snapshots here. Reading a node's pool with txpool_content or txpool_status is a separate capability from Pro and not part of this page.
Ethereum and Polygon only. There is no pending-transaction stream for BNB Smart Chain or Base on this page. Solana has no mempool in this sense; its streams are listed under Streams.

FAQ

Is this the whole Ethereum mempool?: No. There is no single network mempool to subscribe to: every node keeps its own pool and hears transactions in its own order. The stream carries the pending transactions seen by the nodes that serve your subscription. A transaction can be missing from it, can appear and never be mined, or can be replaced by another transaction with the same nonce.
What does a notification contain?: A transaction hash. To see the sender, recipient, value or input, call eth_getTransactionByHash on the JSON-RPC endpoint of the same network. That call is a normal read and uses the plan's read budget.
Which plan includes newPendingTransactions?: Every plan, from the 7-day trial up, on both Ethereum and Polygon. Paid plans raise the read budget you use for the follow-up lookups, and Pro adds newHeads, which is how you confirm that a transaction you saw pending was included in a block.
Can I read the pool with txpool_content instead?: Yes, as a separate capability: txpool_status, txpool_inspect and txpool_content on Ethereum and Polygon from Pro return the pool of the node that served the request, not the whole network mempool. This page is the push stream only.
What happens to transactions I miss while disconnected?: They are gone. The stream has no replay and no cursor. After a reconnect you subscribe again, receive a new subscription id, and continue from that moment. If you need to know what happened in between, read blocks and receipts over JSON-RPC.
Is it billed per notification or in credits?: No. Plans are a flat monthly price with no credits or overage; the stream is gated by plan, and the follow-up reads count against the per-second read limit shown in the table.