What can go wrong, and what happens

Every failure this contract has an answer for, with the answer. None of these is hypothetical: most were run on a live chain before the vault was deployed, and the ones that were not say so.

Nobody buys a ticket

The creator takes the prize back and the raffle is cancelled. That door is open only while no ticket has sold; after the first one it is shut for good.

The creation fee does not come back. It is charged for opening a raffle, and the raffle was opened.

The raffle does not fill

It draws anyway, at the deadline. The prize is the same and the creator's revenue is smaller, because fewer tickets sold.

This is deliberate rather than a gap. A raffle that refunded when it did not fill would give the creator a free option on their own marketing, and would give every player a reason to wait rather than enter.

Nobody closes the raffle

Anyone can close it, including any player and including us, and it costs one transaction. If nobody does for a whole claim window past the deadline, anyone can put the raffle into refund mode instead — so a raffle cannot be left holding ticket money indefinitely by everybody doing nothing.

The beacon never arrives

The beacon can be submitted for 7 days after the raffle closes. If no valid signature arrives in that window, the round can never be resolved and the raffle enters refund mode:

• every ticket is refunded at face value, pull-based;
• the creator takes the prize back;
• the creator receives nothing. No revenue, no share of anything.

Refund mode cannot be forced by anyone, because anyone can submit the beacon. There is no party whose inaction triggers it that another party cannot simply act instead of.

Why a tip is paid for submitting. The moment drand publishes, the winner is computable by anybody, and a refund returns every ticket — so every losing player would prefer that nobody submits. Nobody has to collude and nobody has to act; the outcome that unwinds the raffle is the one that happens if everybody does nothing. A tip that covers the cost breaks that, because it only takes one indifferent third party for whom submitting is profitable.

What this page cannot claim: a refund has not been completed on a live chain. The route is reachable only after the 7 days above, and that timer cannot be shortened — there is no admin and no warp — so it is proven by the test suite and by a raffle deliberately left waiting, and not yet by a completed refund.

The prize token misbehaves

Each raffle's prize sits in an address that holds that raffle's prize and nothing else. A badly behaved token therefore costs its own raffle's prize and nothing else in the system.

• A token that takes a cut on transfer cannot make the escrow lie. What is recorded is the balance that actually arrived, measured across the transfer, so the raffle advertises the smaller figure from the start.
• A token that reverts, is paused, or has blacklisted the winner costs its own prize. It cannot touch the ticket USDC, because claiming the prize and claiming the revenue are separate functions that touch different contracts.
• A token whose supply moves after the escrow — a rebase, an owner burn — delivers what is actually there. The winner is paid the smaller of the recorded amount and the escrow's balance at the moment of the claim. Demonstrated on chain: a 1,000-token prize whose escrow was burned down to 400 paid the winner 400.
• Surplus is stranded on purpose. The recorded figure is a ceiling too, so a token whose supply moves up does not enlarge the prize, and nothing can reach the difference afterwards.

The winner's wallet refuses delivery

A winner can be correct, entitled and unpayable — an NFT recipient without the receiver hook, or an address the token's issuer blacklisted after the raffle opened.

The winner names where the prize goes. claimPrize takes a recipient, only the winner may call it and only the winner may name one, and the zero address is refused — an ERC-20 transfer to zero is a burn that succeeds, which would destroy the prize and report success. Nothing else changes: the winner is still the winner.

What does not change on any version: the winner is still the winner, and the revenue claim is unaffected. Two claims, two functions, and a prize that cannot be delivered does not touch the USDC.

Nobody claims

After the 365 days claim window, anyone can sweep the raffle: the USDC goes to the protocol treasury and the prize is sent there too.

The sweep tries the prize leg rather than requiring it. If the token refuses, the USDC still moves and the prize can be swept later if the token recovers — otherwise a badly behaved token could freeze the USDC leg of its own raffle forever, which is the coupling the separate claims exist to prevent.

The creator disappears

Nothing depends on them. The close is permissionless, the beacon submission is permissionless, the settlement is permissionless, and the winner's claim is the winner's. A creator who never comes back simply never claims their revenue, and after the claim window it sweeps to the treasury.

We disappear

The raffle settles anyway. The vault does not call us, does not read from us and does not know we exist; this site is a reader over public logs. What stops working is this interface, not the raffle.

What that costs a reader: the page that shows a raffle's target round and entries. The same facts are in the chain's own logs.

The chain's randomness precompiles change behaviour

The resolver depends on this chain rejecting a malformed signature point, which it was measured doing. If a chain ever stopped, invalid signatures would start verifying — and unlike every other failure in the randomness path, that one is silent: nothing reverts and every raffle still draws a winner.

It is the reason that check is a test against the live precompiles rather than an assumption, and the reason it is re-measured on any chain this is deployed to.