deviant/Parameters/ASM_CrossChain

ASM_CrossChain — cross-chain master index

The single entry point for everything cross-chain in Deviant: moving value between BCH and other chains (BTC, Tron, Ethereum, …). This is an index/hub — the canonical docs live in their own folders (heavily cross-linked + actively maintained); this file catalogs and routes to them. Vision: bch-interchain-settlement-hub.

Naming note — ASM_ here is a SORT PREFIX, not a taxonomy claim. It groups this folder with ASM_Native/ and ASM_Native/Potidaea_OrbitalSwap/. This folder covers all cross-chain material — including DEX·Multichain rails that are not ASM: List A atomic swaps need a counterparty (that's DEX by the 2×2), as does the Anthemus trading floor. Only List B (lock→oracle→mint IOU) is the ASM·Multichain cell. Don't infer "ASM" from the folder name — check the rail. Taxonomy: ../Anthemus_DEX/ASM_DEX_Taxonomy.md.

Folder layout

Path	Holds
README.md (this file)	the master index / router
Chains/	per-chain onboarding research + its session prompt (which chains, what each needs)
Transactions/	the correspondent build: scope, session prompts, send-UI plan/mockup, Deviant Pay design
ZK-Proof/	zero-knowledge verification on BCH + the trustless zk-light-client trust-floor upgrade (2026-07 Groth16 finding)
T6_BitcoinCash_LN/	the BTC track — "BTC on BCH rails" (HTLC swap-in / BCH-as-channel-substrate), Model 3 BTC-IOU, M3-bond; BTC↔BCH is the List A / lock-side-wall corner of the hub

---

The one-paragraph model

BCH becomes a host for other chains: their assets are deposited, traded on BCH's DEX, and withdrawn home — decentralized, no-KYC. Two deposit mechanics, split by trust:

• List A — trustless atomic swap (value leaves the source; no IOU; end-to-end trustless).
• List B — lock-and-mint IOU (value stays denominated as a CashToken on BCH; trust-minimized, never trustless — the VM wall: BCH can't verify a foreign chain).

Then the loop closes: deposit → trade on Anthemus → withdraw (redeem).

Build plan (product)

Roadmap (bch-interchain-settlement-hub): Phase 1 other-chain→BCH deposit (lock-and-mint) → Phase 2 BCH→origin redeem.

Scope decision (2026-06-28, refined 2026-07-13): two distinct transaction types, named apart —

• Correspondent system (our debit/credit lock-and-mint, BCH ↔ chain). Never call it a "bridge." Deposit: lock on chain X → mint unified USDT on BCH (reserve[X] += amt). Withdraw (single-chain): burn on BCH → release on chain X, requires reserve[X] ≥ amt. Draining the BCH-side reserve counter to zero is fine — that IS the design; we hold no surplus USDT on any foreign chain (never more than the locked amount), so there is nothing to "drain" or rebalance on the foreign side.
• Bridge (its existing-crypto meaning: chain ↔ chain, external, Rabby-style aggregation). We do not build our own cross-chain swap/pool — we integrate external bridges. Phase 2.

Combination (Phase 2): when a user withdraws BCH → chain T and reserve[T] is partial/empty, the system covers what reserve[T] allows directly and draws the shortfall from other chains' reserves, routing that leg through the external (Rabby-style) bridge so the full amount lands on chain T. Invariant holds (burn == total reserves decremented). User only ever sees Send + approve/sign. Accounting validated in scripts/sim-unified-usdt-reserve.mjs (Y's 400 mixed-origin USDT; invariant Σ reserves == minted == Σ balances). The Phase-1 covenant enforces the single-chain rule (over-reserve single-chain withdraw → reject); Phase 2 relaxes it by adding the bridge-routing layer on top — the reject is the Phase-1 boundary, not a dead end.

• Phase 1 scope: phase-1_deposit-build-scope.md — UI in shells/app, source-chain connect-wallet signing, a bridge service (wraps the validated lock-mint logic). Spec/mockup: cross-chain-send.html.

Session plan (revised 2026-07-13 — the two prompts are CO-DEPENDENT; run them in ONE session, in order): The single pasteable prompt is correspondent-session_PROMPT.md; it sequences the two detail prompts below.

1. onchain-testing-session_PROMPT.md — design + on-chain testing; first build the unified-USDT reserve covenant (enforce sim-unified-usdt-reserve.mjs). Has the funded Nile/Sepolia/chipnet keys.
2. phase-1_build_PROMPT.md — then, same session, the Phase 1 correspondent build (service + connect-wallet UI) on top of the tested covenant.

UI models (2026-07-15): the shipping flow is the external-wallet Deposit/Withdraw model with a human-named source gateway (contracts/evm/DeviantBitcoinCashGateway.sol — wallets decode the call as "Deposit To Bitcoin Cash"). A "From → To" Send UI for Deviant's own multi-chain wallet (we sign the source leg in-app, no external popup) is planned in multichain-wallet-send-ui_PLAN.md. Accepting cross-chain payments settled on BCH (merchant use) is designed in deviant-pay_design.md — governed by ADR-0050 (convert at market, never mint a currency you don't hold: solvent by construction).

Adding new chains/coins (Ethereum Classic, Litecoin, DOGE, BSC…) — the 3-bucket decision tree (EVM = config+deploy · UTXO-Script = the validated BTC M-of-N pattern · other VM = a real build), constraints and reuse table: new-chain-onboarding_RESEARCH.md; pasteable session prompt: new-chain-research_PROMPT.md.

Once the correspondent system is designed + tested, a new session does Phase 2: the Rabby-style bridge + the correspondent-plus-bridge combination (user sees only Send/confirm). Phase C (furthest out): a Universal USD — unify the ~90+ fragmented USD stablecoins × chains into one UI "USD" backed by a heterogeneous basket, backend-routed to any specific form/chain on send/confirm. No USD-peg liability — we hold only the 1:1 warehouse peg (native (asset,chain) ↔ its BCH IOU); cross-form conversion always routes at external-market rate, never internal par → solvent by construction. ADR before build = policy only (display/labeling + which stablecoins the basket admits), not solvency (bch-interchain-settlement-hub Phase C).

0. Trust floor — the 2026-07 zk finding (read if trust model is in scope)

• zk verification on BCH & light clients (folder: ZK-Proof/) — the single reference doc for the finding: on-chain Groth16 zk-SNARK verification now runs in one standard BCH tx (no CHIP; 2025 VM upgrades). Removes the BCH-side blocker to a trustless zk-light-client, upgrading List B's trust floor from bonded M-of-N. Falsifies the old "needs a pairing CHIP" line in §6 below. Remaining lift = per-chain consensus circuit + prover. Does NOT change the current correspondent build (still bonded M-of-N).

1. Start here — concept & taxonomy

• ASM vs DEX taxonomy (README) — the 2×2 (ASM/DEX × Native/Multichain).
• cross-chain-asm-concept-and-state — §4 debit/credit, §5 verification spectrum, §6 the VM wall.
• chain & asset landscape — which chains/assets, List A vs List B, validated-rails matrix.

2. List A — trustless atomic swap (value leaves source)

• DEX · Multichain — Atomic Swaps — the HTLC swap cell.
• btc-on-bch-rails test program — T1/T4/T5/RT (BTC↔BCH swap).
• cross-chain HTLC ramp — HTLC fiat/crypto ramp angle.

3. List B — lock-and-mint IOU (value stays; where "send BTC → BTC-IOU" belongs)

• ASM · Multichain — lock → oracle/bond → mint IOU — the cell + wrapped-asset naming.
• BTC instance — Model 3 (BTC-IOU): the T6 track (below) + scripts/chipnet-btc-iou-demo.mjs.
• Tron/Ethereum instances (this session, Build B): build-B scope — τUSDt / τTRX (Tron), εUSDC (Ethereum), reconciliation, bonded M-of-N.

4. The BTC track (T6 / "BCH as a better Lightning" + Model 3 BTC-IOU)

• T6 complete record — all tests (T1–T6r, M3-bond).
• T6 model explained · MVP tech spec
• mechanics/economics/topology · observability & privacy
• why demonstration, not argument — the epistemics.

5. The trading floor (where deposited assets trade)

• Anthemus — the BCH DEX · business model
• Trade demo: scripts/chipnet-hub-dex.mjs (τUSDt ⇄ εUSDC on SharePairAMM).

6. Contracts

Contract	Role
contracts/AtomicSwapHTLC.cash	BCH-side HTLC (List A swap)
contracts/DeviantWrapMintIOU.cash	BCH-side mint of the IOU (List B), oracle checkDataSig
contracts/BondedSignerSlash.cash	the slashable bond (M-of-N trust floor, BCH side)
contracts/tron/TronHTLC.sol	Tron-side HTLC (B1/B2)
contracts/tron/TronUSDTVault.sol, TronTRXVault.sol, TronUSDTVaultMofN.sol	Tron lock vaults (B3–B6)
contracts/SharePairAMM.cash	the DEX pool (Anthemus) where IOUs trade

7. Scripts (by chain)

• BTC signet: btc-bch-htlc-swap.mjs (T4), btc-signet-{channel,penalty,honest-close,mofn-release,ln-leg}.mjs, btc-claim-htlc.mjs, chipnet-btc-iou-demo.mjs, chipnet-signet-iou-redeem.mjs, chipnet-ln-to-t6-routing.mjs, chipnet-channel-board-multi.mjs.
• Tron Nile: tron-gen-address.mjs, tron-balance.mjs, tron-trc20-holdings.mjs, tron-htlc-b1.mjs, tron-bch-htlc-swap.mjs (B2), tron-bch-lock-mint.mjs (B3–B5), tron-bch-lock-mint-trx.mjs, tron-vault-mofn.mjs (B6), tron-{usdt-probe,sim-transfer,b2-claim-retry}.mjs.
• Ethereum Sepolia: eth-gen-address.mjs, eth-balance.mjs, eth-bch-htlc-swap.mjs.
• Trade: chipnet-hub-dex.mjs.

8. ADRs & snapshots

• ADRs: ADR-0016 (routing), ADR-0035 (USD-rail bridge trust), ADR-0046 (T6/BTC + trust floor), ADR-0047 (interchain settlement hub), ADR-0048 (Potidaea business model / brand).
• Snapshots: 0172–0178 (T6/BTC track), 0181 (Build B complete: Tron/Ethereum rail + hub).

9. Memories

[[bch-interchain-settlement-hub]], [[chipnet-dex-and-cross-chain-wrap-plan]], [[wrapped-asset-source-chain-marker]], [[btc-on-bch-rails-not-channel]], [[tether-returns-false-balance-delta]], [[demonstration-over-reasoning-captured-audience]].

---

Placement: "send BTC → get a BTC-IOU on BCH" (the answer)

It belongs in List B (lock-and-mint IOU) → ASM · Multichain → Model 3 (BTC-IOU). It is the BTC instance of the same lock-and-mint pattern generalized this session to τUSDt / τTRX (Tron) and εUSDC (Ethereum) — a sibling of τUSDt.

• Not "custodial." A single custodian is the trusted extreme we reject. Model 3's reserve is a bonded M-of-N (validated as M3-bond: 2-of-3 BTC release on signet + a slashable bond on BCH, BondedSignerSlash.cash). So it is trust-minimized, never trustless — because BTC has no covenants (the VM wall), a BTC peg cannot be trustless; the honest floor is a bonded, slashable signer set with publicly-reconcilable backing (mint == lock).
• Where it was designed: the BTC-specific Model 3 + M3-bond is earlier-session work (T6 track, ADR-0046, snapshots 0172–0178, chipnet-btc-iou-demo.mjs). This session extended the pattern to Tron/Ethereum (Build B). Same mechanism, different source chains.
• In the hub loop: it's a deposit path (the IOU flavor). Once minted, the BTC-IOU trades on Anthemus and redeems back to BTC via the M-of-N reserve.

Naming decision — describe don't brand; and "bridge" ≠ our correspondent system

Unlike Potidaea (the ASM) and Anthemus (the DEX) — which are products/venues worth a brand — cross-chain plumbing is best named what it is. There are two distinct transaction types, and they must carry two different description names (decided 2026-07-13):

• Correspondent system (a.k.a. debit/credit) = our BCH ↔ chain lock-and-mint. Never call it a "bridge." It's the crypto-native correspondent-banking primitive: debit the source chain, credit the destination (nostro/vostro, like a bank wire) — see cross-chain-asm-concept §4.
• Bridge = reserve this word for its existing-crypto meaning: chain ↔ chain external routing (Rabby-style). That's the Phase-2 add-on, not our correspondent rail.
• No Greek/product name for either. User-facing, both are just Send / Receive.
• User-facing = plain language, explicitly explained. The user sees Send / Receive (and, for stables, USDc + a Ledger/Chain selector) — never "lock-and-mint", "IOU", "wrap", or a codename. Under the hood it's debit/credit; on screen it's a transfer. Consistent with [[fiatm-ux-just-swap]] and [[wrapped-asset-source-chain-marker]].
• Principle: keep it as simple as possible for users — name things what they are and explain them explicitly. Brand the venues (Agora ▸ Potidaea / Anthemus); describe the transfer.

This resolves the open naming item ("does the cross-chain ASM get a sibling brand?") — no.