Tools · Server query

Mempool Acceptance Test

Compare whether five independently configured Bitcoin nodes — Andreas, Hal, Martti, Adam, and Peter — would accept a signed raw transaction into their different mempools right now. Peter runs Libre Relay; the other four run Bitcoin Core. The check covers transaction structure, consensus validity, current chain state, fees, conflicts, and each node’s active relay policy.

The test is read-only: it does not broadcast the transaction, announce it to peers, store it for later, or guarantee that either node will accept it at a later time.

Current node mempools

Every row uses the same live comparison contract: client, deployment mode, transaction count, virtual size, usage and capacity, admission floor, minimum relay fee, incremental relay fee, replacement policy, and freshness. Values come from validated caches of the BitcoinStats nodes.

See Node Details for broader operational data and Libre Relay for Peter’s measured policy differences.

Loading metrics…

Andreas Node #1

Bitcoin Core –

Pruned · Multi-network P2P

Transactions–

Virtual size–

Usage / Capacity–

Admission floor–

Minimum relay–

Incremental relay–

–Waiting for data

Hal Node #2

Bitcoin Core –

Full archive · Multi-network P2P

Transactions–

Virtual size–

Usage / Capacity–

Admission floor–

Minimum relay–

Incremental relay–

–Waiting for data

Martti Node #3

Bitcoin Core –

Full archive · Onion-only P2P

Transactions–

Virtual size–

Usage / Capacity–

Admission floor–

Minimum relay–

Incremental relay–

–Waiting for data

Adam Node #4

Bitcoin Core –

Pruned · Multi-network P2P

Transactions–

Virtual size–

Usage / Capacity–

Admission floor–

Minimum relay–

Incremental relay–

–Waiting for data

Peter Node #6

Libre Relay –

Pruned · Multi-network P2P

Transactions–

Virtual size–

Usage / Capacity–

Admission floor–

Minimum relay–

Incremental relay–

–Waiting for data

Mempool min fee is the node’s current admission floor. A fee rate above it is necessary when the floor is elevated, but it does not guarantee acceptance: inputs, conflicts, scripts, standardness, and ancestor or descendant limits are checked separately.

Explicit server query

Paste a signed raw transaction

Whitespace is removed in this browser before submission. The maximum decoded transaction size is 400,000 bytes.

Nothing has been submitted. The transaction stays in this browser until you press “Test acceptance”.

Point-in-time results

Mempool policy decisions

Explicit server query

Submission is explicit and read-only.

Submitted input: The full signed raw transaction is sent only after you explicitly submit it. Network effect: BitcoinStats sends it to the selected BitcoinStats-operated node or nodes for a read-only mempool policy check. It is not broadcast or stored. Cached metrics from the BitcoinStats nodes refresh every 10 seconds while the page is visible.

Raw signed transactionBitcoinStatsSelected node(s)Per-node results

Metrics from the BitcoinStats nodes refresh every 10 seconds while this tab is visible. Your transaction is submitted only when you press “Test acceptance”; it is never retried automatically or stored in the URL, browser storage, or analytics.

Purpose, privacy, and limits

Interpret a point-in-time answer

Node-specific policy

Each node evaluates the same transaction against its own current mempool, chain state, fee floor, standardness rules, and package limits. Their answers can differ.

No broadcast

The backend uses each node’s read-only mempool acceptance check. It never calls a submission RPC and does not relay the transaction to Bitcoin peers.

Not a future guarantee

Conflicts, spent inputs, fee thresholds, ancestors, reorgs, or policy can change after the check. Acceptance also does not promise confirmation.

Usage limits

Up to 6 submissions per minute per IP address, with a maximum of 3 immediate requests. Testing all five nodes still counts as one submission. Raw transactions may be up to 400 kB. Shared capacity is limited, so the service may temporarily return a rate-limit response when busy.

Privacy disclosure

When you submit, your full signed transaction and IP address reach BitcoinStats over the clearnet. The raw transaction is used in memory for this single check on the selected nodes and is not stored. Checks on Hal and Martti continue over an encrypted private WireGuard path; Peter is reached through a pinned, authenticated private TLS interface. Martti’s Bitcoin peer traffic remains Onion-only. Live metrics and the Libre Relay example are served directly by BitcoinStats; your browser contacts no third-party data provider.