Why This Design: The Rationale Behind Asgaya
đź“– Unfamiliar terms? See the glossary for definitions.
Purpose: This section explains WHY Asgaya works the way it does.
After understanding The Mechanism (what it IS) and User Journeys (what it LOOKS LIKE), you might wonder:
- Why these specific components?
- Why payment-first covenants instead of escrow?
- Why 7% volatility buffer instead of 5% or 10%?
- Why Bitcoin Cash instead of Bitcoin or Ethereum?
- Why Cash Accounts instead of phone numbers?
This section provides the answers, organized into four categories:
Navigation
What constraints did we start with?
The ultimate goal: Bitcoin Cash merchant adoption
Why remittances? A niche where we can extract value from legacy providers (5-8% fees) and redirect it to merchants as adoption incentive.
Three core requirements:
- Permissionless - No central authority, anyone can participate
- Compliance - Legal to operate without MSB licenses
- Price Stability - Merchants need certainty, not ±20% swings
Sub-requirements under each:
- Permissionless: No custody, no KYC, no central server, autonomous execution
- Compliance: Legal to operate without MSB/CASP/PI licenses (achieved via: payment-first covenants, bank traceability, clear transaction separation, market-rate exchanges only)
- Price Stability: 7% buffer prevents covenant abort (<7% drops). H€/HAu protect sender on abort (>7% drops) and merchant after cash-out
Read this if: You want to understand the problems we’re solving
What design decisions were forced by reality?
The trade-offs and limitations we can’t avoid:
- Regulatory: No custody = no MSB license needed, but also no user support
- Technical: BCH block time = 10 minutes (covenant settlement delay)
- Economic: Volatility buffer must be >7% or sellers lose money
- Social: Reputation systems only work with identity (Cash Accounts)
- Scaling: Passive mode required or liquidity providers quit
Read this if: You want to understand why certain features exist
How to Use This Section
If You’re New
Start with Requirements → understand the problems first
If You’re Technical
Read Constraints → understand the trade-offs
If You’re Skeptical
Review Research Summaries → see the data (RS062, RS039, etc.)
If You Want to Contribute
Check Unknowns → find research gaps and investigation briefs
What’s NOT in This Section
Implementation Details
See: Reference - technical specs, code, APIs
User Guides
See: User Journeys - step-by-step flows
Mechanism Explanations
See: The Mechanism - what components do
This section is purely about “why” - the rationale, constraints, evidence, and open questions.
Contributing to This Section
We welcome contributions:
- Additional evidence (research papers, data analysis)
- Counter-arguments (why this design might fail)
- Regulatory research (what legal risks exist?)
- Alternative approaches (what did we miss?)
How to contribute:
- Open issue on GitHub
- Submit pull request with new evidence
- Investigate unknowns in Unknowns Directory
Navigation
In this section:
Related sections: The Mechanism · Unknowns · Research