asgayapedia

Requirements: What Asgaya Must Achieve

đź“– Unfamiliar terms? See the glossary for definitions.

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.

The Three Core Requirements

1. Permissionless

No central authority, anyone can participate

What this means:

Why it matters:

Design choices driven by this:

2. Compliance

Legal to operate without MSB licenses

Regulatory frameworks analyzed:

EU (operational target - Spain/Venezuela corridor):

US (reference framework - widely understood terminology):

Why both?

Design strategy: Engineer for EU compliance first (strictest requirements), validate against US framework (most discussed in crypto space).

What this means:

Why it matters:

Design choices driven by this:

Compliance is a constraint we wish didn’t exist, but can’t ignore. May 9, 2026 was the day we discovered our elegant, simple escrow-based architecture was illegal under MiCA. The payment-first covenant design is harder to build, harder to explain, and requires more coordination—but it’s the only path to permissionless operation within EU law. This requirement doesn’t make the design better; it makes it legally possible.

3. Price Stability

Merchants need certainty, not ±20% swings

What this means:

Why it matters:

Design choices driven by this:

Sub-Requirements

Each core requirement has specific implementation constraints:

Permissionless Sub-Requirements

Compliance Sub-Requirements

Volatility Protection Sub-Requirements

Requirement #6: Seller Buffer Recovery

Discovered during Phase 1 implementation (July 2026)

The edge case:

t=0:     Covenant funded (0.0075 BCH total)
         ├─ Payment: 0.007 BCH (sender's capital)
         └─ Buffer: 0.00049 BCH (seller's capital)

t=60:    ⏰ Covenant expires
         ├─ Recipient can NO LONGER claim (past expiry)
         └─ Sender device offline/lost/crashed
         
t=60+:   đź”’ FUNDS LOCKED
         ├─ Recipient blocked (expired)
         ├─ Sender can't refund (offline)
         └─ Seller STUCK (no recovery path)

Without seller recovery: Seller’s buffer capital is permanently locked if sender goes offline after covenant expires.

What this means:

Why it matters:

Design choices driven by this:

function sellerRecoverBuffer(sig sellerSig, datasig oracleSig, bytes oracleMessage) {
    // After expiry, seller can split covenant:
    // - Payment → sender address (fair, even though sender offline)
    // - Buffer → seller (recovers own capital)
    require(oracleTimestamp >= expiryOracleTime);  // Only after expiry
    // ... fair split logic ...
}

How it interacts with other requirements:

This requirement emerged from actual chipnet testing, not initial design. Real-world testing revealed the edge case where sender device failure after expiry would lock seller’s operational capital.

How Requirements Drive Design

Example 1: Payment-First Covenants

Example 2: H€/HAu Tokens

Example 3: Nostr Blacklist

Example 4: Three-Path Covenant Recovery

What’s NOT a Core Requirement

Speed:

Cost:

Scalability:

History & Evolution

Key milestones:

Success Criteria

This architecture succeeds when:

  1. âś… Permissionless achieved:
    • Anyone can participate without permission
    • No entity can shut down the protocol
    • Users maintain custody throughout
  2. âś… Compliance achieved:
    • No licenses needed to operate infrastructure
    • Legal to use in Spain, Venezuela, and target corridors
    • Regulatory risk minimized
  3. âś… Volatility protection achieved:
    • Merchants retain 80%+ after 6 months
    • Senders protected from covenant abort losses
    • H€/HAu tokens circulate (not just held)

Phase 0 validates: Do these requirements translate to real-world adoption?

🏠 Home ↑ Why This Design? 📖 Glossary

Related: Constraints

This site is open source. Improve this page.