Smart Contract
Zipvilization begins with an idea.
Solum begins with a contract.
The Smart Contract is the blockchain foundation that defines and executes the technical rules governing Solum.
Here we stop speaking primarily in metaphors.
We speak in blockchain terms.
Token.
Supply.
Balances.
Transfers.
Taxes.
Pool.
Burn.
Transaction limits.
Wallet limits.
These are not narrative concepts.
They are technical mechanisms.
Only after understanding what they do should we ask what they mean inside Zipvilization.
Blockchain first.
Interpretation second.
What the Smart Contract does
The contract establishes the foundational behavior of Solum.
At a high level, it defines or participates in the execution of:
- the finite token supply,
- token balances,
- transfers,
- transaction rules,
- wallet limits,
- Taxes,
- the Pool,
- Burn,
- and Fair Access mechanisms.
These mechanics form the blockchain substrate beneath the world.
They must be understandable independently of the narrative interpretation built above them.
A developer should be able to ask:
What does the contract do?
and receive a technical answer.
A Colonist should then be able to ask:
What does that mean inside Zipvilization?
and follow the relationship upward.
Two ways to read the same system
Throughout this section, we preserve two parallel views.
| Blockchain | Zipvilization |
|---|---|
| Solum token | Territorial substrate |
| Token supply | Finite world |
| Holder | Colonist |
| Balance | Controlled Solum |
| Pool | Dormant Land |
| Burn | Permanent Nature |
| Tax | Economic mechanism |
| Transaction limits | Fair Access constraints |
| Wallet limits | Concentration constraints |
The left side describes the technical mechanism.
The right side describes its meaning inside the world.
Neither should replace the other.
The interpretation does not rewrite the contract.
The contract gives the interpretation something real to stand on.
Solum
Solum is the blockchain asset at the center of the contract.
Its fundamental territorial equivalence is:
1 Solum = 1 m²
This relationship gives the token a fixed unit of interpretation inside Zipvilization.
At blockchain level, Solum remains a fungible token.
It can exist as balances associated with addresses.
It can move through transfers according to contract rules.
It can be affected by Taxes.
It can remain inside the Pool.
It can be Burned.
Inside Zipvilization, those technical states become part of the geography of the world.
Supply
Solum has a finite total supply.
The supply is not intended to expand through ongoing minting.
This matters technically before it matters conceptually.
A finite token supply establishes a finite quantity of Solum that can exist under the canonical contract design.
Inside Zipvilization, that becomes something larger:
a finite territorial world.
But the technical question comes first:
How much Solum exists?
Can more be created?
What happens when Solum is Burned?
How should circulating and non-circulating states be understood?
Those questions belong to Supply.
Balances
At blockchain level, addresses hold balances.
That statement does not require a world interpretation.
A balance records the quantity of Solum associated with an address according to the contract state.
Inside Zipvilization, that balance can acquire territorial meaning.
The same state can therefore be read as:
Blockchain
Address holds X Solum.
Zipvilization
Colonist controls X m² of Solum.
The technical balance remains the underlying fact.
The territorial interpretation follows from the canonical relationship between Solum and the world.
Transfers
Solum can move.
At blockchain level, a transfer changes balances according to the rules of the contract.
That movement may also interact with:
- Taxes,
- transaction limits,
- wallet limits,
- Pool mechanics,
- and other contract conditions.
Inside Zipvilization, transfers can change the distribution of controlled territory.
But the contract itself does not need to understand the visual appearance of a City or the biological meaning of Zips in order to execute a transfer.
This separation is intentional.
The contract moves Solum.
The world interprets the consequences.
Taxes
Taxes are a fundamental part of the Solum contract architecture.
They should therefore be treated as a first-class blockchain mechanism.
The important questions are technical:
What operations are taxed?
What rate applies?
How is the amount calculated?
Where does the collected Solum go?
When can the Tax change, if at all?
What exemptions exist, if any?
What limits constrain the mechanism?
What contract state records it?
Only after those questions are answered should higher layers interpret the economic consequences.
Taxes may later interact with:
- territorial economics,
- redistribution,
- States,
- Kingdoms,
- Chapters,
- and other civilizational systems.
But those future interpretations must not obscure the mechanism that actually exists.
The Pool
The contract can contain or interact with Solum that has not yet entered ordinary Holder distribution.
Technically, this is a Pool.
We should call it that here.
The Pool has:
- an amount,
- a technical purpose,
- rules,
- inputs or outputs where defined,
- and a relationship with the finite supply.
Inside Zipvilization, the same Solum is interpreted as:
Dormant Land.
Land that exists.
Land that belongs to the finite world.
But land that has not yet entered active colonization.
The technical mechanism is the Pool.
The world interpretation is Dormant Land.
Pool is the mechanism.
Dormant Land is the meaning.
→ Explore Pool
→ Discover Solum
Burn
Burn is another blockchain mechanism that should be described without euphemism.
When Solum is Burned according to the contract mechanism, it becomes permanently unavailable under the corresponding technical rules.
This is an irreversible supply event.
The contract does not need a metaphor to execute it.
Inside Zipvilization, however, that irreversibility has a powerful interpretation:
Burned Solum becomes Permanent Nature.
This gives us another direct parallel:
Blockchain
Burn
Zipvilization
Permanent Nature
The technical operation comes first.
The environmental meaning follows.
Fair Access
A finite asset can concentrate.
A public launch can be dominated.
Automated systems can attempt to acquire large positions rapidly.
Large wallets can change the distribution of a finite world before broad participation has time to develop.
The contract can respond through explicit technical constraints.
These may include mechanisms such as:
- maximum transaction limits,
- maximum wallet limits,
- launch-phase restrictions,
- dynamic limits,
- or other canonical anti-concentration rules.
We call the broader objective:
Fair Access.
But this section must explain the mechanisms, not merely the intention.
Fairness as a principle is conceptual.
Limits in a contract are technical.
→ Explore Fair Access
→ Read the Principles
The contract does not create civilization
The Smart Contract is foundational.
It is not the entire world.
It does not need to contain every future mechanic of civilization.
The Solum contract can establish:
- supply,
- ownership state,
- transfer behavior,
- Taxes,
- Pool behavior,
- Burn,
- and access constraints.
Higher layers can then interpret that state.
SolumWorld can determine world consequences.
SolumTools can expose signals.
SolumView can render state.
Chapters can introduce additional systems.
Civilization can emerge from the interaction between those systems and participants.
The contract provides physics.
It does not write history.
→ Explore SolumWorld
→ Explore the Chapters
The contract does not render the world
A blockchain contract does not need to draw a Farm.
It does not need to decide whether a City should appear blurred.
It does not need to generate mountains.
It does not need to visualize Permanent Nature.
Those responsibilities belong elsewhere.
The separation is deliberate.
Smart Contract
executes blockchain mechanics.
↓
Blockchain state
records the result.
↓
SolumWorld
derives canonical world state.
↓
SolumView
renders the world.
This architecture prevents visual design from becoming blockchain authority.
The contract does not invent meaning
The reverse boundary also matters.
The contract may know that tokens were Burned.
It does not need to know that we call the corresponding world state Permanent Nature.
The contract may know that an address holds Solum.
It does not need to know that the Atlas calls the participant a Colonist.
The contract may know the Pool balance.
It does not need to describe barren land waiting for civilization.
Those meanings belong to Zipvilization.
This keeps the technical layer clean.
Blockchain mechanics should remain blockchain mechanics.
Technical truth and world truth
The two layers must remain connected without becoming confused.
Consider Burn.
The technical truth may be:
A defined amount of Solum was irreversibly removed according to the Burn mechanism.
The world truth may be:
The corresponding territory became Permanent Nature.
The second statement depends on the first.
The first does not depend on the second.
That asymmetry matters.
The same logic applies throughout the architecture.
Blockchain state
↓
canonical interpretation
not:
desired interpretation
↓
invented blockchain state
The contract is measurable
Because the contract operates publicly on blockchain state, many of its mechanics can become observable.
Potential signals include:
- total supply,
- balances,
- Pool balance,
- Burned Solum,
- Tax flows,
- transfer activity,
- wallet concentration,
- and limit state.
SolumTools can expose these signals.
Metrics can present selected measurements.
This creates a public path from execution to observation.
Contract
↓
State
↓
SolumTools
↓
Metrics
→ Explore SolumTools
→ Explore Metrics
The contract should be inspectable
A blockchain system should not depend entirely on our description of it.
The Atlas explains the intended architecture.
The deployed contract ultimately provides technical evidence of its actual behavior.
Where appropriate, participants should be able to inspect:
- the contract address,
- verified source code,
- network,
- token parameters,
- relevant functions,
- events,
- and current state.
The Repository can provide deeper technical context.
Do not trust a description when the mechanism can be verified.
Documentation and deployed code must agree
The Smart Contract section describes the canonical technical architecture.
But documentation can become outdated.
Code can change before deployment.
Deployment can reveal differences.
Therefore an important rule applies:
Never silently resolve disagreement between documentation and deployed code.
If a discrepancy exists, it should be identified.
Then corrected through the appropriate process.
Artificial Intelligence should follow the same rule.
It should not merge two contradictory sources into a plausible third answer.
→ Explore Artificial Intelligence
Immutability and change
Blockchain systems force us to distinguish between rules that can change and rules that cannot.
For every important contract mechanism, the technical documentation should eventually make clear:
- whether it is immutable,
- whether it is configurable,
- who or what can change it,
- under what conditions,
- within what boundaries,
- and how changes become observable.
This is especially important for mechanisms such as:
- Taxes,
- limits,
- Pool behavior,
- exemptions,
- and administrative functions.
“Decentralized” is not a substitute for documenting authority.
We should state what the contract actually permits.
No hidden magic
A good Smart Contract section should allow a technically literate reader to reconstruct the important behavior without depending on narrative language.
For every mechanism, we should eventually be able to answer:
What is it?
What state does it use?
What triggers it?
What does it calculate?
What changes?
Where does value move?
What are the limits?
Can it be changed?
Who can change it?
What events expose it?
What does the resulting state mean inside Zipvilization?
That is the standard for this section.
Smart Contract architecture
The contract section is divided into focused technical areas.
Supply
How much Solum exists, why the supply is finite, and what can or cannot change it.
→ Supply
Taxes
How Tax works at contract level: calculation, collection, destination, boundaries, and technical behavior.
→ Taxes
Pool
How non-distributed Solum is held and how the Pool participates in the contract architecture.
→ Pool
Burn
How Solum is irreversibly removed and what that operation changes technically.
→ Burn
Fair Access
How transaction limits, wallet limits, launch constraints, and related mechanisms restrict concentration and structure access.
Each page begins with blockchain mechanics.
Each can then connect those mechanics back to the world.
From contract to world
The entire relationship can be summarized as:
Supply
↓
finite Solum
↓
finite world
Balance
↓
controlled Solum
↓
Colonist-controlled territory
Pool
↓
Solum awaiting distribution
↓
Dormant Land
Burn
↓
irreversibly unavailable Solum
↓
Permanent Nature
Taxes
↓
contract-level economic flows
↓
economic consequences for Zipvilization
Access limits
↓
technical concentration constraints
↓
Fair Access
The blockchain and the world are not competing explanations.
They are different layers of the same architecture.
Read this section technically
If you are a developer, auditor, or technically curious participant, begin here.
Do not assume that a world metaphor describes exact contract behavior.
Follow the mechanism.
Read the numbers.
Read the rules.
Read the boundaries.
Then inspect the deeper technical source where necessary.
If you are approaching from the world instead, the same paths work in reverse.
Start with Dormant Land.
Reach the Pool.
Start with Permanent Nature.
Reach Burn.
Start with a Colonist.
Reach a Holder and balance.
Start with finite territory.
Reach Supply.
That bidirectional structure is intentional.
For Artificial Intelligence
An AI navigating this section should apply a strict hierarchy.
When answering:
What does the blockchain do?
prefer the technical contract definition and verified implementation.
When answering:
What does that mechanism mean inside Zipvilization?
follow the canonical world interpretation.
Do not replace one with the other.
Do not describe metaphor as bytecode behavior.
Do not describe technical state without acknowledging world meaning when that meaning is relevant.
Mechanism first.
Interpretation second.
Relationship explicit.
Follow the Smart Contract
How much Solum exists?
→ Supply
How do Taxes work?
→ Taxes
Where does Dormant Land exist technically?
→ Pool
How does Solum become permanently unavailable?
→ Burn
How is concentration constrained?
What is Solum inside the world?
→ Solum
How is blockchain state interpreted?
How can contract state be observed?
How is it measured publicly?
→ Metrics
Where is the implementation?
Blockchain underneath civilization
Zipvilization can become visually rich.
Its Territories can mature.
Zips can emerge.
Cities can develop.
States can organize.
Kingdoms can compete or cooperate.
Economies can form.
Political structures may appear.
A civilization may eventually become difficult to understand as a simple token system.
That is precisely why the foundation must remain clear.
Underneath all of that complexity there are operations that should never require mythology to explain.
A balance changed.
A transfer occurred.
A Tax was collected.
Solum remained in the Pool.
Solum was Burned.
A limit applied.
The supply remained finite.
Those facts are simple.
Their consequences may not be.
Zipvilization begins when we allow both truths to coexist:
The blockchain should be technically boring enough to verify.
What emerges from it should be interesting enough that we cannot predict the ending.
→ Return Home
→ Continue to Supply
→ Open the Repository