Mathematically Backed Asset

A digital reconstruction of what a coin used to be: real metal inside, the minter's stamp on the face. In an MBA the "metal" is proof-of-work BCH sealed inside the issuing covenant, and the "stamp" is the covenant bytecode itself — enforced not by a mint's reputation but by Bitcoin Cash consensus. The reservoir IS the liquidity; there is no issuer treasury, no peg desk, no counterparty.

The heritage — what a coin used to be

Before fiat, a coin was two things fused together: a measured amount of metal, and the minter's stamp pressed into its face. The metal was the value; the stamp was the assertion of authenticity and weight. You could reject the stamp and still trust the coin — a goldsmith's scale told you what the metal was worth. You could trust the stamp and skip the weighing — but only if you trusted the mint.

Both halves mattered. The metal was the sound money: scarce, costly to produce, inherently valuable. The stamp was the convenience layer: it let coins change hands without the weigh-and-assay step every single time.

A Mathematically Backed Asset reconstructs that two-part structure on Bitcoin Cash. The sound money is proof-of-work BCH — scarce, costly, inherently valuable, sealed inside the issuing covenant. The stamp is the covenant bytecode itself: an on-chain program, provably immutable, that identifies the issuer and enforces the conservation rule. The enforcement that physical coinage got from chemistry (metal cannot leave the coin without destroying it), an MBA gets from Bitcoin Cash consensus (BCH cannot leave the reservoir except through the redeem branch, which burns the matching units). Different mechanism, identical property.

What makes it an MBA

An MBA is distinct from an ordinary CashToken in one load-bearing way: the backing is inside the covenant. A conventional CashToken is a mint — someone issues units, someone else owns them, and there is no on-chain commitment that any amount of BCH stands behind them. An MBA's issuing covenant locks backingRateSats satoshis per minted unit into itself at the moment of mint, and refuses to let those satoshis out except via the redeem path that burns the corresponding units.

The practical consequence: an MBA has a floor price it cannot drop below without the covenant breaking. For a 100 sats/unit MBA, 1 unit = 100 sats always, as long as the covenant is spendable. There is no market mechanism that can push it below the backing.

Template families

Every MBA uses one of four cashscript covenants. The one you're reading is identifiable from the templateId byte in the asset's DVMB OP_RETURN sidecar, or from the covenant bytecode itself. Three families are live (CoinMBA, ShareMBA, OracleMBA); the fourth (DynamicMBA) is a reserved slot for the Dynamic Rate Asset covenant.

DynamicMBA is distinct from FIATμ: FIATμ combines a dynamic-rate layer with an oracle signal to track a fiat purchasing-power target, while pure DRA (what DynamicMBA covers) works without any oracle, reflective against a shared pool.

The protocol-level fee behavior is the same across all three: on top of the covenant's own fee, a platform fee of 0.5% currently applies (40% to the Potidaea platform, 60% to the DEA Yield vault), configured in the client at swap-build time. The platform fee is a client enforcement, not a covenant rule — a wallet that strips it still produces a tx the covenant accepts, so trust in that fee rests on the client, not the chain.

How to interact

Three operations, all one chipnet transaction each:

• Claim — pay BCH into the covenant's reservoir, receive MBA units at the covenant's rate. Equivalent to a "buy" or "mint" in other systems. Minimum size is bounded by the chipnet dust floor (546 sats) and the covenant's per-unit rate.
• Redeem — spend MBA units back to the covenant, receive the backing BCH. Equivalent to a "sell" or "burn". No signature from the issuer needed; the covenant's redeem branch has no fee for Static MBAs.
• Swap (BCH ↔ MBA) — a convenience wrapper for claim/redeem exposed by the Potidaea dApp at navigate.st/bns/potidaea.asm. The user clicks "Swap"; the dApp decides whether the underlying operation is a claim or a redeem based on direction.

Trust model — what the covenant guarantees

Reading an MBA is reading a cashscript covenant. The guarantees come from BCH consensus, not from any team or process:

• Backing invariant. Every mint of N units locks exactly N × backingRateSats sats into the reservoir UTXO. The covenant refuses any claim transaction whose output accounting does not match.
• Non-clawback. There is no admin branch. The founder key cannot redirect the reservoir, cannot change the rate, cannot pause claims.
• Fee bounded. founderFeeBps is clamped 0..500 at genesis and cannot be raised afterwards; the covenant verifies it on every claim.
• No burn. MBAs never burn. Supply is bounded by the backing (there must always be a reservoir UTXO redeemable for the outstanding units). This is deliberate — a burn under a backing invariant would silently destroy the equivalent BCH, which no safe design allows.

The guarantees deliberately do not include:

• Price above backing. If someone offers you an MBA for less than its backing on a secondary market, the covenant doesn't care. (You should take the deal; the backing is yours on redeem.)
• Market liquidity. The covenant's reservoir gives you a floor and a ceiling at the same price. If the market trades the MBA at a premium, that premium is unbacked and lives or dies by participant behavior.
• Oracle correctness. For the Oracle family, the signed price feed is the trust root. If the oracle lies, the covenant mints at the wrong rate — no on-chain repair.

Reading MBAs from any BCH wallet

A BCH wallet that holds an MBA category id displays it correctly through either of two sidecars we emit alongside every genesis and publish transaction:

• BCMR (CHIP-2023-04) — the interop standard. Our genesis tx carries a second OP_RETURN of the shape <'BCMR'> <sha256(json)> <url>. The URL points at a canonical JSON file on silentmode.st containing the ticker, name, decimals, icon, and extensions. Every general-purpose BCH wallet — Cauldron, Selene, Zapit, Bitcoin.com, Cashonize, Paytaca — autoresolves the display metadata without needing anything from us.
• DVMB — our native sidecar. Carries the full covenant parameters (template id, rate, fee bps, founder locking bytecode) so our stack can rebuild the covenant locally and build a claim transaction without re-fetching anything. Third-party wallets ignore it. See design/potidaea/src/registry.ts.

If your wallet does not autoresolve a new MBA by itself, paste its 32-byte categoryId into the wallet's "Add asset" / "Import token" dialog — the BCMR auto-fetch will fire from there in most wallets.

What a third-party wallet needs to integrate

Two integration tiers. Pick the one that matches what your wallet already does with other CashTokens.

Tier 1 — display only (balance, name, icon)

Zero per-asset work. If your wallet already reads CashToken categories from an electrum endpoint and already honours BCMR, every MBA shows up correctly the moment the user holds one. The genesis transaction carries a OP_RETURN <'BCMR'> <sha256(json)> <url> output; fetch the URL, verify the hash matches, read identities[categoryId] for ticker/name/icon. Nothing from us needs to be installed, imported, or trusted beyond the BCH chain and the on-chain hash gate.

Requirements: an electrum endpoint, BCMR support (CHIP-2023-04), standard CashToken parsing. All already in Cauldron, Selene, Zapit, Bitcoin.com, Cashonize, Paytaca.

Tier 2 — transact (claim / redeem / swap directly)

Needed if the wallet wants to let the user mint or redeem an MBA without routing them to the Potidaea dApp. Requires the covenant artifact plus the exact transaction shape.

What you need:

• The covenant artifact JSON — the three live templates (CoinMBA, ShareMBA, OracleMBA) and the DynamicMBA scaffold are published at /docs/mba/artifacts/. Pass the right one to new Contract(artifact, [...args]). The artifacts page carries the constructor argument order and a verification example you can copy.
• Constructor args, in order: [tokenCategory: bytes32, backingRateSats: int, founderFeeBps: int, founderLockingBytecodeHex: bytes25]. tokenCategory is the categoryId in VM byte order (reversed from the display hex — cashscript's token.category is byte-reversed vs OP_*TOKENCATEGORY). Fetch these from the DVMB OP_RETURN sidecar on the genesis tx, or from our Katalogos entry's parameters chunk.
• Address derivation: rebuild new Contract(artifact, [cat, rate, feeBps, founderLB]) locally and verify contract.tokenAddress equals the on-chain reservoir address before trusting any sidecar params.

Claim transaction shape (BCH → MBA):

input  [0]     reservoir UTXO at contract.tokenAddress (minting NFT, carries supply)
input  [1..N]  payer's plain BCH inputs

output [0]     fresh reservoir at contract.tokenAddress — new supply balance
output [1]     payer's MBA output at payer's tokenaddr — amount = floor(grossSats / rate)
output [2]     founder fee (sats, plain BCH) → founderLockingBytecodeHex   [if feeSats > 0]
output [3..4]  Potidaea platform fee outputs                               [optional]
output [N-1]   BCH change back to payer

Redeem transaction shape (MBA → BCH):

input  [0..N]  payer's MBA UTXOs (same categoryId); their satoshis field IS the backing
               that will be released. The MBA token outputs are NOT re-emitted — they
               are consumed by the implicit burn (no output carries that category).

output [0]     payer's net plain BCH output
output [1]     dust padding at payer       [only if leftoverBacking < 1000 sats, see dust floor]

No covenant input is required on redeem — MBA UTXOs are plain P2PKH-shaped once held in a wallet; the covenant only polices mint. The reduction in circulating supply is implicit (no output carries the burned category).

Tier 3 — route to Potidaea

If you don't want to ship covenant code at all, deep-link into our dApp: https://navigate.st/bns/potidaea.asm/?from=BCH&to=<ticker>&amount=<sats>. The user signs in Potidaea with their existing wallet (WalletConnect or copy-paste the signed tx hex back), you keep your wallet off the covenant surface entirely. Lowest integration cost, highest UX overhead.

Live chipnet catalog

Deployed and chipnet-verified at the time of writing. Mainnet remains view-only — no MBAs are deployed on mainnet yet.

The protocol swap has been chipnet-validated continuously since 2026 with 52 998 recorded swaps and zero exploits (canonical tally in Parameters/ASM_Native/ASM-single-asset-throughput.md).

For developers

Everything a dApp needs to interact with an MBA sits in two files:

• contracts/CoinMBA.cash — the Static MBA covenant. ShareMBA.cash and OracleMBA.cash live beside it; DynamicMBA.cash is the reserved slot for the DRA covenant.
• design/potidaea/src/orbital.ts — the reference client: builds claim and redeem transactions with cashscript, broadcasts via a multi-source fan-out (own-node BCHN + ephemeral public Fulcrums).

A claim transaction's shape is deterministic:

input [0]      the reservoir UTXO (contract, consumes a minting NFT)
input [1..N]   payer's plain BCH inputs

output [0]     fresh reservoir UTXO (contract, remaining supply)
output [1]     payer's new MBA output (token category = this MBA)
output [2]     founder fee (sats)                       — present if feeSats > 0
output [3]     platform fee (sats)                      — Potidaea convention
output [4]     DEA yield vault (sats)                   — Potidaea convention
output [5]     change back to payer

Rate derivation: amountUnits = floor(grossSats / backingRateSats). Chipnet dust floor forces a minimum claim; for a rate of 100 sats/unit at 1% fee that minimum is 546 sats paid in.

Verify a covenant's identity before trusting any client-supplied params:

1. Rebuild the Contract(artifact, [categoryId, rate, feeBps, founderLB]) locally.
2. Compute the derived contract.tokenAddress.
3. Confirm it equals the on-chain address holding the reservoir. If not, the sidecar params are lying.