deviant/Parameters/ASM_Native/ASM-no-shared-state-contention.md

ASM has no shared-state contention — rebuttal section

Context: a governance argument (CHIP-2025-03, block-time change) claims DEX contention is a covenant-design problem, not a consensus one, and points to ASM as a covenant architecture with no shared-state contention regardless of concurrent user count. This section defends that claim from first principles and with chipnet evidence.

---

1. All order liquidity — manual or automated — is the same thing

An order book and an AMM are not different categories. An AMM is an Automated Market Maker: automated order-making. A market maker posts liquidity as an order; an AMM posts it by formula instead of by hand. Either way the liquidity is a counterparty's order, placed on-chain as a spendable object — a resting-order UTXO, or a pool UTXO.

That shared object imposes two unavoidable costs on a UTXO chain:

1. Dependency. Your swap only exists if a maker (human or curve) has posted liquidity for it. No order → no swap. Liquidity is finite and counterparty-provided.
2. Contention. To take the order you must spend that shared object. Two takers reaching for the same order/pool UTXO at the same instant are double-spends: one confirms, the rest are rejected (txn-mempool-conflict). Concurrency is bounded by how many distinct liquidity objects exist, not by the block.

This is a property of sharing an object, and it is a design consequence, not a consensus limit. Faster or slower blocks do not change it.

2. ASM has no order, no counterparty, no shared object

ASM is not order liquidity. There is no maker, no order, no pool. The liquidity is the chain itself: lock BCH → receive a self-backed asset; unlock it → receive BCH, at a fixed protocol rate. Every swap touches only the swapper's own UTXOs:

• Mint (BCH → MBA): each address creates its own self-backed asset from its own input.
• Redeem (MBA → BCH): each address spends its own coin.

There is nothing shared for concurrent swappers to fight over. No dependency (you never need a counterparty to have posted liquidity), no liquidity ceiling (backing comes from your own BCH), and no scaling ceiling (no shared coin to serialize on). The same address can swap consecutively, and any number of addresses can swap simultaneously and consecutively, without collision.

3. Chipnet evidence

Test	Result	Meaning
Parallel mint — N addresses swap BCH→MBA at the same instant, separate txs	N/N accepted, N distinct self-backed assets, 0 collisions	each spends its own input → nothing shared
Parallel redeem — N addresses swap MBA→BCH simultaneously	6/6 accepted	each spends its own coin
Serial + concurrent, same and different addresses	no collision	independent txs

Representative parallel-mint categories (all distinct, each self-backed 100 units / 100,000 bits): 0868e656…4ba3, 1ebd51fa…1f1c, e30dc396…aa98. Parallel redeem: 6/6 (ece05e13…, fd6bd0a3…, 3b0c2ea8…, c06b1a1a…, 69f074a4…, cf590b60…).

4. The counter-example — a shared reservoir is not self-backed ASM

There is one build that reintroduces a shared object: funnel every mint of a single fungible token through one genesis reservoir coin (the whole supply pre-minted into one UTXO at the contract, drained by claim()). Structurally this is an AMM pool — one UTXO holding the reserves, spent and recreated per operation, therefore serialized. It behaves exactly like order liquidity for concurrency, and it is not the self-backed ASM model.

Where it sits — the confusing middle case:

	needs a counterparty/maker?	shares one coin?	concurrent result
Order liquidity (book or AMM)	yes	yes	dependency + contention
Reservoir-claim (shared genesis pool)	no	yes	contention only
Self-backed ASM (mint-your-own / redeem-your-own)	no	no	neither

The reservoir model is counterparty-free economically (no maker needs to have posted liquidity; the backing comes from the claimer's own BCH) but shares one coin structurally — so it inherits the pool's contention while dropping the order's dependency: worst-of-both shape for concurrency, ASM-flavored on the surface. It exists in the repo as the deployed ASM/ASM2 mechanism (snapshots 0007–0008), so it is a real but non-canonical ASM build — one that violates the no-shared-object principle the mechanism is founded on.

Chipnet, 6 addresses claiming the same token from its one reservoir at once:

• all six fetched the same outpoint (496b2ae5…:0),
• 1 confirmed (f6377cec…), 5 rejected txn-mempool-conflict (18).

That contention is not an ASM property — it is the shared-object property. Supply is irrelevant: a reservoir with 10¹⁸ units is still one coin, spendable by one tx at a time. Sequential/chained draws scale; simultaneous independent draws of the one coin collide. Self-backed ASM shares no coin, so none of this applies — the shared reservoir is what to avoid, not what ASM is.

4a. Wallet-layer resolution — client-side retry turns 1/6 into 6/6

Even the non-canonical reservoir build can be made contention-free at the wallet layer without consensus changes, sequencers, or a new covenant. Every loser of the race gets a classifiable error (txn-mempool-conflict (18) / bad-txns-inputs-missingorspent), so the wallet catches it, re-fetches the reservoir tip mempool-inclusive, re-plans against the fresh outpoint, and re-broadcasts. Bounded ≤ 5 attempts with linear backoff (n × 200 ms). This is the tier-4 "optimistic chain + retry" pattern in ASM-single-asset-throughput.md §2d.

Same 6-address chipnet stress, this time each concurrent claim wrapped in the retry loop (scripts/chipnet-asm-forced-race-retry-proof.mjs, tip 324490, reservoir start f61e1e4d…:0):

wallet	Phase A (no retry)	Phase B (with retry)	attempts to succeed
A	txn-mempool-conflict	92c3c78b… ✓	5
C	txn-mempool-conflict	d5d733b9… ✓	1
D	txn-mempool-conflict	79084691… ✓	5
E	txn-mempool-conflict	7b0f6980… ✓	2
F	6c9b3d16… ✓	b425e55f… ✓	3
G	txn-mempool-conflict	4904d1e6… ✓	4
total	1 of 6	6 of 6	20 attempts (mean 3.3), all under 3 s

Trust surface is unchanged from naïve broadcast — the wallet uses its own electrum/SPV session, re-plans locally, re-broadcasts locally, no coordinator. This ships in production wallet code today: shells/app/src/asm-core/retry.ts (beta wallet) and design/potidaea/src/retry.ts (the navigate.st/bns/potidaea.asm dApp).

The measurement upgrade — from 1/6 collision to 1/6 → 6/6 via bounded retry — is not theoretical: it uses the same reservoir, the same 6 wallets, and the same simultaneous-broadcast harness as §4's baseline, differing only in the retry wrapper around each broadcast.

5. Precise scope

ASM's ceiling-free, contention-free property holds as long as each swap touches only self-owned UTXOs — which the self-backed mint-your-own + redeem-your-own model does at every step. A ceiling appears only if an implementation reintroduces a shared object (single reservoir, shared baton, pool). That is a packaging choice ASM does not require.

6. Conclusion for the CHIP debate

ASM is a covenant design with zero shared-state contention regardless of concurrent count, demonstrated on chain. This confirms the thesis: "DEX contention" is a shared-liquidity-object design property — sharing an order/pool coin — not a consensus or block-time limitation. Order liquidity (whether hand-posted or AMM-automated) contends because takers spend a shared object; ASM does not, because there is no object to share — the chain is the liquidity. Block time is orthogonal.