Purpose: Single source of truth for all Asgaya terminology.
Asgaya is an Asturleonese word — the Romance language of Asturias and León (with its Mirandese kin just across the border in Portugal) — meaning “in abundance, plenty”, as in sidra a esgaya (“cider in abundance”). The everyday form asgaya is a contraction of the locution a esgaya, from the verb esgayar (“to break off, split”) — the image of things arriving in quantity.
The name is the promise: a fiat ↔ BCH market in abundance — enough sellers, merchants and liquidity — so that moving money across borders gets cheap for everyone.
A permissionless peer-to-peer protocol built on Bitcoin Cash, delivered as a wallet designed to make remittances simple and affordable. Its mission is to promote merchant Bitcoin Cash adoption by turning every remittance into an opportunity for circular economy growth. It uses a decentralised bulletin board and covenant smart contracts to connect BCH sellers with senders and merchants with recipients, without any central server or custodian.
The decentralised marketplace where BCH sellers and buyers discover each other. In Phase 0, listings are signed Nostr events (NIP-99) that any client can read and cache; anyone can post without permission. A small on-chain anchor (a per-seller NFT carrying the essential fields) is planned for Phase 0+ — it makes listings censorship-resistant and enumerable on-chain, still with no central server.
A Bitcoin Cash smart contract that locks BCH and releases it only when specific conditions are met. In Asgaya, covenants are used to coordinate multi‑party remittances: a seller funds a covenant after receiving fiat, and the BCH is released when the recipient (and optionally a merchant) co‑signs.
A human‑readable name permanently registered on the BCH blockchain (e.g., Elena#142). Cash Accounts serve four simultaneous roles in Asgaya: user identifier, covenant recipient field, payment reference on bank transfers, and bot lookup key. They eliminate the need for phone numbers, email addresses, or long cryptographic addresses.
The architectural principle that a BCH seller never locks their BCH into a covenant until after their bank confirms receipt of the sender’s fiat payment. This eliminates the seller’s capital risk and avoids creating a custodial or money‑transmission relationship.
The compliance separation between the remittance (sender → recipient) and the subsequent commerce (recipient selling BCH to a merchant). The recipient owns the BCH after claiming it from the covenant, making the second transaction a voluntary peer‑to‑peer sale.
The design choice that lets the recipient decide when to claim a remittance, rather than having the sender push it automatically. The pull system compresses volatility exposure to the few seconds of the cash‑out event and creates merchant foot traffic.
Extra BCH that a seller locks into a covenant (currently 7 % above face value) to protect the recipient and merchant from moderate price drops during the claim window. If BCH drops far enough that the collateral can no longer cover the face value, the covenant aborts and the BCH returns to the sender. The buffer is not a fee—it is the seller’s own capital that returns to them when the covenant settles normally.
A notification sent to both sender and recipient when the BCH price drops by 3 % from the covenant’s starting price. It warns the recipient to claim soon before a potential 7 % abort. This is a Phase 0 hypothesis, not a guaranteed protection.
The set of mechanisms that allow merchants (and senders) to convert volatile BCH into value‑stable tokens (H€ or HAu). Planned (Phase 1+) — designed but not built. It uses pooled AnyHedge contracts and CashTokens to mint EUR‑pegged or gold‑pegged tokens.
A BCH‑native CashToken pegged to the Euro via pooled AnyHedge contracts. 1 H€ is always worth approximately €1. It can be minted at covenant lifecycle endpoints (abort or merchant cash‑out). Bootstrap: founder‑provided long side; later: open long‑side market.
A BCH‑native CashToken pegged to the price of gold (XAU) via pooled AnyHedge contracts. It serves as a universal stable value alternative, especially attractive to merchants who want to escape both BCH volatility and local‑currency depreciation.
The Phase 0 liquidity pool that takes the long (speculative) side of all AnyHedge contracts backing H€ and HAu tokens. Funded by the founder, it will be replaced in Phase 1+ by a crowdfunded, community‑operated long‑side pool.
The three revenue streams a merchant earns from a single remittance: (1) a 0.5 % spread on the cash‑out, (2) product margin on groceries the recipient buys during the visit, and (3) the BCH position itself, which can be stabilised into H€/HAu or recycled as a seller.
When a participant operates simultaneously as a BCH seller and a BCH buyer, earning fees on both sides of the corridor. Common among dual‑citizens with bank accounts in both Spain and Venezuela.
A local community member who recruits merchants, builds trust, and often becomes that merchant’s preferred BCH buyer. Onboarders are critical to the cold‑start strategy and may earn the right to become Phase 0 sellers or buyers.
All roles collapse into two fundamental types: BCH Seller (has BCH, wants fiat) and BCH Buyer (has fiat, wants BCH). The traditional labels below are just context‑specific names for these two types.
A BCH buyer who purchases BCH from a seller and sends it via covenant to a recipient. Typically someone sending remittances (e.g., María in Spain).
A BCH seller who receives BCH through a covenant and either keeps it or sells it to a local merchant for cash. Typically the family member receiving the remittance (e.g., Elena in Venezuela).
A BCH buyer whose payment method is “cash at a physical shop.” Merchants provide cash‑out services for recipients and earn spreads, product margins, and stability‑layer benefits.
Someone who lists on the bulletin board as a seller, accepts fiat payments (via Bizum, SEPA, or cash), and uses the notification bot to automatically lock BCH into covenants. They earn a fee per transaction (a Phase-0 bootstrap default of ~0.5 %).
Someone who lists on the bulletin board as a buyer, provides fiat in exchange for BCH, and may stabilise received BCH into H€ or HAu. Merchants are the primary passive buyers.
A professional liquidity provider who operates both as a passive seller and a passive buyer, often recycling the same BCH across multiple transactions. Traders earn fees on volume rather than capital size.
(see Core Concepts)
A BCH seller who issues proper invoices for business clients, typically for larger freelance payments. Same architecture as a regular seller, but with professional documentation.
The non‑custodial BCH wallet where users hold BCH, register Cash Accounts, create covenants, and sign transactions. It also generates Nostr keys and serves as the identity foundation.
(see Core Concepts)
The encrypted peer‑to‑peer messaging layer used to coordinate between counterparties — payment details (sender ↔ seller), the recipient claim, and the cash‑out sale (recipient ↔ merchant). Messages are sent over public relays but are end‑to‑end encrypted using NIP‑17 gift‑wrap (NIP‑44 encryption); it also carries blacklist warnings and covenant‑funded notifications.
The automation engine running on a passive seller’s device. It intercepts bank/payment notifications, extracts Cash Account references, matches them to unfunded covenants via Electrum, and automatically locks the seller’s BCH into the covenant.
(see Core Concepts)
A user’s Nostr public key (npub…) and private key (nsec…). The npub is the coordination address others message; on the bulletin board the listing is signed by the poster’s npub, which is also what verifies the poster’s identity.
The private‑messaging standard Asgaya uses. Each message is wrapped in three layers: a kind‑14 rumor (the payload, unsigned), a kind‑13 seal (encrypted, signed by the sender’s real key), and a kind‑1059 gift‑wrap (encrypted, signed by a random one‑time key). Replaces the deprecated NIP‑04; NIP‑44 provides the encryption.
In cash‑out, the merchant answers a sale request with a pre‑signed quote carrying a short time‑to‑live (e.g. 60 s) and a unique id. The recipient must co‑sign inside the TTL, and the merchant broadcasts only the live quote — so a stale price can never be used.
Asgaya has no heartbeat or presence system: a prompt reply is the proof the other side is online (the request proves the sender, the reply proves the responder). The cash‑out exchange finalises in seconds.
The merchant broadcasts the cash‑out transaction (BCH moves first) and only then hands over the fiat. Until the transaction is confirmed a competing spend could still win, so remote or larger trades wait for a confirmation.
The Phase-0 bootstrap default total fee is ~1 %, split equally: 0.5 % to the BCH seller who provided the BCH, and 0.5 % to the merchant who provided cash‑out services. The protocol takes no fee. (The poster sets its own fee per ad; the reference rate is a guardrail.)
The ability of a passive seller to immediately reuse fiat received from a sender to replenish their BCH inventory (via exchange), while the original BCH is still locked in the covenant. Enables small capital to process high transaction volumes.
The number of times the same capital is turned over per day. Payment-first enables high money velocity — the seller is paid before funding, so the fiat can replenish BCH immediately — letting a small capital base serve a large remittance market.
The phased approach from a curated Phase 0 (trusted sellers, coordinator‑vetted merchants) to a fully permissionless Phase 3 (bonded, reputation‑based, on‑chain enforcement). Decentralisation is delayed until the model is proven.
The Phase 0 plan to bootstrap a two‑sided marketplace: recruit 150 senders and 5 merchants through personal networks, onboarders, and freelancers, and validate all economic and behavioural assumptions before scaling.
The decision to support only physical methods (cash in person, card in person) and a few well‑documented digital payment methods (Bizum, SEPA) at launch, adding new methods only after they are thoroughly researched and tested by community pioneers.
A permanent reputation marker awarded to users who document a new payment method or corridor. Pioneers earn higher trust scores and are credited in the protocol’s release notes.
The insight that Venezuelan merchants and recipients face a currency (VES) that is far more volatile than Bitcoin Cash. Holding BCH (or H€/HAu) is not a speculative gamble—it is a rational escape from guaranteed hyperinflation losses.
The mechanism by which permissionless access accelerates adoption: anyone can join, so the first merchant’s success is visible and competitors can replicate it without gatekeepers. Competitive pressure drives growth faster than any centralised onboarding programme.
A lightweight Bitcoin Cash server that provides blockchain data (UTXOs, transaction history, covenant state) via a JSON‑RPC interface. Asgaya apps use public Electrum servers to monitor covenants and verify on‑chain state; bulletin-board discovery is Nostr in Phase 0.
A Bitcoin Cash unspent transaction output that carries a non‑fungible token (CashTokens NFT). In Asgaya, the planned Phase-0+ on-chain anchor is an NFT UTXO whose commitment holds the listing’s essential fields (identity, asset, payment methods, fee); covenants also use NFTs.
A Bitcoin Cash script opcode that allows embedding arbitrary data (up to 223 bytes) in a transaction. Used for Cash Account registrations, payment‑info exchange (encrypted), and on‑chain fallback for Nostr messages.
The native token standard on Bitcoin Cash, enabling both fungible tokens (like H€ and HAu) and non‑fungible tokens (like the Phase-0+ listing anchor and covenant credentials).
A mature (since 2020) Bitcoin Cash protocol for non‑custodial bilateral hedge contracts. Asgaya’s stability layer uses pooled AnyHedge contracts to back H€ and HAu tokens.
A BCH‑native overcollateralised stablecoin created by the Moria Protocol. MUSD was evaluated as a potential settlement asset but was found to be too immature for Phase 0 (it suffered a critical failure in April 2026).
A method for lightweight clients to verify transactions without downloading the full blockchain. Asgaya’s mobile wallet can operate in SPV mode, though it primarily relies on Electrum servers for convenience.
Accepting a Bitcoin Cash transaction as valid before it is included in a block. Safe for the small amounts involved in Asgaya remittances due to BCH’s low double‑spend risk. Enables the sub‑minute settlement experience.
Terms from the reference Android implementation (AsgayaHusk). These appear in docs/implementation/.
A Bitcoin Cash script address type where the covenant’s redeem script is hashed with SHA‑256 (32‑byte hash). Covenant addresses in Asgaya are P2SH32 (bchtest:...). Contrast with P2SH20 (20‑byte RIPEMD‑160 hash, used for standard script addresses).
The P2SH32 address that locks BCH into a covenant. Funding is sent to this address; claiming/refunding/aborting spends from it.
The Electrum‑protocol index key for an address: the SHA‑256 of the locking script, byte‑reversed. Electrum servers don’t work with addresses directly — clients convert addresses to scripthashes before querying balance, UTXOs, or history.
An output of a transaction that has not yet been spent. In Asgaya, covenant operations are “spending” a specific covenant UTXO. UTXO selection (which unspent outputs to use as inputs) is part of transaction building.
A Base58‑encoded format for a private key, prefixed to indicate network (mainnet K/L, testnet c). In the app, SignatureTemplate(senderWIF) signs a covenant transaction with the sender’s private key. Never log or share WIFs.
A flag in a Bitcoin signature indicating which parts of the transaction are signed (and thus bound) by the signature. Covenant spends use specific SIGHASH types to enforce that outputs match the contract’s rules.
The pool of unconfirmed transactions a node has received but not yet included in a block. A broadcast transaction first enters the mempool, then a block, gaining confirmations over time. Asgaya tracks BROADCAST → MEMPOOL → CONFIRMED.
Sending a signed raw transaction (hex) to the network via an Electrum server. In the v0.2 hybrid, this happens in Kotlin (ElectrumClient.broadcast()), not in the WebView.
Re‑sending a transaction that was dropped from the mempool (e.g., after a network issue). Asgaya checks for unconfirmed pending transactions on app resume and rebroadcasts if needed.
An embedded browser component in an Android app that can run JavaScript. Asgaya uses a WebView to run the CashScript SDK (JavaScript‑only) for covenant transaction building. In the v0.2 hybrid, the WebView does compute only (build + sign); all network operations happen in Kotlin.
The architectural pivot (Aug 20‑21, 2026): WebView = compute (build/sign transactions); Kotlin = network (UTXO fetch + broadcast). Solves the WebView connection‑hang bug (JavaScript timers pause on screen‑off, leaving WebSocket connections hanging). Uses TransactionBuilder.build() instead of .send().
An Android architecture component that survives activity destruction (screen rotation, navigation). Asgaya’s SendViewModel uses viewModelScope so transaction broadcasts aren’t cancelled when the user navigates away. Part of the RS083 patterns.
The CashScript SDK class that assembles a signed transaction from inputs (UTXOs), outputs, and unlockers. build() returns the signed hex locally; send() broadcasts AND polls for confirmation (up to 10 minutes) — never use send() in the WebView.
The Electrum server implementation Asgaya runs on Pi‑chan (testnet). Ports: 60001 TCP (balance/UTXO/broadcast), 60003 WebSocket (brief covenant UTXO fetch), 60004 WebSocket‑Secure (reserved).
The price‑feed component that signs exchange‑rate messages (CHECKDATASIG‑verifiable). Asgaya fetches the oracle pubkey dynamically from the Pi‑chan oracle API (/oracle/info) — zero hardcoded keys. Oracle signatures are inputs to claim/refund/abort covenant spends.
A parallel Bitcoin Cash blockchain with worthless coins, used for safe development and validation. All Phase 0 covenant testing happens on testnet3 before mainnet. (Chipnet is a separate testnet used for covenant‑upgrade testing.)
These terms have been deliberately replaced in the documentation to maintain regulatory clarity and architectural accuracy.
| ❌ Avoid | ✅ Use Instead | Reason |
|---|---|---|
| Escrow | Covenant | Escrow implies a central custodian holding funds |
| Liquidity Provider (LP) | BCH Seller or BCH Buyer | LP was a pre‑covenant role eliminated in May 2026 |
| Platform | Protocol or Bulletin Board | Asgaya is not a company‑run platform |
| Account | Cash Account or Wallet | There are no user accounts on a server |
| Order | Listing | No central order book exists |
| Trade | Transaction or Exchange | Avoids securities‑law connotations |
| Buy/Sell BCH | Trade BCH | Regulatory‑safe language for UI |
| Fee / Spread | both are used — spread (the concept), fee (the app’s per‑ad field) | the poster sets its own rate; there is no protocol fee |
| Kraken | Exchange (generic) | a soft preference — the oracle’s source feed is an implementation detail |
fee, and v0.2 hybrid implementation terms.