Contract Source
Do not trust our description of Solum.
Read the contract.
Then verify that our description is true.
This directory contains the exact Solidity source used as the primary technical reference for the Solum Tokenomics documented throughout this Atlas.
The source is published so that any participant, developer, auditor, researcher, or Artificial Intelligence can inspect the implementation directly.
Documentation explains.
Source code exposes.
Blockchain execution proves.
Transparency requires all three.
Primary Source
File
Solum.sol
Language
Solidity
Token
Solum
Symbol
SOLUM
File size
28,345 bytes
Source lines
783
SHA-256
969d7d9c47055c16d8a0842d736112ccb93bf43f9ebf9574b78b8ccd42d86beb
→ Open the exact Solidity source
Integrity
The SHA-256 hash above identifies the exact source file used as the reference for this documentation.
If even one byte changes, the hash changes.
That includes changes to:
- Solidity code,
- comments,
- spaces,
- indentation,
- line endings,
- or any other byte in the file.
Therefore the hash provides a simple integrity checkpoint.
Reference SHA-256
969d7d9c47055c16d8a0842d736112ccb93bf43f9ebf9574b78b8ccd42d86beb
A file presented as this canonical source should reproduce that hash exactly.
The source is not rewritten for the Atlas
The Solidity file should remain exactly as provided.
The Atlas does not:
- reformat it,
- simplify it,
- rewrite comments,
- normalize indentation,
- insert documentation,
- remove documentation,
- alter whitespace,
- or create a cleaner narrative version.
The purpose of this page is not to improve the source.
It is to expose it.
The source should remain source.
Explanation belongs in the surrounding Tokenomics documentation.
Why the contract is published here
Tokenomics makes many precise claims.
For example:
- Initial Supply is 100 trillion SOLUM.
- Solum uses 18 decimals.
- BUY, SELL, and TRANSFER have different fee structures.
- Burn reduces actual token Supply.
- Reflection does not mint additional SOLUM.
- MAX_TX is 10 billion SOLUM.
- Initial Max Wallet is 30 billion SOLUM.
- Max Wallet evolves through contract time.
- Launch includes a whitelist window and BUY cooldown.
- Fees can decrease but not increase through the documented fee mechanism.
- Treasury changes require a timelock.
- SwapBack parameters remain administratively configurable.
- LP tokens generated by automated liquidity addition go to the current owner.
- No post-deployment mint function is provided.
Those statements should not depend only on our description.
The reader can inspect the source that produced them.
Documentation and source have different roles
The Tokenomics documentation exists because Solidity is not the best interface for every Human.
The source exists because prose should never become a substitute for implementation.
Therefore:
Documentation
Answers:
What does this mechanism do?
Why does it matter?
How does it interact with other mechanisms?
What does it mean inside Zipvilization?
Source
Answers:
What is actually implemented in this reference contract?
The two should agree.
But they are not interchangeable.
Source before interpretation
When interpreting Solum, the preferred causal order is:
Solidity implementation
↓
contract behavior
↓
blockchain state
↓
canonical interpretation
↓
Zipvilization
This order matters.
The narrative must not be used to invent contract behavior.
For example:
Zipvilization says:
Burn becomes Permanent Nature.
That does not tell Solidity how Burn works.
The Solidity implementation first determines whether Burn actually reduces SOLUM Supply.
Only then can the canonical world layer interpret that irreversible state as Permanent Nature.
If documentation and source disagree
A disagreement should never be silently reconciled.
If documentation says one thing and the source appears to say another:
- identify the discrepancy;
- inspect the exact source;
- inspect the relevant specification;
- determine whether documentation is outdated, incorrect, or describing a different version;
- correct the appropriate layer explicitly.
Do not invent a compromise explanation.
Conflict must be surfaced.
Not smoothed over.
Source is not deployment
This distinction is critical.
A Solidity source file can describe an implementation.
It does not by itself prove that this exact implementation is deployed on a blockchain.
Therefore this page distinguishes:
Source identity
from:
Deployment identity
A complete production verification chain eventually requires both.
Deployment Identity
The following information should be added once the canonical Solum deployment exists and has been verified.
Network
To be published after canonical deployment.
Contract Address
To be published after canonical deployment.
Deployment Transaction
To be published after canonical deployment.
Deployment Block
To be published after canonical deployment.
Deployment Timestamp
To be published after canonical deployment.
Verified Explorer Source
To be published after source verification.
Repository Commit
To be published for the exact deployment source state.
Until those values exist and are verified, they should remain explicitly unresolved.
Not yet deployed or not yet published is better than invented deployment data.
The verification chain
Once deployed, the complete verification path should become:
Atlas
explains the architecture.
↓
Solum.sol
provides the reference implementation.
↓
SHA-256
identifies the exact source artifact published here.
↓
Repository commit
identifies the version history.
↓
Deployment transaction
identifies the creation event.
↓
Contract address + network
identify the live instance.
↓
Verified explorer source
links source and deployed bytecode where supported.
↓
Blockchain state
shows what the contract is doing now.
This is the level of traceability Zipvilization should aim for.
A contract can change state without changing source
Even when source code remains identical, live contract state can change.
For example:
- fees can decrease,
- Treasury can change,
- whitelist state can change,
- Fee Exempt addresses can change,
- Limit Exempt addresses can change,
- SwapBack configuration can change,
- ownership can change,
- totalSupply() can decrease through Burn,
- balances can change,
- launch state can progress.
Therefore:
Source tells us what can happen.
Live state tells us what is happening now.
A current-state answer should not be derived from source alone when live state is required.
Initial configuration is not necessarily current configuration
The contract source defines Genesis values.
Tokenomics documents them.
But mutable values may evolve after deployment.
For example:
Initial SELL fee = 10%
does not guarantee:
Current SELL fee = 10%
if a valid reduction has occurred.
Likewise:
Initial Treasury
does not guarantee:
Current Treasury
and:
Initial SwapBack parameters
do not guarantee:
Current SwapBack parameters.
This distinction is fundamental for Artificial Intelligence.
Artificial Intelligence rules
An AI using this source should distinguish four questions.
What can the contract do?
Inspect the source.
What was the initial configuration?
Inspect constructor and initialization logic.
What is the current state?
Read the deployed contract.
What does the resulting state mean in Zipvilization?
Follow the canonical Atlas.
These are four different operations.
AI must not infer deployment
Possessing Solum.sol does not establish:
- a live contract address,
- a network,
- a deployment block,
- current owner,
- current Treasury,
- current fees,
- current Supply,
- current whitelist,
- current exemptions.
Those require deployment evidence.
Until such evidence exists, an AI should say:
Reference source available. Deployment state not established here.
That is a correct answer.
AI must not silently modify the source
If an AI reproduces or processes this contract for auditing, formatting, explanation, compilation, or analysis, it should distinguish:
original source
from:
derived or transformed copy.
A formatted copy is no longer byte-identical to the reference source if formatting changes bytes.
The original SHA-256 should never be attached to a modified copy.
Auditable does not mean audited
Publishing source code makes independent inspection possible.
It does not mean the contract has automatically received a professional security audit.
These terms must remain separate.
Auditable
The source is available for inspection.
Audited
A defined version has been reviewed by a named auditor under a documented scope.
If a professional audit is later completed, the Atlas should publish:
- auditor,
- report,
- date,
- exact source version,
- findings,
- remediations,
- unresolved findings,
- deployment correspondence.
Until then:
public source ≠ professional audit
Verified does not mean secure
Likewise:
source verified
does not mean:
security verified.
Explorer verification can demonstrate correspondence between published source and deployed bytecode under the explorer’s verification process.
It does not prove:
- absence of vulnerabilities,
- sound economic design,
- safe key management,
- safe LP custody,
- correct Treasury operation,
- or risk-free market behavior.
Security requires separate analysis.
Transparency includes uncomfortable facts
Publishing the complete source means publishing the complete trust model.
Not only the features that are easy to market.
The contract can be inspected to understand facts such as:
- owner authority exists,
- Fee Exempt state is configurable,
- Limit Exempt state is configurable,
- SwapBack configuration is mutable,
- SwapBack can be paused,
- Treasury can change,
- LP tokens go to the current owner,
- ownership can be transferred,
- fees can be reduced,
- fees cannot be increased through the documented reduction mechanism,
- MAX_TX has no documented setter,
- no post-deployment mint function is provided.
Transparency is not selecting the comfortable half.
The mechanism is shown whole.
Trust boundaries remain visible
A reader should be able to move directly from any important trust question to the relevant documentation.
Who can change what?
What are the main risks?
→ Security
How do fees work?
→ Fees
How do Burn and Reflection work?
Who receives Liquidity and Treasury value?
What can happen during automated fee processing?
→ SwapBack
The Solidity source sits beneath all of those explanations.
Canonical source identity
For this Atlas reference, the source artifact is identified by:
Filename
Solum.sol
SHA-256
969d7d9c47055c16d8a0842d736112ccb93bf43f9ebf9574b78b8ccd42d86beb
Size
28,345 bytes
Lines
783
These values identify the file provided as the contractual reference used to build this Tokenomics documentation.
If a future source version intentionally replaces it, that replacement should receive:
- a new source identity,
- a new hash,
- explicit version documentation,
- and a clear explanation of what changed.
The previous source should not silently become a different file under the same integrity claim.
Version changes must be explicit
If Solum changes before canonical deployment:
do not overwrite history invisibly.
Record:
- previous source hash,
- new source hash,
- reason for change,
- affected Tokenomics documentation,
- affected security assumptions,
- relevant commit.
If Solum changes after deployment through a new contract or migration:
the distinction becomes even more important.
A new implementation is not automatically the old contract with updated prose.
It is a new technical event.
The Repository remains the technical home
This Atlas exposes the exact source because Tokenomics should be auditable from the public documentation path.
The broader Repository remains the technical home for:
- development structure,
- related contracts,
- tests,
- deployment scripts,
- interfaces,
- technical notes,
- version history,
- and implementation context.
Therefore:
Atlas exposes the evidence.
Repository preserves the engineering context.
Contract Source in one view
Reference artifact
Solum.sol
Integrity
SHA-256:
969d7d9c47055c16d8a0842d736112ccb93bf43f9ebf9574b78b8ccd42d86beb
Purpose
Independent inspection of the exact Solidity source used as the reference for Tokenomics.
Modification policy
Do not modify the reference artifact.
Documentation role
Explain behavior.
Source role
Expose implementation.
Deployment role
Prove which implementation is actually live.
Blockchain role
Record current and historical state.
Canonical world role
Interpret valid blockchain state inside Zipvilization.
Follow the evidence
Read the exact source
Understand the full economic architecture
Understand administrative authority
Understand security boundaries
→ Security
Understand foundational rules
Understand the world interpretation
Open the technical Repository
Verify us
Zipvilization asks the reader to enter an unusual world.
Solum becomes land.
A Holder becomes a Colonist.
Pool-held SOLUM becomes Dormant Land.
Burned SOLUM becomes Permanent Nature.
Blocks become meaningful time.
Zips become population.
Eventually, civilization may emerge.
Those ideas require explanation.
But the contract underneath them should not require belief.
You can read it.
You can hash it.
You can compile it.
You can inspect the permissions.
You can inspect the mathematics.
You can inspect the fees.
You can inspect Burn.
You can inspect Reflection.
You can inspect the limits.
You can inspect Launch.
You can inspect SwapBack.
And once deployed, you should be able to compare all of that against the contract actually running on-chain.
That is the standard.
Not:
Trust us.
But:
Here is what we say.
Here is the source.
Check us.
→ Open Solum.sol
→ Return to Tokenomics
→ Open the Repository