Skip to content

Logistics Contracts

This page explores how player-created delivery requests could work as the core of the trading playstyle.

It does not describe final game behavior. It captures the current direction and unresolved design questions.

Goal

The goal is to give traders a concrete gameplay loop that does not depend on static markets.

Instead of scanning price lists across regions, a trader should be able to:

  • browse open delivery requests posted by other players
  • evaluate which contracts are worth accepting given current routes and risks
  • fulfill contracts by physically transporting goods to the destination
  • collect payment automatically when conditions are met

This creates direct player-to-player dependency and gives trading a clear purpose connected to the rest of the game.

Core Problem

Trading needs a reason to exist that is not speculation or spawn-location advantage.

Logistics contracts solve this by anchoring trade to actual demand: colonies needing supplies, alliances moving war materiel, industries requiring inputs for production.

If players must post real requests and offer real payment, the trade system becomes player-driven and the value of reliable carriers becomes concrete.

Working Directions

Contract posting

One strong direction is that any player can post a delivery request by specifying:

  • what goods are needed
  • what quantity
  • where they must be delivered
  • how much is offered as payment

The requester deposits payment into escrow at posting time.

This prevents abuse: a trader who fulfills the contract can be confident the payment exists.

Contract acceptance

One promising approach is that a contract can be accepted exclusively by one trader at a time.

This gives the trader real ownership over the job and prevents a chaotic race to the same delivery.

An alternative is an open broadcast model where multiple traders can partially fill a large request independently.

Contract variants

Several contract types are worth exploring:

  • One-time delivery — a single delivery of a specified good to a specified location
  • Procurement and delivery — the trader must acquire the goods themselves before delivering
  • Recurring supply contract — a standing agreement to deliver at regular intervals
  • Urgent contract — higher payment for guaranteed speed, possibly with late penalties
  • Alliance supply contract — visible only to specific factions or allies
  • Open public request — visible to any player in the galaxy

Fulfillment

The most defensible direction is that fulfillment requires physical delivery:

  • the trader must fly to the destination system
  • the correct goods and quantity must be present in the cargo hold
  • the delivery must be confirmed at a specific location, colony, or station

Partial deliveries are an open question: a very large contract might reasonably allow a trader to complete part of the order and receive partial payment.

What happens if cargo is lost

If a ship is destroyed while carrying contract goods, the question is what happens to the contract and the payment.

Possible approaches:

  • the contract fails, escrow is returned to the requester, the trader loses only the cargo
  • the trader can claim a partial or full penalty waiver if they can prove destruction by a hostile player
  • insurance or collateral systems could absorb the loss

This area has significant open design work remaining.

Open Questions

  • Should contracts require collateral from the trader to discourage abandonment?
  • Should deadlines be strict, soft, or optional per contract?
  • Should requesters be able to cancel a contract that is already in progress?
  • Should late delivery be partially rewarded or fully failed?
  • Should traders need to physically acquire the goods themselves for procurement contracts, or can they sub-contract?
  • How granular should the delivery location be — system, planet, colony, station, or specific coordinates?
  • Should cargo integrity or condition affect fulfillment for some goods?
  • Can one contract be split across multiple traders filling portions of a large request?
  • What protections exist against a requester deliberately misleading traders about route safety?