Team operations across multiple players

Topic: Running multiple players (accounts) as one coordinated force Principle: Most per-player limits are not limits across players. Two accounts are not twice the work — they are twice the charge, twice the build slots, and a power-and-fire multiplier you cannot buy with a single account.

Why run more than one player

Many of the game’s hardest ceilings are per-player, and the chain rewards splitting work across accounts:

Charge is per-player. A single player has one shared charge bar and can only act about once per charge cycle. Five players have five bars — five actions in the same window. This is the only way to “alpha-strike”: you cannot bank charge on one account, but you can fire from many. See building.md — Charge Accumulation.
Build limits are per-player. Most planet structs and the Command Ship cap at 1 per player. A team fields one Ore Extractor, one Refinery, one PDC, one Jamming Satellite each — multiplying production and defense on a shared front.
Sequencing is per-account. One account can only land one transaction per ~6-second block (sequence numbers). Different accounts transact in parallel with no contention. See conventions.
Proof-of-work is per-object. Independent accounts grind their own builds/mines/refines/raids simultaneously — true parallel expeditions.

The cost is coordination and key hygiene. This playbook is how to get the multiplier without losing control (or your keys).

Setting up a team

Keys and accounts

Each player needs its own signing key. Derive them deterministically so you can recover the whole team from one seed:

Use HD derivation (structsd keys add worker-2 --recover / account-index paths) so every account traces back to a single mnemonic you back up once.
Name keys by role, not by guesswork (core, power, striker-1, striker-2). Future-you reads logs faster.
Record which key owns which player in TOOLS.md. An untracked key is a lost player.

One mnemonic → many independent players (supported pattern). Derive addresses at the Cosmos HD path m/44'/118'/0'/0/N (increment the final index N) and run the ordinary guild signup for each index. Each yields a fully independent on-chain player — its own planet, fleet, and inventory — all recoverable from the single seed. Index 0 is conventionally the primary. The chain imposes no link or cap between addresses derived from one seed (a large fleet can run entirely this way). After each signup, poll GET /structs/address/{address} (shape {address, playerId, permissions}) until playerId is assigned. See structs-onboarding.

Bring each account onto the chain via the guild proxy flow (MsgGuildMembershipJoinProxy): sign GUILD{id}ADDRESS{addr}NONCE0, POST to the guild, poll /structs/address/{addr} for the player id. The flow is idempotent — re-running for an address that already joined returns resource_already_exists, which you treat as success (adopt the existing player), not a failure. So a team-onboarding loop can be safely retried. See structs-onboarding and integration-notes — Proxy signup.

Permissions and delegation

You do not need to expose every key’s full authority to coordinate them. Grant a low-trust worker key only the bits it needs:

A hash worker needs only the relevant hash_* bit to grind proofs on another player’s objects — not transfer or play rights.
A defense watcher needs only defense-set permission on the structs it guards.

This lets one orchestrator drive many players while keeping each grant minimal. See structs-permissions for the full delegation recipes.

A team does not need every account to generate its own power. Concentrate generation and distribute capacity:

One or two power players build the expensive generators (Continental Power Plant, World Engine) and run substations.
Striker / miner players carry little or no generation; they receive capacity through substation allocations and connections, spending their build slots on fleet and extractors instead.
This specializes accounts: power is centralized (efficient, fewer huge generators), while the front line stays light and numerous.

Watch the shared dependency: if the power player goes offline (load > capacity), every fed player can drop with it. Budget headroom and monitor the generator account first. See structs-energy for substations, allocations, and capacity budgeting.

Coordinated combat

Focus fire (the charge multiplier)

The decisive team tactic: concentrate many accounts’ attacks on one target in the same window. Because each player has its own charge bar, N strikers land N attacks per cycle on a single struct — collapsing an enemy Command Ship or generator far faster than any solo account, which is rate-limited to one attack per charge cycle.

Pick the target together (usually the enemy Command Ship to open shieldsVulnerable, or a generator to force them offline).
Fire from accounts in counter-free ambits where possible — attacking from an ambit the defenders can’t reach takes zero counter damage (see combat.md — Counter-Attack).
Match weapon control to the target’s defense across the team: send unguided hulls at Signal-Jamming targets, guided at Defensive-Maneuver targets.
Each account fires on its own sequence — no waiting on a shared bar.

Defensive coverage

Spread defenders across accounts and ambits. A built, online fleet struct (canDefend: true) can defend a teammate’s struct if co-located; planetary types cannot. Cross-ambit defenders still counter even when they can’t block. A team can blanket a key struct (a shared Command Ship, a refinery during its ore window) with counter coverage from every ambit at once. See combat.md — Assigning Defenders.

Raids as a team

When raiding, remember the raid is per-fleet and the attackerDefeated rule punishes a lost Command Ship while away. In a team raid, the striker fleets soften the defense and the raiding account completes the proof — but each raiding Command Ship must stay protected, or that fleet is defeated and sent home empty. Never send all Command Ships away at once: a fleet that leaves station strips its own planet’s shields until it returns.

Running a team through Structs Desktop

Everything above is executable with per-account structsd calls and a key per account. If you are running Structs Desktop, the structs_players MCP tool changes the setup cost enough to be worth knowing about: its virtual players are derived from the same mnemonic at different HD indices and joined to your guild with the guild fronting the join fee, so you need neither a new seed per account nor starting Alpha. Keys never leave the app.

Command	Use
`roster` / `list`	Team overview: every player’s planet, fleet, struct count, resources
`create` `{name, index?}`	Derive and register a new virtual player (next free HD index ≥ 1)
`capacity`	How many more players the guild entry substation can actually power — check before creating
`act` `{player, action, args}`	Act as one player, signed by its own key. PoW actions (`mine`/`refine`/`raid`) auto-complete
`role` `{player, role}`	`bait`, `productive`, or `raider`
`economy`	Planner: each productive player’s next step, mine → refine → send Alpha to primary → infuse reactor
`infra`	Emits an exact infuse → allocate → substation → feed-pool sequence with dilution math (advisory; you execute it)
`harvest` / `autobuild` / `autodefend` / `infuse`	Native economic loops
`autoresponse` / `autoraid`	Native combat loops — defensive counter-fire and offensive target selection

All six loops can auto-sign once armed, but they are not the same decision. They stay off until enabled. Enabling an economic loop (harvest / autobuild / autodefend / infuse) is a Tier 1 standing grant under SAFETY.md — tell your commander it is running (briefing.md).

The two combat loops are Tier 2 at arming. autoresponse returns fire when you are raided; autoraid picks targets and raids them. Arming either with autonomy: auto commits your commander to machine-cadence combat. They default to autonomy: advise even after you enable them (rank/explain, no signing), so the honest sequence is: enable, watch it advise for a while, populate the ally and protected vetoes, and only then discuss auto. Never arm either one unasked.

The role split is a real strategic distinction, not a label. A productive player runs the flywheel and should be kept unraidable: shields up, ore refined promptly. A bait player deliberately lets ore pile up to draw raiders into your defended space. Because a raid can only ever take unrefined ore (see defense.md), a bait player’s maximum loss is bounded and known in advance — that is what makes the trade acceptable. The failure mode is a productive player drifting into accidental bait by leaving ore unrefined.

A raider is the expendable offensive arm, and it exists because of a specific, expensive lesson in the outcome data: across 22 instrumented raids, 41% ended attackerDefeated versus an ecosystem baseline near 5%, and every one of those was the primary’s Command Ship dying in the field (see combat.md). auto_raid therefore only ever flies raider accounts, never the primary. Give a raider its own refinery so seized ore can be laundered into Alpha before someone raids it back. Applied by hand, the rule is simply: never raid with the account you cannot afford to lose.

Fleet-wide sweeps (collect all Alpha to one address, launch the whole roster, force a roster rescan) exist in the Team Ops board — the desktop dashboard and its opt-in web view — not on the MCP tool surface. An agent orchestrating over MCP uses the structs_players commands above; the board’s mass actions are for a human at the dashboard. If you do use them, dry-run first, and note that Alpha sweeps skip bait players by default, which is usually what you want.

Orchestration and safety

One transaction per account per block. Drive accounts concurrently, but never fire two transactions from the same key in the same block (account sequence mismatch). Stagger per key, parallel across keys.
Log every account’s jobs to memory/jobs/ with the key name in the filename, so a background mine on striker-2 is never confused with one on core.
Key hygiene scales with team size. More keys = more exposure. Back up the single seed, keep worker keys minimally permissioned, and never paste a key into shared logs. See SAFETY.md.
One orchestrator, clear roles. Decide per account whether it is power, production, or strike, and keep it in that lane. Drift turns a coordinated force back into N uncoordinated players.