135 lines
4.1 KiB
Markdown
135 lines
4.1 KiB
Markdown
# Behavioral Stability Analysis
|
||
|
||
From architecture to **behavioral stability**: what the two-layer + PMM stack enables, how the three metrics interact, what to simulate first, and where the system can break.
|
||
|
||
---
|
||
|
||
## 1. What you have systemically
|
||
|
||
### Layer A — Design graph
|
||
|
||
- “What could route”: all 11 chains, all potential cW* pools.
|
||
- Lets you simulate **future expansion** before deploying.
|
||
- Prevents accidental routing exposure when adding pools.
|
||
|
||
### Layer B — Deployment graph
|
||
|
||
- “What actually routes”: defined by `config/deployment-status.json`.
|
||
- **Kill switch**: remove a pool from deployment-status to disable routing.
|
||
- Acts as exposure registry, routing firewall, expansion throttle.
|
||
|
||
That separation is central-bank-grade control: programmable monetary corridor, not just liquidity.
|
||
|
||
---
|
||
|
||
## 2. PMM depth as state variable
|
||
|
||
Depth:
|
||
|
||
```
|
||
D = D_0 · min(1, I_T / I_T^*)
|
||
```
|
||
|
||
This gives:
|
||
|
||
- **Self-limiting router exposure**: drain → D drops → marginal rate worsens.
|
||
- **Endogenous slippage widening**: no ad-hoc circuit breaker needed for normal stress.
|
||
- **Routers drain you → marginal rate worsens → routers leave.**
|
||
|
||
So the mechanism is **mathematically stabilizing**.
|
||
|
||
---
|
||
|
||
## 3. Three metrics — economic interpretation
|
||
|
||
| Metric | Economic meaning | Target / risk |
|
||
|--------|------------------|----------------|
|
||
| **Router capture ratio** | Are you the primary stable swap venue? | High capture = revenue + inventory risk. Low = safer peg, less fee income. |
|
||
| **Inventory churn** | Stress metric: Σ\|ΔI_T\| / I_T^* per epoch | Healthy: 0.3–0.8 normal, <1.5 stress. If churn >1.5–2.0, bot intervenes constantly. |
|
||
| **Intervention cost** | “Monetary defense budget”: bridge/mint/burn to keep peg | Linear in volume → OK. Exponential during topology switch → danger. |
|
||
|
||
---
|
||
|
||
## 4. What to simulate first
|
||
|
||
### A) Hub-only across all 11 chains
|
||
|
||
One PMM per cW per chain vs hub.
|
||
|
||
**Questions:**
|
||
|
||
- Does router capture stabilize around **10–30%**?
|
||
- Does churn remain **<1** under normal volume?
|
||
- Is intervention frequency **periodic** rather than constant?
|
||
|
||
**This is the baseline.**
|
||
|
||
### B) Full-quote on chains 1, 56, 137
|
||
|
||
Enable extra quotes (USDT, DAI, etc.) only on Ethereum, BSC, Polygon.
|
||
|
||
**Watch for:**
|
||
|
||
- Multi-hop reflexivity
|
||
- Increased churn
|
||
- Increased router capture
|
||
- **Nonlinear** intervention cost
|
||
|
||
**Rule of thumb:** If churn increases >50% vs hub model → do not deploy full-quote.
|
||
|
||
### C) Bridge shock scenario
|
||
|
||
Inject e.g.:
|
||
|
||
- 5% supply migration 137 → 56 over 24 blocks, or
|
||
- 10% whale exit on one chain
|
||
|
||
**Measure:**
|
||
|
||
- Time to re-center peg
|
||
- Total bot injection required
|
||
- Peak deviation
|
||
|
||
**Interpretation:**
|
||
|
||
- **Damped oscillator** → good.
|
||
- **Resonant feedback loop** → bad.
|
||
|
||
---
|
||
|
||
## 5. Where it can break (advanced)
|
||
|
||
### Cross-chain arbitrage loops
|
||
|
||
If **bridge cost < slippage difference**, routers do: Chain A → bridge → Chain B → swap → bridge back.
|
||
|
||
**Model must include:** bridge latency + probabilistic settlement delay. Otherwise risk is underestimated.
|
||
|
||
### k too tight globally
|
||
|
||
Default k = 0.1, fee = 25 bps. If inventory target is high and k is tight, you can become the cheapest stable venue on thin chains.
|
||
|
||
**Simulate:** k ∈ {0.05, 0.1, 0.2}. Often **k = 0.15–0.2** is safer cross-chain.
|
||
|
||
### EUR tokens (cWEURC, cWEURT)
|
||
|
||
- FX volatility; USD-quoted hubs; dual-source peg risk.
|
||
- Need: **slightly higher k**, **slightly wider band**, possibly **higher fee**.
|
||
- Do **not** treat EUR and USD tokens symmetrically.
|
||
|
||
---
|
||
|
||
## 6. System-level framing
|
||
|
||
The architecture is a **multi-chain programmable monetary corridor**. Each PMM pool is a **localized peg defense membrane**. `deployment-status.json` is the exposure registry, routing firewall, and expansion throttle.
|
||
|
||
---
|
||
|
||
## 7. Next steps (options)
|
||
|
||
1. Run a synthetic 30-day stress sim and extract equilibrium metrics.
|
||
2. Derive analytical stability conditions for k, fee, D_0.
|
||
3. Design adaptive k control law (automatic routing dampener).
|
||
4. Model MEV + oracle-lag attack surface.
|
||
5. **Derive safe inventory target sizing formula per chain** → see [11-safe-inventory-sizing.md](11-safe-inventory-sizing.md).
|