Normative

HashClue Protocol Specification v1

Status: Locked / Final

Protocol Overview & Trust Model
Canonical Secret String (HC1)
Clue System
Economic Rules
- 4.1 Clue Price Curve v1
- 4.2 Guess Price v1
- 4.3 Cartographer's Due
- 4.4 Pot Split Percentages v1
Round Lifecycle
Master Controller / Enforcement Notes
Versioning & Immutability
Explicit Non-Goals / Out of Scope
Status Feed
Appendices

1. Protocol Overview & Trust Model

Dependencies:

Canonical Secret String specification (Section 2)
Commitment Publication rules (Section 5)
Hash Function and On-Chain Determinism rules (Section 6)

Notes: This section defines the formal, informal, and technical guarantees of HashClue. All trust and fairness claims are conditional on the dependencies listed above. After publication, the operator cannot alter the target, select winners, or interfere with resolution. Auditors can verify outcomes independently using the rules defined herein and in the referenced sections.

1.1 Formal Definition

HashClue is a perpetual cryptographic protocol defined by a single real-world physical cache and a single canonical secret string that uniquely encodes that cache. The protocol publishes a public cryptographic hash commitment to that string. Participants submit candidate strings, which are evaluated deterministically against the committed hash. A submission that produces an exact, byte-for-byte preimage match is the sole winning condition.

The protocol recognizes no partial correctness, approximation, interpretation, or probabilistic similarity. Outcomes are objective, binary, and final. Resolution is enforced deterministically on-chain.

HashClue is not a discretionary system. It does not involve operator judgment, moderation, arbitration, or narrative interpretation. It is not a puzzle platform, alternate-reality game, or clue-evaluation mechanism. No off-chain review or subjective decision process exists.

Trust is derived exclusively from cryptographic guarantees and deterministic execution. The public and immutable hash commitment fixes the target. Preimage resistance prevents inference of the target from the commitment. On-chain enforcement ensures that a valid preimage submission resolves automatically. The operator cannot alter the target, select a winner, interfere with resolution, or access participant funds. Fairness does not depend on reputation, moderation, or off-chain assurances.

1.2 Informal Explanation

HashClue is a never-ending treasure hunt secured by cryptography.

One real object is hidden somewhere in the world. The exact way to describe that hiding spot is written as a single, precise text string. A cryptographic fingerprint of that string is made public and cannot be changed.

Anyone can try to guess the original string. If a guess matches it exactly, down to every character, it wins. If it does not, it fails. There are no near misses, no "almost right," and no interpretation.

There is no judge. HashClue does not decide who deserves to win, check reasoning, or review answers. It does not reward effort, creativity, or progress. Only the exact correct string matters.

Trust comes from the system itself. The target cannot be changed, the rules enforce themselves, and anyone can verify the result. The operator cannot cheat, interfere, or move funds. Either the math says you won, or it does not.

1.3 Technical Explanation

HashClue operates by committing publicly to a cryptographic hash of a secret string that encodes a real-world cache location and placement. This commitment is immutable once published. Participants submit candidate strings to the protocol. Each submission is hashed using the same deterministic process and compared to the committed value.

Validation consists solely of equality between the computed hash of the submitted string and the committed hash. No additional signals, metadata, context, or interpretation are considered. The comparison is exact and exhaustive.

Security relies on standard cryptographic assumptions. Preimage resistance ensures that the committed hash does not reveal the underlying string. Collision resistance ensures that only one canonical string can satisfy the commitment. Deterministic execution ensures that identical inputs always produce identical outcomes.

All enforcement occurs on-chain. The protocol logic evaluates submissions and resolves the winning condition without discretionary intervention. The operator has no privileged capabilities after commitment publication. Funds and outcomes are controlled exclusively by protocol execution rather than off-chain processes or human actors.

1.4 Auditor-Aware Notes

Canonical String Assumption: The security and fairness of the protocol fully depend on a single, unambiguous canonical secret string. Rules for serialization, normalization, and encoding are defined in Section 2.
Initial Commitment Trust: While all trust after publication is cryptographically eliminated, the initial commitment must be correctly generated. Operator integrity at the commitment step is a one-time, well-defined trust assumption.
Real-World Cache Consideration: The protocol enforces fairness cryptographically but does not enforce the physical existence or retrievability of the cache. Participants' expectations regarding the real object remain outside the protocol's guarantee.
Hash Function and Determinism: Preimage evaluation assumes a fixed hash function and deterministic chain execution. Any changes in hash function, encoding rules, or chain behavior must be versioned and defined elsewhere.
Scope Enforcement: The protocol does not evaluate effort, proximity, partial matches, or interpretation. All fairness claims are strictly derived from the cryptographic preimage check and deterministic execution.

2. Canonical Secret String (HC1)

Version: HC1 Status: Locked (v1)

2.1 Purpose

HashClue is a cryptographic treasure hunt in which the SHA-256 hash of a single secret string is publicly committed on-chain. Players submit guesses of the full string; only an exact byte-for-byte match wins.

This section defines the canonical v1 secret string format ("winning ticket"). The format is designed to be:

Deterministic (one real-world placement → one valid string)
Unambiguous (no alternate spellings or interpretations)
Human-printable and QR-scannable
Stable over decades
Strictly locally validatable before submission

This specification concerns only the secret string format. It does not define UI, contracts, clues, or gameplay.

2.2 Design Principles

Physical reality first: the string encodes a real, physical hiding spot, not administrative or political labels.
No free text: all fields are fixed-format or fixed-dictionary.
No optional fields: v1 is closed; the grammar is exact.
No ambiguity: multiple representations of the same location are explicitly disallowed.
Forward compatibility: future changes occur under new version prefixes (e.g. HC2).

2.3 High-Level Structure

The v1 secret string has four pipe-delimited fields:

HC1|LAT|LON|<PLACEMENT_DESCRIPTOR>

The placement descriptor format depends on METHOD (see §2.6).

There are no optional suffixes and no whitespace anywhere.

2.4 Version Prefix

Field 1: Version

HC1

Literal, case-sensitive.
Mandatory.
Indicates the grammar defined in this document.
Future versions must use a new prefix (e.g. HC2).

2.5 Location Coordinates

The physical location is encoded using WGS-84 latitude and longitude.

2.5.1 Latitude (LAT)

Format:

[+|-]DD.DDDDDD

Rules:

Explicit sign required (+ or -)
Exactly 2 digits before the decimal point
Exactly 6 digits after the decimal point
Decimal separator is . only
Range: -90 < LAT < +90
+90.000000 and -90.000000 are invalid
Negative zero is not allowed
- -00.000000 is invalid
- zero must be written as +00.000000

Examples:

Valid: +37.774929
Invalid: 37.774929, +7.774929, -00.000000

2.5.2 Longitude (LON)

Format:

[+|-]DDD.DDDDDD

Rules:

Explicit sign required (+ or -)
Exactly 3 digits before the decimal point
Exactly 6 digits after the decimal point
Decimal separator is . only
Range: -180 < LON < +180
-180.000000 and +180.000000 are both invalid
Negative zero is not allowed
- -000.000000 is invalid
- zero must be written as +000.000000

Examples:

Valid: -122.419416
Invalid: -180.000000, -000.000000

2.6 Placement Descriptor

Field 4 encodes how the cache is placed and, for certain methods, physical landmarks required for retrieval.

Base format:

ENV.HOST.METHOD

Extended format (BURIED only):

ENV.HOST.METHOD.ANCHOR_1[.ANCHOR_2]

Rules:

Three base tokens (ENV, HOST, METHOD) are mandatory
BURIED method requires 1-2 additional anchor descriptor tokens
Anchor descriptors identify persistent, visible physical landmarks
Non-BURIED methods use exactly three tokens (base format only)
Tokens are separated by dots (.)
All tokens are uppercase only
All tokens must come from fixed dictionaries or follow defined format rules

2.6.1 ENV: Environment

Allowed values:

INDOOR: enclosed structure
OUTDOOR: open-air land
SUBTERRANEAN: below ground surface
AQUATIC: physically in water

2.6.2 HOST: Physical Substrate

Allowed values:

STRUCTURE
GROUND
ROCK
VEGETATION
WATERBODY

2.6.3 METHOD: Placement Method

Allowed values:

PLACED
CONCEALED
ATTACHED
BURIED
SUBMERGED
EMBEDDED

2.6.4 Anchor Descriptors (BURIED Method Requirement)

When METHOD = BURIED, the placement descriptor MUST include 1-2 anchor tokens.

Purpose: BURIED method obscures the cache from view. Without anchor descriptors, physical retrieval becomes mechanically impossible within the search zone revealed by geographic clues. Anchor descriptors specify visible, persistent landmarks that enable the player to locate the cache position through reasoning rather than exhaustive search.

Format:

ANCHOR ::= <PREFIX>_<LANDMARK>
PREFIX  ::= BENEATH | AT | BY | ON | IN | NEAR | BEHIND | UNDER

Constraints:

Anchor tokens must be SCREAMING_SNAKE_CASE
Must start with one of the eight positional prefixes
Must describe persistent physical landmarks (not transient objects)
Maximum 2 anchor tokens per secret string
Minimum 1 anchor token when METHOD = BURIED

Valid Examples:

BENEATH_LANDMARK
AT_BASE_OF_LANDMARK
BY_LANDMARK

Invalid:

NEAR_CAR (transient object)
LOG (missing positional prefix)
Anchor tokens with non-BURIED methods (disallowed)

Validation:

Secret strings with METHOD = BURIED and zero anchor tokens are invalid
Secret strings with non-BURIED methods and any anchor tokens are invalid

2.6.5 Validity Matrix (Mandatory)

The tuple (ENV.HOST.METHOD) is valid iff all rules below pass.

ENV ↔ HOST

INDOOR → STRUCTURE
OUTDOOR → STRUCTURE, GROUND, ROCK, VEGETATION
SUBTERRANEAN → GROUND, ROCK, STRUCTURE
AQUATIC → WATERBODY, GROUND, ROCK, STRUCTURE

METHOD ↔ HOST

BURIED → GROUND
SUBMERGED → WATERBODY
ATTACHED → STRUCTURE, ROCK, VEGETATION
EMBEDDED → STRUCTURE, ROCK
CONCEALED → STRUCTURE, GROUND, ROCK, VEGETATION
PLACED → STRUCTURE, GROUND, ROCK, VEGETATION (WATERBODY only when ENV is AQUATIC)

ENV ↔ METHOD

INDOOR → PLACED, CONCEALED, ATTACHED, EMBEDDED
OUTDOOR → PLACED, CONCEALED, ATTACHED, EMBEDDED, BURIED
SUBTERRANEAN → PLACED, CONCEALED, ATTACHED, EMBEDDED, BURIED
AQUATIC → SUBMERGED, ATTACHED, PLACED

Cross-table constraint: SUBMERGED requires ENV = AQUATIC.

Anchor Requirements:

BURIED method → minimum 1 anchor token, maximum 2 anchor tokens
All other methods → zero anchor tokens (anchors forbidden)

Invalid tuples are forbidden.

2.7 Character Set and Casing Rules

Allowed characters:

A–Z 0–9 + - . |

Rules:

Uppercase only
No whitespace
Case-sensitive
Any lowercase character invalidates the string
The canonical string MUST be encoded as UTF-8 without BOM, without trailing newline, without null terminator. The resulting byte sequence is the SHA-256 preimage.

2.8 Examples

Valid examples:

HC1|+37.774929|-122.419416|OUTDOOR.GROUND.BURIED.BENEATH_LOG
HC1|+40.416775|-003.703790|INDOOR.STRUCTURE.CONCEALED
HC1|+51.500729|+000.124625|OUTDOOR.STRUCTURE.ATTACHED
HC1|+39.498289|-000.388206|OUTDOOR.GROUND.BURIED.BENEATH_TREE.ON_ROUNDABOUT

Invalid examples (and why):

HC1|37.774929|-122.419416|OUTDOOR.GROUND.BURIED

→ missing explicit sign

HC1|+07.12345|+003.000001|OUTDOOR.ROCK.CONCEALED

→ wrong decimal precision

HC1|+07.123456|-000.000000|OUTDOOR.ROCK.CONCEALED

→ negative zero not allowed

HC1|+07.123456|+003.000001|OUTDOOR.ROCK

→ incomplete placement descriptor (missing METHOD token)

HC1|+07.123456|+003.000001|INDOOR.VEGETATION.BURIED

→ invalid tuple (INDOOR does not allow VEGETATION; INDOOR does not allow BURIED)

HC1|+37.774929|-122.419416|OUTDOOR.GROUND.BURIED

→ BURIED method missing required anchor descriptors

HC1|+40.416775|-003.703790|INDOOR.STRUCTURE.CONCEALED.BENEATH_LOG

→ non-BURIED method with anchor descriptor (anchors forbidden for CONCEALED)

2.9 v1 Closure Guarantee

Version HC1 is closed:

No optional fields
No extensions
No modifiers
No suffixes

The anchor descriptor requirement for BURIED method is not an extension; it is a correctness requirement implicit in the physical solvability constraint. Prior documentation under-specified this requirement.

Any future expansion (e.g. depth, offsets, additional placement detail) must occur under a new version prefix.

3. Clue System

3.1 Clue Ladder v1

Clues are public, global, sequential, and deterministic.

Each clue reveals one objective fact derived from the secret string. Each clue strictly reduces the valid search space. No clue can fully determine the secret string on its own.

Fixed Ladder Order (Immutable)

GEO-1: Hemisphere
GEO-2: Macro geographic cell
ENV-1: Environment class
GEO-3: Regional geographic cell
HST-1: Host class
GEO-4: Local geographic cell
GEO-5: Micro geographic cell (final geographic rung)
MET-1: Method class

Rule: GEO-5 is the final geographic clue. No clue ever reveals exact coordinates or coordinate precision.

3.2 HC-GEO Encoding & Anti-Compute Guarantees

HC-GEO is a deterministic mapping from (LAT, LON) to a base-32 string.

It is library-independent and fully specified here.

3.2.1 Alphabet

0123456789bcdefghjkmnpqrstuvwxyz

3.2.2 Coordinate Domain

LAT ∈ [-90, +90)
LON ∈ [-180, +180)

3.2.3 Normalization

u = (LON + 180) / 360
v = (LAT + 90)  / 180

Both lie in [0,1).

3.2.4 Bit Allocation

For a prefix length L characters:

B     = 5L
Blon  = ceil(B / 2)
Blat  = floor(B / 2)

3.2.5 Indexing

ilon = floor(u * 2^Blon)
ilat = floor(v * 2^Blat)

3.2.6 Interleaving

Bits are interleaved MSB-first:

lon[0], lat[0], lon[1], lat[1], ...

Longitude contributes the final bit if counts differ.

3.2.7 Encoding

Interleaved bits are grouped into 5-bit chunks and mapped to the alphabet.

The result is the HC-GEO string.

3.2.8 Prefix Refinement Guarantee

Each longer prefix strictly refines the previous:

GEO-5 ⊂ GEO-4 ⊂ GEO-3 ⊂ GEO-2

3.2.9 Anti-Compute Guarantee (Critical)

Let:

R(HC1) = all coordinate pairs representable by HC1
CELL_5 = the GEO-5 HC-GEO cell of the true coordinates

Hard requirement (LOCKED):

| { (lat,lon) ∈ R(HC1) ∩ CELL_5 } | ≥ 2^30

That is at least 1,073,741,824 (2^30) possible coordinate pairs.

Consequence:

GEO-5 can never be brute-forced
Compute-only wins are infeasible
Physical search is required

This check MUST be enforced at placement creation time.

Auditor Clarification: Anti-Compute Scope

The ≥ 2^30 GEO-5 candidate requirement constitutes a quantitative feasibility guarantee, not a claim of absolute ASIC resistance or adversarial compute impossibility under all hardware assumptions. The guarantee asserts that, at placement creation time, the remaining coordinate search space is sufficiently large that compute-only solutions are not the dominant or intended resolution path under contemporary, non-specialized assumptions.

Evaluation of this guarantee is therefore a matter of mathematical analysis and prevailing hardware capability, not operator discretion, ethics, or trust. The requirement is enforced mechanically at placement creation time and is independent of any subsequent participant behavior or infrastructure choice.

3.3 Clue Payload Format (HCL1)

All clues use a strict canonical format.

HCL1|<RUNG>|<PAYLOAD>

All characters are ASCII. No whitespace. No optional fields. No alternative encodings.

Payloads by Rung

GEO-1

HCL1|GEO-1|N|E

Latitude hemisphere: N or S
Longitude hemisphere: E or W

GEO-2 / GEO-3 / GEO-4 / GEO-5

HCL1|GEO-n|<PREFIX>

Prefix is an HC-GEO string of fixed length:
- GEO-2 → 2 characters
- GEO-3 → 3 characters
- GEO-4 → 4 characters
- GEO-5 → 5 characters

ENV-1

HCL1|ENV-1|<ENV>

HST-1

HCL1|HST-1|<HOST>

MET-1

HCL1|MET-1|<METHOD>

Clues MUST be published strictly in ladder order.

3.4 Environment / Host / Method Dictionaries & Validity Matrix

All tokens are uppercase ASCII. No spaces. No synonyms. No free text.

3.4.1 ENV (Environment)

INDOOR: enclosed structure
OUTDOOR: open-air land
SUBTERRANEAN: below ground surface
AQUATIC: physically in water

3.4.2 HOST (Physical Substrate)

STRUCTURE
GROUND
ROCK
VEGETATION
WATERBODY

3.4.3 METHOD (Placement Method)

PLACED
CONCEALED
ATTACHED
BURIED
SUBMERGED
EMBEDDED

3.4.4 Validity Matrix (Mandatory)

The validity matrix for (ENV.HOST.METHOD) is identical to the matrix defined in §2.6.4. Refer to that section for the full ENV↔HOST, METHOD↔HOST, and ENV↔METHOD constraint tables and cross-table constraints.

Invalid tuples are forbidden.

3.5 Placement Authoring Rules

The hider MUST ensure:

Coordinates are canonical
Coordinates are not on any hemisphere or HC-GEO cell boundary
GEO-5 candidate count ≥ 2^30
ENV/HOST/METHOD reflect physical reality
Tuple passes validity matrix
Placement is physically stable over time

If any rule fails, the placement is invalid and MUST be redesigned.

4. Economic Rules

4.1 Clue Price Curve v1

Scope

This section defines the global pricing mechanism for unlocking clues in HashClue. It applies to exactly one active round at a time and governs only clue unlock payments.

Fixed Context (Immutable)

One active round at a time
Secret string format HC1 is locked
Clue Ladder order is locked and immutable
Clues are public, global, sequential, and deterministic
Players may unlock only the next clue
Once unlocked, a clue is free for all
Clue unlock payments increase the same public pot that pays the winner

Pricing Model Type

Fixed rising price ladder with a pot-relative safety cap.

Clue Price Ladder (Posted Prices)

Rung	Clue	Posted Price
1	GEO-1	500
2	GEO-2	1,000
3	ENV-1	2,500
4	GEO-3	5,000
5	HST-1	10,000
6	GEO-4	25,000
7	GEO-5	50,000
8	MET-1	100,000

All values are denominated in the game's base currency.

Global Safety Cap (Hard Rule)

For any clue unlock:

If the posted price exceeds 15% of the current public pot, the payable price is reduced to exactly 15% of the pot.

The pot value used is the on-chain balance immediately before payment
This cap applies per rung, globally
The cap ensures late-stage clues are never impossible to unlock

Economic Properties

Early clues are non-trivial: prevents spam and signals seriousness
Mid-game prices ramp decisively: rewards whale acceleration
Late-game prices are large but bounded: capped to pot size
No auctions, no bidding, no discretion
No private advantage: clues are public and simultaneous
No compute-only win path: payment only advances public state
No coordination leverage: posted price is deterministic and global

4.2 Guess Price v1

Scope

This section defines the mandatory, global pricing rule for submitting a guess in HashClue. It is fully deterministic, enforced on-chain, and derived only from public round state.

Pricing Model Type

Hybrid: indexed to Clue Ladder progression, with pot-relative behavior via the existing Clue Price Curve safety cap.

Definitions

One round is active at a time.
Clue Ladder v1 has 8 rungs with fixed posted prices: 500, 1,000, 2,500, 5,000, 10,000, 25,000, 50,000, 100,000.
Clue Price Curve v1 applies: payable clue price = min(posted price, 15% of current public pot).
Let u be the number of clues already unlocked and publicly visible (0–8).
Let j = min(u + 1, 8) be the index of the next locked clue (or the final rung if all clues are unlocked).
All prices are denominated in the settlement asset.

Guess Price Rule

The price to submit one guess is:

Guess Price = max(10, 2% of the payable price of clue j)

The final guess price MUST be rounded up to the smallest transferable unit of the settlement asset.

Payment Split per Guess

92.5% of the guess payment is added to the public pot.
7.5% is paid to the Cartographer as Cartographer's Due (same rate as clue purchases).

Behavioral Properties (Normative)

Guessing is always available; there are no limits, discounts, auctions, or discretionary pricing.
Early in a round, guess price defaults to the fixed minimum, enabling broad participation.
As clues unlock, guess prices increase stepwise in a predictable and explainable manner.
When the clue safety cap binds, the guess price becomes automatically pot-relative, scaling with round stakes.
The cost of large-scale brute-force guessing therefore increases monotonically with both round progress and pot size, preventing any compute-only win path.
Buying clues increases public information but immediately increases the cost of further guessing, preserving economic balance without modifying the clue system.

Public-State Requirement

The guess price depends only on:

the current public pot balance, and
the number of unlocked clues.

No off-chain data, subjective inputs, or hidden variables are permitted.

Clarification: Nature of Guess Fees

Guess fees are not paid to determine whether a guess is correct. Since the committed hash and hash function are public, participants may verify candidate strings off-chain prior to submission. The guess fee represents the cost of submitting a claim into the protocol's on-chain resolution process and competing for inclusion under deterministic rules; it is not a correctness oracle and does not imply payment for evaluation of incorrect guesses.

4.3 Cartographer's Due

Name: Cartographer's Due
Rate: 7.5%
Nature: Flat, immutable
Applies to: Every clue unlock payment and every guess payment
Split:
- 7.5% → Cartographer (game host)
- 92.5% → Public prize pot
The Due is calculated on the actual payable price (after any pot-cap adjustment)

No variation by:

rung
round
time
pot size
participant

4.4 Pot Split Percentages v1

Scope and Purpose

This section defines the immutable distribution of the public prize pot when a HashClue round is won. It applies uniformly to every round in v1, with no discretion, conditions, timing logic, or variability. Distribution is atomic and enforced on-chain at the moment a correct secret string is submitted.

Pot Source (Contextual, Non-Modifiable)

The public pot is funded by guess payments and clue unlock payments, each contributing 92.5% to the pot. Pricing mechanics are defined in Sections 4.1–4.3.

Distribution on Win (v1)

Upon a valid win, the entire public pot is split as follows, summing to 100%:

Recipient	Share
Winner payout	85%
Next-round seed	10%
Charity Wallet	5%

Rationale

This split prioritizes jackpot psychology and fairness by directing the overwhelming majority of value to the winner, ensuring the prize feels decisive and worth pursuing. A fixed 10% carryover seeds the next round with visible, meaningful stakes, preventing cold starts and preserving momentum without diluting the current win. The 5% Charity Wallet allocation is sacrosanct and directed entirely to the designated charity wallet, never reduced or repurposed. The absence of conditions or variability removes perverse incentives to stall, grief, or withhold guesses; the dominant strategy is always to win as soon as possible.

Operational Guarantees

Percentages are constant and immutable in v1.
Distribution is immediate and atomic on win.
The next round begins automatically with the seeded amount.

5. Round Lifecycle

A HashClue round proceeds through the following stages, derived from the rules defined in this specification:

Round Initialization: A new round begins with a seeded pot (10% of the previous round's pot, or an initial seed for the first round). The cryptographic hash commitment to the secret string is published on-chain. All 8 clues are locked.
Active Play: Players may submit guesses at any time (Section 4.2). Players may unlock the next clue by paying the posted price (Section 4.1). Each unlock makes the clue public and global. Clues MUST be unlocked in strict ladder order (Section 3.1).
Resolution: A submission that produces an exact byte-for-byte preimage match against the committed hash is the sole winning condition. Resolution is deterministic and on-chain. No off-chain review or discretionary process exists.
Distribution: Upon a valid win, the pot is split atomically per Section 4.4: 85% to the winner, 10% to the next-round seed, 5% to the Charity Wallet.
Next Round: The next round begins automatically with the seeded amount. A new commitment MAY be published for a new secret string.

One round is active at a time. No parallel rounds exist in v1.

5.1 Winning Submission Source

The canonical submission string required to resolve a round is physically recovered from the cache itself (for example, printed, engraved, or encoded within the placement). Participants do not derive the winning string from live GPS measurements, sensor readings, or proximity calculations. Cryptographic verification serves solely to validate possession of the exact canonical secret committed at placement time.

5.2 Cache Destruction, Theft, and Round Void Conditions

A round's physical cache is a single, non-replaceable instantiation of the committed target. Once a round is live, the cache location and its contents are immutable.

If credible information indicates that the physical cache has been destroyed, removed, or irreversibly compromised prior to successful discovery, the round MUST enter the Dormancy state.

While in Dormancy:

No new clues MAY be released.
The round MUST NOT be resolved.
No new commitments, replacements, or relocations are permitted.

After the expiration of the protocol-defined dormancy period, the round MUST be marked VOID.

When a round is marked VOID:

The canonical secret string (HC1) MUST NOT be revealed.
The accumulated pot MUST roll forward into the subsequent round according to the standard pot rollover rules.
The round MUST NOT be retroactively resolved.

Under no circumstances may a physical cache be relocated, replaced, or reconstructed for an active or dormant round.

These rules apply regardless of intent, fault, or actor.

6. Master Controller / Enforcement Notes

Canonical String Assumption: The security and fairness of the protocol fully depend on a single, unambiguous canonical secret string. The serialization, normalization, and encoding rules in Section 2 are normative.
Initial Commitment Trust: While all trust after publication is cryptographically eliminated, the initial commitment MUST be correctly generated. Operator integrity at the commitment step is a one-time, well-defined trust assumption.
On-Chain Enforcement: All enforcement occurs on-chain. The protocol logic evaluates submissions and resolves the winning condition without discretionary intervention. The operator has no privileged capabilities after commitment publication. Funds and outcomes are controlled exclusively by protocol execution.
Hash Function and Determinism: Preimage evaluation assumes a fixed hash function (SHA-256) and deterministic chain execution. Any changes in hash function, encoding rules, or chain behavior MUST be versioned.
Anti-Compute Enforcement: The anti-compute guarantee (Section 3.2.9) MUST be enforced at placement creation time. The Master Controller SHALL reject any placement where the GEO-5 cell contains fewer than 2^30 valid coordinate pairs.
Clue Publication Order: The Master Controller SHALL publish clues strictly in ladder order. Out-of-order publication is forbidden.
Price Enforcement: All pricing (clue unlocks, guesses) is deterministic and on-chain. The Master Controller SHALL enforce the safety cap and Cartographer's Due as defined in Section 4.
Stewardship Continuity: Cartographer succession, liveness requirements, eligibility rules, renunciation, and abdication are defined in the HashClue Protocol Constitution v1 ("Stewardship & Continuity" section). The Constitution is the authoritative source for all governance-layer rules. This specification does not define succession mechanics.

7. Versioning & Immutability

The following elements are immutable in v1:

HC1: Canonical secret string format
HCL1: Clue payload format
Clue Ladder order (8 rungs, fixed sequence)
HC-GEO encoding algorithm and alphabet
ENV / HOST / METHOD dictionaries and validity matrix
Anti-compute threshold (≥ 2^30)
Clue Price Ladder posted prices
Safety cap (15% of pot)
Cartographer's Due rate (7.5%)
Guess price formula
Pot split percentages (85% / 10% / 5%)

Any future changes MUST occur under new version identifiers (HC2, HCL2, etc.). No silent upgrades are permitted.

8. Explicit Non-Goals / Out of Scope

This specification intentionally does not define:

Smart-contract source code or deployment
Frontend UX or client implementation
Timing or scheduling of clue releases
Unlock mechanics beyond pricing
Narrative, lore, or marketing
Physical cache construction or materials
Dispute resolution (none exists by design)
Multi-round scheduling beyond automatic seeding
Settlement asset denomination or blockchain selection

10. Status Feed

URL: /status.xml Format: RSS 2.0 Purpose: Public notification of significant protocol state changes

10.1 Inclusion Criteria (Strict)

Entries are published ONLY for:

New round opened (commitment published)
Round closed (winner determined, pending verification)
Winner confirmed (payout released)
Protocol or rule corrections affecting solvability
Critical bugs acknowledged or fixed

This feed does NOT include:

Hints or clues about round solutions
Clarifications of existing rules
UI/copy changes
Timing advantages
Marketing or promotional content

10.2 Feed Properties

Append-only: Existing entries never edited or deleted
Mistakes corrected by publishing new correcting entry
Content-addressed GUIDs (hash of category|round_id|published_at|title)
UTC timestamps
Deterministic ordering (newest first)
Valid RSS 2.0 XML with proper character escaping
Feed guarantees last 100 entries only (not complete history)

10.3 Privacy & Tracking

No analytics or tracking
No email subscriptions
No personalization
Standard HTTP caching (5-minute revalidation)

9. Appendices

Appendix A: Lifecycle Diagram (Placeholder)

┌──────────────────┐
│  Round Init       │
│  (Seed + Commit)  │
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│  Active Play      │◄──────────────┐
│  Guess / Unlock   │               │
└────────┬─────────┘               │
         │                          │
         ▼                          │
    ┌─────────┐     No match        │
    │  Hash   ├─────────────────────┘
    │  Check  │
    └────┬────┘
         │ Match
         ▼
┌──────────────────┐
│  Resolution       │
│  (Atomic Split)   │
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│  Next Round       │
│  (10% Seed)       │
└──────────────────┘

Appendix B: Key Parameters (Quick Reference)

Parameter	Value	Defined In
Anti-compute threshold	≥ 2^30 coordinate pairs in GEO-5 cell	§3.2.9
Safety cap (clue pricing)	15% of current public pot	§4.1
Cartographer's Due	7.5% of every payment	§4.3
Guess price formula	max(10, 2% of payable price of clue j)	§4.2
Pot split: Winner	85%	§4.4
Pot split: Next-round seed	10%	§4.4
Pot split: Charity Wallet	5%	§4.4
Clue 1 (GEO-1) posted price	500	§4.1
Clue 2 (GEO-2) posted price	1,000	§4.1
Clue 3 (ENV-1) posted price	2,500	§4.1
Clue 4 (GEO-3) posted price	5,000	§4.1
Clue 5 (HST-1) posted price	10,000	§4.1
Clue 6 (GEO-4) posted price	25,000	§4.1
Clue 7 (GEO-5) posted price	50,000	§4.1
Clue 8 (MET-1) posted price	100,000	§4.1

All values are immutable in v1.

Appendix C: Normative References

WGS-84: World Geodetic System 1984. The coordinate reference system used for all latitude and longitude values in HC1.
SHA-256: Secure Hash Algorithm 256-bit (FIPS 180-4). The hash function used for the public commitment and preimage verification.
Base32 (HC-GEO variant): A 32-character alphabet (0123456789bcdefghjkmnpqrstuvwxyz) used for deterministic geographic encoding. This is the Geohash-standard alphabet, fully specified in Section 3.2.

HashClue Protocol Specification v1

Table of Contents

1. Protocol Overview & Trust Model

1.1 Formal Definition

1.2 Informal Explanation

1.3 Technical Explanation

1.4 Auditor-Aware Notes

2. Canonical Secret String (HC1)

2.1 Purpose

2.2 Design Principles

2.3 High-Level Structure

2.4 Version Prefix

2.5 Location Coordinates

2.5.1 Latitude (LAT)

2.5.2 Longitude (LON)

2.6 Placement Descriptor

2.6.1 ENV: Environment

2.6.2 HOST: Physical Substrate

2.6.3 METHOD: Placement Method

2.6.4 Anchor Descriptors (BURIED Method Requirement)

2.6.5 Validity Matrix (Mandatory)

2.7 Character Set and Casing Rules

2.8 Examples

2.9 v1 Closure Guarantee

3. Clue System

3.1 Clue Ladder v1

Fixed Ladder Order (Immutable)

3.2 HC-GEO Encoding & Anti-Compute Guarantees

3.2.1 Alphabet

3.2.2 Coordinate Domain

3.2.3 Normalization

3.2.4 Bit Allocation

3.2.5 Indexing

3.2.6 Interleaving

3.2.7 Encoding

3.2.8 Prefix Refinement Guarantee

3.2.9 Anti-Compute Guarantee (Critical)

3.3 Clue Payload Format (HCL1)

Payloads by Rung

3.4 Environment / Host / Method Dictionaries & Validity Matrix

3.4.1 ENV (Environment)

3.4.2 HOST (Physical Substrate)

3.4.3 METHOD (Placement Method)

3.4.4 Validity Matrix (Mandatory)

3.5 Placement Authoring Rules

4. Economic Rules

4.1 Clue Price Curve v1

Scope

Fixed Context (Immutable)

Pricing Model Type

Clue Price Ladder (Posted Prices)

Global Safety Cap (Hard Rule)

Economic Properties

4.2 Guess Price v1

Scope

Pricing Model Type

Definitions

Guess Price Rule

Payment Split per Guess

Behavioral Properties (Normative)

Public-State Requirement

4.3 Cartographer's Due

4.4 Pot Split Percentages v1

Scope and Purpose

Pot Source (Contextual, Non-Modifiable)

Distribution on Win (v1)

Rationale

Operational Guarantees

5. Round Lifecycle

5.1 Winning Submission Source

5.2 Cache Destruction, Theft, and Round Void Conditions

6. Master Controller / Enforcement Notes

7. Versioning & Immutability

8. Explicit Non-Goals / Out of Scope

10. Status Feed

10.1 Inclusion Criteria (Strict)

10.2 Feed Properties

10.3 Privacy & Tracking

9. Appendices

Appendix A: Lifecycle Diagram (Placeholder)