Berachain airdrop 2026: qualify without getting sybil-flagged

Berachain mainnet launched in February 2025 with one of the more unusual tokenomics structures in recent memory: a non-transferable governance token (BGT) that you earn by providing liquidity, which you can then burn for BERA. The initial BERA distribution rewarded early testnet participants, but the ecosystem is still young and several native protocols, vault operators, and foundation-backed programs are running or planning their own token distributions. The window to build meaningful on-chain history is still open.

The problem is that protocols on Berachain, like most chains post-2024, are doing serious sybil filtering. Gitcoin Passport scores, on-chain graph analysis, shared funding sources, and timing correlation checks are all standard now. I’ve seen people run 50-wallet farms get zeroed out entirely because every wallet funded from the same CEX withdrawal address within the same two-hour window. That’s not farming, that’s just donating gas money to validators.

This guide is for operators running anywhere from one wallet to a small multi-wallet setup who want to build durable, credible on-chain histories on Berachain. I’ll cover the infrastructure, the exact steps, the common mistakes, and what changes when you try to scale.

what you need

Wallet software: Rabby Wallet is my preference over MetaMask for multi-wallet management. it handles multiple accounts cleanly and shows you transaction previews.
BERA for gas: currently around $0.15-0.40 per standard transaction. budget at least $5 BERA per wallet to start. get it from gate.io, Coinbase, or bridge from Ethereum via the official Berachain bridge.
Liquidity capital: minimum $50-100 per wallet to make interactions meaningful. stablecoins (USDC, USDT) bridge well.
RPC access: the public RPC (https://rpc.berachain.com) is fine for low-volume use. for 10+ wallets, use Alchemy or QuickNode Berachain endpoints to avoid rate limits.
Optional, for multi-wallet ops: a browser profile manager. i’ve reviewed several options over at antidetectreview.org/blog/ if you need a breakdown of what separates them for on-chain work.
Time: expect 30-45 minutes of setup per wallet, then 15-20 minutes of weekly maintenance.

step by step

step 1: set up and fund your wallet

Create a fresh wallet in Rabby. write down the seed phrase offline. do not use a wallet you’ve already connected to sketchy sites.

Fund it from a source that isn’t directly linked to your other farming wallets. if you’re running multiple wallets, fund each from a different CEX account, or use an intermediary wallet that’s had at least 30 days of history. the intermediary shouldn’t send to all your farming wallets on the same day.

# if you want to generate and track multiple wallet addresses programmatically
# use cast from Foundry
cast wallet new
# output: Address: 0xABCD...
# Private key: 0x...

expected output: a funded wallet with at least 10 BERA for gas headroom.

if it breaks: Berachain RPC can be slow during high traffic. if the bridge transaction doesn’t confirm within 20 minutes, check the Berachain block explorer with your transaction hash.

step 2: bridge assets to Berachain

Go to the official Berachain bridge and connect your wallet. bridge USDC or ETH from Ethereum mainnet. the bridge uses LayerZero under the hood and typically confirms in 5-15 minutes.

Bridge at least $50 in assets. a wallet that bridged $8 and never did anything else doesn’t look like a real user. it looks exactly like what it is.

expected output: USDC or ETH visible in your wallet on Berachain mainnet (chain ID 80094).

if it breaks: LayerZero-based bridges occasionally get stuck. use LayerZero’s scan tool to check message status. if the message is stuck, you can manually trigger delivery from the destination chain.

step 3: add liquidity on BEX

BEX is Berachain’s native DEX and the primary venue for earning BGT emissions. Go to bex.berachain.com and add liquidity to an incentivized pool. as of early 2026, HONEY/USDC and WBERA/HONEY pools typically carry BGT rewards.

Provide liquidity in a size that makes sense for a real user. $50-200 is normal. providing exactly $50.00 in every wallet is a pattern. vary your amounts.

expected output: LP tokens in your wallet, pool position visible in your BEX dashboard.

if it breaks: if the transaction fails with “insufficient output amount,” the pool price moved during your transaction. increase slippage tolerance to 1-2% in settings.

step 4: stake LP tokens and start earning BGT

After providing liquidity, you need to stake your LP tokens in the corresponding gauge to earn BGT. in BEX, go to “Pools,” find your position, and click “Stake.”

BGT accrues per block. check back after 24 hours. you’ll see accumulated BGT in the gauge dashboard.

# approximate BGT per day for a $100 HONEY/USDC position
# varies heavily by pool incentives and total TVL
# check current emission rates at hub.berachain.com/gauges

expected output: BGT accumulating in your gauge position. the amount depends on pool emissions at that time.

if it breaks: if you don’t see BGT accruing after 48 hours, confirm you actually staked LP tokens (not just provided liquidity). the two steps are separate.

step 5: delegate BGT to a validator

BGT is non-transferable. you can delegate it to validators, who use it to boost gauge emissions. go to hub.berachain.com and pick an active validator. look for ones with consistent uptime (95%+) and reasonable commission rates.

Delegation is an important on-chain signal. it shows you understand how Berachain’s proof-of-liquidity mechanism works, not just that you clicked “add liquidity.”

expected output: your BGT delegated, visible on-chain. validator’s BGT weight increases.

if it breaks: some validators have minimum delegation thresholds. if the transaction reverts, check the validator’s profile on the hub for requirements.

step 6: interact with Bend (lending)

Bend is Berachain’s native lending protocol. supply HONEY or USDC as collateral. you don’t need to borrow anything, though borrowing a small amount and repaying it adds another transaction type to your history.

Multi-protocol interaction is one of the key signals that separates real users from bots. a wallet that only ever touches BEX is less credible than one that’s touched BEX, Bend, and at least one more application.

expected output: supply position visible in Bend dashboard. interest accruing at market rates.

if it breaks: Bend uses a standard Aave-fork architecture. if you get an “approve” error, make sure you’ve approved the token for the Bend contract first. this is a separate transaction before the supply transaction.

step 7: use at least one more native protocol

Options as of mid-2026: Berps (perpetuals), Infrared Finance (liquid staking for BGT), or any of the newer native protocols that have launched with foundation incentives. the goal is at least 3 different protocols touched per wallet.

Berps is the simplest addition. open a small long or short position, hold it for a few hours, close it. a $20 trade is enough. the point is transaction diversity, not profit.

expected output: additional protocol interactions visible on Berascan.

if it breaks: Berps requires HONEY as margin. if you don’t have HONEY, you can mint it by providing collateral on Bend, or swap for it on BEX.

step 8: establish a consistent cadence

One burst of activity doesn’t build credibility. come back weekly. claim BGT, restake, delegate more, do a small swap. the protocols that ran the most credible distributions in 2024-2025 (Starknet, ZKsync, LayerZero) all gave weight to wallets with activity spread over multiple months, as documented in LayerZero’s sybil analysis methodology.

Set a calendar reminder. 20 minutes every week, per wallet, is the actual cost of doing this right.

expected output: transaction history that shows consistent engagement over 8-16 weeks.

if it breaks: if you’ve been inactive for 4+ weeks, don’t try to backdated activity. just resume normally. the gaps are visible on-chain regardless.

common pitfalls

funding all wallets from the same source on the same day. this is the single most common sybil flag. on-chain graph analysis can trace funds back through multiple hops. use different funding sources, or space out transfers by at least 72 hours between wallets.

identical transaction patterns across wallets. if every wallet provides exactly $100 USDC to BEX, delegates to the same validator, and then does nothing else, that’s not a portfolio of real users. vary amounts, vary timing, vary which protocols you use.

ignoring gas token management. wallets that run dry and can’t execute transactions look abandoned. keep at least 2-3 BERA per wallet at all times.

using the same IP for every wallet. most protocols don’t log IPs for airdrop eligibility, but some front-ends do. if you’re running multiple wallets from the same browser session, that metadata can leak. read through how to separate browser profiles properly, or at minimum use separate browser windows with separate MetaMask installs.

claiming and immediately bridging out. if you receive any token distribution and immediately bridge everything to a CEX, that’s consistent with a sybil behavior pattern. hold tokens for at least a few weeks, interact with them, reinvest them in the ecosystem.

scaling this

10 wallets: the main challenge is funding separation. you need 10 distinct funding paths. this is manageable with 2-3 CEX accounts used in rotation. one person can handle 10 wallets manually in about 3-4 hours per week total.

100 wallets: manual management stops being viable. you need scripted transaction batching. Foundry’s cast tool lets you script interactions across wallets with a simple bash loop. you also need to solve the infrastructure problem: 100 wallets hitting the same public RPC looks like a bot. get a dedicated Alchemy or QuickNode key with higher rate limits. for browser-based interactions, this is where antidetect browser profiles become necessary, and the cost structure changes significantly. there’s a good breakdown of multi-account infrastructure considerations at multiaccountops.com/blog/.

# example: batch BGT claim across multiple wallets with cast
for wallet in $(cat wallets.txt); do
  cast send --private-key $wallet \
    0xGAUGE_ADDRESS \
    "getReward()" \
    --rpc-url https://rpc.berachain.com
  sleep $((RANDOM % 300 + 60))  # random 1-5 minute delay between wallets
done

1000 wallets: at this scale, you’re running a professional operation. the sybil detection systems are calibrated for exactly this. on-chain graph analysis with tools like Nansen or Arkham will cluster your wallets regardless of how carefully you’ve separated funding if there are any behavioral similarities. you need genuinely distinct on-chain histories, different capital sizes, different time zones of activity, and different protocol mixes. the infrastructure cost alone (proxies, browser profiles, RPC bandwidth, gas) runs into hundreds of dollars per month. whether the expected value justifies that depends on the size of the distribution, which is never known in advance.

where to go next

How to farm BGT emissions on Berachain: a liquidity provider’s guide covers the deeper mechanics of gauge voting and how to maximize BGT yield per dollar of capital.
Proof of Liquidity explained: how Berachain’s consensus model works is useful background if you want to understand why the on-chain behaviors in this guide actually matter to the protocol.
Back to the tutorial index for other protocol guides.

For deeper context on the Berachain ecosystem and official documentation on how BGT delegation and gauge mechanics work, the Berachain developer docs are the authoritative source.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-05-19.