Date: 2026-07-13
Type: Mechanism design + algorithm research
Status: Proposed (not yet implemented)
Phase: 0 → 1 transition
Observation: BCH volatility will change over time as adoption grows. Fixed 7% buffer is inefficient during low-volatility periods and potentially insufficient during high-volatility periods.
Key realization (2026-07-13):
Fixed parameters:
Example transaction:
María sends €100 to Elena
Isabel locks: €107 (€100 + 7% buffer)
Warning triggers: -3% price drop
Covenant aborts: -7% price drop
Problems:
Measure recent downside volatility, adjust buffer accordingly.
buffer = max(
base_buffer × (downside_vol_30d / historical_avg_downside_vol),
floor_buffer
)
warning_threshold = buffer × 0.43
Parameters:
base_buffer: 7% (baseline from Phase 0)downside_vol_30d: 30-day rolling downside volatilityhistorical_avg_downside_vol: Long-term average (e.g., 5%)floor_buffer: 2% (minimum safety margin)Scenario: BCH price movements over 5 days
| Day | Price | Change | Seller Impact |
|---|---|---|---|
| Mon | €100 | - | - |
| Tue | €105 | +5% | ✅ Good (sent more value) |
| Wed | €103 | -1.9% | ⚠️ Risk (might abort) |
| Thu | €108 | +4.9% | ✅ Good (sent more value) |
| Fri | €106 | -1.9% | ⚠️ Risk (might abort) |
Total volatility: ~4% (up and down equally)
Downside volatility: ~1.9% (only negative days)
Buffer needed:
Capital efficiency improvement: 2× better with downside volatility!
Input: 30 days of daily BCH/EUR prices
Steps:
# 1. Calculate daily returns
daily_returns = []
for i in range(1, len(prices)):
return_pct = (prices[i] - prices[i-1]) / prices[i-1]
daily_returns.append(return_pct)
# 2. Filter only negative returns (downside)
downside_returns = [r for r in daily_returns if r < 0]
# 3. Calculate standard deviation (downside volatility)
downside_vol = std_deviation(downside_returns)
# Example: downside_vol = 0.028 (2.8% daily downside volatility)
Example (low volatility period):
Historical avg downside vol: 5%
Current 30-day downside vol: 2.5%
Buffer = 7% × (2.5% / 5%) = 3.5%
Warning = 3.5% × 0.43 = 1.5%
Floor check: 3.5% > 2% ✓
Isabel locks €103.50 for €100 remittance
Warning at -1.5% price drop
Abort at -3.5% price drop
Example (high volatility period):
Current 30-day downside vol: 8%
Buffer = 7% × (8% / 5%) = 11.2%
Warning = 11.2% × 0.43 = 4.8%
Isabel locks €111.20 for €100 remittance
Warning at -4.8% price drop
Abort at -11.2% price drop
Example (very stable period):
Current 30-day downside vol: 0.8%
Buffer = 7% × (0.8% / 5%) = 1.1%
Floor check: 1.1% < 2% → Use floor = 2%
Isabel locks €102 for €100 remittance (minimum)
Warning at -0.86% price drop
Abort at -2% price drop
Fixed warning problems:
Solution: Warning scales with buffer
warning_threshold = buffer × 0.43
Maintains constant safety margin:
Seller UX:
Risks without floor:
Phase 0 Floor: 2%
Rationale:
Different corridors have different risk profiles:
EUR → VES: 2.5% floor (VES volatility adds risk)
EUR → COP: 2.0% floor (COP more stable)
EUR → PHP: 1.5% floor (PHP very stable)
Phase 0: Use 2% for all corridors (simplicity)
Oracle must provide:
{
"price_eur": 285.50,
"timestamp": 1720900073,
"downside_volatility_30d": 0.028,
"buffer_recommended": 0.035,
"signature": "..."
}
Optional (for debugging):
{
"total_volatility_30d": 0.045,
"confidence_interval": 0.95,
"data_points": 30
}
Option A: Oracle calculates buffer
buffer_recommendedOption B: Covenant calculates buffer
downside_volatility_30dRecommendation: Option A for Phase 0 (simpler, faster iteration)
Potential providers:
Research needed: Which oracle can provide downside volatility reliably?
Scenario: Isabel has €1000 capital
Fixed 7% buffer:
Per transaction: €107 locked
Max concurrent: 9 transactions
Daily volume (if 1-hour avg claim time): €216/day
Dynamic 3.5% buffer (low volatility):
Per transaction: €103.50 locked
Max concurrent: 9 transactions
Daily volume: €225/day (+4%)
Dynamic 2% buffer (very stable - mission accomplished!):
Per transaction: €102 locked
Max concurrent: 9 transactions
Daily volume: €235/day (+9%)
Over time as BCH stabilizes:
More throughput = lower fees = more competitive = more adoption
Goal: Validate that dynamic buffer would have improved capital efficiency without increasing abort rate.
Data needed:
Metrics to measure:
Simulation output:
Hypothesis:
If hypothesis wrong:
Purpose: Establish baseline metrics
Parameters:
Metrics to collect:
Duration: 1-3 months (enough data for 30-day rolling volatility)
Trigger: After Phase 0 baseline established + simulation validated
Implementation:
Success criteria:
| Metric | Phase 0 (Fixed) | Phase 1 (Dynamic) | Target |
|---|---|---|---|
| Average buffer | 7.0% | 4.5% | <5% |
| Abort rate | 2% | 2% | <3% |
| Warning false alarms | 15% | 8% | <10% |
| Seller throughput | 100% | 120% | >115% |
| Capital locked | €107/tx | €104.50/tx | <€105 |
Research phase:
Development phase:
Deployment phase:
Dynamic volatility buffer is a clear improvement over fixed buffer:
✅ More capital efficient (30-50% less locked during stable periods)
✅ Adapts to market (self-regulating system)
✅ Better seller UX (fewer false alarms, higher throughput)
✅ Measurable success (buffer reduction = BCH stabilization proof)
✅ Proven approach (finance industry uses downside risk metrics)
Phase 0 validates the concept with fixed 7% buffer.
Phase 1 implements dynamic buffer based on real market data.
Phase 2+ optimizes algorithm based on production performance.
Next steps: Historical data simulation, oracle research, chipnet testing.
Authors: Suso (concept) + Coordination (documentation)
Date: 2026-07-13
Status: Research complete, ready for simulation and testing