HashClue: Claim & Verification Mechanics v1
Status: Normative Applies to: All HashClue rounds v1 Purpose: Define unambiguous win, claim, verification, and payout sequencing to prevent disputes, race exploits, re-org attacks, and social ambiguity.
1. Cache Contents (Canonical Claim Material)
Each physical cache MUST contain the following, in sealed and legible form at placement time:
Canonical Secret String (HC1) The exact byte-for-byte secret string required to resolve the active round.
Human-Readable Encoding The canonical secret string printed in plain text with explicit start and end delimiters.
Machine-Readable Encoding A QR code encoding the exact same canonical secret string, with no additional metadata, prefixes, URLs, formatting, or compression.
Checksum Disclosure The SHA-256 hash of the canonical secret string, printed for local verification only.
The canonical secret string is the sole authoritative winning artifact.
If the QR code is damaged, unreadable, or corrupted, or if the human-readable text is illegible, incomplete, or destroyed, no alternative claim is recognized.
Illegibility or damage is a risk borne entirely by the finder.
No additional riddles, clues, URLs, instructions, or interpretive material may be included.
2. Canonical Encoding and Entropy Requirements
The canonical secret string:
- Is an ASCII-only byte sequence
- Is interpreted as raw bytes
- Is matched with no normalization, trimming, case-folding, or whitespace modification
- Must match exactly, byte-for-byte
The canonical secret string MUST be generated with sufficient entropy to make brute-force or dictionary guessing computationally infeasible under contemporary hardware assumptions.
Low-entropy strings (e.g. dictionary words, short phrases, predictable patterns) are prohibited.
The physical cache functions as possession of a high-entropy private key; submission functions as the signature.
3. Definition of a Valid Win
A win occurs only when all of the following are true:
- A participant submits a guess that exactly matches the canonical secret string
- The submitted string hashes to the publicly committed round hash
- The submission is accepted by the authoritative verifier or contract
- Canonical ordering confirms it as first at finality
Physical discovery alone does not constitute a win.
Photographic capture, transcription, memorization, or copying of the secret string is equivalent to physical possession for protocol purposes.
4. Submission Ordering and Finality
HashClue is a submission-first protocol.
Ordering is determined exclusively by:
- Canonical transaction ordering at declared finality depth (for on-chain deployments), or
- The authoritative verifier's monotonic, append-only acceptance log (for off-chain deployments)
A win is provisional until finality is reached.
Finality Depth Parameter
For blockchains with probabilistic finality, a round's winning submission is considered final only after reaching a predefined confirmation depth (FINALITY_DEPTH).
FINALITY_DEPTH is an implementation parameter declared at deployment time (e.g. 6 blocks, 12 blocks) and applies uniformly to all submissions.
Reorganizations occurring prior to this depth may alter provisional ordering.
Reorganizations beyond this depth are ignored for protocol purposes.
Arena Freeze may begin on provisional inclusion, but payout eligibility is gated strictly on finality.
Claims based on broadcast timing, physical discovery time, or intent are non-evidentiary.
5. Race Conditions and Multiple Finders
If multiple participants physically access the cache:
- Only the first valid submission at finality is recognized
- Subsequent identical submissions are rejected as post-resolution
- No tie, split, or arbitration exists
HashClue does not adjudicate physical coordination, private agreements, or disputes.
6. Verification Pending Window
Upon first provisionally valid submission:
- The round enters Verification Pending state
- Arena Freeze activates immediately
- A fixed verification window begins (v1 default: 24 hours)
During this window:
- The winning submission is publicly visible
- The pot is frozen
- No guesses or clues may be submitted
- No funds are released
The verification window exists solely to confirm protocol integrity.
7. Verification Scope and Protocol Breach Definition
Verification consists only of confirming:
- Exact hash correspondence
- Submission validity
- Correct ordering and finality
- Absence of protocol breach
A protocol breach is defined strictly as one or more of the following:
- Cryptographic mismatch between commitment and submission
- Verifier or contract bug affecting acceptance logic
- Balance, accounting, or payout execution fault
- Chain reorganization past declared finality threshold
- Proven compromise of commitment or verification key material
The following are explicitly excluded and are not protocol breaches:
- Finder behavior or conduct
- Allegations of coercion, theft, or prior knowledge
- Claims of unfairness or sportsmanship
- Social consensus, voting, or testimony
- Physical possession disputes
8. Cartographer Freeze Authority
During the verification window only, the Cartographer MAY:
- Maintain Arena Freeze
- Extend the verification window within defined limits
- Halt payout upon detection of an enumerated protocol breach
The Cartographer MAY NOT:
- Reassign a valid win
- Override a valid submission
- Introduce discretionary judgment
- Modify rules post-facto
All interventions must be publicly logged and justified by reference to an enumerated protocol breach.
Verification window extensions are capped (deployment-defined maximum cumulative duration).
Any extension requires a signed public incident note.
9. Arena Freeze Semantics
Arena Freeze begins only upon acceptance of a provisionally valid winning submission.
Effects:
- Guessing disabled
- Clue sales disabled
- Pot balance locked
- Round state immutable except for verification actions
Freeze persists until verification concludes or the round is invalidated due to a protocol breach.
10. Payout Release Conditions
Funds are released only after:
- Finality is reached
- Verification window closes
- No protocol breach is confirmed
- Cartographer releases the freeze
Upon release:
- Winner payout executes atomically
- Charity allocation executes atomically
- Next-round seeding executes atomically
Partial, delayed, or discretionary payouts are prohibited.
11. Finality
Once payout executes:
- The round is irrevocably closed
- No appeals exist
- No retroactive claims are recognized
- The cache becomes inert historical material
Post-resolution cache condition is non-evidentiary.
HashClue recognizes cryptographic finality, not narrative closure.
Appendix A: Informative Comparison (Non-Normative)
| Feature | Narrative Hunt (Standard) | HashClue v1 |
|---|---|---|
| Proof of Find | Photo or testimony at location | Exact byte-string submission |
| Dispute Resolution | Admin judgment | Automated cryptographic match |
| Winner Intent | "I found it first but..." | First valid submission at finality |
| Integrity Check | Social consensus | Hash match + finality window |