Simulator

Simulator

The FoundUps Simulator is the visual simulation engine for the autonomous FoundUp ecosystem. It models the complete economic lifecycle — from UPS token flows and CABR computation to F_i exit fees, 10-year revenue projections, and build task pipelines. The simulator serves as both a research tool for validating economic assumptions and a real-time dashboard for monitoring ecosystem health.

Source: modules/foundups/simulator/ Architecture: FAMDaemon (SSoT) → event_bus → state_store → render

---

CABR: Consensus-Driven Autonomous Benefit Rate

CABR (also referenced as Collective Autonomous Benefit Rate) is the core economic metric of the FoundUps ecosystem. It represents the rate at which autonomous agents generate measurable benefit for ecosystem stakeholders.

The conceptual model: CABR = pipe size (flow rate), while PoB (Proof of Benefit) validation = valve. The pipe determines maximum throughput capacity; the valve ensures only validated benefit flows through.

CABR is not a static interest rate — it is dynamically computed from actual ecosystem activity: build tasks completed, UPS tokens circulated, FoundUp instances launched, and stakeholder engagement metrics. The simulator models CABR trajectories under different growth assumptions to validate that the economic model remains sustainable across market conditions.

---

F_i Exit Fee System

The F_i Exit Fee System protects the ecosystem from extractive behavior — specifically, stakeholders who accumulate UPS tokens and then dump them without contributing sustained value. The simulator models 5 distinct fee structures:

Fee Model	Mechanism	Average Fee	Use Case
Flat	Fixed percentage on all exits	Fixed	Simple, predictable
Tiered	Rate increases with exit size	Progressive	Discourages large dumps
Time-Based	Rate decreases with holding duration	Vesting-like	Rewards long-term commitment
Activity-Based	Rate decreases with contribution history	Merit-based	Rewards active stakeholders
HYBRID	Combines time + activity + size factors	~22.4% avg	Recommended — captures 25.7% of miner dumps

The HYBRID model is the recommended default because it balances three defensive vectors simultaneously: it penalizes short holding periods (time), low contribution (activity), and large exit volumes (size). Simulations show it captures approximately 25.7% of value from extractive "miner dump" scenarios while imposing minimal friction on genuine long-term stakeholders.

---

10-Year Projection Hardening

The simulator generates hardened 10-year revenue projections across three confidence lanes:

Lane	Scenario	Purpose
Downside	Conservative assumptions, low growth, high churn	Stress testing — can the ecosystem survive worst case?
Base	Moderate growth aligned with historical patterns	Planning — expected trajectory for resource allocation
Upside	Optimistic growth, network effects compound	Opportunity sizing — what does success look like?

Revenue projections decompose into three fee streams: gross revenue (total UPS circulation), protocol fees (WSP framework maintenance), and platform fees (infrastructure and compute costs). Each stream is projected independently across all three confidence lanes, producing a 3x3 matrix of projection outputs.

The projections are "hardened" in the sense that they account for known failure modes: stakeholder churn curves, token velocity decay, seasonal activity patterns, and black swan shock absorbers. The simulator does not produce single-point forecasts — it produces ranges with explicit confidence intervals.

---

Build Lifecycle Coverage

The simulator models the complete build task pipeline that drives FoundUp development:

open → claimed → submitted → verified → paid

Stage	Description
open	Task posted to the ecosystem — available for any qualified agent or stakeholder
claimed	Agent or stakeholder has claimed the task — work in progress
submitted	Work completed and submitted for review
verified	Work passes PoB (Proof of Benefit) validation — confirmed to deliver value
paid	UPS tokens transferred to the contributor — task lifecycle complete

The simulator tracks task flow rates between stages, identifies bottlenecks (e.g., verification queue backing up), and models the economic impact of pipeline throughput on overall CABR.

---

FAMDaemon Architecture

The simulator follows a strict architectural pattern with the FAMDaemon as the Single Source of Truth (SSoT):

Design Principles

1. FAMDaemon events = SSoT — all state changes originate from FAMDaemon events. No component creates state independently.
2. state_store derives renderable state — the state store transforms raw FAMDaemon events into display-ready data structures.
3. Render reads ONLY from state_store — the terminal view never queries FAMDaemon directly. It reads pre-computed state.
4. Adapters bridge to FAM contracts — adapter modules translate between the simulator's internal model and the actual FAM (FoundUp Autonomous Module) contract interfaces.
5. Phantom plugs ONLY where logic missing — placeholder modules are used only where real logic hasn't been implemented yet. They are explicitly marked and tracked for replacement.

Primary Wiring Files

File	Role
adapters/fam_bridge.py	Bridge between simulator and FAM contracts
mesa_model.py	Mesa agent-based model definition
step_core.py	Core simulation step logic
step_pipeline.py	Pipeline orchestration for simulation steps
state_contracts.py	State shape contracts and validation
step_pure.py	Pure functional step computations (no side effects)
render/terminal_view.py	Terminal-based visualization output
event_bus.py	Event routing between components
state_store.py	Derived state management

---

FoundUp Lifecycle Policy

The simulator enforces the FoundUp lifecycle stages that govern when instances transition between maturity levels:

Stage	Criteria	Investment Eligibility
PoC (Proof of Concept)	No paid task completed	Cannot receive external investment
Proto (Prototype)	At least one paid task verified	Can accept UPS bids for MVP pre-launch
MVP (Minimum Viable Product)	Paying customers after delivery	Full economic participation

This lifecycle ensures that FoundUps must demonstrate real value creation before accessing ecosystem capital. The simulator models cohort progression through these stages and identifies failure rates at each transition.

---

Investment & Token Model

The simulator models the complete UPS token economy:

F_0 as Sole Investor Source

F_0 (the root FoundUp — the ecosystem itself) is the only source of investment capital. There are no external VCs, no angel rounds, no token sales. All capital flows through F_0's UPS allocation mechanism. This constraint is fundamental to the ROC (Return on Compute) model — capital allocation is algorithmic, not political.

Subscription Accrual

Subscriptions accrue at 200 UPS/term. stakeholders who subscribe to the ecosystem receive a steady flow of UPS tokens that they can allocate to FoundUps they believe in, contribute as build task bounties, or accumulate for governance weight.

Proto-Stage Bidding

Proto-stage FoundUps can accept UPS bids for MVP pre-launch. This creates a prediction market dynamic where stakeholders signal confidence in specific FoundUps by committing UPS tokens before the FoundUp has reached MVP stage.

---

012 Allocation & pAVS Telemetry

Subscription Tiers

012 stakeholders are bootstrapped as subscription accounts across four tiers:

Tier	Level	UPS Allocation
Spark	Entry	Base allocation
Explorer	Active	Enhanced allocation
Builder	Contributing	Builder-tier allocation
Founder	Governance	Maximum allocation

Monthly rollovers ensure unused allocation doesn't expire — it accumulates, giving long-term stakeholders increasing economic weight.

0102 Allocation Batches

The 0102 system processes allocation in batches, ensuring fair distribution across all active stakeholders within each billing cycle. Batch processing prevents front-running and ensures that allocation order doesn't create unfair advantages.

pAVS Telemetry

The simulator integrates pAVS (stakeholder Autonomous Value Score) telemetry to track individual stakeholder contribution metrics. pAVS feeds back into CABR computation, creating a closed-loop system where individual contribution directly influences ecosystem-wide benefit rates.

---

WSP Compliance

WSP	Protocol	Relevance
WSP 48	Recursive Self-Improvement	Simulation learning loops
WSP 73	Persistent Persona Architecture	Agent identity in simulation
WSP 78	State Persistence	SQLite state storage
WSP 96	MCP Governance	FAMDaemon integration

---

See Also

• Economic Model — CABR theory, V3 Engine, Proof of Benefit
• AI Overseer & Security Sentinel — agent coordination governing the simulator
• OpenClaw — swarm execution engine
• FoundUps Portfolio — the FoundUp instances being simulated
• Module Ecosystem — module architecture

---

Back to Wiki Home