We turned the testnet into something you get paid to use. Every on-chain action earns XP — send ASE, swap on Auras, post on the social app, run a validator — and XP is the airdrop. But the piece I want to write about is the multiplier, because it does something that sounds like it needs a bridge and doesn't.
XP is the payout
The idea is simple and old: reward the people who actually use the thing. The dashboard tracks real activity and turns it into points. There are rotating daily quests, streaks that reward showing up, and a leaderboard. None of that is novel. What makes it work is that the points come from real chain events an indexer reads directly — a swap that emitted a Swap, a transfer that moved value, a block a validator actually signed. You can't farm what the chain didn't record.
On top of the base rate sit multipliers: a daily streak, a linked social account, and — the big one — staking.
Stake here, earn there
ASE is live as an ERC-20 on Ethereum mainnet. The staking contract lives there too: lock ASE, get a tier, from ×2 at fifteen thousand tokens up to ×10 at a million and a half. That multiplier then applies to the XP you earn on the Asentum testnet.
That's two different chains. The instinct is that connecting them needs a bridge — some trusted relayer moving state from Ethereum to Asentum, with all the risk that implies. It doesn't, because nothing needs to move. The multiplier isn't a token that has to travel. It's a fact — "this address has 50,000 ASE staked" — and facts on a public chain can just be read.
So the airdrop runs a small watcher that does exactly that: for every wallet a user has linked, it calls stakedBalance and multiplier on the mainnet contract, over a plain public RPC, and writes the tier into our database. When your dashboard computes what your activity is worth, it multiplies by the tier that watcher last read. No bridge, no relayer holding funds, no new trust assumption — just one chain reading another chain's public state and doing arithmetic. If the read fails, it keeps the last value and tries again. If you stake more, the next poll catches it.
The contract even hands us the tier directly — a multiplier(address) view that returns the number — so we don't reimplement the thresholds and risk them drifting out of sync with the thing that actually holds the money.
The part that was annoying
The honest snag: the public Ethereum RPC we point at refuses wide historical log scans — they're "archive" queries behind a paywall. My first design wanted to watch the contract's Staked events to discover stakers. Couldn't, not without an archive node. So the watcher doesn't scan logs at all. It polls the wallets we already know about — the linked ones — which is the only set whose multiplier matters anyway. A stake by someone who hasn't signed up yet is irrelevant until they do, and the moment they link that address, the next poll sees it. The constraint made the design simpler than what I'd planned.
Starting the clock
The last thing was fairness at launch. We didn't want the people who happened to find the dashboard early to bank a head start before anyone else knew it existed. So accrual is gated on a start time: before it, everyone sees a countdown and earns nothing; after it, the same activity starts counting for everybody at once. A per-account override lets us run our own accounts early to test, while everyone who signs up sees the countdown until the date we announce.
So that's where it is: a testnet that pays attention to what you do, a multiplier you set up on Ethereum that takes effect on Asentum without a bridge, and a start line everyone crosses together. We'll announce the date on X and Telegram. Come set up early — it all counts from the gun.