newTxs and pendingTxs
Name: newTxs
, pendingTxs
Options
Key
Description
Values
include
Fields to include in the transaction stream. The subscription plan determines the list of available fields.
tx_hash,tx_contents
[Default: all]
duplicates
Whether or not to include transactions
already published in the feed.
True,False
[Default]
include_from_blockchain
Whether or not to include transactions received first from the connected blockchain node. (Mainly used for testing)
True
[Default],False
filters
You can specify filters in SQL-Like format to only receive certain transactions.
Users can customize the filters.
blockchain_network
Blockchain network name. Use with Cloud-API when working with BSC
Mainnet
[Default, Ethereum Mainnet], BSC-Mainnet
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 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:
Plan
Available Fields
Introductory
tx_hash
Professional and above
tx_hash
, tx_contents.chain_id
, tx_contents.input
, tx_contents.v
, tx_contents.r
, tx_contents.s
, tx_contents.type
, tx_contents.to
, tx_contents.value
, tx_contents.nonce
, tx_contents.gas
, tx_contents.gas_price
, tx_contents.max_priority_fee_per_gas
,tx_contents.max_fee_per_gas
, tx_contents.max_fee_per_blob_gas
, tx_contents.blob_versioned_hashes
,tx_contents.yParity
, local_region
,raw_tx
Deprecated:
tx_contents.from
: requires --tx-include-sender-in-feed
if you are running Local Gateway. See Startup Arguments.
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.
Examples - Websocket
Requests (Cloud-API)
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
.
Requests (Gateway-API)
Notes:
We assume that the Gateway IP is
127.0.0.1
with default ws port28333
in the examples below. By default, the WebSocket endpoint isws://127.0.0.1:28333/ws
for Go Gateway.For Go Gateway, the authentication header is always required for ws connection.
Response (Tx Event)
Examples - gRPC
Subscribing to Gateway Stream in Go using gRPC (ex: PendingTxs stream):
Response (Tx Event)
Last updated