AERE goes verifiably random, drand beacon live

On May 31, 2026 AERE Network deployed an on-chain consumer of the drand verifiable-randomness beacon, making fair lotteries, NFT trait reveals, fair-launch token sales, on-chain games and randomized airdrops finally possible on AERE without trusting any single party.

The two contracts

What drand actually is

drand is the distributed randomness beacon operated by the League of Entropy, a coalition of 19 independent organisations including Cloudflare, EPFL (Swiss Federal Institute of Technology Lausanne), the U.S. Naval Research Laboratory, the University of Chile, Protocol Labs, Kudelski Security, PingCAP, CertiK, and others.

Every 3 seconds, all 19 attempt to sign the value round_number using their share of a threshold BLS-12-381 private key. A threshold (currently 12 of 19) is required to produce a valid aggregate signature. Properties of the resulting random number:

• Bias-resistant: by the time the value is public, the signature is already cryptographically committed, no operator can pick or veto a future value.
• Verifiable: the BLS aggregate signature can be checked against drand's published public key (Quicknet's 96-byte G2 point is hard-coded in our contract).
• Unforgeable: forging requires breaking BLS-12-381 cryptography (the same curve Ethereum uses for its consensus layer).
• Free: drand is a public good. Anyone fetches current and historical rounds at api.drand.sh.
• Predictable timing: Quicknet has a 3-second period starting at unix 1692803367. Round N is published at 1692803367 + N×3.

The integration pattern

Here's the 3-line lottery from the reference consumer:

contract MyLottery {
    AereRandomnessBeacon public immutable beacon =
        AereRandomnessBeacon(0x25b6317efD8C7d425210F56Ee1E204852CD8213C);

    uint64 public drawRound;
    address[] public entrants;

    function openLottery(uint64 secondsUntilDraw) external {
        drawRound = beacon.roundAtTime(uint64(block.timestamp + secondsUntilDraw));
    }

    function enter() external { entrants.push(msg.sender); }

    function draw(bytes calldata drandSignature) external returns (address winner) {
        // Anyone can fetch drandSignature from api.drand.sh//public/
        // and call this. Submitter pays gas; everyone benefits from the random outcome.
        bytes32 random = beacon.submitRound(drawRound, drandSignature);
        winner = entrants[uint256(random) % entrants.length];
    }
}

That's the entire integration. Three lines of contract code, one off-chain fetch from a free public API.

No operator infrastructure, by design

This is a permissionless on-chain primitive, not a Foundation-operated service. Three properties mean no operator has to run any infrastructure:

1. No relayer to run. Anyone can call submitRound. The typical caller is the dApp that needs the random number, submitting a round and reading the resulting randomness happens in the same transaction.
2. Submitter pays gas. The drand signature is ~48 bytes; submitting one costs ~20-30k AERE gas (~$0.00002 at chain-level fees). The dApp's user, or the dApp itself, absorbs this, same as paying gas for any other contract call.
3. No subscription, no licensing, no BD. drand is a free public good run by the League of Entropy. AERE deployed a consumer; the LoE doesn't need to know we exist for their beacon to serve our submissions.

Two phases

Phase 1 (now, live): drand signatures are stored on submission and verifiable off-chain. Anyone in the world can confirm, by checking api.drand.sh//public/, that the on-chain signature matches drand's canonical output for that round. If someone tries to submit a fake signature, the pairing check at drand's verification endpoint will reject it; the on-chain submission is then provably wrong. The trust model is "first credible submitter wins, public audit at all times."

Phase 2 (post-audit, future deploy): enable on-chain BLS pairing verification via AERE's EIP-2537 precompiles (activated in Pectra, Tier 1.1). The contract will then refuse to accept any submission whose BLS signature doesn't verify against drand's public key on chain, fully trustless. The submission interface is forward-compatible; consumer code doesn't change.

What this combines with

• Tier 1.1 Pectra, EIP-2537 BLS precompiles make on-chain BLS verification ~50× cheaper than Solidity-based verification. This is what enables Phase 2 above to be economically viable.
• Tier 1.3 Paymasters, lottery, NFT mint, fair launch contracts can sponsor users' submission gas via AppPaymaster, so end users see no gas at all.
• Tier 1.5 Across intents, cross-chain lotteries become possible: buy ticket on Ethereum, drawn on AERE using drand, winner gets paid on the chain of their choice.
• Tier 1.6 Pyth, prize denominated in USD via Pyth + draw via drand = the full UX of a fair on-chain lottery.

What this does NOT do

• Doesn't replace VRF for sub-second randomness. drand emits one round per 3 seconds; for higher-frequency randomness (some HFT use cases) you still want commit-reveal or a specialised VRF.
• Doesn't provide chain-specific oracle data. drand gives you a public random number; for "price of BTC at noon" use Pyth (Tier 1.6).
• Doesn't pay subsidised gas. The Foundation deploys the contract and walks away.

What's next

Tier 1.8 wires AereFeeBurnVault into the validator coinbase, making the whitepaper §3.3 "37.5% of fees obliterated" claim measurably true on chain. Tier 1.9 deploys batch-auction settlement on AereSwap for native MEV-resistant trading. Tier 1.10 ships Fee Monetization for developer revenue share, strong builder magnet.

The application layer is where the work continues.