The initial M-series specs were wrong (text digestion pipeline). Replaced
with the actual economy organ architecture:
M0 hub (independent system, scoped autonomy, multi-layered braking)
M1 Marketplace (multi-trader harness, deterministic law script, veto)
M2 Data Feeds (RSS + live market, bridges Marketplace ↔ Sims)
M3 Sims hub + 7 sub-specs (always-running, bounded predictions):
M3a statistical, M3b sociological, M3c AMM/liquidity,
M3d MEV/adversarial, M3e tokenomics/macro, M3f consensus/staking,
M3g market microstructure
M4 Wallets (sovereign custody, our keys only, 1:1 trader binding)
M5 Traders (AI actors, wallet-bound, all tool calls monitored)
M6 Conductor (supervisory AI, veto, pause/investigate, SAE intake)
M7 SAE monitor (trader surveillance, Brain-compatible message format)
Grounded in AMM invariant mechanics, MEV game theory, SDE tokenomics,
and evolutionary consensus games. Tax stub for Verschwörern Veregeister.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
4.2 KiB
M1 — Marketplace (multi-trader harness)
1. Component
The economy organ's trading floor: a multi-trader harness through which all market actions must route. No trader may buy, sell, mint, or interact with any on-chain protocol except through the Marketplace. Enforces a deterministic law script (scoped invariants — the marketplace's own constitution) and integrates the Conductor's veto (M6) before execution.
2. Status / certainty
DESIGN-FIRST · ABSENT. Role C4; implementation C1.
3. Language & location
TBD · src/economy/marketplace/. Needs to interface with blockchain APIs (RPC/REST), wallet
signing (M4), and the Conductor (M6). Deterministic law script must be auditable and non-Turing
(no unbounded loops — it's a constitution, not a program).
4. Does / does-not
- Does: receive trade requests from Traders (M5); validate against the deterministic law script (scoped invariants); check Conductor veto (M6); verify trader-wallet binding (no wallet = no access); execute approved actions on-chain via the bound wallet's API; record all actions for SAE (M7) monitoring; collect tax on realized income → Verschwörern Veregeister stub (M0).
- Does-not: decide what to trade (Traders decide); predict markets (Sims do); hold keys (Wallets do); supervise behavior (Conductor + SAE do).
5. Interface contract
submit_action(trader_id, action: MarketAction, wallet_id) -> { accepted | vetoed | law_violation | no_wallet }.MarketAction∈ {buy,sell,mint,provide_liquidity,withdraw_liquidity,claim_rewards, … }.law_check(action: MarketAction) -> { pass | violation(rule_id, reason) }— deterministic, pure function. The law script is loaded at startup and immutable at runtime (mirrors S3 / the COBOL vault pattern).veto_check(action: MarketAction, trader_id) -> { approved | vetoed(reason) }— calls M6 Conductor.execute(action: MarketAction, wallet_id) -> { tx_hash | error }— on-chain execution via wallet API.tax_event(trader_id, income_amount) -> receipt— triggers tax collection.
6. Dependencies & stubs
- M4 Wallets — signing + execution; stub: mock wallet that logs transactions.
- M5 Traders — action source; stub: canned trade requests.
- M6 Conductor — veto authority; stub: always-approve.
- M7 SAE — action log consumer; stub: print actions.
- Blockchain RPCs — on-chain execution; stub: simulated chain responses.
7. Invariants / laws
- L1 (C5): all market actions route through the Marketplace — no direct on-chain execution by any trader. This is the economy organ's S1.
- L2 (C5): the deterministic law script is immutable at runtime — loaded at startup, never modified by traders, conductor, or sims. Changes require a restart with a new script version. Mirrors the COBOL vault (S3).
- L3 (C4): no wallet, no access — a trader without a bound wallet cannot submit actions. The Marketplace enforces this before any other check.
- L4 (C4): veto is checked after law, before execution — law violations are rejected outright; Conductor veto applies only to law-passing actions. The law is above the Conductor.
- L5 (C4): every action is logged — SAE (M7) receives a record of every submitted action (including rejected ones) for behavioral analysis.
8. Build steps
- Define
MarketActiontypes and the law script format. - Implement the law checker (deterministic, pure, non-Turing).
- Wire veto check to M6 Conductor.
- Wire execution to M4 Wallet API.
- Wire action logging to M7 SAE.
- Implement tax collection on realized income.
9. Tests
Law enforcement: known violations rejected; valid actions pass. Veto: conductor veto blocks execution. Wallet binding: walletless trader rejected. Logging: every action (pass + fail) logged. Tax: income event triggers tax stub. Immutability: law script cannot be modified at runtime.
10. Open items
- The law script language/format (DSL? declarative rules? S-expressions?).
- Which blockchain protocols/RPCs to support initially.
- Position limits, drawdown stops, and other risk parameters — live in the law script or in the Conductor's judgment?
- Tax rate / calculation method (fixed %, tiered, per-asset?).