# 12: Composed MYCO System

## How Everything Fits Together

The MYCO bonding surface is a **multi-channel token issuance system** that combines financial reserve deposits with non-financial commitments, all managed through a unified reserve architecture.

## Data Flow

### Minting (Inflow)

```
User deposits ETH, USDC, DAI, ...
    │
    ▼
[Imbalance Fee Check]
    │ Fee applied if deposit skews reserve weights
    ▼
[Safety Check — Reserve Tranching]
    │ Blocked if deposit worsens weight deviation beyond threshold
    ▼
[N-D Ellipsoid Bonding Surface]
    │ Invariant r increases proportional to deposit value + geometry
    │ MYCO minted = supply * (r_new/r_old - 1)
    ▼
[Update Reserve State]
    │ Vault balances, total value, backing ratio
    ▼
$MYCO credited to depositor
```

### Commitment Minting (Parallel Channels)

```
Labor attestation / Subscription payment / Staking lockup
    │
    ▼
[Rate Limit + Flow Dampening]
    │ Per-channel caps, cooldowns, exponential memory
    ▼
[Mint $MYCO]
    │ No invariant change (commitment-backed, not reserve-backed)
    │ Subscription payments DO add to reserve; labor/staking do NOT
    ▼
[Update Supply]
    │ Backing ratio decreases (more supply, same/slightly more reserve)
    ▼
$MYCO credited to contributor/subscriber/staker
```

### Redemption (Outflow)

```
User burns $MYCO
    │
    ▼
[Flow Dampening]
    │ Exponential outflow memory → penalty multiplier
    │ Effective redemption = amount * penalty
    ▼
[P-AMM Redemption Curve]
    │ Rate depends on backing ratio:
    │   ba ≥ 1 → rate = 1.0 (par)
    │   ba < 1 → parabolic discount
    │   ba ≪ 1 → floor rate θ̄
    ▼
[Optimal Withdrawal Split]
    │ Withdraw more from overweight vaults → rebalance
    ▼
[Safety Check]
    │ Ensure withdrawal doesn't worsen vault deviations
    ▼
[Execute]
    │ Return USD-equivalent assets to user
    │ Burn $MYCO, shrink surface invariant
    ▼
Assets returned to redeemer
```

## Parameter Governance

All parameters are governance-controlled. Key governance decisions:

| Decision | Parameters | Effect |
|----------|-----------|--------|
| Reserve composition | Target weights, max deviation | Which assets and in what proportion |
| Surface geometry | λ_i, Q rotation | How concentrated pricing is per asset |
| Redemption safety | P-AMM α, θ̄, outflow memory | How aggressively to protect remaining holders |
| Fee structure | Static fee, surge rate, threshold | Economic incentives for balanced deposits |
| Commitment rates | Tokens per unit, rate limits, caps | How much non-financial contributions mint |
| Dynamic evolution | Weight schedules, oracle multipliers | How parameters change over time |

## Invariants (Things That Must Always Hold)

1. `supply >= 0` — never negative supply
2. `reserve_value >= 0` — never negative reserves
3. `redemption_amount <= reserve_value` — never return more than exists
4. `sum(vault_weights) == 1.0` — weights always normalized
5. `flow_tracker.current_flow >= 0` — flow tracking always non-negative
6. `commitment_minted <= cap * supply` — commitment channels capped

## Simulation Scenarios

Three built-in scenarios test the system:

1. **Token Launch**: 50 depositors over 30 days, some redemptions at day 60-90
2. **Bank Run**: All holders try to redeem continuously — flow dampening protects
3. **Mixed Issuance**: Monthly financial deposits + weekly labor contributions over 1 year

## Implementation

- `src/composed/myco_surface.py` — Full system class (`MycoSystem`)
- `src/composed/simulator.py` — Scenario runner and built-in scenarios