deviant/Parameters/deviant_technical_spec_v2_8.md

Deviant Wallet — Technical Specification v2.8

Verified against snapshots 0001–0021

Compiled 2026-05-18. Status markers: ✅ Validated on chipnet | 🔧 Specified, not yet implemented | ❓ Open question

Changes from v2.7: (1) Dual-register asset names added — MBA = Minted Backed Asset (technical) / Mathematically Backed Asset (broad); DEA = Direct Emission Asset (technical) / Deviant Equilibrium Asset (broad); spec leads with the technical name. (2) NBA family naming — the right-hand (no-backing) family is now NBA (Non-Backed Asset) with Token / classical tokens as the familiar parallel; "Token" remains the wallet display label. (3) UI names restructured — SPECTRUM is now the filterable Asset List (backed/non-backed + subcategory/use-case filters), ORBITAL is the Explorer (market-cap-style data), and the ASM swap interface is now AGORA (formerly "Orbital Network"). Pending (see reconciliation report): OP_RETURN→NFT-commitment backing marker, validation/status refresh to current snapshots, founder-fee cap framing, stablecoin classification vs ADR-0028, and DRA + divisibility sections.

Changes from v1: Reservoir model corrected, contract function names corrected, redemption mechanics corrected, D-1 implementation corrected, T-002 added, Phase 2 progress updated, fee amounts corrected, library specifics added.

Changes from v2.0: 10 BCH rate tier added to ALLOWED_RATE_TIERS. Parameters added to vocabulary.

Changes from v2 (historical — at the time of v2.1 only): Asset taxonomy was restructured to reflect the canonical parent/child relationship — MBA is the single parent category, with DEA, PLA, MCA, MTA as four direct child classes. Section 4 was rewritten at v2.1 with seven subsections walking from traditional finance through the MBA position. Note: §4 was subsequently removed in v2.6 — the positioning content was relocated to the project corpus, with only the canonical MBA definitions and wallet display rules retained inside the spec. The original v2.1 subsection structure was:

• §4.1 (new) establishes how traditional finance relates an asset to its value — two relationships: direct value (the asset IS its value, market-priced, no operative backing claim) and declared backing (the asset is a claim on an underlying, soft-enforced). Fiat and fiat-pegged stablecoins are explicitly noted as occupying both columns: declared backing structurally present, but not operatively accessible to typical holders, so they function as direct-value assets in practice. The section incorporates the empirical record of soft-backing failure: NYAG/Tether settlement Feb 2021, Terra/UST collapse May 2022, USDC depeg during the SVB failure March 2023. The closing structural test names the diagnostic for hard vs soft backing: whether the asset's price equals its rate by construction (hard) or approaches it through market mechanisms with observable deviation (soft).
• §4.2 introduces the three-layer view: Layer 1 (pure assets — gold, BTC, BCH), Layer 2a (soft-backed derivative claims — gold certificates, WBTC, USDT, bonds), Layer 2b (strict-backed derivative claims — the MBA Standard, novel).
• §4.3 states the categorical distinction at the enforcement layer (soft vs strict).
• §4.4 pairs each MBA class with its real-world Layer 2a soft-backed peer.
• §4.5 provides canonical definitions of the four MBA classes.
• §4.6 scopes the wallet's "Token" display category.
• §4.7 specifies wallet display rules.

OLA expansion corrected to canonical definition (later renamed to PLA in v2.3); MCA expansion corrected from "Managed Certificate Asset" to "Deviant Managed Asset" (later reverted to "Managed Certificate Asset" in v2.4 to restore M-C-A acronym integrity). Supply terminology decoupled from reservoir implementation throughout — "reservoir" now scoped to the technical contract UTXO; "supply" used for the economic property. Deflationary property reframed as a consequence of the current CashScript reservoir behavior, not a designed economic property of the MBA Standard. Glossary reorganized into six topical sub-tables with peer-asset-class references added to MBA class entries.

---

1. Project Overview

Deviant is a non-custodial BCH wallet supporting two classes of instruments:

1. Standard CashTokens — CashTokens with no MBA backing: the Non-Backed Asset (NBA) family (familiar parallel name: Token / classical tokens), displayed as the wallet's "Token" category. These cover a wide range of legitimate use cases (memberships, credentials, conventional tokens) but carry no protocol-level redemption floor.
2. Mathematically Backed Assets (MBAs) (technical: Minted Backed Assets) — BCH backing locked at genesis, unconditionally redeemable at a fixed rate without a custodian, purely based on mathematics.

The MBA Standard is a new asset class. In the three-layer view of the asset landscape (see Traditional Asset Types and Backing Standards in the project corpus), it occupies Layer 2b — strict-backed derivative claims: instruments structurally parallel to existing Layer 2a soft-backed claims (gold certificates, WBTC, USDT, bonds), but with the claim-to-underlying relationship enforced by protocol invariant rather than by custodian, issuer, or institutional commitment. The MBA Standard is not a substitute for Layer 1 pure assets (BCH itself, gold, BTC); it is a category of derivative claim whose enforcement mechanism is consensus rather than trust.

Product statement (finalized):

Deviant wallet allows users to issue Mathematically Backed Assets with a predetermined set of rules, unconditionally redeemable at a fixed rate without a custodian — purely based on mathematics. Unlike traditional tokens and NFTs, which have no locked peg, depend on intermediary trust, and are subject to market manipulation.

---

2. Technical Foundation

2.1 Stack (from snapshot 0001)

• Language: TypeScript
• Runtime SDK: cashscript (CashScript runtime, separate from compiler)
• Compiler: cashc@0.12.1 — important: cashscript@0.12.x does not export compileFile. The compiler moved to a separate cashc package. Importing compileFile from cashscript silently fails.
• BCH library: mainnet-js 3.1.7
• Networks: chipnet primary (mainnet-js TestNetWallet defaults to chipnet via wss://chipnet.imaginary.cash:50004), testnet4 fallback (config change only)

2.2 BCH Base Layer

• Supply cap: 21,000,000 BCH — fixed at protocol genesis, permanent
• Key upgrade — May 2022: Transaction introspection opcodes live (OP_OUTPUTBYTECODE, OP_OUTPUTVALUE, OP_OUTPUTTOKENAMOUNT, OP_OUTPUTTOKENCATEGORY, OP_INPUTINDEX, OP_UTXOTOKENCATEGORY) — prerequisite for Architecture A
• Key upgrade — May 2023: CashTokens — native miner-level FT and NFT validation

2.3 CashTokens — Critical Properties

• FT supply is fixed at genesis. A minting NFT lets the holder create new NFTs of the same category but cannot create new FTs. output_FT_sum > input_FT_sum returns tokenValidationOutputsExceedInputs at consensus level with no exception for minting-NFT-bearing inputs. (Verified in libauth source, snapshot 0008.)
• Category IDs are stored in consensus (little-endian) order on-chain. TXIDs are displayed big-endian (RPC order). Libauth byte-reverses string category fields when encoding tx outputs but does NOT reverse bytes constructor arguments.
• Developer footgun: txidToConsensusBytes(displayHex) = hexToBin(displayHex).reverse(). Pass display TXID directly → constructor disagrees with OP_OUTPUTTOKENCATEGORY. Applied in genesis, mint, and swap scripts.
• Dust limit: ~546 bits minimum output value — load-bearing for contract integrity (see §5.3)
• NFT capability encoding: OP_*TOKENCATEGORY returns 33 bytes for NFT outputs (32-byte category + 1-byte capability) and 32 bytes for FT-only outputs.

---

2.4 Asset Class Definitions

The wallet recognizes eight asset classes organized along three binary properties:

• Backing: Fixed-rate (MBA) / No rate (NBA — Non-Backed Asset; familiar: Token)
• Mint rule: Permissionless / Managed
• Supply: Unlimited / Limited

Two binary axes (mint × backing) define four quadrants; each quadrant contains two sub-classes distinguished by supply.

Naming — dual register. Asset names run in parallel: a technical/structural name and a broad-audience name, both canonical. This spec leads with the technical name. The two assets with a distinct second reading are MBA = Minted Backed Asset (technical) / Mathematically Backed Asset (broad), and DEA = Direct Emission Asset (technical) / Deviant Equilibrium Asset (broad). PLA, MCA, and MTA use their single structural names (Permissionless Limited Asset, Managed Certificate Asset, Managed Tranche Asset). The non-backed family is NBA = Non-Backed Asset (technical) / Token, classical tokens (familiar) — its members are PTU/PTL/MTU/MTL, whose code letter "T" reflects the familiar "Token" name; "Token" also remains the wallet's user-facing display category.

The Quadrant

                ┌───────────────────────────┬───────────────────────────┐
                │      FIXED RATE  (MBA)    │      NO RATE  (NBA)       │
┌───────────────┼───────────────────────────┼───────────────────────────┤
│ PERMISSIONLESS│   DEA   ·   unlimited     │   PTU   ·   unlimited     │
│               │   PLA   ·   limited       │   PTL   ·   limited       │
├───────────────┼───────────────────────────┼───────────────────────────┤
│ MANAGED       │   MCA   ·   unlimited     │   MTU   ·   unlimited     │
│               │   MTA   ·   limited       │   MTL   ·   limited       │
└───────────────┴───────────────────────────┴───────────────────────────┘

MBA Classes — Fixed-Rate Backing (Left Half of Quadrant)

Code	Name	Mint	Rate	Supply	ASM eligible
DEA	Direct Emission Asset / Deviant Equilibrium Asset	Permissionless	Fixed	Unlimited	✅ Full
PLA	Permissionless Limited Asset	Permissionless	Fixed	Limited	⚠️ Until supply depleted
MCA	Managed Certificate Asset	Managed	Fixed	Unlimited	❌
MTA	Managed Tranche Asset	Managed	Fixed	Limited	❌

DEA — Direct Emission Asset / Deviant Equilibrium Asset. Permissionless mint, fixed rate, unlimited supply. The Nash Equilibrium configuration where the contract replaces counterparty, market maker, and liquidity provider simultaneously. The primary innovation of the MBA Standard. ✅ Validated on chipnet (snapshot 0008).

PLA — Permissionless Limited Asset. Permissionless mint, fixed rate, limited supply. Same permissionless-mint mechanism as DEA — anyone can claim from the contract at the fixed rate — but with a hard supply cap declared at genesis. When the supply is exhausted, the ASM no longer issues new units. Holders retain the Protocol Net Value floor and may redeem to BCH at any time at the genesis rate. The supply is deflationary in the current CashScript implementation (redemptions reduce total supply) — a consequence of the present reservoir mechanism, not a designed economic property of the MBA Standard. May be adjusted in future implementations.

MCA — Managed Certificate Asset. Managed mint, fixed rate, unlimited supply. The founder is the sole issuer — new units enter circulation only through founder-initiated mint transactions. The fixed BCH backing rate applies to every issued unit. Stablecoin home: an MCA with a USD-denominated rate is the architectural pattern for a non-custodial stablecoin on BCH. Architecture A only (Architecture B cannot carry an MCA — see §3.2 and §7).

MTA — Managed Tranche Asset. Managed mint, fixed rate, limited supply. Same managed-mint pattern as MCA but with a hard supply cap. Use case: bond-like instruments, structured-finance positions, fixed-allocation tranches. Like PLA, MTA exhibits deflationary supply under the current CashScript implementation.

On the deflationary property: All four MBA classes are technically deflationary under the current CashScript reservoir behavior — redemptions burn the FTs rather than return them to the issuance pool. For DEA and MCA this is operationally irrelevant (unlimited supply); for PLA and MTA it is the operative supply dynamic. This is a property of the present implementation, not an intrinsic property of the MBA Standard. Future implementations may modify the reservoir behavior to return redeemed units to circulation.

NBA Classes — Non-Backed Assets / classical tokens — No Backing (Right Half of Quadrant)

Code	Name	Mint	Rate	Supply	ASM eligible
PTU	Permissionless Token Unlimited	Permissionless	None	Unlimited	❌
PTL	Permissionless Token Limited	Permissionless	None	Limited	❌
MTU	Managed Token Unlimited	Managed	None	Unlimited	❌
MTL	Managed Token Limited	Managed	None	Limited	❌

PTU — Permissionless Token Unlimited. Permissionless mint, no backing rate, unlimited supply. A CashToken whose mint covenant is open to any spender and whose supply has no cap declared at genesis. No protocol-enforced rate-to-BCH relationship. Use cases: open-mint memecoins, free-issuance experimental tokens, community-mintable assets without supply cap or backing claim.

PTL — Permissionless Token Limited. Permissionless mint, no backing rate, limited supply. Same permissionless mint as PTU, but with a hard supply cap declared at genesis. No backing claim. Use cases: open-mint NFT-like collectibles where any participant can mint up to the cap, community-distributed claim tokens, time-limited mint events with a fixed total.

MTU — Managed Token Unlimited. Managed mint, no backing rate, unlimited supply. Issuer-controlled mint with no supply cap and no backing claim. The default form of most existing CashTokens and ERC-20-style instruments — issuer can mint arbitrary new units, market sets the price. Use cases: project tokens, governance tokens, utility tokens, conventional unbacked altcoins.

MTL — Managed Token Limited. Managed mint, no backing rate, limited supply. Issuer-controlled mint with a hard supply cap. Use cases: tickets (event admissions with fixed seat count), credentials (membership tokens, certificates of completion), tranched collections, fixed-supply community tokens. The issuer retains mint authority up to the cap.

On non-backed assets (NBA / tokens): The NBA classes (PTU, PTL, MTU, MTL) carry no protocol-enforced backing claim. Their market value is determined entirely by issuer reputation, community demand, and traded liquidity. The wallet displays no peg, no rate, no redemption path for any Token class — these mechanisms do not exist for unbacked CashTokens.

Classification Algorithm

The wallet classifies a CashToken UTXO into one of the eight classes by observing three properties:

Step 1 — Backing marker. Does the UTXO carry an MBA backing marker?

• Phase 1 (current implementation): OP_RETURN tag with rate field (see §4)
• Phase 2 (snapshot 0017+): Native CashTokens NFT commitment field with rate encoding
• If present → MBA family (proceed to Step 2 with the rate value as the fixed rate)
• If absent → NBA family (Non-Backed Asset; proceed to Step 2 with no rate)

Step 2 — Mint rule. Inspect the CashTokens minting capability:

• Mint covenant open to any spender → Permissionless
• Mint covenant gated to a specific authority address → Managed

Step 3 — Supply. Inspect the CashTokens supply commitment:

• No commitment cap declared at genesis → Unlimited
• Commitment field encodes maximum supply → Limited

Combining the three properties produces one of the eight class identifiers:

Backing	Mint	Supply	Class
Fixed rate	Permissionless	Unlimited	DEA
Fixed rate	Permissionless	Limited	PLA
Fixed rate	Managed	Unlimited	MCA
Fixed rate	Managed	Limited	MTA
None	Permissionless	Unlimited	PTU
None	Permissionless	Limited	PTL
None	Managed	Unlimited	MTU
None	Managed	Limited	MTL

The wallet renders each class with its own label, icon, and behavior per the Wallet Display Rules in §9.

---

3. Architecture Modes

3.1 Architecture B — Soft Layer (UI Abstraction)

• Standard BCH UTXOs — no contract locking
• Rules enforced by wallet software only (wallet convention)
• Token identity = local definition: name, ticker, satsPerUnit, associatedAddresses
• Permissionless mint = wallet convention, not consensus enforcement
• External wallets see standard BCH UTXOs
• Primary use: closed, mutually-trusting groups only — never for tokens received from untrusted parties (see §7 on T-002)

3.2 Architecture A — Hard Layer (On-Chain Enforcement)

• CashScript P2SH32 contracts on BCH
• Contract enforces output template, output value, token amount via introspection opcodes
• Reservoir model: entire FT supply seeded at genesis into a single reservoir UTXO at the contract address. claim() transfers FTs out of the reservoir. The reservoir is monotonically decreasing.
• Self-backed FT UTXOs: each minted FT UTXO carries tokenAmount × backingRateSats BCH inside it
• Redemption = standard P2PKH spend of the FT UTXO — no contract path, no fee, holder's private key only
• The contract is immutable at deployment. No upgrade path, no selfdestruct, no admin function.

3.3 Hybrid Model

• Same tokenCategory (tokenId) works across both architectures
• Architecture B by default — escalate to A when enforcement is needed
• Token identity preserved through the transition

---

4. The Contract — DeviantOpenMintFT.cash

Contract file: contracts/DeviantOpenMintFT.cash Compiled artifact: contracts/dist/DeviantOpenMintFT.json

4.1 Constructor Parameters (Core Parameters — invariant at genesis)

Parameter	Type	Description
categoryId	bytes32	CashTokens token category in consensus byte order (use txidToConsensusBytes())
backingRateSats	int	BCH satoshis per MBA unit. Must be standard tier (≥ 1000, power of 10).
feeBps	int	Founder fee in basis points. 0–500.
founderAddress	bytes20	Founder P2PKH hash for fee payouts.

4.2 Contract Function — claim(tokenAmount, recipientLockingBytecode)

The only contract function. Enforces:

// Output 0: reservoir decremented by tokenAmount, same contract address
require(tx.outputs[0].lockingBytecode == tx.inputs[this.activeInputIndex].lockingBytecode);
require(tx.outputs[0].tokenAmount == tx.inputs[this.activeInputIndex].tokenAmount - tokenAmount);

// Output 1: recipient gets tokenAmount FTs, self-backed with full BCH
require(tx.outputs[1].tokenAmount == tokenAmount);
require(tx.outputs[1].value == grossSats);  // grossSats = tokenAmount * backingRateSats

// Fee output (if feeBps > 0)
// founder receives feeSats = (grossSats * feeBps) / 10000

Fee calculation:

grossSats = tokenAmount * backingRateSats
feeSats = (grossSats * feeBps) / 10000
netSats = grossSats + feeSats   // caller pays netSats total
founderReceives = feeSats
contractReceives = grossSats    // as backing inside the recipient UTXO

No fee on redemption. Redemption is a standard P2PKH spend — the holder spends their self-backed FT UTXO. The BCH inside is released. The FT is consumed. No contract involvement, no fee, no additional logic.

4.3 Reservoir Architecture

At genesis, a single reservoir UTXO at the contract address holds:

• The minting NFT (capability = minting)
• 10^18 FT units (the entire supply)
• Minimum BCH (dust)

Every claim() call:

1. Decrements the reservoir FT count by tokenAmount
2. Creates a new self-backed FT UTXO at recipientLockingBytecode with tokenAmount FTs and grossSats BCH
3. Routes feeSats to founderAddress (if fee > 0)

The minting NFT is preserved in the reservoir output on every claim so the category can issue new NFTs if needed in future. It does not affect FT supply.

4.4 Self-Backed FT UTXOs

Key architectural property: each minted FT UTXO is a self-contained unit. It carries:

• tokenAmount FT units
• tokenAmount × backingRateSats BCH

To redeem: spend the UTXO with a standard P2PKH signature. No contract call. The BCH is released. The FTs are burned. The holder receives the BCH at the genesis-fixed rate, unconditionally.

---

5. Rate Tiers

5.1 Allowed Tiers

ALLOWED_RATE_TIERS in src/tokenMetadata.ts:

Rate (bits/unit)	BCH per unit	Status	Use case
1, 10, 100	< 0.000001 BCH	❌ Below minimum — dust limit makes valid UTXOs impossible	—
1,000	0.00001 BCH	✅ Minimum	High-volume, low-denomination tokens
10,000	0.0001 BCH	✅	Standard loyalty and merchant MBAs
100,000	0.001 BCH	✅	Mid-tier assets
1,000,000	0.01 BCH	✅	Premium assets
100,000,000	1 BCH	✅	High-value assets
1,000,000,000	10 BCH	✅	Institutional / large-player assets

Code change required in src/tokenMetadata.ts:

export const ALLOWED_RATE_TIERS = [
  1_000n,
  10_000n,
  100_000n,
  1_000_000n,
  100_000_000n,
  1_000_000_000n,   // 10 BCH per unit — added for high-value asset use case
];

5.1.1 The 10 BCH Tier — High-Value Asset Use Case

The 10 BCH tier (1,000,000,000n bits per unit) serves a distinct purpose from the lower tiers.

What it proves: The Mathematical Backing Standard works at any scale. A single MBA unit at the 10 BCH tier carries 10 BCH of verifiable, on-chain, unconditionally redeemable backing. No custodian. No trust required. No intermediary. The claim() contract enforces output[1].value == grossSats at consensus level — the same enforcement mechanism that works at 1,000 bits works identically at 1,000,000,000 bits. There is no approximately.

Who it is for: Institutional participants, large-player asset issuers, real estate tokenization, high-value commodity backing, any use case where a single unit represents significant capital. A founder deploying at this tier commits 10 BCH per MBA unit issued — a meaningful capital commitment that signals serious participation.

Practical implications:

• Minimum viable claim: 1 unit = 10 BCH committed by the claimer
• Founder deploying 100 units total supply: 1,000 BCH in backing at genesis
• Fee at 1% (100 bps): 0.1 BCH per unit claimed — meaningful, sized appropriately
• Transaction fee: same ~2,500 bits as any other claim() — base layer fees do not scale with token value
• UER with a 1 BCH tier token: 1,000,000,000 / 100,000,000 = 10 — 1 high-value MBA = 10 standard BCH-tier MBAs

Why this matters for institutional credibility: The Protocol Net Value of a 10 BCH tier MBA is verifiable on-chain by any participant at any time without trusting any institution. A large player can verify the backing of their position independently — the same property that protects a small holder protects a large one. The Mathematical Backing Standard does not have different rules for different participants. It is the same invariant function at every scale.

5.2 Why Powers of 10 Only

The Universal Exchange Rate between two permissionless mint MBAs is rateA / rateB. Arbitrary rates produce non-standard cross-rates. Rate purity is a protocol requirement, not a suggestion.

5.3 Why Minimum 1,000 Bits — This Is Load-Bearing

The dust limit (~546 bits) combined with require(tx.outputs[1].value == grossSats) means:

• At rate 0: grossSats = tokenAmount × 0 = 0. Output value = 0 violates dust limit. No valid claim() can ever be constructed. Rate-0 canonical contract = bricked, not a faucet.
• At rate 1/10/100: smallest useful claim amounts produce sub-dust fee outputs or sub-dust backing values. Economically unviable.
• At rate 1,000: minimum claim of ~546 units produces outputs meeting dust requirements.

The dust limit is therefore a consensus-level enforcement of the rate floor. The wallet should reject non-standard rates at Avalanche deployment with a precise error, not just a generic warning.

5.4 Fee Economics (from wiki/fee-economics.md, snapshot 0021)

Fee percentage is invariant to BCH price. Fee, dust, and token value are all bit-denominated. BCH price appreciation cancels out of the feeSats / (units × rate) ratio. A 100× BCH price increase does not rescue sub-1,000-bit rates.

Real transaction fees (corrected from original spec):

• Standard BCH transfer: ~220 bits (1 bit/byte)
• CashTokens FT transfer: ~2,000 bits (real measurement from chipnet scripts)
• claim() transaction: ~2,500 bits (validated chipnet)
• Swap transaction: ~3,000 bits (validated chipnet)
• Recommended: 1.5×–2× safety multiplier on naïve byte-size estimates for any CashScript covenant transaction

Governance note: Dust limit and minRelayTxFee are relay policy (not consensus) — changeable without a fork via CHIP process. Fee percentage is invariant to BCH price, but the fiat weight of dust increases with appreciation, pushing low rates further from viability. Rate-1,000 floor is correct for current policy; a future policy change would trigger a revision to ALLOWED_RATE_TIERS.

---

6. The Atomic Swap — Validated Architecture

6.1 How the Swap Works ✅

Validated TXID: e68e610f0e4f5374d6bbc8564ca80ce10f11fae7c21cf526c094bec867dd7370 (chipnet, snapshot 0008)

A swap of N Token A for M Token B in a single transaction:

Inputs:
  [0] Token B reservoir UTXO  — unlocked via contractB.claim(M, walletBytecode)
  [1] Wallet's Token A FT UTXO — unlocked via P2PKH signature
  [2] Wallet BCH UTXO          — covers fees

Outputs:
  [0] Token B contract (reservoir decremented by M, minting NFT preserved)
  [1] Wallet token-address (M Token B FTs, self-backed: M × rateB bits)
  [2] Wallet BCH address (change)

Token A FTs are burned implicitly in the transaction (no output for them). Requires TransactionBuilder({ allowImplicitFungibleTokenBurn: true }) — this flag is on the constructor options, not a settable property after construction.

6.2 Universal Exchange Rate (UER)

UER(A→B) = rateA / rateB

Example: rateA = 10,000 bits, rateB = 1,000 bits
UER = 10,000 / 1,000 = 10
→ 1 unit of Token A = 10 units of Token B

Derived from genesis constants only. Deterministic. No oracle. No counterparty.

6.3 Cumulative Chipnet Validation (as of snapshot 0017)

129 swaps + 6+ claims + 4 vulnerability tests across 17 snapshots. Zero protocol-level exploits. Zero demonstrated paths to trap user funds. Zero bypass of fee enforcement. Every observed failure mode was caught by SDK guards or contract require statements before funds were affected.

Update: as of the Potidaea platform-fee swap-relay measurements the cumulative chipnet swap count now stands at 52,998 (sharded 6,341 + K=1 single-reservoir 9,222 + GMX Potidaea 9,296 + OpenMint Potidaea 26,599 + earlier bulk/PoC ~1,540), still zero exploits. See ASM_Native/ASM-single-asset-throughput.md §4a for the current authoritative tally — update that section and this line together when new throughput runs land.

---

7. Vulnerability Analysis

7.1 T-001 — Non-Canonical Contract Rug ✅ Defenses validated on chipnet (snapshot 0020)

Threat: Malicious founder deploys a contract claiming Deviant Standard compliance (correct metadata, correct rate) but containing a founderFreeMint() backdoor that issues FTs without locking BCH backing. The fraud lives in the BCH-to-FT ratio of the UTXO, not the token identity. Same tokenCategory, indistinguishable by category alone.

Critical property: Receive-time risk only. Users who minted directly via claim() are fully protected. Users who receive tokens via transfer are at risk.

Chipnet evidence: Attacker spent ~3,175 bits to airdrop 1,000,000 underbacked FTs to victim. Honest claim() of 1,000,000 units would require 1,000,000,000 bits. Both D-1 and D-2 fired independently and correctly.

D-1 — Canonical Address Verification 🔧 (PoC validated, production module unbuilt)

Implementation: Reconstruct the canonical P2SH32 address from the token's published parameters (categoryId, backingRateSats, feeBps, founderAddress) using the canonical DeviantOpenMintFT template. Compare the resulting address against the on-chain contract address holding the reservoir.

canonical_address = p2sh32(DeviantOpenMintFT.template(publishedParams))
on_chain_address = resolveReservoirAddress(tokenCategory)

if canonical_address == on_chain_address:
    → DEA-Verified or PLA-Verified (per declared supply mode):
        show Protocol Net Value, enable swap
        (PLA swap only while supply > 0)
else:
    → "Non-standard CashToken — peg not guaranteed"
       No swap eligibility. Show only literal UTXO BCH.

Note: D-1 is an address equality check, not a raw bytecode comparison. The canonical template is instantiated with the token's published parameters; the resulting P2SH32 address is what gets compared.

D-2 — Per-UTXO Backing Check 🔧 (PoC validated, production module unbuilt)

On every incoming FT UTXO:

expected_bch = utxo.ft_amount * token.satsPerUnit
if utxo.bch_value < expected_bch:
    flag UNDERBACKED
    display: "X tokens — only Y bits redeemable (peg requires Z bits)"
    exclude from redeemable peg balance

D-3 — Canonical Bytecode Source 🔧

For v1: embedded constant (canonical DeviantOpenMintFT bytecode hash hardcoded in wallet release). Open question Q-T1: capture current canonical bytecode hash in a constants file.

What D-1 is NOT: D-1 does not apply to Architecture B. There is no on-chain anchor to verify against in Architecture B. This is a property of the tier, not a gap to close.

7.2 T-002 — B-Model Definition Poisoning (snapshot 0019)

Threat: Architecture B token identity lives entirely in local wallet definitions. An attacker authors a poisoned definition (wrong satsPerUnit, squatted symbol) and gets a victim's wallet to use it.

Two concrete attacks:

• A-1 — Misvaluation on receive: Attacker sends 1,000 bits with a definition claiming satsPerUnit: 1. Victim's wallet displays "1,000 XZC." Victim believes they received ~1,000,000 bits of value.
• A-2 — Overpayment on send (causes real BCH loss): Attacker convinces victim to import XZC with satsPerUnit: 1,000,000. Victim sends "5 XZC" → wallet moves 5,000,000 real bits.

Why D-1 cannot apply to B model: B tokens leave no on-chain artifact. No genesis, no category, no bytecode, no cost. Nothing to verify against.

Defenses D-4–D-8 (all wallet-side, write-up only — none built yet):

Defense	Description	Status
D-4	Raw-BCH co-display (mandatory). Every B-token figure shown alongside literal bit/BCH value.	🔧 Required in B display layer
D-5	Definition-import friction + raw-BCH send confirmation. Every B-token send shows final BCH amount.	🔧 Required in B send path
D-6	Non-authoritative symbol rendering. B tokens never visually equivalent to A-model verified tokens.	🔧 Required in B display layer
D-7	Optional issuer signature on B definitions. Verified by key, not by chain.	❓ Requires schema decision first (Q-T5)
D-8	Ecosystem plurality. Open format, multiple wallet implementations, multiple registries.	Governance commitment

Primary control (spec §3.2): Architecture B is for closed, mutually-trusting groups only. Never for tokens received from untrusted parties.

7.3 Additional Validated Issues

Issue	Status	Fix
V-001 Rogue minting NFT donated to contract address	✅ Fixed	Picker filter amount > 0n (u.token.amount > 0n)
V-002 Missing rate peg check	✅ Documented	Never deploy without require(tx.outputs[1].value == grossSats)
Sub-dust FT remainder rejection	✅ Documented	Fold leftover into burned amount when sub-dust
Multi-input BCH picker	✅ Fixed	Use multiple BCH UTXOs when single UTXO insufficient
Reservoir UTXO contention at high throughput	❓ Open	~10 swaps/min sequential works; parallel/sharded reservoir needs design

7.4 Threats Eliminated by Architecture

Class	Why not a threat
Founder closes contract	No selfdestruct, no admin path. Bytecode is set in stone at P2SH32.
Founder drains user BCH	User BCH is in self-backed P2PKH UTXOs. Founder has no access.
Founder mints to themselves at no cost	Contract requires output[1].value == grossSats. Founder pays same rate.
Founder dump / price crash	No market price exists below the peg. Floor is consensus-enforced.
Cross-contract token theft	Categories are unique and consensus-enforced. Foreign contracts cannot touch a token's UTXOs.
Peg violation in claim()	Equality check enforced by contract. Bypass = different bytecode = different address = no reservoir.

---

8. Architecture A vs Architecture B — The Categorical Distinction

From snapshot 0019 (conceptual frame):

Axis 1 — Custody: Does a third party hold the asset?

• Both tiers: No custodian. BCH travels with the user. Both tiers close Axis 1.

Axis 2 — Representation integrity: Can the claim/label be faked?

• Architecture B: Cannot close this axis. No on-chain anchor. The wallet is the authority — its word is the only word.
• Architecture A: Closes this axis. The wallet is a verifier — if it lies, you check against the chain and catch it.

The categorical distinction: Architecture B needs an authority. Architecture A replaced the authority with a verifier. This is a difference of kind, not degree.

Stablecoin implication (snapshot 0021):

• Architecture A is the only correct home for a stablecoin: managed-mint, FT supply fixed at genesis, no permissionless claim().
• Architecture B cannot carry a stablecoin. A "B stablecoin" is plain BCH with a label. An issuer trying to honour B-model dollar redemptions would be drained instantly. Spec §3.2 bans this.

---

9. UI Components — Five Interfaces

AVALANCHE — Create

Genesis event. User sets parameters, locks Backing Standard, deploys Vessel.

Fields:

• Asset name, ticker symbol
• Backing rate (must be standard tier — validated against ALLOWED_RATE_TIERS)
• Total units (0 = unlimited supply, deployed as a 10^18 reservoir; N = limited supply, deployed as an N-unit reservoir)
• Mint rule (Permissionless / Managed)
• Founder fee (0–5%)
• Architecture tier (A or B)
• Metadata: description, icon (IPFS CID)

Warning required before deploy: "Core parameters are permanently set at genesis. The backing rate, mint rule, and supply cannot be modified after deployment."

Post-deploy: Display asset with its verified class designation — DEA, PLA, MCA, or MTA — followed by the verification state (Verified / Unverified). If founder fee > 0, show AMC (Automated Monetization Contract) active status.

Note on gift claim (V5, snapshot 0017): The recipientLockingBytecode parameter allows the claimer to specify any recipient — not just themselves. Enables third-party-paid onboarding, charitable airdrops, gift cards. Not a vulnerability — a feature.

METROON — Asset List

The filterable asset directory. "Metroon" names the registry of assets — listed across the backed ↔ non-backed spectrum.

Filters:

• Primary: Backed (MBA) / Non-backed (NBA, the "Token" display family)
• Secondary: subcategory (e.g. stablecoins), use-case (game currency, tickets, memberships, collectibles), architecture tier (A / B), verification status
• Scope toggle: My holdings / All assets

Per entry:

• Class designation (DEA / PLA / MCA / MTA / PTU / PTL / MTU / MTL)
• For MBAs: Protocol Net Value (units × backing-rate), backing verification status (Verified / Unverified / Warning)
• Architecture tier (A or B)
• Raw BCH value always shown alongside token units (D-4 requirement for B-model tokens)
• For non-backed assets: standard CashToken display, no peg information

ORBITAL — Explorer

The asset explorer — market-cap-style data across the ecosystem: rankings, per-asset detail, supply/backing stats, and history. The "charted heavens" where every asset body is observed. Read-only / analytical; distinct from SPECTRUM (the filterable list) and AGORA (where trades happen).

AGORA — Interact / Swap

Launch, discovery, and ASM swap marketplace — the UI for the Autonomous Swap Market (AuSM) that emerges from ASM at scale. Founders publish and promote assets here; users swap.

ASM swap is available to permissionless-mint MBAs. Eligible: DEA-Verified and PLA-Verified (D-1 + D-2 passing). PLA participation continues until the supply is depleted; DEA participation is structurally continuous.

Swap execution: redeem (P2PKH spend of Token A FT UTXO) + mint (Token B claim()) in a single transaction where possible. Requires TransactionBuilder({ allowImplicitFungibleTokenBurn: true }).

ELEVATION — Upgrade

Architecture B → Architecture A escalation. Checked by assertEscalationIntegrity() in src/tier.ts — verifies bchSats, rate, pkh, and openMint all match across the tier transition.

Wallet Display Category: "Token" (the NBA family)

The wallet's "Token" display category applies to the Non-Backed Asset (NBA) family — CashTokens on the BCH chain that do not carry MBA backing. ("Token" / classical tokens is the familiar parallel name for NBA, kept as the user-facing display label.) This category contains four sub-classes (PTU, PTL, MTU, MTL — see §2.4) distinguished by mint rule and supply, each rendered with its own label in the wallet UI. This is a wallet-rendering concept — distinct from the broader category of soft-backed claims (gold certificates, bonds, USDT, WBTC, etc.) which are structural peers in the asset landscape but are not held by this wallet. For the full asset-landscape positioning, see Traditional Asset Types and Backing Standards and The MBA Standard — Asset Taxonomy in the project corpus.

For CashTokens that the wallet displays:

Display label	Wallet behavior
Token · PTU	Permissionless mint, unlimited supply, no backing. Standard CashToken display, no peg information.
Token · PTL	Permissionless mint, limited supply, no backing. Display supply cap if encoded; no peg information.
Token · MTU	Managed mint, unlimited supply, no backing. Standard CashToken display, no peg information.
Token · MTL	Managed mint, limited supply, no backing. Display supply cap if encoded; no peg information.

No Token class has a backing mechanism or Protocol Net Value floor. Use cases include tickets (MTL), credentials (MTL), memberships (MTL or MTU), community-mintable collectibles (PTL), open-mint experimental tokens (PTU), and conventional issuer-controlled tokens (MTU). All are valid CashToken applications that do not require the rate-backed redemption guarantee the MBA Standard provides.

Wallet Display Rules

Class	Verification surface	Display state	Swap eligibility
DEA	D-1 (canonical address) + D-2 (per-UTXO backing)	DEA — Verified when both pass; show Protocol Net Value, enable Agora swap	✅ Full
PLA	D-1 + D-2	PLA — Verified when both pass; show Protocol Net Value, enable Agora swap until supply depleted	⚠️ Until supply depleted
MCA	D-1 (canonical address) + per-mint backing check (managed-mint variant of D-2)	MCA — Verified when both pass; show Protocol Net Value; no swap	❌
MTA	Same as MCA	MTA — Verified when both pass; show Protocol Net Value; no swap	❌
MBA — Unverified	Any MBA where D-1 fails	"Non-standard contract — peg not guaranteed." No Protocol Net Value display. Show only literal UTXO BCH amount.	❌
PTU	CashTokens parameters: permissionless mint, no supply cap, no MBA marker	"Token · PTU" label. Standard CashToken display. No peg, no Protocol Net Value.	❌
PTL	CashTokens parameters: permissionless mint, supply cap present, no MBA marker	"Token · PTL" label. Display supply cap. No peg, no Protocol Net Value.	❌
MTU	CashTokens parameters: managed mint, no supply cap, no MBA marker	"Token · MTU" label. Standard CashToken display. No peg, no Protocol Net Value.	❌
MTL	CashTokens parameters: managed mint, supply cap present, no MBA marker	"Token · MTL" label. Display supply cap. No peg, no Protocol Net Value.	❌

---

10. Phase 2 Status (from snapshots 0017–0021)

Step 1: Basic wallet (key gen, BCH send/receive)       ✅  mainnet-js + chipnet scripts
Step 2: Token metadata DB (in-memory)                  ✅  snapshot 0018
Step 2.5: Registry sync + server                       ✅  snapshot 0019 (23 tests passing)
Step 3: UTXO classification engine                     ✅  snapshot 0018
Step 4: Architecture B display layer                   🔧  next
Step 5: Architecture B token send/receive              🔧  next
Step 6: Basic swap calculation (math only)             ✅  src/swapMath.ts

Next concrete work:

1. Architecture B display layer — surfaces summariseBalances from classify.ts to UI. D-4 and D-6 are component-level requirements here.
2. Architecture B send/receive — wire mainnet-js + registry + classifier into transaction construction for B-token transfers. D-5 goes here.
3. Production D-1/D-2 module — src/verify/ module, fold D-2 into UTXO classification engine (src/token/classify.ts). PoC logic exists in scripts/chipnet-t001-verify.mjs.
4. D-3 / Q-T1 — capture canonical DeviantOpenMintFT bytecode hash as embedded constant (ADR-0008 Decision A).

---

11. Registry Architecture (snapshot 0019)

11.1 What Exists

• src/token/portable.ts — stable JSON wire format (PortableToken, PortableRegistry)
• src/token/sync.ts — client-side sync with three modes: add-new-only (default, safe), force-refresh, dry-run
• src/registry/server.ts — HTTP server, GET /tokens returns PortableRegistry feed
• scripts/registry-serve.mjs — runnable server reading from .registry-tokens.json

11.2 Critical Design Decision — add-new-only Default

The sync client default mode (add-new-only) refuses to overwrite existing local token entries. A malicious or hijacked registry cannot push compromised metadata for a token the user has already verified. The user must explicitly opt into force-refresh.

For Architecture A tokens, the wallet verifies the contract bytecode hash against the chain before treating a registry entry as trusted.

11.3 Anyone Can Run a Registry

The server serves whatever JSON file it's given. Token issuers can run their own. Multiple registries can be configured (first-seen wins per tokenId). No central authority.

---

12. Key Files

contracts/
  DeviantOpenMintFT.cash          — canonical contract
  DeviantOpenMintFT_Backdoor.cash — T-001 PoC malicious contract (test use only)
  dist/DeviantOpenMintFT.json     — compiled artifact

src/
  tokenMetadata.ts   — TokenMetadata type, ALLOWED_RATE_TIERS (1000n floor)
  tokenId.ts         — deriveTokenId, OP_RETURN encode/parse
  tier.ts            — TierBToken/TierAToken, assertEscalationIntegrity
  swapMath.ts        — computeRedemption, computeSwap
  token/
    portable.ts      — JSON wire format
    sync.ts          — registry sync client
  registry/
    server.ts        — HTTP registry server

scripts/
  chipnet-genesis.mjs       — deploy genesis token
  chipnet-asm-claim.mjs     — claim from reservoir
  chipnet-asm-swap.mjs      — atomic swap
  chipnet-asm-bulk-swap.mjs — bulk swap (100+ validated)
  chipnet-t001-genesis.mjs  — T-001 PoC: deploy backdoor contract
  chipnet-t001-attack.mjs   — T-001 PoC: execute attack
  chipnet-t001-verify.mjs   — T-001 PoC: validate D-1 + D-2 defenses
  registry-serve.mjs        — run registry HTTP server

wiki/
  architecture.md    — architecture documentation + stablecoin worked example
  fee-economics.md   — rate-tier viability, dust/fee-floor governance
  risks.md           — R-011 (T-001), R-012 (T-002)
  decisions.md       — ADRs
  testing-strategy.md

---

13. Open Questions

ID	Question	Priority	Source
Q-T1	Capture canonical DeviantOpenMintFT bytecode hash in constants file for D-3.	High	snapshot 0018
Q-T2	D-1 comparison: constructor-parameter positions varying (one hash for all tokens) vs fixed (per-token hash)? Variable is more usable.	High	snapshot 0018
Q-T3	Contract version field in bytecode for multiple canonical templates across upgrades?	Medium	snapshot 0018
Q-T4	BCMR "verified contract template" attestation — existing precedent or Deviant extension needed?	Medium	snapshot 0018
Q-T5	B-token definition schema: include issuer-signature field (D-7) from v1, or add later? Schema changes cheap now, expensive after definitions circulate.	High	snapshot 0019
Q-T6	Hard guard vs friction-only for unsigned B-token sends above a BCH threshold?	Medium	snapshot 0019
Q-T7	Registry plurality (D-8) — does Deviant ship a reference registry? How is "reference" prevented from becoming "canonical"? ADR needed.	Medium	snapshot 0019
Q-T8	Content-addressed B-token ID (sha256 of genesis params) — surface in wallet so users can compare against out-of-band-trusted value?	Low	snapshot 0019
Q-T9	Should D-1 verifier also assert backingRateSats >= 1000? Belt-and-suspenders — dust already forecloses rate-0. Lets wallet show precise rejection reason.	Low	snapshot 0018

---

14. Security Requirements Summary

Requirement	Phase	Status
Rate tier validation at Avalanche	1	🔧 Required
Non-standard token display (no peg for failed D-1)	1	🔧 Required
User irreversibility warning at genesis	1	🔧 Required
D-4: Raw-BCH co-display for B tokens	2 (B display layer)	🔧 Required
D-5: Definition-import friction + raw-BCH send confirmation	2 (B send path)	🔧 Required
D-6: Non-authoritative B token rendering	2 (B display layer)	🔧 Required
D-1: Canonical address verification	2 (post-B layer)	🔧 PoC done, production unbuilt
D-2: Per-UTXO backing check	2 (post-B layer)	🔧 PoC done, production unbuilt
D-3: Embedded canonical bytecode constant	2 (post-B layer)	🔧 Required (ADR-0008)
Picker filter amount > 0n	✅	Applied in all chipnet claim/swap scripts
allowImplicitFungibleTokenBurn: true in TransactionBuilder	✅	Required for all swaps

---

15. Glossary

15.1 Asset Taxonomy

Term	Definition
MBA	Minted Backed Asset (technical) / Mathematically Backed Asset (broad) — parent category covering the four fixed-rate-backed asset classes (DEA, PLA, MCA, MTA). Layer 2b in the asset landscape (see Traditional Asset Types and Backing Standards in the project corpus): a strict-backed derivative claim on a Layer 1 asset (BCH), with the claim-to-underlying relationship enforced by CashScript contract invariant at consensus level. Structurally parallel to Layer 2a soft-backed claims (gold certificates, WBTC, USDT, bonds, ETF shares) which share the same derivative-claim shape but rely on institutional, custodial, or legal enforcement that admits exception. MBA is not a substitute for Layer 1 pure assets (gold, BTC, BCH itself) — those are the substrates that derivative claims reference. MBAs and Tokens together form an eight-class structure that the wallet recognizes — see §2.4.
DEA	Direct Emission Asset (technical) / Deviant Equilibrium Asset (broad) — permissionless mint, fixed rate, unlimited supply. Real-world peer: naturally unbounded extractive commodities (e.g. seawater, atmospheric carbon). The primary innovation: Nash Equilibrium where the contract replaces counterparty, market maker, and liquidity provider simultaneously. ✅ Validated on chipnet.
PLA	Permissionless Limited Asset — permissionless mint, fixed rate, limited supply. Issuance-pattern analogue: naturally scarce commodities (gold, silver, oil) — anyone can extract, finite. NB (ADR-0027): issuance analogy only — raw gold/silver are unbacked Layer-1 direct value → NBA / PTL (consistent with the MBA row above: Layer-1 pure assets are substrates, not MBAs). A PLA is the backed claim (BCH floor) sharing that issuance pattern — like a capped certificate backed by a reserve (MBA : BCH ∷ certificate : gold). Deflationary under current CashScript implementation.
MCA	Managed Certificate Asset — managed mint, fixed rate, unlimited supply. Real-world peer: issuer-controlled assets with expansion rights (fiat currencies, custodial stablecoins, corporate shares with authorized-but-unissued capital). Founder-issued. Stablecoin home (Architecture A only).
MTA	Managed Tranche Asset — managed mint, fixed rate, limited supply. Real-world peer: issuer-controlled assets with fixed issuance (bonds, structured notes, numbered art prints, ETF shares, closed-end funds, fixed-supply tokens). Deflationary under current CashScript implementation.
NBA / Token	Non-Backed Asset (NBA) — the family of non-MBA CashTokens (no fixed backing rate); familiar parallel name Token / classical tokens, which is also the wallet's user-facing display category. Subdivides into four sub-classes — PTU, PTL, MTU, MTL — distinguished by mint rule (permissionless/managed) and supply (unlimited/limited). Distinct from the broader category of soft-backed claims (gold certificates, bonds, USDT, WBTC, etc.) — see Traditional Asset Types and Backing Standards in the project corpus.
PTU	Permissionless Token Unlimited supply — permissionless mint, no backing rate, unlimited supply. Use cases: open-mint memecoins, free-issuance experimental tokens, community-mintable assets without supply cap.
PTL	Permissionless Token Limited supply — permissionless mint, no backing rate, limited supply. Use cases: open-mint NFT-like collectibles, community-distributed claim tokens with fixed total, time-limited mint events.
MTU	Managed Token Unlimited supply — managed mint, no backing rate, unlimited supply. Use cases: project tokens, governance tokens, utility tokens, conventional unbacked altcoins; default form of most existing CashTokens.
MTL	Managed Token Limited supply — managed mint, no backing rate, limited supply. Use cases: tickets (event admissions with fixed seat count), credentials (membership tokens, certificates), tranched collections, fixed-supply community tokens.

15.2 Mechanisms

Term	Definition
MBM	Mathematically Backing Mechanism — the process by which MBAs are created. Fixed at genesis through Avalanche execution.
ASM	Automated Swap Mechanism — counterparty-free swap via claim + P2PKH redeem. Available to DEA and PLA (until supply depleted).
AuSM	Autonomous Swap Market — what emerges when ASM operates at scale across multiple DEAs/PLAs.
UER	Universal Exchange Rate — rateA / rateB, invariant function of genesis constants. Deterministic. No oracle. No counterparty.
AMC	Automated Monetization Contract — founder fee embedded in claim(). Productive from genesis. Proportional to claim activity.
PNV	Protocol Net Value — the invariant floor value of an MBA. units × backingRate. Always provable on-chain. Always recoverable.

15.3 Architecture Vocabulary

Term	Definition
Reservoir	The technical contract UTXO holding the FT supply at the contract address. Architecture-level implementation detail. The supply held in the reservoir is monotonically decreasing in the current CashScript design — a property of the present implementation, not a designed economic property of the MBA Standard.
Self-backed UTXO	FT UTXO carrying tokenAmount × backingRateSats BCH. Redeemed via P2PKH spend — no contract call, no fee, holder's private key only.
Vessel	The individual contract (synonymous with "contract" in MBA Standard documentation). Each Vessel is dedicated to one MBA.
Core Parameters	Constructor parameters — invariant after genesis: categoryId, backingRateSats, feeBps, founderAddress.

15.4 UI Names

Term	Definition
Avalanche	Asset creation interface. Genesis event. Irreversible.
Metroon	Asset list / classification view. Filterable directory — primary filter backed (MBA) / non-backed (NBA); secondary filters: subcategory (e.g. stablecoins), use-case (game currency, tickets, memberships, collectibles), tier, verification. Scope toggle: my holdings / all assets.
Orbital	Asset explorer. Market-cap-style data, rankings, and per-asset detail across the ecosystem — the "charted heavens."
Agora	Launch, discovery, and ASM swap marketplace (DEA and PLA-until-depletion); the UI for the Autonomous Swap Market (AuSM).
Elevation	Architecture B → A escalation interface.

15.5 Threats and Defenses

Term	Definition
T-001	Non-canonical contract rug — receive-time risk. D-1 + D-2 mitigate.
T-002	B-model definition poisoning — wallet-layer risk. D-4 through D-8 mitigate.
D-1	Canonical address verification (reconstruct P2SH32 from published params, compare to on-chain).
D-2	Per-UTXO backing check at receive time.
D-3	Embedded canonical bytecode constant.
D-4	Raw-BCH co-display for all B-token figures.
D-5	Definition-import friction + raw-BCH send confirmation.
D-6	Non-authoritative B token symbol rendering.
D-7	Optional issuer signature on B definitions.
D-8	Ecosystem plurality (governance commitment).

15.6 Build Notes

Term	Definition
cashc	CashScript compiler package (separate from cashscript runtime since v0.12). Importing compileFile from cashscript silently fails.
allowImplicitFungibleTokenBurn	TransactionBuilder constructor option required for swap transactions.
ALLOWED_RATE_TIERS	Validated power-of-10 backing rates: 1,000 / 10,000 / 100,000 / 1,000,000 / 100,000,000 / 1,000,000,000 bits per unit.

---

Document version: V2.8 · Verified against snapshots 0001–0021 (naming + UI pass; technical validation unchanged from v2.7) Changes from V2.7: dual-register asset names (MBA / DEA); NBA family naming (NBA / Token / classical tokens) with Token retained as wallet display label; UI names restructured — Metroon = Asset List, Orbital = Explorer, Agora = swap/interact (was Orbital Network).

Document version: V2.7 · Compiled 2026-05-19 · Verified against snapshots 0001–0021 Changes from V2.6: §2.4 extended from four MBA classes to all eight asset classes the wallet recognizes. The four Token sub-classes (PTU, PTL, MTU, MTL) are now defined formally parallel to the four MBA classes (DEA, PLA, MCA, MTA), with the 2×2 quadrant (mint × backing) as the underlying classification structure. The classification algorithm — how the wallet detects which class a given CashToken UTXO belongs to — is now specified explicitly. §9 Wallet Display Rules table expanded to nine rows (four MBA classes, four Token sub-classes, plus MBA — Unverified for fallback). The wallet renders each of the eight classes with its own label and treatment. §2.4 renamed from "The Four MBA Classes — Canonical Definitions" to "Asset Class Definitions" to reflect the broader scope. §15 Glossary updated: single "Token" entry replaced with five entries (Token category + four sub-classes); MBA entry updated to reference the eight-class structure. The 4-letter naming form (PTUS, PTLS, MTUS, MTLS) is reserved for public taxonomy documents outside the spec where the derivation of the 3-letter form is explained; inside the spec only the 3-letter form is used.

Document version: V2.6 · Compiled 2026-05-19 · Verified against snapshots 0001–0021 Changes from V2.5: Structural cut — §4 (Asset Taxonomy) removed entirely. The section was 292 lines of positioning content (the direct-value-vs-backed traditional-finance diagram, the three-layer Layer 1 / Layer 2a / Layer 2b framing in depth, the soft-vs-strict categorical distinction in depth, and the peer-class diagram). None of this is implementation-spec content — it is positioning content for comparative-analyst readers. The taxonomy material's natural home is the comparative-analysis documents in the project corpus: Traditional Asset Types and Backing Standards (descriptive taxonomy of the existing landscape), The MBA Standard — Asset Taxonomy (base taxonomy positioning MBAs against traditional assets, planned), and MBA Specifications Detailed Taxonomy (sophisticated-reader expansion, planned). The cut content is preserved verbatim in deviant_taxonomy-source.md for development of those corpus documents. Survivors relocated within the spec:

• §4.5 (Canonical MBA Class Definitions) moved to §2.4 as part of Technical Foundation — developers need these formal definitions to implement the four MBA classes.
• §4.6 (Wallet Display Category "Token") and §4.7 (Wallet Display Rules) moved to §9 UI Components as additional subsections — these are implementation rules for wallet UI.
• The Layer 1 / Layer 2a / Layer 2b framing remains briefly defined inline in §1 Project Overview (sufficient for the spec's purposes); the full elaboration is in the corpus. Sections 5–16 renumbered to 4–15 to fill the gap. All internal cross-references updated accordingly.

Document version: V2.5 · Compiled 2026-05-19 · Verified against snapshots 0001–0021 Changes from V2.4: Bank-deposits row in §4.1 corrected. Physical fiat and digital fiat are direct-value counterparts to bank deposits — both forms are the same money in different physical/digital forms. The bank deposit is not structurally a claim on a different asset class; it is a transfer of money (physical or digital) into a commercial bank account, where the deposit balance represents the holder's own money held by the intermediary. Two deposit types are now distinguished: standard (immediately accessible — card, NFC, transfer, ATM withdrawal) and locked / term (held for fixed period in exchange for interest; no direct access during the lock). Soft enforcement: bank solvency + willingness to honor + subject to access-permission revocation (capital controls, account freezes, withdrawal limits). The cell notes that "CBDC" is the same digital fiat controlled by a different entity (the central bank) — refusing it a separate taxonomic category since the money form and structural identity are identical to other digital fiat. Changes from V2.3: Two coordinated terminology changes. (1) Mint-axis rename: "closed mint" → "managed mint" throughout. Completes the structural-property naming begun in V2.2 with "open mint" → "permissionless mint." "Closed" was descriptive but asymmetric with "permissionless"; "managed" precisely names the structural property — issuance is gated to a designated controller (the deploying address). The new axis labels "permissionless / managed" now read as parallel structural-property names rather than a mix of perspectival descriptions. (2) MCA expansion reverted: "Deviant Managed Asset" → "Managed Certificate Asset." Restores the M-C-A acronym integrity. The V2.1 "correction" from "Managed Certificate Asset" to "Deviant Managed Asset" was a regression — the M-C-A letters do not match "Deviant Managed Asset" (the C is unaccounted for). "Managed Certificate Asset" matches the acronym and accurately captures the structural identity: a managed-mint instrument that operates as a holder-bearing certificate backed by the deploying issuer's contract commitment. Symmetric with "Managed Tranche Asset" (MTA) in the M-class family — both managed, one with fixed cap (Tranche), one with unlimited supply (Certificate). Changes from V2.2: Asset class rename — OLA (Open Limited Asset) → PLA (Permissionless Limited Asset). The rename completes the "open" → "permissionless" terminology shift introduced in V2.2 by extending it from property-description vocabulary to the asset class name itself. "Permissionless" precisely names the structural property — any participant satisfying the issuance precondition can produce new units regardless of who deployed the contract. The acronym update preserves the L (Limited) and A (Asset) letters; only the leading letter changes. All references to OLA throughout the spec and corpus are updated to PLA. The same rename has been applied across the corpus directory and is planned for other affected corpus documents in a subsequent pass. Changes from V2.1: Terminology rename — "open mint" → "permissionless mint" throughout. "Open" was ambiguous (open to whom? for what?), while "permissionless" precisely names the structural property. The asset class names (OLA = Open Limited Asset, etc., at the time) retained their established acronyms in V2.2; the property-description vocabulary used the corrected term. V2.3 subsequently brought the asset class acronym into alignment. Changes from V2: Asset taxonomy restructured — MBA is the single parent category with four direct child classes (DEA, OLA, MCA, MTA — OLA renamed to PLA in V2.3). OLA expansion corrected to "Open Limited Asset" (subsequently renamed to "Permissionless Limited Asset" in V2.3); MCA expansion corrected to "Deviant Managed Asset" (subsequently reverted to "Managed Certificate Asset" in V2.4 to restore M-C-A acronym integrity). Supply terminology decoupled from reservoir implementation. Deflationary property scoped to current CashScript reservoir behavior rather than presented as designed economic property. Glossary reorganized into six topical sub-tables. Previous versions (V2, V2.1, V2.2, V2.3, V2.4, V2.5, V2.6) retained for reference. Where versions conflict, the latest is correct.