Commerce is how Alpha Matter compounds into economic power. The core loop: refine Alpha → infuse a reactor (capacity) → route it through an allocation to a substation → sell it through a provider → buyers pay in tokens via agreements → reinvest. Layered on top are guild Central Bank tokens (mint/redeem) and direct transfers. Where structs-energy is “power my own structs”, this skill is “make Alpha and energy earn.”
Conventions (TX_FLAGS, -- rule, charge bar, one-tx-at-a-time, ualpha denom suffix) are in conventions.md. Every command here is Tier 1 or Tier 2 — default to interactive.
Sell or hold? Surplus capacity earns nothing idle. If you have headroom beyond your own structs, sell it. Price in guild tokens (1uguild.0-N) to create demand for your guild’s currency, or in ualpha for direct value.
Buyer-side: shop before you commit. An agreement is paid upfront for the full duration (capacity × rate × duration), and closing early can incur a penalty. Compare providers on rateAmount, capacityMaximum, durationMaximum, and penalties before opening.
Reactor staking economics. Infusing a reactor both raises your capacity and stakes behind a validator at a locked commission. Lower commission = more capacity to you; staking strengthens the guild’s reactor. It’s reversible only via a defusion cooldown — don’t stake Alpha you’ll need short-term.
The energy flywheel (advanced default): mine → refine → infuse guild reactor → automated allocation grows substation capacity → sell via provider for guild tokens → redeem/reinvest. Each turn compounds. Decisions live in knowledge/economy/valuation, trading, and playbooks/phases/late-game.
| Type | Updatable | Deletable | Auto-grows | Limit | Use |
|---|---|---|---|---|---|
| static | no | no (while connected) | no | unlimited | fixed routing |
| dynamic | yes | yes | no | unlimited | flexible/managed routing |
| automated | yes | no | yes (with source capacity) | one per source | energy sales (recommended) |
| provider-agreement | system | system | system | system-created | auto-made when agreements open — never create manually |
Only the controlling player can delete/transfer an allocation (--controller [player-id], defaults to creator).
structs-energy).structsd tx structs allocation-create --allocation-type automated TX_FLAGS -- [your-player-id] [power]
structsd tx structs substation-create TX_FLAGS -- [your-player-id] [allocation-id]
structsd tx structs provider-create TX_FLAGS -- [substation-id] [rate] [access-policy] [provider-penalty] [consumer-penalty] [cap-min] [cap-max] [dur-min] [dur-max]
Pricing/policy heuristics: rate 1uguild.0-N (drives guild-token demand) or a ualpha rate; access-policy open-market (max reach), guild-market (members at/above a rank — grant via permission-guild-rank-set [provider-id] [guild-id] 262144 [rank]), or closed-market (explicit PermProviderOpen only); penalties 0 initially to lower friction; cap/dur ranges wide (e.g. 1000–1000000000 / 100–1000000).
structsd query structs provider [id]; provider-withdraw-balance TX_FLAGS -- [provider-id]. Earnings drip from the provider’s collateral (escrow) to its earnings address as blocks pass.structsd query structs provider-all (or your guild’s). Compare rate/capacity/duration/penalties.structsd tx structs agreement-open TX_FLAGS -- [provider-id] [duration-in-blocks] [capacity]
structsd tx structs substation-allocation-connect TX_FLAGS -- [substation-id] [allocation-id]
agreement-capacity-increase|decrease, agreement-duration-increase; agreement-close [agreement-id] (may penalize).structsd tx structs reactor-infuse [your-address] [validator-address] [amount]ualpha TX_FLAGS
Validator address is structsvaloper1... (from structsd query structs reactor [id], validator field) — not the reactor ID. Commission locks at infusion. Unstake: reactor-defuse [reactor-id] (cooldown); reactor-cancel-defusion to re-stake during cooldown; reactor-begin-migration [player-addr] [src-val] [dest-val] [amount] to move stake (verify the destination — no undo).
structs-guild and knowledge/economy/guild-banking for the bank’s collateral mechanics and the guild-bank-* commands.player-send [from-address] [to-address] [amount] TX_FLAGS. A typo in the destination is permanent — to a brand-new address this is Tier 2.| Action | Command |
|---|---|
| Allocation create / update / delete / transfer | structsd tx structs allocation-create --allocation-type [t] TX_FLAGS -- [source-id] [power] (+ allocation-update/allocation-delete/allocation-transfer) |
| Substation create | structsd tx structs substation-create TX_FLAGS -- [owner-id] [allocation-id] |
| Provider create / delete / withdraw | structsd tx structs provider-create \| provider-delete \| provider-withdraw-balance TX_FLAGS -- ... |
| Agreement open / close / adjust | structsd tx structs agreement-open \| agreement-close \| agreement-capacity-increase \| ... TX_FLAGS -- ... |
| Reactor infuse / defuse / migrate | structsd tx structs reactor-infuse \| reactor-defuse \| reactor-begin-migration TX_FLAGS -- ... |
| Token transfer | structsd tx structs player-send [from] [to] [amount] TX_FLAGS |
| Query provider / agreement / reactor | structsd query structs provider \| agreement \| reactor [id] |
TX_FLAGS per conventions.md. Requires structsd on PATH and a signing key.
structsd query structs provider [id] — capacity, rate, active agreements, balance.structsd query structs agreement [id] — status (OPEN→ACTIVE→EXPIRED), capacity, duration.structsd query structs reactor [id] — infused amount, defusion cooldown.structsd query structs player [id] — balance after transfers/withdrawals.reactor-cancel-defusion to re-stake, or wait it out.structs-energy).