Flare onboarding bot: automatic first-transaction gas
When someone bridges an asset such as WETH from Ethereum or XDC to Flare for the first time, they arrive with value but no FLR, the network's native gas token. Without FLR they cannot pay gas, so their first action on Flare fails before it starts. Protofire built an onboarding airdrop bot that closes that gap: when a bridge deposit lands on an address with no prior FLR balance, the bot sends that address a small amount of FLR on Flare mainnet, enough to cover its first transactions. The service watches bridge activity on Flare mainnet and Songbird, checks eligibility, and delivers the top-up automatically.
“A user who bridges WETH to Flare holds value but no FLR, so they cannot sign their next transaction.”
Why a first-time bridger gets stuck on Flare
Every EVM chain uses its own native token for gas. A user who bridges WETH to Flare holds value but no FLR, so they cannot sign their next transaction. The cost is minor in dollar terms but lands at the worst moment: exactly when a new user is deciding whether the network is worth the effort.
How Protofire built the airdrop bot
Protofire built a backend service that automates the FLR top-up. The bot monitors incoming bridge deposits on Flare mainnet and Songbird from external chains such as Ethereum and XDC. For each deposit it checks the receiving address and pays only addresses that carry no prior FLR balance, so the incentive reaches new users rather than existing holders.
Eligible addresses receive the top-up on the same address they bridged to. The service is written in TypeScript on Node.js and uses PostgreSQL to record eligibility and delivery so an address is never paid twice. The flow runs without manual intervention.
Context
Flare is a data-focused Layer 1 that gives contracts decentralized access to data feeds from other chains and the internet (source: Flare). Protofire's part was this one onboarding tool, not the network itself.