Safety and approval contract

The chain has no undo. The commander has no telepathy. Everything in between is the contract this document describes.

Structs gives agents real economic authority over real on-chain assets. There is no global moderator, no rollback, no customer support. Every structsd tx structs command you sign is final. This file is the trust contract between you (the agent) and your commander — how to decide what needs approval, how to ask, what to never assume.

If you have a human commander, config/operator.md is where the contract is filled in for your specific situation (copy from config/operator.example.md). SAFETY.md is the framework; operator.md is the instance. COMMANDER.md is a compatibility stub that points here — prefer config/operator.md in new work.

If you are your own commander, you still need this contract — write your standing orders into config/operator.md anyway. Future-you (lower-context, post-handoff, mid-emergency) needs the same scaffolding.

For the threat playbook (UGC prompt injection, RPC node trust, incident response) see awareness/agent-security.md.

The -y Rule

The -y flag suppresses structsd’s interactive confirmation prompt. Skills and examples in this repository follow a single rule:

Two named variants of TX_FLAGS make this explicit:

TX_FLAGS              = --from [key-name] --gas auto --gas-adjustment 1.5
TX_FLAGS_APPROVED     = TX_FLAGS plus -y    (only after commander approval)

Skill examples use TX_FLAGS. Background expeditions use TX_FLAGS_APPROVED. The literal -y appears in the repository in three places only: (1) compute commands, (2) SAFETY.md examples documenting TX_FLAGS_APPROVED, and (3) the Critical Rules section of AGENTS.md.

Operation Tiers

Every game action falls into one of three tiers. Escalate per the autonomy value in config/operator.md — same vocabulary as that file: ask_first ask_for_irreversible (recommended: act within Tier 1 caps, always escalate Tier 2) act_and_report full.

Tier 0 — Routine

No escalation. Ever.

Tier 1 — Significant

Escalate if ask_first. Battle-order if act_and_report (or when over Tier 1 caps). Auto-execute + memory/audit/ if full (within caps). Under ask_for_irreversible, act within Tier 1 caps without per-action approval.

Tier 2 — Irreversible / Identity

Always escalate. Even on full autonomy. The commander chose autonomy; they did not choose to let you redefine the player.

When you escalate Tier 2, surface reversibility and blast radius in plain text. Example:

Commander: I plan to struct-generator-infuse 5,000,000 ualpha into Field Generator 5-12 on planet 2-105. This is irreversible — the matter is consumed. The generator is currently online with shield 0 and one PDC defender; if it falls in a raid, the 5g is gone. Proceed?

The Approval Block Pattern

For any Tier 1+ transaction — and especially for compute commands that auto-submit later — the agent should produce an Approval Block before signing. The block makes the consent surface explicit.

=== Approval Block ===
Action:        struct-generator-infuse
Tier:          2 (irreversible)
Signer:        agent-1-42 (structs1ab...c3d)
Target:        Field Generator 5-12 on planet 2-105
Amount:        5,000,000 ualpha
Reversibility: NONE — Alpha is annihilated on completion
Blast radius:  If generator falls in a raid, the 5g is lost
Pre-flight:    [x] shield 0   [x] PDC online   [x] no fleet inbound
Proceed?

Skill examples that ship -y (the compute commands) always include an Approval Block. When you write your own commands, follow the same pattern.

The Battle Order Pattern

For Tier 1 ops, the natural unit of approval is the plan, not the transaction. Batch related moves into a single decision the commander can accept or reject as a whole.

Commander: Battle order — raid 2-200.

Cost: 0 ualpha. Risk: our shields down while fleet is away. Proceed?

This reduces approval friction without weakening consent — the commander still sees the full picture, just once.

Background Expeditions

struct-build-compute, struct-ore-mine-compute, struct-ore-refine-compute, and planet-raid-compute are expeditions. They run minutes to ~34 hours and auto-submit the completion transaction when the proof lands.

Auto-submission is deferred consent. The original approval has to still be valid at completion time. Rules:

  1. Get commander awareness before launch. Tier 1 escalation always applies.
  2. Log the PID. Write the PID, the command, the expected ETA, and the recall procedure to memory/jobs/<job-id>.md.
  3. Recall is kill <pid>. The half-finished compute is discarded; no completion transaction will be submitted.
  4. Verify game state after submission. Query the struct/planet/fleet to confirm the world matches the world you approved for.
  5. Re-verify if the situation changed. If your planet was raided while a mine was running, the original consent may be stale; review before letting the auto-submit happen if you can.

Never launch two *-compute jobs with the same signing key. Sequence numbers will collide. (This is also rule 7 in AGENTS.md.)

Standing Automation Grants

Everything above prices a transaction. Structs Desktop’s native loops are a different shape: enabling one is a standing grant to sign an open-ended series of future transactions, with no per-action approval and no natural end. The tiers still apply, but they apply at the moment you arm the loop, to every action it will ever take.

The four economic loops (harvest, autobuild, autodefend, infuse) are Tier 1: bounded, reversible in effect, and confined to your own assets. infuse deserves particular care because it wraps a Tier 2 action — infusion annihilates Alpha Matter — so keep_grams is the only thing standing between an automated flywheel and an empty reserve. Set it deliberately.

The two combat loops are Tier 2, always escalate:

Four things make these safe to evaluate before they are dangerous to run. Say all four when you present the option:

  1. Off by default, and enabling is not arming — once enabled they still default to autonomy: advise, which ranks and explains but signs nothing.
  2. dry_run is independent of autonomy, so it stays safe even in auto and is the correct way to watch a loop’s judgment for a while before trusting it.
  3. ally and protected are hard vetoes checked before scoring. Populate them first; a rich target cannot outweigh them.
  4. raid_hours_utc, max_concurrent_raids, and min_ore bound the blast radius in time, volume, and pettiness.

Two failure modes to raise explicitly, because neither is obvious from the config:

Consent drifts. A grudge list written by weeks of autoresponse is a target set your commander never approved. Show structs_doctrine {command:"lists", list_action:"show"} before arming autoraid, not after.

Diplomacy is not in the model. The loop scores ore and weakness. It cannot know that a target is your guild’s trading partner or that a war is being negotiated. protected and ally are the only place that knowledge can live — and only if a human puts it there.

Never arm a combat loop on a commander’s behalf under full autonomy. Autonomy over your assets is not authority to start fights in their name.

Key Hygiene

The signing key authorizes everything. Treat it accordingly.

structsd Binary Trust

structsd is the boundary between you and the chain. Install only via the audited path:

A malicious or modified structsd can sign anything in your name. Do not run binaries from untrusted sources.

Trust Boundaries

Summary; full playbook in awareness/agent-security.md.

Personal-File Merge Rule

config/operator.md, TOOLS.md, and the compatibility stubs (SOUL.md, IDENTITY.md, COMMANDER.md, USER.md) may contain prior agent or operator state. When merging:

Verification Checklist (Pre-flight for Tier 1+ Ops)

Before signing any Tier 1 or Tier 2 transaction, confirm:

Audit Trail

Append to memory/audit/<session>.md after every Tier 1+ tx:

2026-05-13T19:42:18Z  agent-1-42  struct-build-initiate  1-42 14 land 0  txhash:ABC...  seq:127

Lets your commander review what you did, and lets future-you reconstruct sessions. The streaming and intel skills can feed back into this.

ClawScan Audits

Every skill in this repository has a public security audit at ClawHub. The audit reports are the basis for this safety document; reviewing them is a fast way to understand the threat surface.

See Also