The contracts
Two contracts, both immutable, on chain 5042002.
Prize vault 0x6dd9cd89d05ABF680528c96A2dBF3414fB6BB8a6
Randomness 0x72fa0ff3B85a68E52331033e8732089fc95F9fb7
Treasury 0x000000000000000000000000000000000000FEE1
Vault version v4
Every figure this documentation states is read from the vault above when the page is built. If one of them says [unavailable], the vault did not answer and we would rather print that than a number from memory.
What is immutable
The vault has no admin, no owner, no upgrade path and no proxy. Every parameter is set at deployment and there is no function that changes one. The figures below were fixed when this vault was deployed and cannot move while it is the vault:
protocol fee 5% of ticket revenue
creation fee $1.00
ticket revenue cap $5,000.00 per raffle
tickets per raffle 3 to 1,000,000
smallest ticket $1.00
duration 1 hour to 30 days
claim window 365 days
relayer tip $0.05
known resolvers 1
The randomness resolver at 0x72fa0ff3B85a68E52331033e8732089fc95F9fb7 carries two of its own, fixed the same way:
margin 1 minute added to a close before the round is fixed
escape window 7 days to submit the beacon
Changing any of them means deploying a new vault. Raffles on this one stay on it, under the terms they were created with, for as long as they run. That is why raffles from more than one vault can appear on the same board and why each one says which vault it is on.
A raffle is immutable from creation and locked from its first entry. Before any ticket sells the creator can take the prize back and cancel; after one, nothing about the raffle changes.
What the guardian can do
One address can do one thing: pause the creation of new raffles.
New raffles are not paused.
That is the only privileged function in the contract. It appears in exactly one place, and what it guards is a single boolean that createRaffle reads.
What the guardian cannot do
It cannot touch a winner, an escrow, a claim, a refund or the randomness — and not because it is forbidden to. There is no function that does any of those things, for any caller, including us. A guardian who wanted to redirect a prize would have nothing to call.
A pause does not reach a live raffle. Raffles that exist go on selling tickets, closing, drawing and paying out while creation is paused.
The vault can also be deployed with no guardian at all, in which case the pause reverts for every caller including the zero address.
What nobody can do
- Change a winner. The winner is derived from the seed and the ticket ranges, in the transaction that settles. There is no stored winner to overwrite and no function that sets one.
- Change a seed. It is the hash of a drand signature the resolver verified.
- Move an escrow. Each raffle's prize is in its own address, and the only caller that address accepts is the vault, along the paths above.
- Take ticket money. It is owed to the buyers until a draw makes it the creator's, and owed back to them if the draw never happens.
Reading it yourself
The vault's whole surface is public, and everything on this site is derived from its logs — the same logs anybody can read.
- The vault: 0x6dd9cd89d05ABF680528c96A2dBF3414fB6BB8a6
- The resolver: 0x72fa0ff3B85a68E52331033e8732089fc95F9fb7
Source and the test suite are in this project's repository. The deployed bytecode of each vault version is kept verifiable against the source it was built from, in its own frozen directory, because a contract that cannot be checked against its source is a contract you are taking our word for.
Money that is never in the vault
USDC on this chain is the gas token and the ticket token, and a raffle's ticket money sits in the vault until it is claimed. The prize never does: it is in that raffle's own escrow, from the transaction that created the raffle until the transaction that pays it out.
Nothing here is payable in the native asset and none of these contracts has a receive function.