The ASE Token
Mainnet Airdrop
Earn mainnet ASE through demonstrable testnet participation · 6 minutes
TL;DR
60,000,000 ASE (6% of total supply) is reserved for testnet operators. Distributed at mainnet TGE based on demonstrable testnet participation, split into three buckets: validator operation (40M), contract builders (10M), grants & bug bounties (10M). The largest bucket goes to validators because running consensus hardware is the most sybil-resistant signal.
Earned, not airdropped. No KYC. No survey. The chain itself decides the allocation.
The 60M pool
| Bucket | ASE | % of pool | How to earn |
|---|---|---|---|
| A. Validator operation | 40M | 67% | Pro-rata to testnet ASE earned (50-block min, 100k bond floor, 600k cap) |
| B. Contract builders | 10M | 17% | Unique-caller-weighted contract usage (20-caller min, 200k cap) |
| C. Grants + bug bounties | 10M | 17% | Public schedule with +25% Twitter bonus, transparent grant list |
Why not a simple snapshot
An obvious airdrop design — "your testnet ASE balance becomes your mainnet ASE" — fails because testnet ASE is faucet-distributed. Per-IP rate limits don't survive contact with VPNs and proxy bundles. A determined attacker with a script and $20/month VPN access could drain a chunk of the pool without ever running real infrastructure.
The fundamental fix: don't base allocation on token holdings. Base it on activities that are hard to fake at scale:
- Running a validator that produces blocks — requires real hardware, real bandwidth, real uptime. Faking it costs more than the airdrop is worth.
- Deploying contracts that get used by other people — requires writing real code. Caller-diversity filters detect self-call farms.
- Filing real bug reports or shipping ecosystem tools — manual review, transparently published.
Things that are NOT rewarded: just submitting transactions, just holding faucet tokens, one-time interactions. End-user airdrops universally degenerate into bot farms; we don't pretend otherwise.
Bucket A — Validator operation (40M)
The largest bucket. Reuses the chain's own validator-rewards system as the calculation engine — your testnet earnings ARE the airdrop input.
your_validator_airdrop = min(
(your_testnet_ase_earned / total_qualifying_testnet_ase) × 40M,
600,000 // hard cap = 1% of total 60M pool
)Three sybil filters:
- Hardware proof of life: validator must have proposed at least 50 blocks during the testnet to qualify. Just bonding and idling earns zero.
- Stake floor: validator must have bonded ≥ 100,000 testnet ASE at some point. Excludes "bond once with dust for free airdrop" attacks.
- Per-address cap: 600,000 mainnet ASE max per address. Excess from cap-binding addresses redistributes to others under the cap.
The same testnet rewards economics described in Staking Rewards apply to the testnet — including the 10% per-block cap and the 5/80/15 split. Your testnet ASE is your mainnet ASE input, and the architecture decides the rest.
Bucket B — Contract builders (10M)
For developers who deployed contracts on testnet that real people used.
contract_score = unique_callers_count × √(state_changing_calls)The unique-caller filter is the load-bearing piece: a caller is "unique" only if their first ASE was NOT received from the contract deployer. This breaks self-call farms — you can't fund 100 wallets from your own deployer and pretend they're organic users.
Sybil filters:
- Contract must have ≥20 unique callers to qualify
- Per-address cap: 200,000 mainnet ASE
- State-changing-calls only — read-only spam doesn't count
Top deployers ranked by sum of their contract scores split bucket B pro-rata. A working dApp with even modest organic usage qualifies.
Bucket C — Grants & bug bounties (10M)
Honest admission: not everything can be calculated on-chain. This bucket funds qualitative contributions: bug reports, ecosystem infrastructure, translations, content, third-party tools.
Bug bounty schedule
| Severity | ASE bounty | Examples |
|---|---|---|
| Critical | 500k–2M | Consensus break, fund loss, key compromise. Examples: double-spend exploit, signature forgery, validator-key extraction. |
| High | 100k–500k | State corruption, DoS at scale. Examples: stalling the chain, contract storage corruption, sybil-as-validator. |
| Medium | 25k–100k | Subtle bug, non-fatal misbehavior. Examples: wrong gas accounting, rare race conditions. |
| Low | 5k–25k | UX, docs, minor issues. Examples: confusing error messages, doc inaccuracies. |
| Twitter-public reports | +25% bonus | On top of any of the above, when submitted with @asentum mention and $ASE cashtag. |
Other grants
- Doc translations (verified quality, per major language): 50k–200k ASE
- Third-party tools (block explorers, wallets, dev tools): variable, evaluated case-by-case
- Significant content (deep technical posts, video tutorials): 25k–100k ASE
- Discord / community pillars: capped at 50k ASE per recipient
Transparency commitment: the FULL recipient list with line-item rationales is published before mainnet TGE. Anyone can see exactly who got what for what reason. If a grant can't be defended publicly, it doesn't get made.
The Twitter bonus
Bug reports submitted publicly on Twitter with @asentum mention and $ASE cashtag earn a +25% bounty bonus on top of the severity-based amount.
The reasoning is honest: public bug reports become free distributed marketing. Each report is a viral case study from someone who actually understands the chain. The algorithm rewards the cashtag and the project handle, which compounds discovery. Worst case for any bug: it becomes a story about how Asentum handled it transparently.
For sensitive critical bugs that shouldn't be disclosed before a fix ships, the public Twitter post can be a high-level acknowledgment ("found a critical issue, working with @asentum on disclosure") — that still earns the bonus. The technical details go through private security channels.
Per-address maximum
Across all three buckets, the most any single super-contributor can earn is approximately 1–1.5% of the total 60M pool:
- 600k from bucket A (validator operation)
- 200k from bucket B (builder operation)
- Subjective from bucket C (per the published schedule)
Even the most active triple-role participant — runs a validator, ships a popular dApp, files critical bugs — can't capture more than ~1.5% of the airdrop. The architecture refuses concentration even from the most engaged community members.
What you can do today
The testnet is live at testnet.asentum.com. To start earning toward your mainnet airdrop allocation:
- Run a validator. Bond at least 100,000 testnet ASE. Stay online and produce blocks. Reward = activity, not presence. Earlier is better — early validators capture more share.
- Submit epoch_entry if you're not in the top 50 by stake. Keeps you in the rotating-reserve eligibility pool, which is where 15% of every block's reward goes.
- File bugs publicly. If you find one, post on Twitter with @asentum and $ASE for the +25% bonus. Then submit technical details privately if it's a sensitive issue.
- Build something real. A working dApp on testnet with 20+ unique users qualifies for bucket B. The most-used contracts capture the bulk of that bucket.
The snapshot block for the airdrop calculation will be announced ~30 days before mainnet launch. Earnings up to that block count; nothing after.
Read next