The game, explained simply

Imagine a shared space board game that never closes.

Players form fleets from their ships, fly between star systems, gather and move resources, build things, trade with other players, fight, and improve their characters. The board and all the important game pieces are recorded on a public blockchain, so anybody can check what exists and what state it is in.

That part of Star Atlas is called SAGE. This guide describes the current generation, SAGE C4, as Atlas Kit sees it on the z.ink public test realm. It does not try to cover every story, product, or future feature in the wider Star Atlas universe.

The whole game in one picture

There are two sides to the game: the player and the world.

You                                         The galaxy
│                                           │
├─ Wallet                                  ├─ Regions
├─ Profile                                 │  └─ Star systems
└─ Character                               │     ├─ Planets
   ├─ Faction                              │     ├─ Asteroids
   ├─ Council Rank and research            │     └─ Starbases
   ├─ Fleets → ships, cargo, movement       └─ Warp-lane connections
   ├─ Starbase storage and crafting habs
   └─ Claim stakes

Your Character is the point where those sides meet. It controls fleets, registers at starbases, owns production facilities, earns progress, and acts for your Profile inside SAGE.

First: who are you?

Star Atlas uses three related identities:

1. Your wallet is the keyring. It can prove that you approve an action.
2. Your Profile is your Star Atlas identity.
3. Your Character is that Profile’s presence inside SAGE.

The distinction matters. A wallet can control a Profile, but the two are not the same thing. A Profile can give different keys different permissions, and a Character—not a wallet—owns the SAGE fleets and progression state.

You can also join one of the three player factions:

• MUD
• ONI
• Ustur

A faction is your side in the galaxy. Factions control territory and assets, hold resources, and have changing relationships with one another. They are not three fixed character classes with a simple permanent bonus.

See You and Factions when you want the technical version.

The galaxy is a map of connected places

The Galia Expanse is divided into regions. Regions contain star systems, and each system is one point on a two-dimensional map.

A system can contain:

• planets;
• asteroids;
• connections to other systems; and
• a shared starbase.

The game interface may draw a beautiful solar system with stars and orbiting bodies, but the gameplay map is simpler: the system has one pair of coordinates, and its bodies belong to it. C4 does not store a separate Star account.

Some systems are joined by warp lanes. Think of them as faction highways. A lane only works when both ends are controlled by the same faction, and using one charges an ATLAS toll based on the starbase level at the gate.

The chain stores gameplay facts such as names, positions, bodies, connections, ownership, and starbase state. It does not necessarily store every piece of presentation. Visual star details, orbital animation, artwork, and system lore blurbs may be generated by the client or come from off-chain content.

See Starmap for the full world model.

Ships become useful when they form a fleet

You may own ship tokens in a wallet, but ships do not fly around SAGE one at a time. You import ships into the game, place them in your state at a starbase, and assign them to a Fleet.

A fleet is one game piece made from one or more ships. Its ships combine into effective fleet statistics such as:

• speed and warp range;
• fuel use and fuel capacity;
• cargo and ammunition capacity;
• mining rate;
• scan power and cooldown; and
• shields, hull strength, weapons, and repair ability.

A ship configuration describes one kind of ship setup. Fleet statistics describe what the assembled group can do together.

Fleets also have separate places for ordinary cargo, fuel, and ammunition. Capacity matters: owning a resource does not mean every fleet has room to carry it.

See Fleets and Cargo.

A fleet is always doing something

A fleet does not have one simple location field. Its location depends on its current state.

It might be:

• docked at a starbase;
• idle at a point in space;
• travelling by warp or subwarp;
• mining an asteroid;
• recovering after destruction; or
• transferring through a Claim Stake operation.

This is a useful way to think about the game: a Fleet is not merely a bag of ships. It is a game piece in the middle of a particular activity.

Movement comes in three main forms:

• Subwarp is slower and uses less fuel.
• Coordinate warp trades more fuel for a much faster trip and is limited by the Fleet’s warp range and cooldown.
• Warp-lane travel jumps between connected systems when faction control permits it, and charges an ATLAS toll.

Starting a journey and arriving are not always the same event. Time can pass before the Fleet reaches its destination, and the completed journey may need to be settled before the Fleet can begin its next activity.

See Warp & subwarp.

Starbases are the ports of the game

A starbase is shared infrastructure in a star system. Fleets dock there, and it can host storage, markets, repairs, upgrades, and production.

The shared starbase and your state at that starbase are different things. The port may exist even when you have never visited it. Before it can hold your cargo or escrowed ships, your Character registers there and gets its own local Starbase Player state.

That local state can contain:

• cargo stored at the base;
• ships waiting to be assigned to Fleets;
• respawn information; and
• upgrades or other player-specific activity.

Cargo stored at a starbase is not cargo aboard a Fleet. Moving goods between them is a real game action, and the Fleet must be docked there.

See Starbases.

The economy is a loop, not a single activity

Most economic play connects several systems.

Mining

Asteroids hold resource deposits. A Fleet travels to an asteroid and extracts selected resources at rates determined by both the deposit and the Fleet. Mining fills cargo over time; it is not one instant “give me ore” button.

Claim stakes

A Claim Stake is longer-term infrastructure on a suitable planet. It begins with a hub, can add buildings for extraction, processing, power, and storage, and produces or consumes resources over time. Buildings need crew, construction takes time, and the Stake needs rent to remain deployed.

Crafting

Crafting has three pieces:

• a recipe says which inputs become which outputs;
• a crafting hab is the facility at a starbase; and
• a crafting process is one recipe running there for a period of time.

Starting a process commits its inputs and crew. Finishing the timer does not automatically collect the result; completion is another game action.

Markets

A local market belongs to a star system. Players post bids and asks for one resource at a particular price and quantity. This means there is no universal price for ore, fuel, or food: prices can differ between systems and change while you are looking at them.

Faction markets are different. They offer goods on faction terms instead of using the player order book.

Together, those activities create the basic economic loop:

travel → gather → transport → process → trade → improve → repeat

See Mining, Claim stakes, Crafting, and Markets.

Scanning and combat add uncertainty

Scanning lets a Fleet search its surroundings. A scan pattern defines what the scan costs and what it might find. A scan can discover useful cargo or loot, or it can find nothing. Fleet stats and cooldowns limit how often and how effectively it can scan.

Combat compares the ships, weapons, defences, and state of opposing Fleets. Attacks can miss or critically hit. Damage usually wears down shields before the hull. Chance is part of the result, so Atlas Kit can explain the inputs and current state but cannot promise who will win.

Combat can leave Loot accounts behind, and hostile actions can interact with the game’s outlaw state. Those are game records of consequences, not merely animations in the client.

See Scanning and Combat.

Progression turns activity into new options

Your Character earns XP in categories such as piloting, mining, crafting, and combat. Council Rank records Character-wide progression alongside those activity-specific levels.

Career levels award career research points and contribute toward Council Rank Renown. Research nodes can require levels and spend those points, ATLAS, and cargo. Unlocking one grants a perk, such as access to larger ships, more Fleet capacity, faster movement, or better crafting.

Progress therefore has two parts:

1. do activities to earn XP and meet requirements;
2. choose research that turns that progress into useful capabilities.

Faction contribution has its own rhythm. Loyalty epochs are time windows in which contribution is recorded. Accumulated ATLAS rewards can sit in a Loyalty bank until claimed. Reward configuration is versioned, so the rules for one epoch are not automatically the rules for every epoch.

See Council Rank, Loyalty points, and Rewards.

What “on-chain” changes about the game

In a traditional online game, one company’s server keeps the authoritative database. In SAGE, important state is stored in blockchain accounts. An account has an address, an owning program, and encoded data.

That gives the game a few unusual properties:

• The state is public to read. You do not need the official interface to inspect a Fleet, market, or system.
• Reads are snapshots. Another player or transaction can change the state after you read it.
• Time-dependent values are often calculated. A travelling Fleet does not need to write a new position every second; its current position can be derived from its journey and the clock.
• Changes happen through transactions. A transaction can cost fees, move assets, and fail if the world changed before it executed.
• Not all content needs to be on-chain. Artwork, interface layout, generated visuals, and lore can live elsewhere while gameplay state remains public.

The chain is the referee for the final result. An app or SDK can check many rules beforehand, but it cannot overrule the game program.

Where Atlas Kit fits

The chain stores compact bytes for programs, not friendly objects for people. Atlas Kit translates those bytes into game-shaped TypeScript.

Its simplest rule is:

• Nouns are reads. Read a Character, Fleet, system, inventory, recipe, or market and receive a validated snapshot.
• Verbs begin as Plans. Moving, transferring, crafting, trading, or fighting first produces an inert description of the intended transaction.

A Plan does not sign or send anything. It lists the signers, accounts, preconditions, expected effects, and warnings. You can inspect and simulate it before a wallet is asked to approve anything. Execution receives an external signer for that one call, submits once, waits for a result, and then the app reads the affected state again.

read → plan → inspect → simulate → sign → execute once → read again

Atlas Kit is therefore a translator and safety boundary. It is not the game client, a wallet, an automatic player, or a promise that every possible C4 instruction already has a friendly planner.

See How Atlas Kit reads the game and How Atlas Kit changes the game.

A first expedition, from beginning to end

Here is one way the pieces can connect for a new player:

1. A wallet creates or controls a Profile.
2. The Profile joins MUD, ONI, or Ustur and registers a Character in SAGE.
3. The Character registers at its faction’s Central Space Station (CSS).
4. Ships and supplies move from the wallet into that CSS’s player storage.
5. The player creates a Fleet, assigns ships, and loads fuel, food, ammunition, or other cargo needed for the trip.
6. The Fleet undocks and travels to a system containing a useful asteroid.
7. After arrival is settled, the Fleet begins mining selected resources.
8. The player later stops mining, returns to a starbase, docks, and unloads the cargo.
9. The resources can be stored, sold in that system’s market, or used by a crafting process.
10. The activity contributes to progression, which can unlock research and make later expeditions more capable.

That is not the only way to play. A player might trade between local markets, develop Claim Stakes, run production, scan, fight, contribute to a faction, or build tools that watch the public game state. But the same pieces keep reappearing: identity, world, Fleet state, cargo, time, and explicit actions.

The small vocabulary worth remembering

Term	Plain-English meaning
SAGE	The Star Atlas game layer where Fleets travel, gather, build, fight, and trade.
C4	The current generation of SAGE, incompatible with older SAGE account layouts.
z.ink	The public test realm where this C4 deployment runs, separate from Solana mainnet.
Profile	Your Star Atlas identity.
Character	Your Profile’s player state inside SAGE.
Fleet	One moving and acting group of ships.
Starbase	A system’s shared port and service centre.
Starbase Player	Your personal storage and state at one starbase.
ATLAS	The in-game currency used by markets, fees, and rewards.
Account	One addressed piece of blockchain state.
Snapshot	A validated view of an account at the time it was read.
Plan	An inspectable, unsigned description of one supported transaction.

When one of those terms becomes important in code, the full glossary and game map are the quickest next stops. To read live state yourself, continue with Your first read.