Oasis VaultCryptoPunk raffle audit

Public inclusion proof · Tool 01

Verify your raffle entries.

Use the original commitment transaction to prove that one or more of your codes were included before the winner could be known. The full check runs in your browser against Ethereum.

Complete evidence checklist

Everything needed to verify independently.

The organizer publishes two references. Every other draw value is either chosen by the verifier or read directly from Ethereum mainnet.

01 Organizer publishes
  • Commitment transaction hashPoints to the immutable OVCR payload.
  • Expected signer addressMust be both sender and recipient of the commitment.
02 Verifier provides
  • Ethereum RPC URLPublicNode is prefilled, and the verifier may replace it with any mainnet endpoint.
  • Participant’s raffle codesOne or more codes may be checked together; each is normalized before hashing.
03 Ethereum supplies
  • Transaction and receiptStatus, sender, recipient, value, calldata, and commitment block.
  • Committed raffle dataRaffle ID, target block, code count, Merkle root, and full ordered code list.
  • Proof materialEvery leaf needed to reproduce the root and each participant-code proof path.

Commitment details

Use the public values published with the raffle.

Private by design. Your codes are checked on this device and are not submitted to Oasis Vault.

Beginner-friendly option

Ask an AI to verify your raffle codes.

Fill in the public details above, then copy this short prompt into an AI assistant that can browse the web and run code. It will follow the complete public instructions for this audit.

Ready-to-copy verification promptIncludes all your current raffle-code inputs
Read instructions ↗

Copying only places the prompt on your clipboard. Pasting it into an AI service shares these values with that provider. A legitimate verification never needs a seed phrase, private key, password, or wallet connection.

Technical details

Open verification specification

Expand this section to inspect the complete, independently reproducible method.

The exact Merkle inclusion method.

This is the complete method implemented by the tool. It is intentionally specific enough to reproduce in another language or application.

01

Shared precondition

Authenticate the on-chain commitment.

Network

The RPC must report Ethereum mainnet.

Execution

Transaction exists and its receipt status equals 1.

Shape

from == to == expectedSigner and value == 0.

Timing

commitmentBlock < targetBlock.

02

Calldata schema

Decode the commitment with no hidden fields.

OffsetSizeFieldRule
04Magic0x4f564352 (“OVCR”)
416Raffle IDUUID bytes
208Target blockUnsigned 64-bit integer
284Code countUnsigned 32-bit integer; 1–8,000
3232Merkle root32-byte hash
649 × countRaffle codesNine UTF-8 bytes each

The payload is rejected unless its total length is exactly 64 + (9 × codeCount) bytes.

03

Merkle construction

Normalize, hash, sort, and rebuild.

  1. Normalize

    Trim whitespace; preserve the lowercase ov- prefix; uppercase the six-character suffix.

  2. Validate

    Every code must match ^ov-[0-9A-HJKMNP-TV-Z]{6}$.

  3. Hash leaves

    Domain-separate every code with byte 0x00.

  4. Canonical order

    Sort entries by leaf hash ascending and reject duplicate leaves.

  5. Hash nodes

    Domain-separate every internal node with byte 0x01.

  6. Split tree

    At each level, split at the largest power of two strictly smaller than the number of leaves.

Leafkeccak256(0x00 ∥ UTF8(normalizedCode))
Nodekeccak256(0x01 ∥ leftHash ∥ rightHash)
04

Acceptance conditions

All three results must agree.

  • The rebuilt root equals the 32-byte root in the commitment.

  • The committed codes are already in canonical leaf-hash order.

  • Each included participant code exists in that sequence and its proof path resolves to the same root.

Conclusion: inclusion proves the code was locked into the raffle before the future target block existed.