A world worth building.

Project status

Civiloria is a planned persistent civilization and economic strategy game for browsers, with Solana as its first blockchain. Players will establish cities, organize production, trade through physical logistics, develop champions, and advance through technological eras in a shared world.

This is the first public design white paper, version 0.1, dated 3 October 2026. The project is in design and early development. The website and written specification exist; the complete game and financial programs have not been built or deployed. There is no live token, announced sale date, or playable public world.

The owner has chosen to complete and test the core game before scheduling the token sale and live launch. This paper describes the agreed product direction. Proposed implementation details, balance values, and unresolved decisions are identified where relevant. It is not a promise of player earnings, fixed returns, or token appreciation.

Vision and player experience

Civiloria centers on the long-term satisfaction of building a civilization that remains useful to its neighbors. A city’s location shapes its development options. Its population, technology, tools, and infrastructure determine what it can produce. Players exchange surplus for the goods their own cities need.

A typical session is intended to last around 10 to 20 minutes. Production, construction, travel, and other time-based activities continue while the player is offline, subject to real constraints such as supplies and storage. The world persists rather than resetting through mandatory seasons.

A civilization is a player’s entire empire. Multiple cities share research while maintaining separate population, local production, infrastructure, and logistics. Building a second city is another economic commitment, not simply a duplicate reward source.

The visual target is a detailed, animated 3D world accessible from desktop and mobile browsers. Players should see districts develop from early settlements into industrial, modern, and futuristic cities. Website imagery is concept art, not a screenshot of a completed game.

World and ownership

Geography

Continents contain continuous rivers, forests, mountains, lakes, coastlines, and other features overlaid with a hex ownership grid. Features on a tile determine which districts may be developed there.

Once developed, districts of the same type and level have equal base capabilities. A mine does not receive a permanently superior ore table because of a lucky mineral deposit. Staffing, supplies, research permissions, damage, equipment, and applicable weather still affect actual operation.

Each continent is intended to support at least 50 to 100 cities. Exact dimensions, generation parameters, and terrain overlap thresholds remain to be selected and tested.

Founding and expansion

A city starts with a purchased capital and exclusive rights to buy the rest of a radius-five hex zone. The complete disk contains 91 tiles, including the capital. A valid capital location must allow a full non-overlapping reservation and be at least three hex steps inland from the ocean shore under the final coordinate convention.

Unused exclusive rights last 30 days after the most recent purchase inside the reservation. A qualifying purchase renews those rights. Purchased land never expires.

Players must buy all currently exclusive tiles before making primary purchases beyond the reservation. Expansion must connect to the city and cannot enter another player’s active reservation. If unused rights expire, the owner keeps every purchased tile and may expand into eligible connected unowned land without first buying all the formerly reserved tiles.

Land purchase prices increase with distance from the city’s capital. Radius five is an initial reservation, not a hard maximum city size.

Water and new continents

Lake and shore tiles are purchasable. Pure ocean tiles are purchasable only within two hexes of shore; more distant ocean remains available for navigation but not ownership. Continents are separated by at least ten intervening water hexes.

A new randomized continent can open when every existing continent has at least 80% of its purchasable land owned or actively reserved, or when no legal capital locations remain across existing continents. Owned and reserved coverage is counted once, and expired reservations do not count. Exact proof and accounting mechanisms must be validated on-chain.

Property sales

Players can sell complete cities or individual tiles. Isolated purchases are allowed, but goods and forces still need physical logistics. Sales preserve damage and occupation.

A buyer’s civilization research determines what an acquired district can operate. For example, a medieval civilization buying a modern weapons factory would produce permitted medieval weapons at reduced efficiency until it learns the required technology. Buying the structure does not grant the seller’s research.

The treatment of population, garrisons, unfinished jobs, reservations, and active contracts in a city sale remains an explicit design decision.

Population and production

The capital begins with a marketplace, bank, and town hall. Production districts develop automatically as complete building groups, with cosmetic choices rather than detailed placement of every building.

Each district type has ten meaningful upgrade levels. Upgrades are local to individual tiles and cost materials plus a token fee. Higher levels generally take longer. Redevelopment into another terrain-eligible district is possible; salvage and transition details remain open.

Players allocate civilians to workplaces. Full district output requires the specified workforce, and additional workers do not automatically exceed capacity. A relevant specialist champion can perform the work of multiple ordinary workers.

Production families include mining, hunting, farming, lumber, metalworking, cooking, leather and textiles, medicine, weapons and armor, oil and fuel, and electricity. The final district roster and recipes are still in development.

Resources are renewable. Disasters can create temporary shortages. Mines at the same level share their ore probabilities, with common, uncommon, and rare outcomes. The planning example of 80% stone, 15% copper, and 5% tin for a basic mine is illustrative, not final balance.

Recurring consumption is central to the economy:

• Food supports population growth and productivity. Shortages can increase sickness.
• Medicine is consumed to treat illness or injury, rather than automatically for every healthy villager.
• Tools wear out and require repair or replacement.
• Construction and research consume their defined inputs.
• Armies need equipment, supplies, and replacement soldiers.

Offline production is constrained by workers, inputs, power, tools, damage, and storage. Logging in later must not reroll earlier results or apply new settings retroactively.

Research and progression

Research is shared across every city in a civilization. Players begin with one research slot; later research infrastructure can add slots. Technologies have prerequisites, and advanced units and districts require the appropriate facilities and knowledge.

The proposed broad eras are settlement, medieval, industrial, modern, and futuristic. The pacing target is months to industrial technology and approximately a year to futuristic capability. These are targets to test, not an exact promised schedule for every player.

Players cannot pay to shorten research or construction timers. They can improve their economy through ordinary gameplay, including acquiring inputs, building infrastructure, and developing research capacity.

District level and research era are separate. A refinery starts its own ten-level development when refinery technology becomes available; it does not need to exist as a primitive settlement-era building.

Trade and infrastructure

Markets support player buy orders, sell orders, and recurring supply agreements. The seller is responsible for delivery. There is no planned NPC commodity demand guaranteeing a buyer or token income.

Goods travel through caravans, ships, and later railways and aircraft. Distance creates delivery times, capacity limits, costs, and exposure. Troops move faster than caravans. Cities can construct roads, while tolls can be charged only on owned hexes; detailed access and construction permissions are still being defined.

NPC bandits may take some or all of a shipment. Safe routes and sufficient escorts can reduce NPC bandit risk to zero. That does not remove separate danger from player warfare.

Players may hire game-generated mercenaries for delivery contracts. These are temporary service forces: casualties require no compensation to another player, and survivors leave when the job ends. The proposed restriction is that they cannot become permanent troops, offensive occupation forces, or a source of farmable equipment.

Delivery escrow is the proposed mechanism for reserving payment until the agreed delivery condition is fulfilled. Partial fulfillment, replacement deadlines, refunds, collateral, and route changes require final rules before implementation.

Energy and weather

Oil rigs are dedicated districts that can be placed on any otherwise purchasable tile, including inland and offshore locations. They exclude other primary districts from their tile, while compatible roads and infrastructure may coexist. A separate refinery converts crude oil into usable fuels.

Solar and wind generation occupy dedicated districts. Their output follows local conditions derived from coherent weather systems moving across a continent. Clouds, rain, and wind affect generation; storms disable solar and wind on affected tiles. The world uses a 24-hour day and night cycle.

Once transmission technology is researched, roads automatically support basic electricity transfer. Upgrades can increase capacity and support larger contracts. Electricity can be traded through connected physical road infrastructure between cities and civilizations. It cannot be shipped across oceans by boat; fuel can.

Forecast horizons, generation curves, storage, transmission losses, capacity reservation, and shortage priorities remain technical and balance decisions. Weather history must remain reproducible so late settlement produces the same result as timely settlement.

Warfare and diplomacy

War is intended to be costly, with prepared defenders at an advantage. A declaration starts a 24-hour preparation period, followed by the relevant invasion travel time. Players command grouped forces and standing orders through staged battles rather than controlling individual soldiers in real-time action combat.

New civilizations receive 90 days of attack protection. Declaring war ends that protection immediately. Thereafter warfare is allowed, with a planned bully penalty for attacking a much weaker civilization. The power comparison and numerical penalty remain open.

Attackers can occupy ordinary districts, take their full produced output, damage buildings, and steal exposed materials. They do not acquire title to the land. Stolen production must be transported, and the defender can attack the occupier’s caravans.

The capital cannot be attacked, captured, occupied, damaged, or raided.

The longer occupation lasts, the larger the capped combat advantage available to a force dislodging the occupier. A successful force may liberate the district or become its new occupier. Preserving a continuous occupation history is proposed to prevent friendly transfers from resetting resistance.

Ordinary soldiers may die permanently, become injured, or survive. Eligible surviving troops can return to the workforce after discharge. Champions cannot die.

An offline defender should receive an email when an attacker departs. Notification requires an off-chain service, while standing defense must remain effective even if an email is delayed or never opened.

Each civilization can belong to one formal alliance, with separate trade agreements, access treaties, and nonaggression pacts also allowed. Negotiated peace can include withdrawal, reparations, and a binding truce. Inactive-war closure, alliance authority, and exact treaty timings remain to be specified.

Champions and events

Champions have common, uncommon, and rare rarity. The tavern offers six random named champions each week, the same six for all players. A civilization may own only one of each named champion across all its cities. Already-owned tavern offers are unavailable for purchase.

Paid random recruitment is also planned. If it produces an already-owned champion, the duplicate becomes champion training materials.

Champions gain experience through professions and combat. Specialists can improve a workshop’s effective workforce, while combat champions accompany troops and participate in map-based excursions. One assignment at a time is a proposed implementation constraint.

Defeated champions survive but may be gravely injured for days or longer. Higher-level champions require stronger recovery medicines. They retain their equipped items, which lose durability during battle and take extra loss on defeat.

At zero durability, equipment becomes broken rather than permanently destroyed. Restoring broken equipment requires twice the defined normal repair materials. Exact repair recipes and injury durations remain balance work.

Excursions take place at actual map locations through a separate event layer. They must not block land purchases or development. Public, private, and shared-event reward rules will be defined before implementation.

Individual and team tournaments use entry fees to fund prizes. Brackets are based on overall champion battle power, including level and equipment. Prize escrow is separate from distributable game fees; any additional organizer fee must be explicit.

Token distribution

The planned game token has a fixed maximum supply. Total units, decimals, ticker, token address, and sale price have not been selected.

The developer allocation vests in 24 equal monthly releases over two years. The exact UTC release schedule and anchor will be published before deployment.

SOL received from the presale is split separately: 50% for development and 50% for the SOL side of initial liquidity. The treasury manages the project’s initial liquidity position under published rules.

Sale format, caps, undersubscription handling, unsold-token treatment, refund conditions, and liquidity venue remain open. No sale takes place before the complete core has been built, tested, and prepared for release.

The onboarding model is a free tutorial outside the live economy followed by a paid live-world start. The starter package is priced in a fixed number of tokens that can be revisited. The initial target is around USD 10 to 20 at the chosen starting token price, not a permanent dollar peg.

Banking and governance

Game fee allocation

Primary land purchase receipts and defined game fees are distributable revenue. Seller proceeds, customer deposits, bond principal, unfulfilled trade escrow, liquidity contributions, and prizes reserved for tournament winners are separate assets or liabilities. Only explicit fees on those activities enter the game-fee split.

The bond share goes to the developer during the initial 90-day period. Bonds may be acquired and transferred from launch day, but accrue no fee rewards before global activation. There are no retroactive rewards for this period.

Ordinary deposits

Ordinary deposited token principal is immediately withdrawable. Depositors receive their pool’s share of actual fees according to weekly time-weighted eligible holdings. Withdrawing does not erase reward weight already accrued for the week.

Bonds and two separate clocks

The global launch clock enables bond rewards and bondholder governance 90 days after live-game launch.

An individual redemption clock begins when a bondholder requests redemption. After 90 days, that bond’s principal becomes claimable and the bond stops earning immediately, even if the owner waits to collect it. During the countdown it continues to earn only when global bond rewards are enabled.

Transfer preserves the redemption countdown. Each holder receives the rewards attributable to their own eligible holding period. A bond requested for redemption exactly at launch matures at global activation and earns no bond fees.

Weekly accounting

Ordinary deposits and bonds have separate global reward pools. Eligible rewards are allocated weekly using average stake over time. For a pool with nonzero total eligible weight:

holder reward = weekly pool fees × holder eligible stake-seconds ÷ total eligible stake-seconds

The week containing bond activation counts only post-activation eligible holding time and bond fees. Missing a weekly claim does not forfeit it; historical claims and bounded batch claims are planned.

Principal backing remains separate from rewards and treasury spending. Empty-pool handling, rounding, bond splitting, partial redemption, cancellation, and final data structures must be resolved before bank implementation.

Governance and liquidity

The developer governs initially. Ninety days after live launch, bondholder governance begins, with voting power based on eligible bond holdings. Vested developer-owned bonds follow the same terms as all others. Unvested developer allocation does not independently confer bond votes.

Snapshot mechanics, quorum, proposal thresholds, execution delays, and emergency powers remain open. Program upgrade authority, treasury control, and custody of principal are separate authorities whose treatment must be published.

Players may optionally participate in an external SOL and game-token liquidity pool through the bank interface. That position earns the pool’s applicable swap-fee share and carries its own market exposure. It is not an ordinary deposit or bond. No fixed return is promised for any of these products.

Blockchain architecture

The core requirement is that ownership, resources, production outcomes, combat, and financial balances are enforced on-chain rather than decided by a private authoritative game server.

The proposed implementation records decisions and settlement checkpoints, then applies elapsed activity in bounded transactions. It should not require a transaction for every second, worker, or animated vehicle. Players or other permitted resolvers can advance due mechanical events without the losing side’s consent.

Results must remain consistent whether activity is settled frequently or after a long absence. Claim timing must not reroll resources, extend a matured bond, retroactively improve defense orders, or rewrite old weather.

This does not eliminate infrastructure. Browsers still need static assets and RPC access. Email notifications need an external delivery service. Verified randomness may need a provider. Optional indexers may improve discovery, but cannot authorize outcomes or invent balances.

The randomness provider, account layout, settlement algorithm, transaction budgets, and asset representation are not finalized. Fairness requires committed inputs, bound random requests, verified outcomes, and protection against selective retries. A predictable timestamp or an operator-controlled secret is not sufficient evidence of fair randomness.

Solana is the first chain. Future chain support is possible, but cross-chain ownership and bridging are not part of the initial core. Devnet is the proposed public application testing environment; Solana’s separately named Testnet is focused on network and validator testing.

Development and launch

Development proceeds through design and feasibility, a first city economy, trade and progression, champions and events, warfare and diplomacy, all technology eras, integrated financial systems, and complete visual and operational testing.

The release gates are:

1. Resolve implementation-blocking design decisions and prove the difficult architecture assumptions.
2. Build the complete core on a testing network, including the full progression through futuristic technology.
3. Run public playtesting, economic balance studies, mobile and desktop performance tests, adversarial scenarios, and security review.
4. Publish final token, sale, vesting, treasury, governance, and launch terms.
5. Schedule the token sale and live launch only when the core is ready.
6. At live launch, begin the initial fee schedule and allow bonds to be acquired.
7. After 90 days, activate bond rewards, the normal fee split, and bondholder governance.

A fresh live world without transferable test assets is the proposed starting policy, pending final confirmation. Testing will use accelerated time and seeded scenarios to exercise long progression; those tools must be unavailable in the live deployment.

Open decisions

This document sets the direction without claiming that every implementation detail is settled. Outstanding work includes:

• Final content: district roster, recipes, the full technology graph, champions, equipment, and rewards.
• Balance: worker requirements, food and medicine use, storage, production, prices, military costs, travel speeds, and progression times.
• Ownership edges: city-sale contents, active contracts, protection after transfers, isolated property, and reservation inheritance.
• Conflict: battle stages, bully penalties, resistance caps, occupation permissions, peace, and treaty timing.
• Finance: supply denomination, sale terms, vesting timestamps, weekly accounting boundaries, empty pools, rounding, and governance rules.
• Technology: verifiable randomness, bounded offline settlement, data availability, world expansion proofs, and account costs.
• Delivery: browser performance targets, graphics assets, notification services, RPC providers, deployment controls, and recovery procedures.

Changes to confirmed economic or ownership rules should be explicit and documented. A completed specification is a foundation for testing, not evidence that a system has already passed it.

Technical references

The project’s design is original planning material. These official sources support the platform facts above, not claims about an already-working Civiloria implementation:

• Solana clusters and testing networks
• Solana accounts
• Solana programs
• Solana transactions
• Solana RPC
• Solana token authority changes

Platform details should be rechecked when implementation choices are made. This white paper will evolve as prototypes, playtesting, and explicit design decisions provide evidence.