Taxes

Taxes are revenue collected from the population of an owned planet. The owner sets a rate from 0 to 100 through Planet administration. A higher rate can build personal wealth without hauling goods, but it reduces production and stock limits and increases the troops needed to prevent a revolt.

Revenue and collection

At the end of a planetary production update, the game adds approximately (tax rate / 1200) × men credits to the planet's tax bank, using its population after that update's item production. The fractional result is discarded when added to the integer balance. For example, a rate of 10 with 100,000 men adds 833 credits on that update. A rate of 0 adds none.

The tax bank is separate from both the owner's spendable cash and the planet's operating cash. The owner must collect taxes through the administration menu to move them into personal cash. Accumulated taxes do not fund planetary production or its cash bonus while they remain in the tax bank.

Cost to production

The rate also multiplies production and each item's calculated stock maximum by 1 − (tax rate / 120). At a rate of 10, this tax factor is about 0.917: roughly 8.3% less output and capacity than at rate 0, all else equal. At the maximum rate of 100, it is about 0.167. Other factors, including environment, resources, and the planet's operating cash, still apply.

Reducing a stock maximum can be more costly than simply producing fewer items. If the revised maximum is below stock already on the planet, the next update clamps the stock down to that maximum. A higher tax rate can therefore discard accumulated goods even when production of those goods is set to zero. See Planetary production for the complete production and capacity calculation.

Revolt risk

After tax is credited, an owned planet compares its defending troops with men × (tax rate / 120) × 0.35. If the population-derived value is greater than the troop count, the game makes a one-in-ten revolt roll on that update. Falling farther below the threshold does not increase the chance on a single roll, but the risk recurs on later updates while the shortage persists. Meeting or exceeding the threshold prevents a revolt through this check.

At rate 10 with 100,000 men, the threshold is about 2,916.67. With 2,916 troops, the planet faces the 10% roll; with 2,917, it does not. That margin must be maintained as the population changes. At rate 0, the threshold is zero, so this tax-driven revolt check cannot trigger.

If a revolt occurs, the planet becomes free. It retains its old troop count divided by a random integer from 2 through 9, rounded down; the other troops are lost. See Classic bug: Revolt troop losses are reversed for the misleading classic revolt report, which ge-next corrected without changing these odds.

Taxes or gold?

Taxation provides a direct, collectible revenue stream without tying up a ship, but the production penalty, lower stock maximums, and possible need for more troops can outweigh the proceeds. Producing gold can yield more personal cash instead: allocate some colonist effort to gold, collect the physical gold from the planet at regular intervals, carry it to Zygor, and sell it. That uses production effort and cargo space and requires a trip and a sale. If gold remains on the planet until its next production update, the game converts it at the configured base price into planetary operating cash, not the owner's personal cash; gold produced during an update is ordinarily available until the following update. Operating cash can itself improve production, so leaving gold in place may also be useful. See Gold for that tradeoff.

Classic numeric limits

Classic stores planetary tax and cash as 32-bit unsigned quantities. Near their limits, unchecked additions can wrap and signed formatting can make a large valid balance appear negative. Gold conversion and sale have related quantity-by-price limits. See Classic bug: Cash and counter wraparound. Carrying extreme quantities of gold is a separate cargo-calculation hazard in classic; see Classic bug: Cargo weight overflow. ge-next adds bounds checks and correct unsigned displays, but these fixes do not remove the ordinary production and revolt tradeoffs above.