Digital scarcity
with a history.

01 — Protocol

Scarcity is not a number in a database.

A declared maximum supply is only one part of digital scarcity. A scarce entity also needs a verifiable origin, an issuance rule, a persistent identity, an ownership history, and a way to distinguish earned state from arbitrary modification.

Hashima is designed to make those properties explicit and auditable.

• 01IssuanceWhy was the entity allowed to exist?

  Every entity is created under an explicit rule: a template, an authorized process, or a cryptographic event. Existence is not an arbitrary database row — it has a reason that can be stated and checked.

• 02IdentityWhat makes it the same entity across time?

  Identity is derived from cryptographic inputs, not assigned by a UI. The same inputs reproduce the same identifier, so an entity remains itself across renderers, clients, and years.

• 03ProvenanceWhere did it come from?

  Birth context — block reference, nonce, template, issuing process — is recorded with the entity. Origin is part of the record, not a marketing claim.

• 04OwnershipWho currently controls it?

  Ownership is a tracked, transferable state with a history. The current holder is one entry in a chain of custody rather than a single mutable field.

• 05Earned stateWhich changes were produced by verifiable work or events?

  Changes that come from verified proof of work or authorized events are separated from changes an operator could simply type in. That separation is what makes progress meaningful.

02 — How Hashima works

From an event to an entity.

Five stages separate the moment an entity is allowed to exist from the many ways it can later be displayed.

1. 01

   Origin

   A Bitcoin event, key, protocol template, or authorized issuance process creates the context of birth.

2. 02

   Derivation

   Cryptographic inputs are combined to produce a deterministic identity.

3. 03

   Registration

   Hashima records the entity, its owner, provenance, and initial state.

4. 04

   Evolution

   Valid proof of work or other authorized events can modify the entity's earned state without changing its original identity.

5. 05

   Representation

   Games and applications render the entity as a character, object, territory, collectible, or other interface.

identity = SHA256(templateId : birthNonce : speciesKey)

03 — Two layers of truth

What an entity is. What an entity earns.

The immutable core never changes. Everything earned accumulates around it, and stays attributable to verified work or authorized events.

04 — Case study

The first living world built on Hashima.

Hashimon is a game world populated by creatures born with cryptographic DNA. Each Hashimon has a persistent identity, an owner, a provenance record, and a proof-of-work biography.

Its appearance can change between a browser sprite, an AI-generated illustration, a 3D model, or a voxel-world creature. Those representations are not the creature itself. Hashima preserves the underlying identity.

• 01A Hashimon is issued through controlled rules.
• 02Its DNA is deterministically derived.
• 03Its genetic traits remain immutable.
• 04Its evolution is earned through verified SHA-256 work.
• 05Its identity can survive across multiple game worlds.
• 06Its energy may eventually protect property, power territories, or participate in planned sieges.

Enter the Hashimon world Read the Hashimon case study

05 — Portable identity

One identity. Many worlds.

Hashima separates protocol identity from rendering. A client decides how an entity looks; the protocol decides what it is. Universal interoperability is not claimed today — it is the architectural direction being built toward.

06 — Architecture

A layered protocol, not another game database.

Each layer answers a different question, and only the layers below it are assumed.

• L4

  Bitcoin layer

  Blocks, proof of work, timestamps, cryptographic events.

  Block heightDifficultyTimestampsHash events
• L3

  Hashima protocol layer

  Issuance, identity, provenance, ownership, state verification.

  Issuance rulesDeterministic derivationProvenanceOwnershipShare verification
• L2

  Application layer

  Hashimon, property systems, energy systems, collections.

  HashimonPropertyEnergyCollections
• L1

  World and interface layer

  Browser, Luanti, Minecraft, APIs, future engines.

  BrowserLuantiMinecraftAPIs

07 — Property and energy

When scarcity begins to affect the world.

Hashima entities are not intended to remain passive collectibles. Their earned energy can become useful inside persistent public worlds. None of the following is a shipped feature — it is the direction under design.

• R01

  Protecting territory through Hashimon-generated energy fields.

• R02

  Giving defensive structures measurable durability.

• R03

  Requiring attackers to plan and expend resources during a siege.

• R04

  Connecting ownership records with world-level property.

• R05

  Making war and expansion consequences of entities, energy, and coordination.

08 — Manifesto

Protocol principles

1. 01

   Bitcoin before unnecessary chains

   Use Bitcoin as the primary root of objective work and history.

2. 02

   Identity before imagery

   A visual file can be copied. A protocol identity has provenance and state.

3. 03

   Work before arbitrary rarity

   Earned characteristics should arise from verifiable events, not hidden admin decisions.

4. 04

   Determinism before opacity

   Wherever possible, the same inputs should reproduce the same identity and traits.

5. 05

   Portability before platform captivity

   A digital entity should not disappear when one game client changes.

6. 06

   Honesty before decentralization theater

   Clearly distinguish server-authoritative components from independently verifiable protocol state.

09 — Development status

Built in public. Still becoming a protocol.

Filter by what runs today, what is being built, and what is still open research.

• Deterministic Hashimon DNA

  Working today

• Controlled server issuance

  Working today

• Ownership records

  Working today

• Verified SHA-256 shares

  Working today

• Proof-of-work-driven evolution

  Working today

• Browser and voxel-world representations

  Working today

• Hashima API as source of truth

  Working today

• Cross-world identity synchronization

  In active development

• Public property rules

  In active development

• Hashimon-powered territory protection

  In active development

• Improved provenance proofs

  In active development

• Developer-facing protocol documentation

  In active development

• Bitcoin anchoring strategies

  Research direction

• Portable title and ownership records

  Research direction

• Independent state verification

  Research direction

• Energy markets for game worlds

  Research direction

• Open integration standards

  Research direction

• Protocol overviewScope, vocabulary, and what the protocol asserts.
• Identity and issuanceDerivation inputs, issuance rules, determinism.
• Proof-of-work verificationShare submission, validation, and accepted work.
• Ownership and provenanceCustody records, transfers, birth context.
• Hashimon implementationHow the first world uses the protocol today.
• API referenceCurrent authoritative endpoints and payloads.
• Property researchTerritory, energy fields, and siege mechanics.
• RoadmapWhat is being built and what remains open.