πŸš€ TOKEN_LAUNCH β€” Canonical Birth Conditions

This document defines how Solum enters existence.

It does not describe marketing. It does not announce dates. It does not promise outcomes.

It defines the mechanical, auditable conditions under which the Zipvilization experiment begins.


🌐 Where the Launch Happens

Solum is launched exclusively on:

  • Network: Base
  • DEX: Aerodrome (V2-style pool)

There is no multi-chain launch. There is no alternative pool. There is no secondary genesis.

If Solum does not exist in this environment, it does not exist at all.


⏳ No Fixed Launch Date

There is no predetermined launch date.

The pool will be created only when:

  • the contract is final
  • the documentation is complete
  • the mechanics are publicly auditable
  • early participants have had time to understand and critique the system

Speed is not a goal. Correctness is.


πŸ’§ Full-Supply Pool Seeding

At launch, 100% of the Solum supply is seeded into the pool.

The initial liquidity is intentionally minimal (approximately 100€ worth of ETH, adjusted at launch time).

This design choice is deliberate.

Why this matters

  • There is no artificial scarcity at genesis
  • There is no privileged pre-allocation
  • Price discovery is emergent, not engineered
  • Access is mechanical, not discretionary

The result is an entry condition where participation is structurally inexpensive, not selectively granted.

Early access is not free β€” it is mechanically accessible.


🧱 The Protected Launch Phase (First 48 Hours)

The first 48 hours after trading is enabled are treated as the most fragile phase of the system.

During this period, additional protections apply.

These protections are on-chain rules, not policies.


πŸ›’ Buy-Side Restrictions (48h Only)

During the protected phase:

  • Only BUY transactions are restricted
  • SELL transactions are always allowed
  • Transfers remain unrestricted

Buy constraints:

  • Maximum per buy: MAX_TX
  • Cooldown per wallet: 60 minutes
  • Cooldown applies only to BUY actions

This ensures:

  • no rapid accumulation
  • no high-frequency dominance
  • equal temporal access per wallet

Participation is paced. Not blocked.


πŸ”“ Whitelist Priority Access (First 60 Minutes)

Within the protected phase, an additional rule applies:

  • Whitelisted wallets have priority access during the first 60 minutes
  • This priority does not change:
    • max transaction size
    • cooldown rules
    • wallet limits

Whitelist access means:

  • the right to participate early
  • not the right to accumulate more

This distinction is fundamental.


🧭 After the Protected Phase

Once the first 48 hours pass:

  • buy cooldowns are removed
  • launch-specific restrictions expire
  • the contract behaves according to its permanent rules

Nothing is toggled manually. Nothing is extended. Nothing is negotiated.

Time alone resolves the phase.


βš–οΈ Design Rationale

These mechanics exist to protect:

  • early coherence
  • observational clarity
  • resistance to launch chaos
  • meaningful initial participation

They are not defensive measures. They are structural constraints.

They do not favor insiders. They do not punish activity.

They enforce temporal fairness.


πŸ”’ Canonical Status

All rules described here:

  • are implemented on-chain
  • are enforced automatically
  • are time-bound
  • are publicly auditable

If a behavior is not allowed by the contract, it does not exist during launch.

If a rule is not described here, it should not be assumed.


πŸ“Œ Final Note

Token Launch is not an event.

It is the moment when:

  • abstract rules begin producing history
  • territory becomes measurable
  • participation becomes visible

Nothing more. Nothing less.