DEV Community

SwiftNodes
SwiftNodes

Posted on • Originally published at swiftnodes.io

Berachain RPC: Standard EVM, but the Token You Earn Can't Be Transferred

#blockchain #ethereum #tutorial #web3

Berachain is one of the rare chains where the RPC is completely ordinary and the economics are the thing you have to understand. It's an EVM-identical Layer 1 (chain ID 80094) — your Solidity, ABIs, viem/ethers/foundry, and eth_* calls all work with zero changes. What's different is underneath: a Proof-of-Liquidity consensus and a three-token model where one of the tokens, BGT, is something you earn but cannot transfer. Treat BGT like a normal ERC-20 and your integration will fail in a way the RPC won't warn you about. Here's the map — mostly "everything works," with the two things that genuinely differ.

The essentials

Berachain mainnet (live since February 2025) is chain ID 80094, an EVM-identical L1 with:

  • Three tokens, each with a job: BERA (native gas token, 18 decimals), HONEY (a native stablecoin), and BGT (governance/emissions token — non-transferable, earned by providing liquidity).
  • Proof-of-Liquidity (PoL) consensus — validator rewards are tied to liquidity provided to the ecosystem, not raw staking.
  • BeaconKit on CometBFT — ~2-second blocks with single-slot deterministic finality (an "EVM cockpit over a CometBFT engine," like Kaia, Sei, and Story).
  • EVM-identical — Solidity, ABIs, and the full Ethereum toolchain deploy unchanged.

Connecting is completely standard EVM:

import { createPublicClient, http, defineChain } from "viem";

const berachain = defineChain({
  id: 80094,
  name: "Berachain",
  nativeCurrency: { name: "Bera", symbol: "BERA", decimals: 18 },
  rpcUrls: { default: { http: ["https://rpc.swiftnodes.io/rpc/berachain?key=YOUR_API_KEY"] } },
});

const client = createPublicClient({ chain: berachain, transport: http() });
await client.getBlockNumber();   // just works
Enter fullscreen mode Exit fullscreen mode

The gotcha: BGT is earned, not transferred

This is the one that catches integrations. In a normal ERC-20 world, if you hold a token you can send it — transfer, transferFrom, approve a spender, done. BGT breaks that assumption on purpose. BGT is a non-transferable (soulbound-style) governance token: you earn it by providing liquidity under Proof-of-Liquidity, and you can delegate it to validators, use it to vote, or burn/redeem it for BERA — but you cannot send it to another address like a normal token.

What that means when you build:

  • Don't expose a "send BGT" flow. A wallet or app that renders BGT as a transferable balance and offers a transfer button will produce transactions that revert. The RPC will happily accept the call and the transaction will fail on-chain — a confusing bug if you assumed ERC-20 semantics.
  • Model it as position + redemption, not spendable balance. You read a BGT balance with balanceOf like any token (reading balances right), but the actions available are delegate / vote / redeem-for-BERA, not transfer. Design your UI and accounting around that.
  • BERA and HONEY are normal. BERA (gas) and HONEY (stablecoin) behave like ordinary tokens/native coin — it's specifically BGT that has the transfer restriction. Don't over-apply the rule.

If you take one thing from this post: check which of the three tokens you're touching, and remember BGT is the non-transferable one.

Proof-of-Liquidity, briefly (and why it barely touches the RPC)

Proof-of-Liquidity is the reason BGT exists. Instead of paying block rewards purely to stakers, Berachain routes emissions (as BGT) to liquidity providers and the protocols they support, aiming to keep liquidity — and therefore security — on-chain. It drove a large pre-launch ecosystem of DeFi protocols designed around BGT incentives.

For a developer, PoL is mostly an economic/protocol layer, not an RPC one. You interact with the reward and liquidity contracts the same way you'd call any contract (eth_call to read, eth_sendRawTransaction to act); there's no special namespace. The one place it does surface is the BGT rule above — that's PoL's design showing through into token behavior.

Finality: single-slot, so confirm once

BeaconKit on CometBFT gives single-slot deterministic finality — a committed block is final, no reorgs. Practically:

  • Skip the reorg machinery. The reorg-handling patterns collapse to "confirm once" — no deep confirmation counts, no block-hash reconciliation for probabilistic reorgs.
  • ~2-second blocks — fast enough that WebSocket subscriptions (newHeads, logs) beat tight polling for live data.

It's the same fast-finality comfort as the other CometBFT-EVM and BFT-EVM chains we've covered — Kaia, Sei, Monad — where "final means final" once you see the block.

What carries over unchanged (almost everything)

Because Berachain is EVM-identical, treat it as a standard EVM chain:

  • eth_call, eth_getBalance, eth_getLogs, eth_getTransactionReceipt, eth_estimateGas, eth_sendRawTransaction, eth_subscribe all behave normally.
  • Solidity contracts, ABIs, and the viem/ethers/hardhat/foundry toolchain deploy and run as-is.
  • BERA is the 18-decimal gas token; gas follows standard EVM mechanics (gas estimation basics); WebSocket subscriptions work.

The short version

Berachain (chain ID 80094) is an EVM-identical L1 — standard eth_*, viem/ethers/foundry unchanged — built on Proof-of-Liquidity consensus with a tri-token model: BERA (gas), HONEY (native stablecoin), and BGT (governance, earned via liquidity). The one thing that will bite you is that BGT is non-transferable — you earn, delegate, vote, or redeem it for BERA, but you cannot transfer it, so any flow that treats it like a normal ERC-20 will revert. PoL is otherwise an economic layer that barely touches the RPC, and single-slot CometBFT finality means you confirm once (no reorgs). Build it like any EVM chain — just get the BGT rule right.

Building liquidity-incentivized DeFi, HONEY stablecoin apps, or anything indexing Berachain? A flat-rate Berachain RPC endpoint gives you chain 80094 over HTTP and WebSocket alongside 75+ other chains under one key. Grab a free key and point your stack at:

https://rpc.swiftnodes.io/rpc/berachain?key=YOUR_API_KEY
Enter fullscreen mode Exit fullscreen mode

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

Top comments (0)