🧭 Project

This folder defines the foundational posture of Zipvilization.

It does not describe how the system is implemented. It defines why the project exists, how it enters reality, and under which constraints it operates.

Everything here is canonical, public, and intentional.

If something is not stated in this folder, it must not be assumed elsewhere.

📂 What This Folder Is

The project folder contains the documents that define:

  • the origin of Zipvilization
  • the conditions of its birth
  • the logic of its launch
  • the role of early participants
  • the limits under which the project operates
  • the posture toward communication, trust, and responsibility

This folder exists before code.

It is the layer where intent is fixed so that implementation cannot drift.

🧬 Origin — What kind of world is this?

LORE_GENESIS.md

This document defines the foundational narrative frame of Zipvilization.

It answers:

  • what “civilization” means in this context
  • where this world exists
  • how territory and history emerge from abstract activity

There are no characters at the beginning. There is no fiction imposed.

Lore here is interpretation of reality, not fantasy.

🚀 Birth — How does the system enter reality?

TOKEN_LAUNCH.md

This document defines the conditions of existence for Solum.

It explains:

  • where the token is launched
  • why there is no fixed launch date
  • why initial access is mechanically cheap
  • how the first moments are structured to reduce distortion

Token Launch is not a marketing event.

It is the transition from potential to execution.

🔓 First Participation — Who enters first, and why?

EARLY_ACCESS.md

This document defines the early participation phase.

It explains:

  • why uncontrolled randomness at birth is dangerous
  • why early understanding matters more than speed
  • why the mechanism is intentionally not finalized yet

Early Access is not a reward.

It is a structural stabilizer.

🔐 Limits & Responsibility — What is explicitly assumed and protected?

ASSUMPTIONS.md

This document lists the explicit assumptions under which Zipvilization operates.

It defines:

  • what the project assumes about users, markets, and environments
  • what it does not attempt to solve or guarantee

Nothing outside these assumptions is implied.

SECURITY.md

This document defines the security posture of the project.

It clarifies:

  • what is protected by design
  • what is intentionally left unprotected
  • why no system-level guarantees are claimed

Security here is about honesty of scope, not absolute safety.

🏛️ Resources — How does the project sustain itself?

TREASURY.md

This document defines the role of the treasury.

It explains:

  • why the project starts with minimal economic investment
  • why access for colonists is almost free
  • why resources are still required to grow

It makes explicit that:

  • the human factor has no special privilege
  • no speculative advantage is claimed
  • funds exist to sustain development, not extract value

🧾 After Launch — What guarantees follow existence?

POST_LAUNCH_GUARANTEES.md

This document defines the post-launch commitments.

It covers:

  • liquidity handling principles
  • ownership and control posture
  • transparency about future decisions

It does not promise outcomes.

It commits to explicit decision-making.

📡 Communication — How meaning is shared

COMMUNICATION.md

This document defines the communication posture of Zipvilization.

It explains:

  • why there is no Discord or Telegram
  • why GitHub is the canonical source of truth
  • why other platforms exist for explanation, not authority

Communication exists to clarify, not to negotiate reality.

🧱 How These Documents Work Together

These files define the conditions of existence:

They precede:

Without this folder, everything else lacks context.

🔒 Canonical Status

All documents in this folder are:

  • public
  • versioned
  • auditable
  • binding at the level of intent

If something is not stated here,

it is not part of the project’s promise.

📌 Final Note

This folder does not describe features.

It defines responsibility.

Before code executes, before tokens move, before the world becomes visible,

the project must know

what it is doing and why.

This is that place.