What makes Zund different

At a glance

Quickstart

Three steps: sign, send, track. No sign-up.

1. Sign your transactions

Build and sign your transactions as usual. A bundle is a list of raw signed transactions, executed in order and all together, or not at all.

Pay the builder the way you prefer: a priority fee, or a direct ETH transfer to block.coinbase inside your transaction.

2. Send the bundle

curl -s https://zundbuilder.com \
  -H 'content-type: application/json' \
  -d '{
  "jsonrpc": "2.0", "id": 1,
  "method": "eth_sendBundle",
  "params": [{
    "txs": ["0x02f8...signed tx 1", "0x02f8...signed tx 2"],
    "blockNumber": "0x18d4a21"
  }]
}'

const ZUND = "https://zundbuilder.com";

async function sendBundle(txs, blockNumber) {
  const res = await fetch(ZUND, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({
      jsonrpc: "2.0", id: 1, method: "eth_sendBundle",
      params: [{ txs, blockNumber: "0x" + blockNumber.toString(16) }]
    })
  });
  return (await res.json()).result;   // { bundleHash, simulation }
}

3. Read the answer

You get the simulation result right away, in the same response. This one is real, from a live mainnet transaction:

{
  "bundleHash": "0x3e8cf25e71af056f873f777d5f269f8f3ef4d1569f9aef98178ff429a02a4cd5",
  "simulation": {
    "ok": true,
    "reason": null,
    "builderPaymentEth": 0.000006368400127368,
    "ms": 9,
    "txs": [{ "hash": "0xe29da8c1…0c3c", "status": "SUCCESS", "gasUsed": 127368, "error": null }]
  }
}

Then call zund_getBundleStats with the bundleHash to see whether it landed, in which block, and at which position.

Principles

Ethereum is for everyone, so its blocks should be too. These are the rules Zund follows, published so anyone can hold us to them.

1. No club

No whitelist, no API key, no account, no private priority lane. Every bundle is ranked by what it adds to the block, and by nothing else. Who sent it does not matter.

2. Your flow is yours

• Zund never front-runs, back-runs or sandwiches the transactions and bundles it receives.
• Zund does not let others do it either: a bundle that sandwiches another sender's transaction is rejected when it arrives, with the reason in the response.
• Bundles are never unbundled, broadcast to the public mempool or shown to other searchers.
• Zund runs no searcher strategies on the flow it receives.

3. No censorship

Zund's transaction blocklist is empty. Any valid transaction that pays for its place can be included.

4. Every sender gets an answer

A bundle that is rejected is never silently dropped. You get the reason in the same response, and you can track the outcome block by block.

5. A thin margin

The builder keeps a small share. Most of the value created by a bundle goes back to the people who create it. The refund rule is public: 90% of the surplus you create comes back to you, the same rule for everyone.

6. Built for the next Ethereum

Zund is designed for the protocol that is coming (ePBS, inclusion lists, encrypted mempools), not the one that is leaving. See Ready for what's next.

How blocks are built

From your request to a finished block, in four stages.

1. Gateway: instant simulation

Every eth_sendBundle is decoded and simulated on the latest mainnet state before anything else. The simulation charges the priority fee and follows ETH transfers to the Zund coinbase, so it knows exactly what the bundle pays. You get the result in the response, usually in 5 to 35 ms.

2. Engine: algorithms compete

The bundle then goes to the engine, based on rbuilder running on its own reth node. Three block-building algorithms run at the same time and the most valuable block wins:

Orders are re-simulated inside the block they are placed in, so interactions between bundles are taken into account, not only the gas price.

3. End-of-block pass

After the block is filled, bundles sent with eth_sendEndOfBlockBundle are tried on the final state of the block. This is where you back-run what happened inside the block itself. A bundle that reverts or pays nothing is dropped, and the block stays as it was.

4. Relays

Zund submits every block to the Flashbots, Ultra Sound, Titan, Aestus and Agnostic relays, paying the proposer only what is needed to beat the best competing bid.

How much the proposer gets. Zund reads the best competing bid live and offers just above it: bid = min(block value, best other bid + 0.00001 ETH). The proposer gets what it takes to win; the rest of the block value is the surplus that goes back to the senders (see Refunds). Zund never bids more than its block is worth.

API overview

Standard JSON-RPC 2.0. If you have already sent bundles to any builder, you already know how to use Zund.

Methods

Signing (optional)

You can add the standard Flashbots header X-Flashbots-Signature: <address>:<signature>, where the signature is the EIP-191 signature of the keccak256 hash of the request body. If it is valid, your address is shown as signer in zund_getBundleStats. It is required for replacementUuid and eth_cancelBundle.

Limits and error codes: see Errors & limits.

Send a list of signed transactions to be included together, in order, in the target block. Nothing is included unless the whole bundle is valid.

Parameters

Example

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_sendBundle",
  "params": [{
    "txs": ["0x02f8b1…", "0x02f8d3…"],
    "blockNumber": "0x18d4a21",
    "revertingTxHashes": []
  }]
}

curl -s https://zundbuilder.com \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_sendBundle","params":[{"txs":["0x02f8b1…","0x02f8d3…"],"blockNumber":"0x18d4a21"}]}'

Response

{
  "jsonrpc": "2.0", "id": 1,
  "result": {
    "bundleHash": "0x3e8cf25e…4cd5",
    "simulation": {
      "ok": true,
      "reason": null,
      "builderPaymentEth": 0.000006368400127368,
      "ms": 9,
      "txs": [
        { "hash": "0xe29da8c1…0c3c", "status": "SUCCESS", "gasUsed": 127368, "error": null }
      ]
    }
  }
}

Possible reasons

A bundle placed after every other order, on the final state of the block. Use it to back-run what happens inside the block itself.

Parameters

Example

{
  "jsonrpc": "2.0", "id": 1,
  "method": "eth_sendEndOfBlockBundle",
  "params": [{
    "txs": ["0x02f8…"],
    "blockNumber": "0x18d4a21",
    "targetPools": ["0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640"]
  }]
}

{ "jsonrpc": "2.0", "id": 1,
  "result": { "accepted": true, "note": "will be tried after all other orders, on the final block state" } }

Guarantees

• Same atomicity as a normal bundle: all transactions or none.
• If the bundle reverts or pays nothing on the final state, it is dropped and the block does not change.
• No instant simulation for this method: the state it depends on does not exist yet when you send it.

Send one signed transaction privately. It is not broadcast to the public mempool.

Parameters

{ "jsonrpc": "2.0", "id": 1, "method": "eth_sendRawTransaction", "params": ["0x02f8…"] }

{ "jsonrpc": "2.0", "id": 1, "result": "0x…transaction hash" }

Withdraw your replaceable bundles. Only the signer who sent them can cancel them.

Parameters

The request must carry a valid X-Flashbots-Signature. Zund pairs the uuid with the verified signer, so nobody else can cancel or replace your bundles, even if they learn the uuid.

{ "jsonrpc": "2.0", "id": 1, "method": "eth_cancelBundle",
  "params": [{ "replacementUuid": "3b35aab2-e12a-4063-9714-877df1a0f05d" }] }

{ "jsonrpc": "2.0", "id": 1,
  "result": { "cancelled": true, "replacementUuid": "3b35aab2-…", "bundles": 1 } }

bundles is how many of your pending bundles were marked CANCELLED. The engine drops them from the next rebuild of the block.

Replace instead of cancel

To update a bundle, send a new eth_sendBundle with the same replacementUuid. The previous one becomes REPLACED in zund_getBundleStats.

Everything Zund knows about your bundle. Available immediately, updated every block.

Parameters

{ "jsonrpc": "2.0", "id": 1, "method": "zund_getBundleStats",
  "params": ["0x3e8cf25e71af056f873f777d5f269f8f3ef4d1569f9aef98178ff429a02a4cd5"] }

{
  "bundleHash": "0x3e8cf25e…4cd5",
  "status": "FORWARDED",
  "reason": null,
  "targetBlock": 26038817,
  "receivedAt": "2026-09-23T07:53:16.379Z",
  "txCount": 1,
  "signer": null,
  "simulation": { "ok": true, "builderPaymentEth": 0.0000063684, "ms": 9, … },
  "landing": {
    "status": "LANDED",
    "block": 26038817,
    "position": 117,
    "builder": "BuilderNet",
    "complete": true,
    "success": true
  }
}

Fields

Unknown hashes return { "status": "UNKNOWN" }. Bundles are kept for 6 hours.

The rules of this builder as JSON, so your bot can read them.

{
  "name": "Zund",
  "phase": "live: Zund bids every slot to Flashbots, Ultra Sound, Titan, Aestus and Agnostic relays",
  "principle": "a builder for everyone: no whitelist, no API key, same rules for every bundle, every sender gets an answer",
  "forbidden": ["sandwiching the flow Zund receives", "censorship (blocklist is empty)"],
  "refunds": "90% of the surplus back to senders by contribution, 10% fee, paid in the same block (starts with bidding)",
  "docs": "https://zundbuilder.com",
  "limits": { "requestsPerSecondPerIp": 30, "maxBodyBytes": 1048576 }
}

Errors & limits

The same limits for everyone. No paid tier.

Limits

Error codes

A bundle that decodes correctly but fails simulation is not an error: you get a normal result with simulation.ok: false and a reason.

Bundle tracing

Know what happened to every bundle, while it still matters: the simulation comes in the response, the landing check runs every block.

Lifecycle

status

landing.status

Checklist when a bundle does not land

1. Look at simulation.reason. Most failures are there.
2. Check targetBlock. A bundle for a block that has already passed cannot land.
3. Check the payment. Another bundle touching the same state may simply pay more.
4. If a transaction may already be on chain, list it in droppingTxHashes.

Refunds with bidding

When your bundle makes a Zund block more valuable, most of that value comes back to you. One rule, the same for everyone, written here in full.

The rule in one sentence

After paying the proposer, Zund keeps 10% of what is left and gives the other 90% back to the senders, in proportion to how much each one added to the block.

How it is computed

For every block Zund wins:

refundᵢ = (1 − f) × min(S, Σⱼ μⱼ) × μᵢ / Σⱼ μⱼ

The builder only keeps f × min(S, Σμ), plus any surplus that no bundle created (for example, from public mempool transactions).

Example

Who gets it

• Identity: the address in your X-Flashbots-Signature header. Without a signature, the sender of the first transaction of the bundle.
• Where it goes: refundRecipient if you set it, otherwise your identity address.
• Split identities do not pay more. A group of identities can never receive more in total than their bundles contributed to the block, so splitting your flow across many keys gains nothing.
• Everyone who sends privately to Zund qualifies: bundles, end-of-block bundles and private transactions. Transactions that were already public in the mempool do not.

When and how it is paid

• Inside the block, if you set refundPercent (see below).
• Right after the block for the surplus share. As soon as a Zund block lands, it is computed and paid by transactions from the Zund coinbase, usually within the next few blocks. Anyone can check them on chain against the block.
• Dust is kept for you, not lost. A refund smaller than the gas needed to send it is added to your balance and paid in a later block, once it is worth sending.
• Visible. Each bundle's refund will appear in zund_getBundleStats.

Refunds inside the same block: refundPercent

Like Titan, you can also ask for a refund paid inside the same block. Add refundPercent (1–99) to eth_sendBundle: that share of what your bundle pays the builder is sent back to you by a transaction placed right after your bundle, in the same block. Its gas is taken from the refund.

Then the surplus rule still applies. What you received inside the block is subtracted from your contribution, and 90% of the remaining surplus is shared as described above. At Titan, what is left after refundPercent stays with the builder; at Zund, 90% of it comes back to the senders.

Zund Protect live

A private RPC for your wallet. Your transactions never go to the public mempool, so nobody can sandwich them.

Add it to your wallet

What happens to your transaction

• Private. Zund does not broadcast it to the public mempool.
• It lands fast. Zund puts it in its own block and also shares it privately with builders that do not sandwich private flow (Titan, Quasar, Flashbots Protect), so it is included whoever wins the slot.
• No sandwich at Zund. Bundles that sandwich another sender are rejected at the door.
• Reads are served by Zund's own node: balances, nonces, calls, gas estimates, receipts, logs (up to 1,000 blocks per query).

Builder identity

How to recognise a Zund block, and where Zund will send its blocks.

To pay the builder directly from a contract, transfer ETH to block.coinbase. It always points to the builder of the block your transaction is in.

Live numbers

Everything Zund does, counted in public. Updated every 5 minutes from the builder's own logs. Raw file: /stats.json.

Blocks won are checked on chain (fee recipient = Zund coinbase). "Bids above block value" must always be 0: Zund never pays a proposer more than its block is worth.

Ready for what's next

Ethereum is changing how blocks are built. Zund is designed for where it is going.

Status & roadmap

What works today, and what comes next. Updated as things ship.

Live

Next

Changelog