The Constraint: Capital efficiency vs risk coverage
The Real Question: How do we fix the value delivered — without fixing the BCH price up front?
What the buffer enables is value-guaranteed delivery. By deferring price discovery to when the recipient claims (or the covenant expires or refunds), the fiat value is guaranteed while the BCH price is settled later. Money velocity comes from payment-first (constraint 1); the two are intimately related.
Three forces limit remittance design:
BCH volatility is the price we pay for censorship resistance and zero intermediaries.
What it does:
Why not 5%? More aborts during volatility spikes → system fails when needed most
Why not 10%? 10% locked = less capacity → fewer participants
The comparison:
| Buffer | Success Rate (4h) | Capital Efficiency | Payday Stress | Result |
|---|---|---|---|---|
| 5% | Lower | High | Fails under stress | Sellers avoid peaks |
| 7% | 99.45% (RS062) | Balanced | Holds | Fast recycling + adequate protection |
| 10% | Higher | Low (10% always locked) | Starves capacity | Fewer participants |
Note on 8-hour windows: RS062 tested 4-hour windows (0.55% abort) and 24-hour windows (2.30% abort). 8-hour windows likely fall between: ~0.8-1.2% abort rate. Longer windows = more volatility exposure. Phase 0 measures actual rate.
This section is about capacity — but the enabler is payment-first, not the buffer (constraint 1). The buffer’s own job is value-guaranteed delivery (below).
10 sellers × €500 capital = €5,000 total. 8-hour claim window = 3 cycles/day.
€5K × 3 = €15K daily capacity. × 30 days = €450K monthly. 90x leverage.
Payment-first enables this: Seller receives fiat before funding, locks €107 BCH (€100 face + €7 buffer), recipient claims within 8 hours. Merchant gets €100 of BCH; €7 buffer returns to seller. Seller recycles €100 fiat → next transaction. Minutes between payment and funding; hours until claim (median 2-4h). Buffer rarely consumed (99.45% success). Failed transactions return capital quickly.
Without payment-first — and the fast recycling it enables — this math doesn’t work. The buffer protects each transaction while the capital recycles.
Note: If median claim time is shorter (2-4 hours as Phase 0 hypothesizes), cycles increase to 4-6 per day, improving capacity to €600K-€900K monthly. The 8-hour window is conservative.
From RS039: Remittances aren’t evenly distributed. They spike on paydays.
Spanish salary cycle:
Annual bonuses:
€500K monthly volume distribution:
| Period | Volume | Days | Daily Avg |
|---|---|---|---|
| Week 1 (payday) | €300K | 7 | €43K |
| Week 2-4 | €200K | 23 | €9K |
First weekend concentration:
This tests the limit. Each seller processes one transaction every 35 minutes during peak. 7% buffer holds: fast recycling handles 1.7 tx/hour sustained without breaking.
At €500K monthly volume (Phase 2+ scale), something extraordinary happens.
We become the weekend market: Weekend BCH volume is €250K/day (50% of weekday, 50-70% thinner orderbook). Asgaya payday weekend = €100K Saturday-Sunday = 40% of weekend market. December payday weekend (normal + bonus + holiday surge) = €330K, with €150K Saturday alone = 60% of weekend volume. We don’t just survive BCH volatility. We start to control it.
Foreknowledge arbitrage (Phase 1+ strategy): At scale, we predict our own transaction volume (payday patterns repeat monthly). Sellers pre-buy €100K BCH Friday (high liquidity, better price), use reserves Saturday (no market impact), replenish Monday (post-spike, better price). This is inventory management, not manipulation—Amazon pre-positions stock before Prime Day, airlines hedge fuel before peak travel, Asgaya sellers pre-position BCH before payday.
The dual benefit:
Payment-first enables this: Fast capital recycling allows sellers to accumulate reserves during low-demand periods and deploy during peaks without breaking.
| Area | Question | Hypothesis |
|---|---|---|
| Capital Efficiency | Median claim time? | 2-4 hours, not 8 |
| Cycles/day per seller? | 3-4x | |
| €500 capital supports €45K/month? | Yes | |
| Payday Concentration | Abort rate spike during surges? | No, 7% holds |
| Sellers run out of capital? | Occasionally, self-corrects | |
| % sellers accumulate vs profit? | Unknown | |
| Buffer Adequacy | 7% breach rate in production? | ~0.8-1.2% (8h window) |
| Aborts due to price vs expiry? | Unknown | |
| Market Impact | Volume to move BCH prices? | ~€100K |
| Sellers adopt arbitrage? | Unknown, but incentivized | |
| Asgaya stabilizes or amplifies? | Stabilizes via smoothing |
Success criteria: Abort rate <1%. Capital recycling >2.5 cycles/day. Payday surge handled without liquidity crisis. Sellers report profitability beyond base fees.
It’s an educated guess, not science.
What we know:
What we don’t know:
Note on price spikes: A price spike does not cause an abort — abort only triggers on a drop past the buffer. If the price rises, the covenant settles normally and the funder gets a larger buffer back (less BCH is needed to cover the fiat payment, so more remains as buffer). Spikes are friendly to the funder; only sustained drops are the risk. The payday concern is therefore about downward pressure, not spikes.
The bet:
Back-testing can’t predict human behavior under real incentives. Payday concentration needs live data. Seller recycling behavior is unknown (accumulate vs profit-take).
Phase 0 validates the guess. Then we know.
Phase 0 uses fixed 7% buffer to establish baseline.
Phase 1+ implements dynamic buffer based on recent volatility (RS074: Dynamic Volatility Buffer)
As BCH stabilizes through real-world use, the buffer can shrink:
buffer = max(
7% × (downside_volatility_30d / historical_avg_volatility),
2% // minimum safety margin
)
Example scenarios:
| Market Condition | Downside Vol | Buffer | Capital Locked (€100 tx) |
|---|---|---|---|
| High volatility (Phase 0 start) | 5% | 7% | €107 |
| Medium volatility (Year 1) | 3% | 4.2% | €104.20 |
| Low volatility (Year 2+) | 1.5% | 2% (floor) | €102 |
Why this matters:
Why downside volatility? Sellers don’t care when price goes up—they only risk money on downward moves. Measuring only downside volatility (not total volatility) makes buffers 30-40% more capital efficient.
Dynamic warning threshold: Warning also scales with buffer (buffer × 0.43) to maintain constant safety margin and reduce false alarms.
Phase 0 validates the 7% baseline. Phase 1 makes it adaptive.
The buffer isn’t about moving volume — it’s about guaranteeing value. Capacity (money velocity) comes from payment-first; the buffer is what makes deferred settlement safe.
By deferring price discovery — to the recipient’s claim() (at some point in the future), to expiry() (~8 hours), or to refund() — Asgaya guarantees the fiat value without fixing the BCH price up front:
Without the buffer: a price drop between funding and claim would leave the delivered value short — the value guarantee would break.
With the 7% buffer: value-guaranteed delivery holds through ordinary volatility, and the residual buffer returns to the funder.
The constraint we’re optimizing: not “how do we move the most volume?” (payment-first’s job) but “how large must the buffer be to guarantee value while keeping capital free?”
7% is the answer. Probably.
Status: Phase 0 Validation (Phase 1 dynamic buffer designed)
Last Updated: 2026-07-13
Confidence: Medium (strong back-test data, unproven in production, sensitive to human behavior)
—
| 🏠 Home | ↑ Constraints | 📖 Glossary |