mirror of https://github.com/SHOGGOTH-SECTOR/sica-fondt.git synced 2026-07-31 16:16:26 +00:00

Rewrite M-series: crypto trading engine + market prediction sims

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>

2026-07-13 21:10:15 +00:00

4.4 KiB

Raw Blame History

M5 — Traders (AI actors)

1. Component

The economy organ's hands: specialized AI actors that buy, sell, and mint cryptocurrency and NFTs. Each trader is bound to a Wallet (M4), operates through the Marketplace (M1), queries Sims (M3) for predictions, and has all tool calls monitored by the SAE (M7). Multiple traders may operate concurrently with different specializations (DeFi yield, NFT minting, arbitrage, long-term holding, etc.).

2. Status / certainty

DESIGN-FIRST · ABSENT. Role C3; implementation C1.

3. Language & location

TBD · src/economy/traders/. Each trader is an AI actor — likely LLM-based (small models for speed) or hybrid (LLM for strategy + deterministic execution logic). The harness managing multiple traders may be Pony actors or a Python async framework.

4. Does / does-not

Does: query Sims (M3) for market predictions (bounded, multi-domain); consume Data Feeds (M2) for real-time market state; formulate trade decisions based on predictions + data + specialization; submit MarketAction requests to the Marketplace (M1) via bound wallet (M4); operate with scoped autonomy — trades within law/budget constraints don't need Brain or Conductor approval.
Does-not: execute on-chain directly (Marketplace does); hold keys (Wallet does); supervise other traders (Conductor does); modify the law script (immutable — M1-L2); bypass the Marketplace (M1-L1).

5. Interface contract

init_trader(specialization, wallet_id, config) -> trader_id. specialization ∈ { defi_yield, nft_minter, arbitrageur, trend_follower, market_maker, … } — extensible.
decide(market_state, predictions: [BoundedPrediction]) -> MarketAction? — the trader's core loop. May return no action (waiting is a valid decision).
tool_call(tool_name, args) -> result — every tool call is intercepted and logged to SAE (M7) before execution. Includes Marketplace submissions, Sim queries, and Data Feed reads.
pause() / resume() — Conductor (M6) can pause a trader pending investigation.
status() -> { active | paused | investigating, wallet_id, specialization, position_summary }.

6. Dependencies & stubs

M1 Marketplace — action submission; stub: mock marketplace that logs actions.
M2 Data Feeds — market data; stub: canned data.
M3 Sims — predictions; stub: fixed predictions.
M4 Wallet — bound 1:1; stub: mock wallet.
M6 Conductor — supervision; stub: no supervision.
M7 SAE — monitors all tool calls; stub: print calls.

7. Invariants / laws

L1 (C5): all market actions go through the Marketplace — a trader cannot interact with any chain or protocol except via MarketAction → Marketplace (M1). Enforced by architecture (no direct RPC access), not just policy.
L2 (C5): all tool calls are monitored — every tool invocation (Marketplace, Sims, Feeds, internal) is logged to SAE (M7). No unmonitored trader action.
L3 (C4): wallet binding is irrevocable within a session — a trader's wallet cannot be reassigned to another trader at runtime.
L4 (C4): Conductor can pause — a paused trader cannot submit actions, query sims, or read feeds until resumed by the Conductor (M6).
L5 (C3): trader specialization constrains strategy but not the interface — all traders use the same MarketAction vocabulary regardless of specialization.

8. Build steps

Define the trader agent architecture (LLM-based? hybrid? rule-based for v1?).
Implement the decide loop (observe market state + predictions → action).
Wire tool-call interception → M7 SAE.
Wire Marketplace submission → M1.
Implement pause/resume for Conductor control.
Build at least two specializations to test multi-trader dynamics.

9. Tests

Marketplace-only: trader cannot call chain RPC directly. Monitoring: every tool call appears in SAE log. Wallet binding: trader uses only its bound wallet. Pause: paused trader cannot submit actions. Specialization: different specializations produce different action patterns on identical market state.

10. Open items

Trader agent architecture (which LLM? how much deterministic logic vs. model inference?).
Number of concurrent traders and resource allocation per trader.
Specialization catalog (which types, and how do they differ in strategy?).
Inter-trader coordination (do traders see each other's positions? shared state? isolated?).

4.4 KiB Raw Blame History