Salt Wars Docs

Live Game

Salt Wars is built around a simple repeatable loop: own units, send them to drops, wait for the trip, collect rewards, and use those rewards to push deeper into the game.

The production version is meant to support wallet-connected worms and sticks, live resource balances, drop pools, send transactions, collect transactions, reward reveals, health, healing, knockout state, equipment NFTs, item stats, delegation controls, and community-linked eggs.

New maps and drops should arrive regularly. The front end can help players understand what is happening, but the important gameplay state should either live onchain or be derived from onchain events and contract reads.

Game Loop

Pick a drop

A drop is a place on the map with a package pool behind it. Drop cards show what is left, what kind of rewards are available, and whether there is an enemy or damage risk attached to the route.

Send a unit

The app previews the trip before the player signs. Once the send transaction is confirmed, the unit is locked into an action with a target drop, a route, a start time, and an arrival time.

Wait for the trip

Units can be idle, walking, ready to collect, returning, or knocked out. The frontend should not need to check every frame to know this. It can load the action state, count time forward locally, and refresh only when something important changes.

Collect the reward

When a unit is ready, the collect flow shows the unit progress first, then reveals the reward. The spinner is presentation. The reward itself comes from the claim and the drop pool.

Units

Units are the pieces players use to interact with the map. Worms are live first. Sticks are planned as a separate collection later, using the same broad ideas: ownership, stats, action state, health, inventory, and rewards.

A worm is an NFT owned by a wallet. The roster on the map is filtered from the connected wallet and then enriched with indexed game state. That lets the player see which worms are home, which are walking, which are ready to collect, and which need healing.

Stats affect how a unit behaves. HP controls damage and knockout. Attack matters for enemy interactions. Speed affects travel. HP/day, stamina, capacity, XP rate, and slots give equipment and future systems room to matter without turning the frontend into the source of truth.

XP is shown during collection before the reward reel starts. If XP crosses a level threshold, that should become its own clear moment before the collect flow moves on.

Drops & Rewards

Drops are map zones connected to reward packages. A package can be $DIRT, a worm NFT, equipment, or a future asset type. The UI can make this look exciting, but the package counts should come from the drop and vault state.

The important rule is simple: the app should never display a reward as available if the vault cannot pay it. Drop tables describe what can be won. Vaults hold the assets. Claims allocate packages from the remaining pool.

Economy [WIP - not final]

$DIRT is the first ecosystem token. The initial deployment goal is to put most of the supply into gameplay drops, with smaller allocations for liquidity and team operations.

Fees from token activity, NFTs, and gameplay are designed to feed the game loop first. A portion returns to gameplay drops, a portion burns, and a portion supports the team. These percentages are tunable by contract if the system needs to adjust after launch.

Equipment

Equipment is a separate NFT layer. Items can sit unequipped in a wallet, be equipped to a unit, or move between units through the equipment manager.

Equipment needs to feel different from currency in the UI. A $DIRT reward is mostly an amount. An equipment reward needs an item image, a name, a rarity, and legible stat effects. The collect reel, reward list, inventory, and unit cards should all make that difference visible.

Item effects use bounded stat keys like HP, attack, speed, XP rate, HP/hour, stamina, capacity, and slots. The frontend can preview those effects, but the equip state itself belongs to the item and equipment contracts.

Data Layer

The browser should not hammer chain reads during normal play. It should load the state it needs, animate from that state, and refresh only when the wallet, map, drop, or action changes.

The API exists to make the game fast enough to play. It gives the frontend one compact read surface for wallet units, balances, drop pools, action state, claims, item state, and debug snapshots. It does not replace contract state or decide rewards.

After a wallet transaction, the app can force a narrow refresh for the affected wallet, action, drop, and balances. That keeps the interface responsive while the chain remains the place where consequential state settles.

Contracts

Salt Wars is organized as a set of contracts that separate ownership, map configuration, reward custody, actions, health, equipment, and claims. Production addresses will be published from the live app config when the production deployment is locked.

Coming Next

The next work is about making the live loop richer and easier to read. The map needs to stay fast with real wallets. The collect flow needs to stay readable even with many rewards. The data layer needs to lazy-load and refresh important state instead of treating every frame like a fresh truth check.

After that, the bigger systems can come in: more item families, eggs and projects, future resources like $SALT, deeper unit progression, more maps, and cleaner ownership controls.

The goal is a steady content cadence: new dropped maps, new rewards to farm, and token economics that can refill future drops based on usage, minting, and community activity.

Onchain Status

The intended line is simple: ownership, balances, actions, drops, vaults, claims, health, equipment, and community-linked egg state should be onchain or derived from chain data. The browser and API make that state playable; they should not be treated as the authority for rewards or ownership.

The only pieces that are not fully decentralized in the current production plan are listed below.

FAQ