Encrypted. Decentralized. Evidence-based. Accountability without arbitrators.
What happens when a passive user doesn’t complete a transaction?
Scenario:
1. María (active buyer) creates covenant (empty, no BCH yet)
2. María pays seller via cash-in-person / Bizum / SEPA (fiat leaves her account)
3. Seller's phone dies / bot crashes / seller ghosts
4. Seller never locks BCH into covenant
5. Covenant expires as an empty shell (no BCH to refund)
6. María lost her money, must pursue refund manually
This is the payment-first risk model. Active users pay BEFORE BCH is locked. If the seller never locks BCH, the covenant can’t refund anything—it was never funded.
Traditional solution: Central arbitrator reviews evidence, makes judgment, enforces outcome.
Asgaya’s constraint: No central arbitrator. No company to enforce rules. Permissionless.
How do users hold each other accountable without intermediaries?
Critical insight: Not all payment systems work the same.
What varies by payment method:
Asgaya’s approach: Progressive payment rollout
This document describes the framework. Specific evidence formats are documented per payment method.
Why cash-in-person first: Simplest evidence (“Did you receive cash?”), no digital infrastructure dependencies, tests reputation system without parsing complexity.
Active users post blacklist events to Nostr with evidence.
When a passive user fails to complete a transaction, the active user:
No judge. No arbitrator. Just evidence and reputation.
Primary evidence source: The notification listener bot (automated, trustless)
For digital payments (Bizum, SEPA):
For cash-in-person:
Edge case: Active user pays wrong recipient
Problem:
1. María wants to pay seller at +34-612-345-678
2. María types +34-612-345-679 (typo in Bizum app)
3. Payment goes to wrong person
4. Seller never receives payment
5. María blacklists seller (has bank notification showing "payment sent")
6. Seller's reputation unfairly damaged
Solution: Recipient name matching (Bizum Phase 0)
Bizum notifications include recipient name. María’s app checks:
if payment_notification.recipient_name == seller.expected_name:
# Safe to blacklist (payment went to correct person)
allow_blacklist()
else:
# Name mismatch detected
warn_user("You paid someone else. Seller not at fault.")
block_blacklist()
This prevents false accusations automatically.
For payment methods without name verification: Blacklist expires after 30 days if passive user provides counter-evidence (bank statement showing no payment received).
Asgaya’s architecture puts the risk on the active user (the one initiating the transaction).
1. Active user creates covenant (empty shell, no BCH yet)
2. Active user pays passive user via fiat (€100 leaves active user's bank)
3. Passive user's bot detects payment
4. Passive user's bot locks BCH into covenant ← IF THIS NEVER HAPPENS, ACTIVE USER LOSES €100
5. Recipient claims BCH from covenant
Covenant never funded (seller ghosts):
Steps 1-2: María pays €100
Step 3: Seller receives payment
Step 4 NEVER HAPPENS: Seller ghosts, never locks BCH
Result:
✗ Covenant is an empty shell (no BCH was ever locked)
✗ Seller has María's €100 in their bank account
✗ Covenant expires with NOTHING TO REFUND
✗ María must pursue refund manually (blacklist or legal action)
Covenant funded but expired/aborted:
Steps 1-4: María pays, seller locks BCH
Step 5 doesn't happen: Recipient never claims OR BCH drops >7% (covenant aborts)
Result:
✓ BCH returns to María automatically (covenant refund works)
✗ Seller keeps the €100 fiat
⚠️ María gets BCH back (but may have net loss if price dropped)
This is intentional, not a flaw:
Trade-off: Active users take payment-first risk in exchange for permissionless, non-custodial architecture.
For unfunded covenants, blacklist is the ONLY recourse:
This is why reputation and dispute resolution must work reliably. The active user has no other protection.
How we reduce payment-first risk initially:
Phase 1+ relies on: Mature reputation system, large transaction history, market filtering of bad actors.
Scenario A: Malicious passive seller (cash-in-person)
María hands €100 cash to seller at café
Seller counts money, takes it
Seller ghosts (doesn't lock BCH in covenant)
Covenant expires after 24 hours as empty shell
María has no automatic refund (covenant never had BCH)
Seller has her €100, María must pursue manual refund
Scenario B: Technical failure (digital payment)
María pays €100 via Bizum (fiat leaves her bank)
Seller's phone dies mid-transaction
Notification listener bot never sees payment
Bot never locks BCH (covenant remains empty)
Covenant expires with nothing to refund
María must contact seller for manual refund
Scenario C: Malicious passive seller (digital payment)
María pays €100 via Bizum (fiat in seller's bank)
Seller receives payment (bot sees notification)
Seller deliberately doesn't lock BCH (keeps covenant empty)
Covenant expires as empty shell
Seller has María's €100, no BCH was ever locked
María must pursue refund via blacklist pressure or legal action
All scenarios: Payment delivered to seller, covenant never funded, no automatic refund possible.
María’s app prompts:
Transaction not completed.
Want to blacklist this seller?
Evidence required (select one):
• Bot-parsed payment notification (automatic)
• Cash-in-person witness statement
• Manual evidence upload
[Continue] [Cancel]
Evidence by payment method:
Cash-in-person:
Bizum (Spain):
payment.recipient_name == seller.expected_nameSEPA (Spanish IBAN):
For payment methods without programmatic access:
María’s app then:
{
"kind": 30078,
"tags": [
["d", "blacklist_entry"],
["target_cash_account", "Elena#142"],
["evidence_hash", "sha256:a1b2c3..."],
["evidence_type", "bank_notification"],
["amount", "100.00"],
["currency", "EUR"],
["payment_method", "bizum"],
["timestamp", "1719067935"]
],
"content": "encrypted_evidence_blob", // Full SMS screenshot, encrypted
"pubkey": "npub1maria...",
"created_at": 1719067940,
"sig": "signature..."
}
Public data (visible to all):
Private data (encrypted, only accessible to validators):
Blacklist events are not immediately trusted. Validators check evidence:
Phase 0 validators: Trusted community members (Suso, early adopters)
Phase 1+ validators: Any user with high reputation can validate
Validation process:
Consensus threshold: 3+ validators agree → blacklist confirmed
Result:
Beyond Phase 0: Counter-claims replace validators
Goal: Disputes resolve between users. Legal system is the ultimate arbiter.
When blacklist is posted, passive user can:
If both parties blacklist each other:
False accusers get blacklisted too:
Once blacklist is validated, Elena#142’s on-chain reputation reflects it:
// Elena's reputation BEFORE blacklist
{
cash_account: "Elena#142",
total_transactions: 50,
completed_transactions: 49,
completion_rate: 98% // 49/50
}
// Elena's reputation AFTER blacklist
{
cash_account: "Elena#142",
total_transactions: 51,
completed_transactions: 49,
completion_rate: 96% // 49/51 (blacklisted transaction counts as failed)
}
Additionally, Nostr dispute history shows:
Users querying Elena’s profile see: ⚠️ Unresolved dispute (June 22, 2026)
Elena can restore her reputation by refunding María:
Redemption is automated: María’s notification listener bot detects the refund payment, automatically posts resolution event. Elena doesn’t need to ask María to forgive her—evidence of refund is enough.
Bank notifications are notarized proof (push notifications, SMS, or email depending on bank/country).
In Spain (2026): Most banks send push notifications, not SMS. This is actually better—push notifications can be accessed programmatically by the app without requiring screenshots.
Spanish banks (and most KYC’d banks) include in payment notifications:
This is sufficient to prove:
Critical for Bizum (Spain): Notifications include recipient name
This enables automatic false-accusation prevention:
# María's notification listener bot parses outgoing Bizum notification
payment = parse_bizum_notification(notification)
if payment.recipient_name == seller.expected_name:
# Payment went to correct seller, safe to blacklist if covenant expires
allow_blacklist()
else:
# María paid wrong person (typo in phone number)
warn_user("Payment sent to '{payment.recipient_name}', not seller '{seller.name}'")
block_blacklist() # Seller not at fault
Without name verification (some payment methods): Blacklist requires additional evidence or expires after 30 days if disputed.
Editing a bank notification is document forgery. In Spain, this is “falsedad documental” (Article 390-392, Spanish Penal Code): 6 months to 3 years in prison. For a €100 dispute, facing felony charges is irrational. Banks can verify transaction existence via transaction ID, making fraud easy to prove.
Banks act as de facto notaries—the notification is trusted third-party evidence without requiring a third-party arbitrator.
If evidence is disputed, validators can: check transaction ID with bank APIs, request full bank statements, contact seller’s bank to verify non-payment, or compare payment details hash with on-chain covenant data. False accusations are quickly detected.
Digital payment scenario:
María pays seller via Bizum
Seller's phone battery dies
Notification listener bot never sees payment
Bot never locks BCH
Covenant expires empty—no automatic refund, María must pursue seller
Cash-in-person scenario:
María hands €100 cash to seller at café
Seller's phone is dead, can't confirm receipt in app
Covenant expires empty—no automatic refund
María must pursue seller for manual refund
Who’s at fault? Seller (passive role = responsibility to maintain infrastructure).
What happens:
Fair outcome: Passive sellers are responsible for uptime. If their infrastructure fails, they must make it right.
Digital payment:
María pays seller via Bizum
Seller's notification listener bot has a parsing bug
Bot doesn't recognize the new notification format
Bot never locks BCH
Covenant expires as an empty shell—no BCH was ever locked
Cash-in-person:
María hands cash to seller
Seller confirms receipt verbally but forgets to tap "Confirm" in app
Bot waiting for confirmation, never locks BCH
Covenant expires as an empty shell—no automatic refund
Same outcome as Edge Case 1: Seller’s responsibility to maintain working systems.
Mitigation for Phase 1+:
Phase 0 approach: Blacklist first, resolve later. Bias toward protecting active users (they took the capital risk by sending payment first).
Digital payment false claim:
María never paid seller (covenant expired empty, no refund to get)
María fabricates bank notification (attempts to blacklist seller anyway)
Cash-in-person false claim:
María never met seller
María posts blacklist claiming she handed cash
Outcome (Phase 0 with validators):
Outcome (Phase 1+ with counter-claims):
Why this is rare:
Seller realizes bot failed
Seller manually refunds María before she blacklists
María receives refund
No blacklist needed. María can optionally post a “positive resolution” note (increases seller’s reputation for handling failure gracefully).
Incentive for sellers: Refund immediately when you realize a problem. Faster resolution = less reputation damage.
When a blacklist event is posted:
Why encrypt evidence?
Phase 1+ improvement: Zero-knowledge proofs could prove “bank SMS exists” without revealing contents, even to validators. Phase 0 accepts encryption as sufficient.
| Feature | Nostr Blacklist | Central Arbitrator | No System |
|---|---|---|---|
| Speed | Minutes (post evidence) | Days-weeks (review, decision) | N/A (no recourse) |
| Cost | Free | $10-50 per case | Free |
| Censorship | Resistant (decentralized) | Vulnerable (company can refuse) | N/A |
| Evidence | Bank notifications | Submitted to company | N/A |
| Enforcement | Reputation drop (social) | Account ban (technical) | N/A |
| Redemption | Automatic (refund detected) | Manual (company decides) | N/A |
| Permissionless | ✅ Yes | ❌ No (company controls) | ✅ Yes |
Trade-off: Nostr blacklist relies on social enforcement (reputation), not technical enforcement (account ban). A blacklisted user can still try to transact—but no one will accept. Central arbitrators can ban accounts completely.
Why social enforcement works: Active users check reputation before sending fiat. A seller with 96% completion rate and a recent dispute is skipped in favor of a seller with 99% completion rate and clean history. Market-driven accountability.
Dispute resolution is fully automated. Users don’t manually monitor transactions—bots handle detection, evidence collection, and posting:
Notification Listener Bot (Passive Seller):
Dispute Listener Bot (Active Buyer):
Validator Bot (Phase 0 only):
| Area | Question | Hypothesis |
|---|---|---|
| Evidence Quality (cash) | Is witness statement sufficient for cash-in-person disputes? | Yes (burden of proof on accuser) |
| Evidence Quality (Bizum) | Do push notification parsing + name matching prevent false accusations? | Yes (recipient name verification catches payment errors) |
| Evidence Quality (SEPA) | Are SEPA notifications parseable without screenshots? | Yes (push notification access works) |
| False Accusation Rate | % of blacklist events that are false/disputed? | <1% (name matching catches errors, tampering is a felony) |
| Redemption Rate | % of blacklisted users who manually refund? | >80% (reputation is valuable) |
| Validator Efficiency | Time to reach 3+ validator confirmations (Phase 0 only)? | <48 hours |
| User Trust | Do users check blacklist history before transacting? | Yes, >90% |
| Payment Method Adoption | Which payment methods see most usage? | Cash-in-person (simplest), then Bizum (documented) |
Success criteria:
80% redemption rate (blacklisted users refund to restore reputation)
90% users check dispute history before selecting passive counterparty
| Limitation | Impact | Mitigation | Why We Accept |
|---|---|---|---|
| Social enforcement only | Blacklisted user can still attempt transactions | Active users check reputation before sending fiat; low completion rate = no business | Technical enforcement (account bans) requires central authority (unacceptable) |
| Validator trust | Must trust validators to honestly assess evidence | Phase 0: trusted community; Phase 1+: reputation-weighted voting | Zero-knowledge proofs (Phase 2+) could eliminate validator trust |
| Evidence required | Active user must keep bank notifications | Standard practice for financial transactions; most users screenshot automatically | Without evidence, blacklist system is vulnerable to false accusations |
| 24-hour grace period | Passive user has 24 hours before covenant expires (can ghost for 24h) | Acceptable capital lockup for active users; prevents instant blacklisting without waiting | Shorter timeout = higher false positive rate (bot delays, bank delays) |
| No refund guarantee | Blacklisted user may never refund | Active user gets automatic covenant refund only if BCH was locked (funded covenants); for unfunded covenants, blacklist is the only recourse | Permissionless system can’t force refunds (no company to enforce) |
Dispute resolution isn’t perfect. It’s permissionless and payment-agnostic.
Traditional systems have central arbitrators who can enforce outcomes (ban accounts, force refunds). Asgaya has evidence and reputation. Users choose who to trust based on completion rate and dispute history.
The market decides. A seller with 99% completion rate and no disputes outcompetes a seller with 96% and a recent blacklist. Reputation is valuable, so users refund to restore it. Accountability without authority.
Safety over speed. Asgaya starts with cash-in-person (simplest, no digital dependencies) and progressively adds payment methods only after they’re fully documented and tested. Each corridor expands when users demand it and verify the implementation works.
Cash-in-person + Bizum in Spain is revolutionary enough. Adding 50 payment methods on day 1 would be fast. Deeply understanding each payment system before launching is safe. We choose safe.
Status: Phase 0 Implementation
Last Updated: 2026-06-22
Confidence: High (bank notifications proven as evidence, blacklist reuses Nostr infrastructure)
—
| 🏠 Home | ↑ Nostr Coordination | 📖 Glossary |