asgayapedia

Asgaya Remittances: Inefficient by Design

The Constraint: Seller risk vs custody/compliance

Traditional escrow held client fiat → triggered custody regulation (MiCA/PSD2). Asgaya’s payment-first model avoids this: the seller locks their own BCH only after receiving the sender’s fiat. No entity ever holds client funds.


The Decision: Payment-First + Two-Step Settlement

  1. Sender pays seller via Bizum → seller receives fiat BEFORE funding covenant
  2. Seller locks BCH into covenant (€100 face value + €7 buffer from their inventory)
  3. Covenant requires TWO signatures to claim: recipient + merchant (in-person verification)
  4. If unclaimed after 8 hours → BCH goes to the sender wallet

Note on 8-hour window: Phase 0 hypothesis based on RS062 data (99.45% success at 4-hour windows) + stability layer protecting senders on abort. Allows gathering complete claim-timing data without excessive covenant failures.


The Trade-off

What We Gain

No custody (seller never locks BCH before receiving fiat)
No intermediation (no entity holds funds between parties)
Legal recourse (bank transfer traceable, court precedent)

What We Lose

Recipient friction (must go to merchant in person within 8 hours)
Inefficient UX (extra step vs direct wallet delivery)
Merchant dependency (system fails if no merchants available)


Why This Choice

This inefficiency is intentional. We’re betting recipients accept the friction because:

  1. They’re buying groceries anyway (picking up money = shopping trip)
  2. Merchant provides cash or holds BCH (recipient’s choice)
  3. Right kind of merchants (neighborhood shops, high foot traffic)
  4. They might onboard merchants themselves (recipient agency)

But this is an assumption. Phase 0 validates whether recipients actually tolerate this UX.


Economic Argument: Seller Protection

Even if BCH price crashes past the 7% buffer:

Payment-first + abort mechanism ensures sellers are always BCH-neutral or in profit.


Payment Timeout: 10 Minutes (Phase 0 Hypothesis)

After sender creates covenant and receives payment details:

Note: This timeout is a Phase 0 starting assumption, validated by sender behavior data. May be adjusted based on real-world usage patterns.


Phase 0 Validation

Open Questions:

Success criteria:


Why We Can’t Use Traditional Escrow

Traditional escrow flow:

Sender → Escrow (locks BCH) → Wait for payment confirmation → Release to recipient

Problems:

Payment-first flow:

Sender → Pays Bizum → Seller receives fiat → Seller locks BCH → Covenant → Recipient claims (merchant co-sign)

Advantages:


The Bet We’re Making

Hypothesis: Recipients tolerate inefficiency because the alternative (expensive legacy remittances) is worse.

Western Union:

Asgaya:

The trade: Recipients already go somewhere to pick up money. If that “somewhere” is a neighborhood merchant where they shop anyway, the friction becomes negligible.

If we’re wrong: Phase 0 abort rate will be >50%, recipients will complain, adoption fails. We adjust or pivot.

If we’re right: Recipients prefer cheaper + inconvenient over expensive + convenient. Merchant network becomes moat.



Status: Phase 0 Validation
Last Updated: 2026-06-21
Confidence: Medium (strong rationale, unproven in practice) —

🏠 Home ↑ Constraints 📖 Glossary