🎁 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.