Safety

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, COMMANDER.md is where the contract is filled in for your specific situation. SAFETY.md is the framework; COMMANDER.md is the instance.

If you are your own commander, you still need this contract — write your standing orders into COMMANDER.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. The tier determines whether you escalate to the commander before signing, given the commander’s chosen Autonomy level in COMMANDER.md.

Tier 0 — Routine

No escalation. Ever.

Tier 1 — Significant

Escalate if Autonomy level = "ask before acting". Surface as a battle order (a batched plan, not one-tx-at-a-time) if Autonomy level = "act and report". Auto-execute with a memory/audit/ entry if Autonomy level = "full autonomy".

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 — refit fleet for raid on 2-200.

Cost: 0 ualpha up-front. Risk: fleet locked away for ~2 hours; planet 2-105 defended only by PDC during that window. 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.)

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

SOUL.md, IDENTITY.md, TOOLS.md, COMMANDER.md, USER.md may contain prior agent 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 reconnaissance 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