The snapshot download ran for about 15 hours. Five parts, roughly 500 GiB each (the last one 163 GiB), totalling ~2.1 TiB. We watched the logs tick through pruned.tar.part0000 through pruned.tar.part0004 and waited. Then the pod crashed mid-extraction.

On the next restart, the node refused to initialize. The error was this:

ERROR error initializing database  err="found 1 unexpected files in database directory, including: tmp"

That was it. No further detail. l2chaindata was never created - the database directory contained only the LOCK file and the tmp/ staging directory left behind from the download. Every restart produced the same error. Every restart ended in the same crash loop. There was no flag to skip the check, no --force-init, no obvious way to tell the node to proceed anyway.

To understand why this is not a bug you can work around but a design choice you have to accommodate, it helps to look at how Nitro decides whether it is safe to initialize at all.

How Nitro initializes from a snapshot

The init flags

Nitro's snapshot init system is configured through --init.* flags (or the JSON config equivalent):

• init.latest: "pruned" - downloads the latest pruned snapshot automatically

• init.url: "https://..." - pins to a specific snapshot URL

• init.download-path - where to stage downloaded tar parts, separate from the database directory; if not set, Nitro defaults to <persistent.chain>/nitro/tmp/

Download flow

The sequence, from cmd/nitro/init.go:

1. Fetches the manifest from the snapshot URL

2. Downloads multipart tar files (.part0000, .part0001, ...) to download-path

3. Joins the parts into a single archive

4. Extracts the archive directly into <persistent.chain>/nitro/l2chaindata/

5. Cleans up the tmp/ staging directory - but only if download-path was not explicitly set

checkEmptyDatabaseDir

Before any initialization work begins, Nitro checks the database directory against a strict allowlist in checkEmptyDatabaseDir:

// cmd/nitro/init.go
allowedFiles := map[string]bool{
    "LOCK": true, "classic-msg": true, "l2chaindata": true,
}
for _, entry := range entries {
    if !allowedFiles[entry.Name()] {
        unexpectedFiles = append(unexpectedFiles, entry.Name())
    }
}
if len(unexpectedFiles) > 0 {
    return fmt.Errorf("found %d unexpected files in database directory, including: %s", ...)
}

When download-path is not set (the default), Nitro creates <persistent.chain>/nitro/tmp/ as the staging directory. If the pod crashes mid-download, tmp/ is left behind with whatever partial tar parts had been written. On the next restart, checkEmptyDatabaseDir finds tmp/ in the database directory - it is not in the allowlist - and the node refuses to start.

This is the most common failure mode when setting up a new Nitro node.

The check runs before any initialization work. There is no flag to skip it, no recovery mode. The only way forward is to either remove the unexpected files manually or prevent them from being there in the first place.

The fix: init.download-path

Set init.download-path to a path on a separate PVC. Nitro stages all download artifacts there, leaving the main data PVC containing only LOCK (and eventually l2chaindata). If the pod crashes, checkEmptyDatabaseDir passes on restart and the download resumes.

Resuming downloads

The download library Nitro uses - github.com/cavaliergopher/grab - detects already-downloaded files by comparing local file size to the server's Content-Length. Existing complete parts are skipped. This makes crash recovery essentially free - you lose at most one in-progress part.

Cleanup is manual

When download-path is set, Nitro does not clean up the download artifacts after extraction completes. The parts and joined archive remain on the init PVC. Delete them manually once you have confirmed the node is syncing.

Disk space math

Peak init PVC usage: ~4.2 TiB (parts + joined archive simultaneously). We used 6 TiB for headroom.

PVC sizing:

• Init PVC: 6 TiB on cheaper HDD-backed storage - sufficient because downloads only need sequential throughput, not live-database IOPS

• Main data PVC: 4 TiB on SSD-backed storage - needed for the IOPS of a live pebble database

Helm chart implementation

init.download-path is auto-injected into config.json via the Helm template when initStorage.enabled: true. When disabled, the init PVC is removed by Helm automatically - it is a standalone PVC, not a volumeClaimTemplate, so Helm can delete it without touching stateful data.

The extraction destination is always <persistent.chain>/nitro/l2chaindata/ regardless of download-path. Setting download-path only affects where the parts and joined archive live during the download phase.

Resource sizing

Observed on an 8-core node, April 2026:

Memory stays elevated after sync completes - pebble keeps a large portion of the database in the block cache. The jump to 3-6 cores during feed catchup is from processing the backlog of L2 transactions.

Our Kubernetes resource requests: cpu: "4", memory: "8Gi". The 8 GiB request is conservative relative to the ~14-15 GiB actual usage during and after sync. Set limits accordingly or leave memory unlimited.

During feed catchup the node is CPU-heavy: it executes the backlog of L2 transactions as fast as it can. The 4-core request lets the pod schedule on a reasonably sized node while allowing burst up to 6 cores. If your cluster enforces CPU limits, expect catchup to take longer.

Sync phases

Phase 1: Blob-fetching sync (historical)

Nitro replays historical L1 batches from the snapshot date forward. Batches posted after Dencun (EIP-4844, March 2024) are stored as blobs on the beacon chain rather than as calldata. Nitro fetches them from the beacon chain as it processes each batch.

Because our local Prysm node was still backfilling at this point and did not yet cover the older blob range, these historical blobs were served by Chainstack, the external beacon endpoint we ran as the primary during sync. Chainstack saw ~150-200 req/min during this phase. The phase ends once the node catches up near the chain head and switches to the sequencer feed.

(The beacon URL configuration - Chainstack as primary, local Prysm as fallback - is covered in the next section.)

Phase 2: Feed-driven sync (near head)

Once close enough to the chain head, Nitro switches to receiving transactions from the sequencer feed (wss://arb1.arbitrum.io/feed). No blob fetching is needed in this mode - the feed delivers transaction data directly.

Observable: Chainstack beacon requests drop to ~0.

The log line Reading message result remotely repeating on the same msgIdx is normal during this phase - it is polling the sequencer feed while waiting for the next message to be confirmed:

INFO Reading message result remotely.  msgIdx=432935973
INFO Reading message result remotely.  msgIdx=432935973

Phase 3: Live (synced)

created block logs appear at real-time cadence. The node is at head.

Timing

Real measurements, pruned snapshot, April 2026:

Total from scratch to synced: ~31 hours, of which ~15 hours is the download.

Background cleanup during catchup

During Phase 1 and 2 you will see log lines like these:

INFO Unindexing transactions  blocks=44,635,000 txs=75,903,733 total=327,775,881 elapsed=14m33s
INFO Deleting tail epoch #1 in progress...

These are normal - not errors. Nitro is pruning old transaction indexes from the snapshot data in the background while it syncs.

Beacon and blob setup

Nitro needs a beacon endpoint to fetch EIP-4844 blobs. We run two: an external Chainstack endpoint and a local Prysm instance. During the initial sync we set Chainstack as the primary and local Prysm as the fallback, because Prysm had only just been deployed and did not yet hold historical blobs. Nitro queries the primary first and falls back to the secondary when the primary does not have the blob.

parent-chain:
  blob-client:
    beacon-url: "https://chainstack-url/beacon/..."  # primary (external Chainstack)
    secondary-beacon-url: "http://prysm.svc:3500"    # fallback (local Prysm)

The field names are beacon-url (primary) and secondary-beacon-url (fallback). During sync we pointed the primary at Chainstack so historical blobs resolved immediately, with local Prysm as the fallback.

Why two URLs, and the switch: local Prysm was deployed on April 20, 2026 with --enable-backfill. It takes approximately 18 days (~May 8) to backfill full blob history. Until then, Prysm returns 404 for pre-April-20 slots, so keeping Chainstack as the primary kept the sync from stalling on those misses. After ~May 8, once Prysm had full history, we flipped the primary to local Prysm and dropped the Chainstack secondary-beacon-url, relying on local Prysm alone.

Monitoring blob fetches

Prysm exposes HTTP API request counts. Three useful queries:

# Blob request rate by status code
rate(http_request_count{exported_endpoint="blob.Blobs", job="prysm-beacon"}[5m])

# Blob request latency p99
histogram_quantile(0.99,
  rate(http_request_latency_seconds_bucket{exported_endpoint="blob.Blobs", job="prysm-beacon"}[5m])
)

# Backfill progress
backfill_blobs_download_count{job="prysm-beacon"}

Prysm's HTTP metric label is exported_endpoint, not endpoint. Prometheus relabeling renames it during scrape. A 200 status means Prysm has that blob locally; 404 means it has not backfilled that slot yet. While Prysm is still backfilling, Chainstack stays the primary so those gaps do not stall the sync.

Kubernetes operational notes

Diagnostic mode

We added a diagnosticMode flag to the Helm chart. When true, it replaces the Nitro command with a signal-handled sleep:

command:
  - /bin/sh
  - -c
  - "trap 'exit 0' TERM INT; sleep infinity & wait"

The sleep infinity & wait form matters. wait is a shell builtin and is interrupted by signals immediately. Bare sleep infinity ignores SIGTERM, so kubectl delete pod hangs until the grace period expires - and if you resort to --force --grace-period=0, network teardown is skipped, leaving stale interfaces on the host.

Stale veth after force-delete

Force-deleting a pod (--force --grace-period=0) bypasses network teardown. The host-side veth interface remains, causing the replacement pod to fail with:

Failed to create pod sandbox: ... container veth name ("eth0") peer provided ("gke33b862248e7") already exists

GKE kubelet GC resolves this automatically in ~10 minutes (observed). If urgent: drain and uncordon the node, or SSH in and ip link delete <veth-name>.

Use --force --grace-period=0 only when you are certain the pod is truly stuck. The stale veth can prevent the replacement pod from starting on the same node for up to 10 minutes.

Moving files between PVCs

mv across different PVCs falls back to copy+delete (different filesystems). Use rsync for large transfers:

rsync -a --info=progress2 /source/ /dest/

--info=progress2 shows overall bytes/speed/ETA instead of per-file output - much cleaner for multi-TiB transfers.

Snapshots

Browse available snapshots at Arbitrum snapshot explorer

Available types for Arbitrum One (arb1):

• Pruned (recommended for RPC nodes): ~2.1 TiB compressed, new snapshot every ~12 days

• Archive-path: much larger, for full history access

• Archive: LevelDB format (legacy)

init.latest: "pruned" always picks the newest available pruned snapshot. To pin a specific snapshot:

init:
  url: "https://snapshot.arbitrum.io/arb1/2026-04-08-a3b0e3cf/"

Pinning is useful when you have already downloaded parts and want to resume a specific snapshot after a crash. Set init.url to the same snapshot URL and grab will detect the existing parts by Content-Length and skip re-downloading them.

The community Helm chart ships with an empty nitro.initContainers stub - no built-in snapshot handling. The tmp/ problem exists there too with no upstream workaround. Custom init containers can be injected via initContainers: (raw YAML passthrough).

To verify what snapshot a running node initialized from, check the logs for INFO Downloading initial database url=... or INFO Successfully joined parts into archive. These appear once during the init phase and are not repeated on subsequent restarts.

The non-obvious part of this setup is that Nitro's default staging location for snapshot downloads sits inside the same directory it checks for unexpected files before initializing - so a crash leaves behind a file that permanently blocks the next start. Setting init.download-path to a separate PVC moves the staging artifacts out of that directory, making downloads crash-safe and resumable without manual intervention. For a closer look at the logic, cmd/nitro/init.go is the place to start.

🎁 Special gifts for hackathon builders! 🎁

The Mezo Hackathon: Building Bitcoin’s Future, organized by Encode Club, is a four-week virtual hackathon inviting developers to push Bitcoin into everyday finance. Builders compete for a $30,000 worth of veMEZO tokens by creating apps and services on top of Mezo — the Bitcoin-first, EVM-compatible blockchain.

Whether you are building a DeFi protocol, a payment tool, a yield-generating product, or anything in between — Boar provides the infrastructure to build on top of it. RPC endpoints for Mezo, Ethereum, and Bitcoin, plus AI-ready tooling on top, so you can focus on shipping.

A Starter Pack from Boar

We work every day to make blockchain infrastructure accessible to developers — with RPCs for Bitcoin, Ethereum, and Mezo, plus tooling for AI-assisted development. For this hackathon, we are putting three things on the table specifically for participating builders.

1. Blockchain MCP — Query Mezo, Ethereum, and Bitcoin with Your AI Agent

One of the hardest parts of blockchain development is debugging: tracing a failed transaction, decoding a revert reason, tracking balances across chains. Our Blockchain MCP is a free, remote Model Context Protocol server that gives your AI coding assistant (Claude, Cursor, and others) direct read access to blockchain data — no local node, no API key, no setup.

What it supports:

• Bitcoin — mainnet and testnet (UTXOs, transactions, blocks, address data)

• Ethereum — mainnet (balances, tokens, smart contract calls, ENS resolution)

• Mezo — mainnet (EVM-compatible queries, bridge data, MUSD tracking)

What it can do:

• Look up balances, transactions, and block data across all three chains

• Decode smart contract ABI and trace transaction failures with human-readable revert reasons

• Batch-read on-chain state via Multicall3

• Resolve ENS names and fetch associated metadata

• Query ERC-20 token holdings with full metadata

It is completely stateless and requires zero authentication. Just drop the config into Claude, Cursor or your AI agent of choice and start querying.

Claude Code — run in your terminal:

claude mcp add boar-blockchain-mcp-basic --transport http --scope project https://mcp.boar.network/basic
claude mcp add boar-blockchain-mcp-advanced --transport http --scope project https://mcp.boar.network/advanced

Full setup instructions and a Prompt Cookbook with six ready-to-use agent workflows are available in the GitHub repository.

2. Higher RPC Limits for Mezo and Ethereum

Boar offers production-grade RPC endpoints for Mezo and Ethereum, free to use within standard rate limits. For hackathon teams building under time pressure, those limits can sometimes get in the way.

If you are participating in the Mezo Hackathon and need higher throughput, you can request elevated limits at no cost — double the free plan limits.

RPC endpoints available:

• Mezo Mainnet

• Ethereum Mainnet

You can generate your API key and find endpoint URLs at dashboard.boar.network.

3. Free Bitcoin RPC — Mainnet and Testnet3

Bitcoin RPC access is a paid tier on the Boar platform. For the Mezo Hackathon, we are opening it up for free to all registered participants — both Bitcoin Mainnet and Testnet3.

If your project involves bridging assets to Mezo, building a Bitcoin-native payment flow, or anything that touches the Bitcoin base layer, you will need reliable RPC access. We are making sure that is not a blocker for you.

To unlock both higher RPC limits and free Bitcoin access in one step, fill out our hackathon request form. After submitting, the Bitcoin Mainnet and Testnet3 endpoint URLs will appear directly on the confirmation screen — no waiting, no back-and-forth. Sign in or create your Boar account first to get your API key, then submit the form.

Why Boar

We are a blockchain infrastructure provider focused on three networks that matter most to the Mezo ecosystem: Bitcoin, Ethereum, and Mezo itself. Our platform offers:

• RPC endpoints for Bitcoin, Ethereum, and Mezo

• High availability infrastructure with global coverage

• Developer-first tooling, including the Blockchain MCP for AI-assisted workflows

Our goal is simple: developers should spend time building products, not fighting infrastructure. Everything we are giving away for this hackathon reflects that.

How to Get Started

Here is the short version of what to do right now:

1. Register for the hackathon at encodeclub.com/programmes/mezo-hackathon-building-bitcoins-future

2. Create your Boar account at dashboard.boar.network and generate your API key

3. Add the Blockchain MCP to your AI tool of choice using the instructions at github.com/boar-network/blockchain-mcp

4. Submit the hackathon form to unlock elevated RPC limits and free Bitcoin RPC access

Good luck, and build something great.

Have questions about Boar’s infrastructure or the hackathon offer? Reach out to us.

Your AI assistant can write code that reads the blockchain, but it can't read the blockchain itself. It's like having a very talented translator who's never allowed to listen to the conversation.

This post is about why that gap exists, what MCP is and how it closes that gap, and some fun things that become possible once your AI can actually see what's happening on-chain.

Why AI agents are blind to on-chain data

It helps to understand why this limitation exists in the first place.

Large language models work with text. They're trained on text, they reason in text, they produce text. When you ask Claude or Copilot to write a smart contract, it's doing something it's built for - generating text that happens to be code.

But blockchain state isn't text. It's a live, constantly changing database distributed across thousands of nodes. To check a balance, you need to make an RPC call to an actual node. To decode a failed transaction, you need to fetch the receipt, extract the revert data, and run it through an ABI decoder. These are runtime operations, not text generation tasks.

Without a way to make those calls, the model can only work with what's in the conversation: the code you pasted in, the error message you copied, whatever context you manually provided. It's working with a snapshot you gave it, not with reality.

MCP: giving AI tools hands (and eyes)

This is where the Model Context Protocol comes in. MCP is an open standard - think of it as a plugin system for AI assistants. It lets your AI client (Claude Desktop, Cursor, VS Code, Claude Code, Windsurf, Gemini CLI) connect to external servers that expose tools the model can call during a conversation.

The key insight is that the model doesn't need to know how to make an RPC call. It just needs to know that a tool called eth_get_balance exists, what parameters it takes, and what it returns. The MCP server handles the actual blockchain interaction. The model handles the reasoning.

This is a general pattern - MCP servers exist for databases, APIs, file systems, all sorts of things. But for blockchain developers specifically, it solves a problem that's been surprisingly annoying: your AI assistant can finally look things up instead of asking you to look things up for it.

What this looks like in practice (with real addresses)

We built Boar's Blockchain MCP , a remote MCP server with 50 read-only tools covering Bitcoin, Ethereum, and Mezo. No install, no API key, no account. It runs on Cloudflare's edge, uses Streamable HTTP transport with SSE fallback, and every request is stateless.

But enough about the plumbing. Let's talk about what you can actually do with it, because that's where it gets interesting.

Settle a mass between friends

Your coworker insists Vitalik has moved most of his ETH out of his main wallet. You're not so sure. Instead of alt-tabbing to Etherscan:

"Resolve vitalik.eth and tell me the current ETH balance. Also, has the address received any transactions in the last 10 blocks?"

The agent resolves the ENS name, fetches the balance, and checks recent activity. Argument settled in 15 seconds without leaving your editor. (Spoiler: he still has quite a bit.)

The "is this contract what I think it is?" moment

You're reading through someone's codebase and they're importing a contract at 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48. No comment explaining what it is. Classic.

"What is the contract at 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 on Ethereum? Fetch its ABI and give me a summary of what it can do."

The agent verifies it's a contract (not an EOA), pulls the verified ABI from Sourcify, and tells you it's the USDC proxy - listing transfer, approve, balanceOf, mint, burn, the Transfer event, all of it. You can then ask follow-up questions: "what's the total supply?" and it'll call eth_call to read directly from the contract.

This beats the workflow of: open browser → navigate to Etherscan → paste address → click "Contract" tab → click "Read Contract" → scroll through the list.

Archaeology on the Bitcoin genesis block

This one's just fun:

"Look up the balance and UTXOs for Satoshi's address: 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa. How many people have sent BTC to it, and what's the total?"

The agent calls btc_get_balance and btc_get_utxos and returns years worth of accumulated donations from people sending small amounts to the genesis address. It's a great way to test that your Bitcoin tooling works, and honestly it's just a fun rabbit hole to go down with an AI that can actually read the data.

The 3am "why did this revert?" debugging session

Your transaction failed. The receipt says status: 0x0. Very helpful, Ethereum.

"Transaction 0x596030fc0f8e2ccf193ce5f2b661446d48645da5621d02938621e2c1b6b93e2a failed on Ethereum. Fetch the receipt, decode the revert reason, and explain what went wrong in plain English."

The agent pulls the receipt, extracts the revert data, decodes it, and tells you: this was a Uniswap V3 swap that failed because the transaction deadline had passed. In plain English. No hex decoding, no ABI lookup, no opening five different tabs.

This is the kind of thing that takes 30 seconds with the MCP and 10 minutes without it - and at 3am, that difference matters a lot.

Batch-reading contract state without writing a script

You need to check 5 different values from a contract - maybe prices from an oracle, balances from a vault, or parameters from a governance contract.

"Use Multicall3 to batch-read the following from contract 0x...: totalSupply, paused, owner, decimals, and symbol."

One call, five results. No for-loop, no script, no waiting for sequential RPC responses. The agent batches everything through eth_multicall and gives you a clean summary.

The setup - it's embarrassingly simple

All of this works once you add a URL to a config file. Here's the quick version for the most popular clients.

Claude Desktop - add to claude_desktop_config.json:

{
  "mcpServers": {
    "boar-blockchain-mcp-basic": {
      "type": "streamable-http",
      "url": "https://mcp.boar.network/basic"
    },
    "boar-blockchain-mcp-advanced": {
      "type": "streamable-http",
      "url": "https://mcp.boar.network/advanced"
    }
  }
}

Claude Code - run in terminal:

claude mcp add boar-blockchain-mcp-basic --transport http --scope project https://mcp.boar.network/basic
claude mcp add boar-blockchain-mcp-advanced --transport http --scope project https://mcp.boar.network/advanced

Configuration for Cursor, VS Code, Windsurf, Gemini and others is here.

That's the /basic endpoint with 37 tools - balances, transactions, blocks, logs, gas, ENS, ABIs. It covers most of what you'll need.

When you want contract calls, revert decoding, calldata encoding, or Multicall3, add the /advanced endpoint as a second server (13 tools, completely separate set, no overlap).

One thing worth knowing: each endpoint adds its tool descriptions to your AI's context window. If you're working on something where context space is tight, start with just /basic and add /advanced only when you need it.

Why "read-only" is a feature, not a limitation

Every tool is strictly read-only. No transaction signing, no private key access, no state modification.

A read-only surface area means the security model is simple. There's no risk of your AI agent accidentally sending a transaction, approving a token spend, or interacting with a malicious contract in a way that costs you money. It can look at everything, touch nothing. For a tool that's designed to run inside your AI assistant - where prompts can be ambiguous and the model is making autonomous tool calls - that's exactly the trust model you want.

Things people don't immediately think of

Beyond the obvious "look up a balance" use case, a few patterns have surprised us.

Onboarding new team members gets easier. Someone who's new to blockchain development can ask "what tokens does this address hold?" or "what happened in this transaction?" in plain English. They don't need to learn cast, pick the right block explorer, or parse JSON-RPC responses. The AI translates between "human question" and "blockchain query" automatically.

Exploring unfamiliar chains becomes frictionless. The interface is the same whether you're looking at Bitcoin UTXOs, Ethereum contract state, or Mezo token balances. You don't need to find the right explorer, learn a new CLI, or figure out which RPC methods a chain supports. You just ask.

And if you're building AI agents that need on-chain awareness - monitoring bots, analytics pipelines, research tools - the MCP gives you a clean interface without writing custom RPC code for each chain.

The repo, the docs, and how to break things

The whole thing is MIT-licensed and lives on GitHub. The repo includes full tool references for the basic and advanced endpoints, setup guides for every supported client, and a prompt cookbook with six detailed workflows you can copy-paste right now.

We're adding more chains and more tools based on what people actually use. If you try it and something doesn't work the way you'd expect, or you want support for a chain we don't cover yet, open an issue. The best features we've shipped so far came from exactly that kind of feedback.

So - what's the first thing you'd ask your AI to look up on-chain? We've been having fun with increasingly weird prompts internally, and we're curious what people come up with.

We've been there. That's a big part of why we built Boar Network's RPC service.

The infrastructure you forget about - until it breaks

Every time your application reads a balance, submits a transaction, or fetches a block, it's making an RPC call. It's the most fundamental piece of infrastructure in any blockchain project - and it's the one most developers spend the least time thinking about.

Here's what typically happens: you grab a free endpoint from whoever shows up first in a Google search, hardcode it into your config, and move on. It works fine for a while. Then your app gets real users, or you start deploying across multiple chains, and things start breaking in ways that are hard to diagnose.

Timeouts that come and go. Rate limits you didn't know existed. Inconsistent responses between providers on different chains. The kind of problems where the error message tells you nothing useful.

So we built our own - and opened it up

Boar Network runs RPC infrastructure for Ethereum, Bitcoin, and Mezo, with more chains coming. We're not a reseller - we run our own nodes, contribute to protocol development, and participate in governance on the networks we support. We understand these chains because we help build them.

The service works through a simple model: you sign up at the Boar Dashboard, generate a key, and your endpoints are live. The URL format is straightforward:

https://<network-name>.boar.network/<your-key>

One dashboard, one key management system, multiple chains. No juggling separate providers for each network.

From sign-up to first response

Once you have your key, you can test it immediately:

curl \
    -X POST \
    https://<network-name>.boar.network/<your-key> \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

That's a standard JSON-RPC call asking for the latest block number. You should get a response back in single-digit milliseconds. Nothing special, but that consistency is the point.

Drop it into whatever you're already using

The integration looks the same as any other RPC provider, which is intentional. You shouldn't have to refactor anything to switch.

Hardhat - add your networks to hardhat.config.js:

module.exports = {
  networks: {
    mezo: {
      url: "https://<network-name>.boar.network/<your-key>",
      accounts: [process.env.PRIVATE_KEY],
    },
    ethereum: {
      url: "https://<network-name>.boar.network/<your-key>",
      accounts: [process.env.PRIVATE_KEY],
    },
  },
};

viem:

import { createPublicClient, http } from "viem";

const client = createPublicClient({
  transport: http("https://<network-name>.boar.network/<your-key>"),
});

const blockNumber = await client.getBlockNumber();
console.log("Current block:", blockNumber);

ethers.js:

import { JsonRpcProvider } from "ethers";

const provider = new JsonRpcProvider(
  "https://<network-name>.boar.network/<your-key>"
);

const block = await provider.getBlockNumber();
console.log("Current block:", block);

The point is: it's a standard RPC endpoint. If your tooling speaks JSON-RPC, it works with Boar.

What about when traffic gets real?

One thing worth mentioning: switching RPC providers in a running project is one of those tasks that should take five minutes and somehow takes a full day. You're updating configs across environments, touching CI pipelines, and hoping nothing quietly breaks.

We thought about this early on. Contact us to receive a free Enterprise plan for the duration of your migration. No need to switch applications all at once. Migrate without double-spending.

What are we missing?

We're actively expanding to more networks and improving the service based on what developers actually need. If there's a chain you want us to support, or something about the developer experience that could be smoother, we'd genuinely like to hear about it.

You can reach us here or find us on the channels listed on our site. We read everything.