Trust and Transparency: On-Chain Verified Raffle Mechanics

By DeHub Team — 2022-07-05

In Q3 2022 we shipped on-chain verified raffle mechanics, in the same quarter we ran a $1,000,000 house raffle with more than 15,000 participants.

The scale changed the requirement

We had built provably fair randomisation for the arcade the previous year. The principle was already settled: rules published first, randomness we cannot re-roll, results checkable afterwards by someone who assumes we are lying.

What changed at a million pounds was the surrounding surface. In a small game raffle the only contested question is who won. In a large one, every step is contested — who was eligible, when entries closed, whether the count is right, whether the minimum was met, whether the entry you bought was recorded at all.

Provable randomness answers one of those. On-chain verified mechanics answer the rest.

What went on-chain

• Entry records, so the participant list is reconstructable by anyone rather than asserted by us.
• The eligibility and closing rules, fixed before entries opened.
• The threshold conditions, including the minimum sales required for the draw to proceed.
• The draw itself, executed from those inputs.

The third item is the one that mattered most, and not in the way we expected.

The part that proved itself by failing

The house raffle did not reach its minimum. It was not drawn, and every purchase was refunded.

Because the minimum was a published, on-chain condition rather than a line in the terms, there was nothing to argue about. The threshold was visible, the sales were visible, and the conclusion followed mechanically. Nobody had to take our word for the fact that we were not simply choosing not to draw.

That is a strange thing to describe as a success and it genuinely was one. A verification system that only works when the outcome is good is not a verification system. Ours produced an unwelcome answer, publicly, and held.

What it was not

It was not a solution to the parts that are not on-chain. Acquiring a property, holding it, structuring an offer across jurisdictions, processing thousands of refunds — none of that is verifiable by a contract, and all of it is where most of the actual work and most of the actual risk sat.

We have been careful since about which claims we attach to on-chain verification. "The draw is verifiable" is true. "The raffle is trustless" would not have been.

Where it went

Later raffles were sized so the minimum was reachable rather than aspirational — smaller prizes, festive formats, memberships and holidays. The mechanics carried over unchanged.

The same standard now applies anywhere DeHub decides something with value attached: leaderboards, airdrop snapshots, creator revenue. If we decide it, you should be able to check it.

The design rule that came out of it

Publish the condition that lets someone conclude you are in the wrong.

Most transparency in this industry publishes the conditions under which the project is in the right — the successes, the completions, the metrics that went up. That is not verification, it is reporting with a favourable selection.

The house raffle's minimum was useful precisely because it was a condition we could visibly fail, and did. A threshold that can only ever be met is decoration.

Applied generally: if a published rule has no realistic path to embarrassing you, it is not doing the job. Every verification mechanism DeHub has shipped since is assessed against that, including dhbscan.com, which shows contract activity without filtering it to the flattering parts.