Skip to main content

Pending Transactions

Subscribes to pending transactions in the blockchain mempool, with optional filtering by contract methods and addresses.

Common Properties​

  • Name - The custom name of the node.
  • Color - The custom color of the node.
  • Delay Before (sec) - Waits in seconds before executing the node.
  • Delay After (sec) - Waits in seconds after executing node.
  • Continue On Error - Automation will continue regardless of any error. The default value is false.
info

If the ContinueOnError property is true, no error is caught when the project is executed, even if a Catch node is used.

Inputs​

  • Client ID - The client ID from the Create Client node.
  • Subscription Method - The subscription method name (typically "newPendingTransactions").

Output​

This node has 2 outputs:

  • Output 1 (default) - Not used
  • Output 2 (transaction) - Triggered when a matching pending transaction is detected

Options​

  • ABI - Optional ABI ID to filter transactions by method signature.
  • ABI Methods - Array of method names to filter (requires ABI).
  • To - Optional destination address to filter transactions.
  • Once - If enabled, emits only once then stops subscription.
  • HTTP Provider URL - Optional HTTP endpoint for transaction details lookup.

How It Works​

The Pending Transactions node monitors the mempool for pending transactions. When executed, the node:

  1. Connects to the blockchain via WebSocket
  2. Subscribes to pending transaction hashes
  3. For each pending transaction hash:
    • Retrieves transaction details
    • Applies filters (method, address)
    • If match, emits on output 2
  4. Continues monitoring until stopped (unless "Once" is enabled)

Requirements​

  • WebSocket RPC endpoint (wss://)
  • Valid Client ID
  • Optional: HTTP provider for better reliability
  • Optional: Parsed ABI for method filtering

Error Handling​

The node will return errors for:

  • Invalid Client ID or connection failure
  • WebSocket connection errors
  • Invalid ABI ID (if provided)
  • Invalid method names
  • Network connectivity issues

Filtering Options​

No filters: Receives all pending transactions (very high volume).

By destination address: Only transactions sent to specific contract or wallet.

By method: Only transactions calling specific contract methods.

Combined: Transactions to specific address AND calling specific methods.

Usage Notes​

  • Requires WebSocket connection
  • Very high data volume without filters
  • Pending transactions may never confirm
  • Use filters to reduce noise
  • HTTP provider improves transaction lookup reliability
  • Memory intensive for high-volume monitoring

Example​

Monitoring pending Uniswap swaps:

Inputs:

  • Client ID: 7e8f9a0b-1c2d-3e4f-5a6b-7c8d9e0f1a2b (wss:// endpoint)
  • Subscription Method: newPendingTransactions

Options:

  • ABI: a1b2c3d4-e5f6-7g8h-9i0j-k1l2m3n4o5p6 (Uniswap Router ABI)
  • ABI Methods: ["swapExactTokensForTokens", "swapTokensForExactTokens"]
  • To: 0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D (Uniswap V2 Router)
  • Once: false
  • HTTP Provider URL: https://mainnet.infura.io/v3/YOUR_KEY

Output on detection:

{
  "id": "unique-id",
  "trx": {
    "hash": "0x...",
    "nonce": 123,
    "from": "0x...",
    "to": "0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D",
    "value": "0",
    "gas": 200000,
    "gasPrice": "50000000000",
    "input": "0x38ed1739..."  // Encoded swap method
  }
}

Common Use Cases​

Front-Running Detection: Monitor pending transactions to detect potential front-running.

MEV Opportunities: Identify profitable MEV opportunities in pending swaps.

Arbitrage Monitoring: Watch for pending trades that create arbitrage opportunities.

Large Transfer Alerts: Detect large pending transfers for market intelligence.

Contract Interaction Analysis: Study how users interact with specific contracts.

Gas Price Analysis: Monitor gas prices users are willing to pay.

Filtering Examples​

All transactions to a contract:

To: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"
ABI: (empty)
Methods: (empty)

Specific method calls:

To: "0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D"
ABI: "uniswap-router-abi-id"
Methods: ["swapExactTokensForTokens"]

Any method from list:

To: (empty - any address)
ABI: "erc20-abi-id"
Methods: ["transfer", "transferFrom", "approve"]

Transaction Data Structure​

Received transaction object:

{
  "hash": "0x...",              // Transaction hash
  "nonce": 42,                  // Sender's nonce
  "from": "0x...",              // Sender address
  "to": "0x...",                // Destination address
  "value": "0x...",             // Value in WEI (hex)
  "gas": 200000,                // Gas limit
  "gasPrice": "50000000000",    // Gas price in WEI
  "input": "0x...",             // Encoded method call
  "v": "0x...",                 // Signature
  "r": "0x...",
  "s": "0x..."
}

Processing Pending Transactions​

Extract transaction details:

pendingTx = message.trx

sender = pendingTx.from
recipient = pendingTx.to
gasPrice = pendingTx.gasPrice
methodData = pendingTx.input

// Decode method call
decodedMethod = decode(methodData, abi, method)

Check if transaction confirms:

pendingHash = pendingTx.hash

// Wait and check
wait(30000)  // 30 seconds
receipt = getTransactionReceipt(pendingHash)

if (receipt) {
  // Transaction confirmed
} else {
  // Still pending or dropped
}

Volume Management​

Pending transaction volume:

  • Ethereum mainnet: 100-1000+ tx/second
  • Without filters: Overwhelming data volume
  • With address filter: 10-100+ tx/second (depends on contract)
  • With method filter: Much more manageable

Recommendations:

  • Always use filters for production
  • Test with restrictive filters first
  • Monitor resource usage
  • Use "Once" for testing

Memory and Performance​

High-volume considerations:

  • Each transaction object consumes memory
  • Processing time affects throughput
  • WebSocket buffer can overflow
  • System resources matter

Optimization strategies:

  • Use specific filters
  • Process asynchronously
  • Don't store all transactions
  • Extract only needed data
  • Use rate limiting if needed

HTTP Provider Benefits​

Why use HTTP provider:

  • More reliable transaction lookup
  • WebSocket may miss details
  • Better for high-volume scenarios
  • Fallback for WebSocket failures

Example:

HTTP Provider URL: "https://mainnet.infura.io/v3/YOUR_KEY"

Method Signature Matching​

How method filtering works:

  1. Extract first 4 bytes of input data
  2. Calculate method signature from ABI
  3. Compare signatures
  4. Emit if match found

Example:

// Transfer method
Signature: "transfer(address,uint256)"
Hash: keccak256("transfer(address,uint256)")
Selector: 0xa9059cbb (first 4 bytes)

// Transaction input starts with 0xa9059cbb → Match!

Real-Time Bot Examples​

Sandwich attack detection:

Pending Transactions (swaps)
  → Identify large swaps
  → Calculate price impact
  → Alert if sandwich opportunity

Large transfer alert:

Pending Transactions (transfers)
  → Check transfer amount
  → If > threshold
  → Send alert with details

Gas price monitoring:

Pending Transactions (all)
  → Extract gas price
  → Calculate statistics
  → Track trends

Reliability Considerations​

Pending transactions may:

  • Never confirm (too low gas, errors)
  • Be replaced (nonce replacement)
  • Confirm quickly (high gas price)
  • Stay pending for hours (low gas)

Don't assume:

  • All pending tx will confirm
  • Order of pending tx matters
  • Same tx hash will confirm

Combining with Other Nodes​

Complete monitoring flow:

Pending Transactions
  → Store hash
  → Wait for confirmation
  → Get Transaction Receipt
  → Process confirmed data

Front-running prevention:

Pending Transactions (your contracts)
  → Identify suspicious patterns
  → Compare with your pending tx
  → Take defensive action

Testing Setup​

Test on testnet first:

  1. Use testnet RPC (wss://goerli...)
  2. Subscribe to test contract
  3. Generate test transactions
  4. Verify detection works
  5. Check filtering accuracy

Volume testing:

  1. Start with restrictive filters
  2. Gradually broaden
  3. Monitor system resources
  4. Adjust based on capacity

Error Handling​

Connection issues:

try {
  subscribePending()
} catch (error) {
  log("Subscription failed", error)
  retry()
}

Processing failures:

onPending((tx) => {
  try {
    process(tx)
  } catch (error) {
    log("Processing failed", tx.hash, error)
    // Continue with next transaction
  }
})

Privacy Considerations​

Pending transactions reveal:

  • Addresses involved
  • Amounts being transferred
  • Methods being called
  • Gas prices being paid
  • Trading strategies

Use responsibly:

  • Don't exploit user information
  • Respect privacy where possible
  • Follow regulations
  • Consider ethical implications
warning

Monitoring pending transactions consumes significant resources. Always use filters to reduce volume to manageable levels. Without filters, you may receive hundreds of transactions per second.

danger

Pending transactions are not confirmed and may never be included in a block. Never assume a pending transaction will execute. Always verify confirmation with Transaction Receipt.

tip

For production use, always specify at least the "To" address filter. This dramatically reduces the volume of transactions you need to process.

Advanced Filtering​

Combine multiple conditions:

// Only swaps to Uniswap V2 Router
// calling swapExactTokensForTokens
// with gas price > 100 GWEI

To: "0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D"
Methods: ["swapExactTokensForTokens"]

// Then in processing:
if (tx.gasPrice > 100000000000) {
  // Process this transaction
}