myco-bonding-curve/docs/12-composed-system.md

113 lines
3.6 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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