newTxs and pendingTxs
Last updated
Last updated
Name: newTxs
, pendingTxs
The BDN supports subscribing to two transaction streams:
newTxs
is a stream of all new transactions as they are propagated in the BDN.
pendingTxs
is a stream of all new transactions as they enter the Ethereum/BSC/Polygon transaction pool.
For expedience, all transactions received through the BDN are immediately published to the newTxs
feed. By design, the Gateway/Cloud-API do not perform the same detail of transaction validation that the Ethereum nodes do, and cannot completely guarantee that all transactions propagated are valid (e.g. the Gateway/Cloud-API do not check for double spends). Therefore, these transactions have had basic validations done (e.g. checksums and other sanity checks) but may not be accepted into the TxPool.
The Gateway/Cloud-API can then leverage the Ethereum nodes for further validation of the transaction (e.g. check that it will be accepted into the TxPool), and publish results to the pendingTxs
feed. Users planning to use pendingTxs
with a Gateway feed should enable validation against their local Ethereum node.
It is expected that newTxs
stream will perform faster than pendingTxs
. The performance difference can be significant (10-100ms). Users interested in timely transaction information could find newTxs
stream more appealing, while those who rely on strict correctness of the transactions data should utilize the pendingTxs
stream.
The newTxs
stream can send transactions that have been (a) previously confirmed hours or days prior, or (b) replaced by a higher priced transaction with the same nonce. It is recommended that users with latency sensitive applications track the latest nonce for each account and use it to filter out stale messages.
The fields allowed in the include
section, which is currently available via Websocket only, depends on the user's subscription plan:
The transaction feed will publish the data for each transaction in a separate message. Users that are only interested in a subset of transactions can utilize the feed's filtering options.
The transaction feeds are available via both Websocket and gRPC.
Notes:
Follow the examples below based on your subscription plan. We suggest you to use "try...catch" to better handle exceptions caused by potential disconnections. The examples below contain the minimum code required for all transactions stream subscriptions.
See Cloud-API IPs to work directly with IP ( wss://<IP>/ws
)
Enterprise plan users can choose to work directly with wss://<region>.<network name>.blxrbdn.com/ws
(e.g.wss://virginia.eth.blxrbdn.com/ws
for ETH)
for the best performance.
Non-Enterprise plan users should use wss://api.blxrbdn.com/ws
.
Notes:
We assume that the Gateway IP is 127.0.0.1
with default ws port 28333
in the examples below. By default, the WebSocket endpoint is ws://127.0.0.1:28333/ws
for Go Gateway.
For Go Gateway, the authentication header is always required for ws connection.
Subscribing to Gateway Stream in Go using gRPC (ex: PendingTxs stream):