design(cross-chain): DGB rail commits to atomic-swap-primary (snapshot 0271)
Design decision locked in after a long thread exploring alternatives. Two
designs fully explored and killed on the way:
1. Self-custodial Taproot vault with owner-fallback leaf. Killed by the
cross-chain double-spend exploit: Alice locks DGB → sells CashToken to
Bob → waits T_fallback → uses fallback to recover DGB → Alice has
money+DGB, Bob has worthless CashToken. Any owner-fallback in a
bearer-CashToken model is a rug-pull vector by construction.
2. Pool-with-cosign design gating spends on BCH burn observability.
Killed by the fundamental constraint (user's phrasing): "DGB is
completely detached from Bitcoin Cash chain, and doesn't care if
someone has burned cashtokens." DGB script can only verify locally-
checkable primitives (sigs, hash preimages, timelocks); no way to
cryptographically bind a DGB spend to a BCH event. Collapses to
either MPC-federated trust or non-transferable personal receipt —
neither is a categorical improvement over the shipped rail.
Atomic swap sidesteps both because it never asks DGB to know about BCH.
The cryptographic linkage is a shared preimage that unlocks both sides;
neither chain needs to understand the other. And in an atomic-swap rail
there's no pool at all — after each swap the DGB is in some specific
market-maker's wallet under their own single-sig key.
Snapshot 0270's three covenants (WithdrawalHTLC, DepositHTLC,
Deposit.burn) are the BCH-side foundation and need no changes — they
were designed for exactly this composition. The remaining lift is:
- DGB-side HTLC primitives in services/correspondent/dgb.mjs
- Swap driver script
- Matching layer (Anthemus tie-in)
- MM float bootstrap decision (Option A one-time genesis mint vs
Option B ongoing MM-only oracle-attested path)
Index rebuilt to 314 snapshots. Next: extend dgb.mjs with the HTLC
primitives (build/verify/claim/refund), targeting a chipnet ↔ DGB
testnet dry-run for snapshot 0272.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
Local Dev
parent
4b1a3080d7
commit
1865e6d518
2 changed files with 208 additions and 2 deletions
204
snapshots/0271-cross-chain-atomic-swap-primary-rail-decision.md
Normal file
204
snapshots/0271-cross-chain-atomic-swap-primary-rail-decision.md
Normal file
|
|
@ -0,0 +1,204 @@
|
|||
---
|
||||
domain: cross-chain
|
||||
summary: "Design decision — the DGB rail commits to ATOMIC-SWAP-PRIMARY. Two alternatives fully explored and killed: (a) self-custodial Taproot vault with owner-fallback creates a cross-chain double-spend rug-pull because Alice can sell CashToken to Bob then recover DGB via fallback leaf; (b) any pool-with-cosign design that hopes to gate the DGB spend on a BCH burn is impossible on DGB Script alone — DGB is completely detached from BCH and doesn't care if CashToken burned. Atomic swap sidesteps both because it never asks DGB to know about BCH — the cryptographic linkage is a shared preimage that unlocks both sides. Snapshot 0270's three covenants (WithdrawalHTLC, DepositHTLC, Deposit.burn) are the BCH-side foundation and need no changes; the remaining lift is DGB-side HTLC primitives + a swap driver + a matching layer (Anthemus) + MM float bootstrap."
|
||||
tags: cross-chain, atomic-swap, dgb, design-decision, deposit, withdrawal, htlc, non-custodial, trust-model, deposit-covenant, anthemus, digibyte
|
||||
---
|
||||
|
||||
# Snapshot 0271 — DGB rail commits to atomic-swap-primary (design decision)
|
||||
|
||||
**Date:** 2026-09-16
|
||||
**Track:** Cross-chain / correspondent rails · design
|
||||
**Status:** Design decision, no code changes in this snapshot. Locks in the direction for the next
|
||||
build (snapshot 0272: chipnet ↔ DGB testnet dry-run of the atomic-swap flow using the
|
||||
already-shipped BCH covenants from 0270).
|
||||
|
||||
---
|
||||
|
||||
## Decision
|
||||
|
||||
The DGB deposit/withdrawal rail is **atomic-swap-primary**. Peer-to-peer atomic swaps between DGB
|
||||
mainnet and DGB CashToken on BCH, with market-makers providing liquidity, replace the
|
||||
bonded-operator model as the mainline rail going forward. The shipped bonded-operator rail
|
||||
(snapshots 0267–0269) continues to run for the deposits already on it, but new architecture work
|
||||
is on the atomic-swap path.
|
||||
|
||||
## Reasoning trail — the two designs that were killed
|
||||
|
||||
Recording these explicitly so future-us doesn't re-litigate them.
|
||||
|
||||
### Dead end 1 — self-custodial Taproot vault with owner-fallback
|
||||
|
||||
Initial proposal was a bespoke DGB Taproot vault:
|
||||
|
||||
```
|
||||
Leaf 1 (normal cross-chain unlock, no timelock):
|
||||
<AliceDgbKey> OP_CHECKSIGVERIFY
|
||||
<oracleKey> OP_CHECKSIG
|
||||
|
||||
Leaf 2 (self-recovery fallback after long timelock):
|
||||
<T_fallback> OP_CHECKLOCKTIMEVERIFY OP_DROP
|
||||
<AliceDgbKey> OP_CHECKSIG
|
||||
```
|
||||
|
||||
Claimed property: Alice always has an emergency exit after `T_fallback`, giving her a real
|
||||
self-custody guarantee independent of oracle liveness.
|
||||
|
||||
**The exploit that killed it (2026-09-11):**
|
||||
|
||||
1. Alice locks 100 DGB → oracle mints 100 CashToken to Alice on BCH.
|
||||
2. Alice sells the 100 CashToken to Bob for cash on BCH.
|
||||
3. Alice waits `T_fallback` blocks.
|
||||
4. Alice unilaterally spends her vault via Leaf 2 → recovers 100 DGB.
|
||||
5. **Alice now holds:** cash from selling + her 100 DGB. **Bob holds:** worthless CashToken. Every
|
||||
downstream CashToken holder is a rug-pull victim.
|
||||
|
||||
The fallback is not a security feature in a bearer-CashToken model — it's a time-delayed
|
||||
cross-chain double-spend built directly into the vault script. The length of `T_fallback` just
|
||||
prices the rug-pull in time; it doesn't prevent it.
|
||||
|
||||
**Conclusion:** in a bearer CashToken model there is no meaningful "Alice's DGB" after Alice
|
||||
transfers the CashToken. Any owner-fallback path is by construction a rug-pull vector. Design has
|
||||
to drop the fallback entirely — but then the design collapses back into a pure operator-custody
|
||||
model, and the "self-custodial" claim was hollow.
|
||||
|
||||
### Dead end 2 — pool with cosign gated on BCH burn
|
||||
|
||||
Second proposal was a shared DGB pool whose spends require multi-signature: operator's key +
|
||||
someone's cosign. Cosign only when a BCH CashToken burn is observable.
|
||||
|
||||
The intuition is right — the enforcement should live on BCH where covenants can enforce, not on
|
||||
DGB where they can't. But when made rigorous, the design has a fundamental constraint:
|
||||
|
||||
> **DGB is completely detached from Bitcoin Cash chain, and doesn't care if someone has burned
|
||||
> cashtokens** (user, 2026-09-16).
|
||||
|
||||
DGB script can verify signatures, hash preimages, and timelocks — all locally-checkable primitives.
|
||||
It cannot verify "a CashToken burn happened on BCH". So any cosigner requirement written into a
|
||||
DGB script only checks *who signed*, not *whether the burn condition was met*. A malicious
|
||||
cosigner can sign whether or not a burn happened; DGB script can't tell the difference.
|
||||
|
||||
The design collapses into one of:
|
||||
- **Per-deposit 2-of-2 (operator + depositor)** — cryptographically strong, but non-transferable
|
||||
(Bob can't withdraw from Alice's vault without Alice's cooperation). Not a wrapped-DGB UX.
|
||||
- **MPC threshold + BCH burn-cert verification** — the "cosigner" role is the threshold-signing
|
||||
protocol, gated by each signer independently verifying the BCH burn before contributing their
|
||||
share. Cryptographic enforcement, but the trust is *procedural inside each signer's software*
|
||||
— nothing on DGB stops M colluding signers from producing a fraudulent signature. Same-shape
|
||||
risk as an M-of-N federated bridge.
|
||||
- **Adaptor signatures** — mathematically clean, but the spending tx's destination is fixed in the
|
||||
pre-signed adaptor sig, which doesn't work for arbitrary future withdrawers.
|
||||
|
||||
None of these give wrapped-DGB UX + cryptographic non-custody simultaneously. They give one or the
|
||||
other. The MPC variant is buildable and legitimate (it's what wBTC/wETH do at a trust level), but
|
||||
it's still M-of-N federated trust — not a categorical improvement over the shipped bonded-operator
|
||||
rail, just a different shape of the same trust.
|
||||
|
||||
**Conclusion:** any design that keeps a pool of DGB on DGB mainnet requires trust in whoever holds
|
||||
the pool key. There is no clever way to cryptographically bind BCH burn events to DGB spending
|
||||
authority without one of: (a) DGB Script upgrades that can verify BCH state, (b) a trusted-signer
|
||||
set, or (c) no pool at all.
|
||||
|
||||
## Why atomic swap works — the cryptographic linkage that neither dead end had
|
||||
|
||||
Atomic swap eliminates the class of problems both dead ends ran into, because it *never asks DGB
|
||||
to know about BCH*. The linkage between the two chains is a single shared preimage `s`:
|
||||
|
||||
- **DGB side (per swap):** a plain P2SH-HTLC. Claim path: `<H> OP_SHA256 OP_EQUALVERIFY <counterparty_pk> OP_CHECKSIG`. Refund path: `<T> OP_CLTV OP_DROP <owner_pk> OP_CHECKSIG`.
|
||||
- **BCH side (per swap):** the shipped `WithdrawalHTLC.cash` (for withdrawal) or `DepositHTLC.cash`
|
||||
(for deposit) from snapshot 0270. Claim path requires the same preimage `s`.
|
||||
|
||||
To claim on either side, the claimant must reveal `s`. Revealing `s` on one chain makes it
|
||||
available to the counterparty on the other chain. The atomicity is cryptographic:
|
||||
|
||||
- If Alice reveals `s` to claim CashToken on BCH, the market-maker sees `s` on BCH and uses it to
|
||||
claim Alice's DGB on DGB mainnet.
|
||||
- If neither party reveals, both HTLCs time out and refund to their original owners. No state
|
||||
change on either chain.
|
||||
|
||||
**Property:** at no point does anyone hold spending authority over funds they didn't already have
|
||||
signature power over. Alice's DGB is either in her wallet (before swap) or in a specific
|
||||
market-maker's wallet (after swap). There's no pool, no operator, no cosigner set. The
|
||||
transferable-CashToken problem dissolves because the CashToken is a plain FT — anyone can hold it,
|
||||
and withdrawal is another atomic swap with whichever market-maker is willing to make the market.
|
||||
|
||||
## What we already have — snapshot 0270's covenants are the BCH-side foundation
|
||||
|
||||
Nothing needs to change on the BCH side. The three covenants shipped at snapshot 0270 and their
|
||||
tx-layout convention are exactly what an atomic-swap-primary rail wants:
|
||||
|
||||
- **[`contracts/Deposit.cash`](../contracts/Deposit.cash)** with `burn()` — the reservoir that un-mints CashToken when a withdrawal atomic-swap claim happens.
|
||||
- **[`contracts/WithdrawalHTLC.cash`](../contracts/WithdrawalHTLC.cash)** — Alice locks CashToken for withdrawal; market-maker claims with preimage; refund path returns to Alice.
|
||||
- **[`contracts/DepositHTLC.cash`](../contracts/DepositHTLC.cash)** — market-maker locks CashToken for deposit; user claims with preimage; refund path un-mints back to reservoir.
|
||||
|
||||
Regtest: 8/8 (3/3 existing deposit tests + 5/5 composition tests). See snapshot 0270 for the
|
||||
pinned tx layout and the design refinements the regtest surfaced.
|
||||
|
||||
## What's left to build
|
||||
|
||||
The lift from "regtest-verified BCH side" to "usable atomic-swap deposit/withdrawal rail":
|
||||
|
||||
1. **DGB-side HTLC primitives** in [`services/correspondent/dgb.mjs`](../services/correspondent/dgb.mjs) — extending the existing rail module:
|
||||
- `buildDgbHtlc({ hashLock, counterpartyPubkey, ownerPubkey, refundLockTime, network })` → P2SH address + redeem script
|
||||
- `verifyDgbHtlc(txid, vout, expectedParams)` → boolean + confirmations
|
||||
- `claimDgbHtlc(txid, vout, preimage, claimerPrivkey)` → signed tx (claim leg)
|
||||
- `refundDgbHtlc(txid, vout, ownerPrivkey)` → signed tx after `refundLockTime` (refund leg)
|
||||
- Same three-API-shape verifier pattern as the existing `verifyLock` (Insight / Blockbook / Esplora).
|
||||
|
||||
2. **Swap driver script** — `scripts/dgb-atomic-swap.mjs`. `--yes` gated, `--direction=deposit|withdrawal`, `--dgb=N`, `--counterparty=<addr>`. Orchestrates the full swap end-to-end, following the driver-shape pattern of [`scripts/redeem-dgb-mainnet-real.mjs`](../scripts/redeem-dgb-mainnet-real.mjs).
|
||||
|
||||
3. **Matching layer** — how market-makers and users find each other:
|
||||
- Bare-bones (early testing): a JSON order-book file MMs write to and drivers read.
|
||||
- Anthemus tie-in (production): market-makers post DGB CashToken orders on Anthemus; the driver reads the order book and initiates the swap after matching. This closes a real product loop — Anthemus becomes the discovery layer for the DGB rail rather than a separate thing.
|
||||
|
||||
4. **Chipnet ↔ DGB testnet dry-run** — genesis a fresh reservoir on chipnet against the current
|
||||
`Deposit.cash` (with `burn()`), do a full deposit atomic-swap and a full withdrawal
|
||||
atomic-swap. Snapshot 0272 territory.
|
||||
|
||||
5. **MM float bootstrap decision** — where do the first CashTokens come from? Two options,
|
||||
deferred to when MM invitation happens (not blocking earlier steps):
|
||||
- **Option A**: one-time genesis mint via `Deposit.deposit()` (oracle-attested). Trusted mint
|
||||
at genesis, distributed to registered MMs based on their DGB inventory. One-time trust event;
|
||||
from then on all user-facing flows are atomic-swap-only. MMs have skin in the game.
|
||||
- **Option B**: retain `Deposit.deposit()` as an MM-only ongoing path. Only registered MMs can
|
||||
call it (require a BCH bond to become an MM). Oracle trust surface is bounded to "MM float
|
||||
growth"; user deposits/withdrawals remain atomic-swap-only.
|
||||
- Both leave `Deposit.deposit()` non-user-facing. Regular users never see the oracle-attested path.
|
||||
|
||||
## Trust profile — the honest picture
|
||||
|
||||
- **Per-swap:** trustless (atomic HTLC).
|
||||
- **CashToken transferability:** works — the CashToken is a plain FT; Bob receives it via a
|
||||
normal BCH transaction; his withdrawal is another atomic swap with any MM.
|
||||
- **MM inventory management:** MMs balance DGB and CashToken via swaps with users and with other
|
||||
MMs (BCH-only swaps for CashToken, or another MM's DGB position). Competition sets the spread.
|
||||
- **Backing invariant:** total CashToken supply = total DGB held across all MMs + reservoir.
|
||||
Publicly auditable at any moment by summing on-chain balances.
|
||||
- **The one non-atomic-swap trust surface:** MM float bootstrap. Genesis mint is a one-time event
|
||||
or a bounded ongoing path (Option A/B). Either way, users never rely on trust for their own
|
||||
deposits/withdrawals.
|
||||
|
||||
Compared to bonded-operator (shipped) or MPC-threshold-federated (dead end 2), this is a genuine
|
||||
trust reduction — not a rearrangement. The user's DGB is never in a pool anyone else can touch.
|
||||
|
||||
## Fits the project convention
|
||||
|
||||
- **Not called a bridge.** "Correspondent" per [[correspondent-system-and-reserve-covenant]]. Two-step deposit/withdrawal session.
|
||||
- **CashToken identity by category** ([[wrapped-asset-source-chain-marker]]). DGB-on-BCH stays `DGB` in the UI; the category is the technical identity marker.
|
||||
- **Anthemus** as the matching layer is consistent with [[anthemus-dex-naming]] and [[anthemus-business-model]] — a fee surface on the atomic-swap side is one of the five fee lanes.
|
||||
- **A deposit is a balance**, not a wrapped IOU ([[wrapped-asset-source-chain-marker]]). Even in an atomic-swap rail, the CashToken is presented to users as "DGB on Bitcoin Cash", not "wrapped DGB IOU".
|
||||
|
||||
## Pointers
|
||||
|
||||
- BCH-side covenants (already shipped): [`contracts/Deposit.cash`](../contracts/Deposit.cash) · [`contracts/WithdrawalHTLC.cash`](../contracts/WithdrawalHTLC.cash) · [`contracts/DepositHTLC.cash`](../contracts/DepositHTLC.cash)
|
||||
- Regtest: [`test/regtest/deposit-htlc-composition.test.ts`](../test/regtest/deposit-htlc-composition.test.ts) (5/5)
|
||||
- DGB rail (bonded-operator, shipped): [`services/correspondent/dgb.mjs`](../services/correspondent/dgb.mjs)
|
||||
- Shipped live drivers: [`scripts/onboard-dgb-mainnet-real.mjs`](../scripts/onboard-dgb-mainnet-real.mjs) · [`scripts/redeem-dgb-mainnet-real.mjs`](../scripts/redeem-dgb-mainnet-real.mjs)
|
||||
- Handoff for parallel sessions: [`wiki/cross-chain/atomic-swap-handoff.md`](../wiki/cross-chain/atomic-swap-handoff.md)
|
||||
- Preceding snapshots: 0267 (rename + rail), 0268 (deposit live), 0269 (redeem round-trip + trust discussion), 0270 (atomic-swap covenant triangle, regtest-verified)
|
||||
|
||||
## Not in this snapshot
|
||||
|
||||
- Any code changes. Design decision only.
|
||||
- DGB-side HTLC implementation — next step, going into `dgb.mjs`.
|
||||
- Chipnet dry-run — separate snapshot (0272) when the driver is ready.
|
||||
- MM float bootstrap decision — deferred to MM invitation time.
|
||||
|
|
@ -10,7 +10,7 @@
|
|||
> Duplicate snapshot numbers exist (0018, 0019, 0022, 0027, 0053, 0054, 0057, 0062, 0083, 0084,
|
||||
> 0144, 0145, 0153, 0164) — they are distinct files, disambiguated below by slug.
|
||||
|
||||
_313 snapshots · 313 tagged · 8 domains · regenerate after adding one._
|
||||
_314 snapshots · 314 tagged · 8 domains · regenerate after adding one._
|
||||
|
||||
## Quick-find — all snapshots (Ctrl-F by №, domain, tag, or word)
|
||||
|
||||
|
|
@ -328,6 +328,7 @@ _313 snapshots · 313 tagged · 8 domains · regenerate after adding one._
|
|||
| [0268](0268-cross-chain-dgb-deposit-live-mainnet-to-chipnet.md) | cross-chain | cross-chain dgb digibyte deposit live-mainnet chipnet deposit-covenant native-coin correspondent first-real-run cashtoken | DGB deposit LIVE end-to-end — 10 DGB locked on DigiByte mainnet (tx f334cd5293… block 24154002, vault dgb1q7p09cwq…) → 10 DGB credited to Alice as a CashToken on the Bitcoin Cash chipnet via the new contracts/Deposit.cash covenant (mint tx e21ceafcd8…, category 74b6e111446253bb…). Independently verified both chains: locked == credited. First native-coin (non-stablecoin) deposit; first live use of Deposit.cash and services/correspondent/dgb.mjs. |
|
||||
| [0269](0269-cross-chain-dgb-redeem-roundtrip-live.md) | cross-chain | cross-chain dgb digibyte redeem round-trip live-mainnet chipnet deposit-covenant bonded-operator-custody security-truth bip143 p2wpkh min-relay-fee dust | DGB REDEEM round-trip closed end-to-end, both chains verified. Alice surrendered 10 DGB CashToken on chipnet (return tx d67d9205…) → operator released 9.9995 DGB from the mainnet vault to her P2PKH (release tx 317e73d3… confirmed block 24154111); ~0.0005 DGB absorbed as network fee. Also: fixed real P2WPKH-signing bug in dgb.mjs (BIP143 scriptCode must be P2PKH-shape, not P2WPKH output), DGB min-relay is ~200 sat/vB (not 20), and honestly documented that vault DGB is bonded-operator-custodied (plain P2WPKH), NOT covenant-enforced by the BCH burn — same trust floor as evm/tron/solana rails. |
|
||||
| [0270](0270-atomic-swap-deposit-withdrawal-htlc-design.md) | cross-chain | cross-chain atomic-swap htlc design deposit withdrawal covenant sketch mpc trust-model deposit-covenant | Design sketch — atomic-swap deposit/withdrawal for the cross-chain rails, using paired HTLCs. WithdrawalHTLC.cash (BCH side, burn-on-claim) sketched in full; DepositHTLC.cash sibling (BCH side, burn-on-refund) sketched in outline; mocked driver walks the choreography (Phases 1-5). Fixes the deposit-time and withdrawal-time trust window in the current bonded-operator rails (0267-0269). Honestly bounded: does NOT reduce accumulated custody trust in the DEX's source-chain address — that still needs MPC/multi-sig + slashable-bond scaffolding. Design-only, not committed to any live rail. |
|
||||
| [0271](0271-cross-chain-atomic-swap-primary-rail-decision.md) | cross-chain | cross-chain atomic-swap dgb design-decision deposit withdrawal htlc non-custodial trust-model deposit-covenant anthemus digibyte | Design decision — the DGB rail commits to ATOMIC-SWAP-PRIMARY. Two alternatives fully explored and killed: (a) self-custodial Taproot vault with owner-fallback creates a cross-chain double-spend rug-pull because Alice can sell CashToken to Bob then recover DGB via fallback leaf; (b) any pool-with-cosign design that hopes to gate the DGB spend on a BCH burn is impossible on DGB Script alone — DGB is completely detached from BCH and doesn't care if CashToken burned. Atomic swap sidesteps both because it never asks DGB to know about BCH — the cryptographic linkage is a shared preimage that unlocks both sides. Snapshot 0270's three covenants (WithdrawalHTLC, DepositHTLC, Deposit.burn) are the BCH-side foundation and need no changes; the remaining lift is DGB-side HTLC primitives + a swap driver + a matching layer (Anthemus) + MM float bootstrap. |
|
||||
| [0271](0271-wallet-bulk-import-from-encrypted-keystore.md) | wallet | wallet keystore bulk-import multi-account ui chipnet master-password aes-gcm pbkdf2 subtle-crypto multi-key-store settings | Design spec for Settings→Wallets → "Import from encrypted keystore": UI-side loop over `MultiKeyStore.importWif/importSeed` that reads `Keys/chipnet-keystore.json` (chipnet-keystore/2-encrypted, PBKDF2-SHA256/200k + AES-256-GCM), prompts once for the master password, previews entries with labels/categories/cashaddrs, checkbox-selects, and imports N wallets under one PIN entry. **No MultiKeyStore API changes**; uses the stable `importWif`/`importSeed` shipped 2026-07-07. |
|
||||
|
||||
## Wallet UI (shells/app) `(101)`
|
||||
|
|
@ -536,7 +537,7 @@ _313 snapshots · 313 tagged · 8 domains · regenerate after adding one._
|
|||
- [0168-fiatm-exchange-demo-and-adaptive-layer-design](0168-fiatm-exchange-demo-and-adaptive-layer-design.md) — FIATμ Exchange demo + adaptive response layer design · _fiatm_
|
||||
- [0169-real-data-historical-sim-empirical-7b-va](0169-real-data-historical-sim-empirical-7b-va.md) — real-data historical sim — empirical §7b validation + data-source paywall finding
|
||||
|
||||
## Cross-chain / interchain hub / T6 `(50)`
|
||||
## Cross-chain / interchain hub / T6 `(51)`
|
||||
|
||||
- [0170-chipnet-amm-usdm-pusd-and-crosschain-wrap-tusdt](0170-chipnet-amm-usdm-pusd-and-crosschain-wrap-tusdt.md) — chipnet USDm/PUSD AMM + real cross-chain wrap (USDt → τUSDt) · _usdm, cross-chain, crosschain, wrap_
|
||||
- [0171-crosschain-wrap-safeerc20-fix-robustness-naming](0171-crosschain-wrap-safeerc20-fix-robustness-naming.md) — cross-chain wrap hardening: SafeERC20 fix, robustness suite, naming model, source-chain selector · _cross-chain, crosschain, wrap_
|
||||
|
|
@ -588,6 +589,7 @@ _313 snapshots · 313 tagged · 8 domains · regenerate after adding one._
|
|||
- [0268-cross-chain-dgb-deposit-live-mainnet-to-chipnet](0268-cross-chain-dgb-deposit-live-mainnet-to-chipnet.md) — DGB deposit LIVE end-to-end — 10 DGB locked on DigiByte mainnet (tx f334cd5293… block 24154002, vault dgb1q7p09cwq…) → 10 DGB credited to Alice as a CashToken on the Bitcoin Cash chipnet via the new contracts/Deposit.cash covenant (mint tx e21ceafcd8…, category 74b6e111446253bb…). Independently verified both chains: locked == credited. First native-coin (non-stablecoin) deposit; first live use of Deposit.cash and services/correspondent/dgb.mjs. · _cross-chain, dgb, digibyte, deposit, live-mainnet, chipnet, deposit-covenant, native-coin, correspondent, first-real-run, cashtoken_
|
||||
- [0269-cross-chain-dgb-redeem-roundtrip-live](0269-cross-chain-dgb-redeem-roundtrip-live.md) — DGB REDEEM round-trip closed end-to-end, both chains verified. Alice surrendered 10 DGB CashToken on chipnet (return tx d67d9205…) → operator released 9.9995 DGB from the mainnet vault to her P2PKH (release tx 317e73d3… confirmed block 24154111); ~0.0005 DGB absorbed as network fee. Also: fixed real P2WPKH-signing bug in dgb.mjs (BIP143 scriptCode must be P2PKH-shape, not P2WPKH output), DGB min-relay is ~200 sat/vB (not 20), and honestly documented that vault DGB is bonded-operator-custodied (plain P2WPKH), NOT covenant-enforced by the BCH burn — same trust floor as evm/tron/solana rails. · _cross-chain, dgb, digibyte, redeem, round-trip, live-mainnet, chipnet, deposit-covenant, bonded-operator-custody, security-truth, bip143, p2wpkh, min-relay-fee, dust_
|
||||
- [0270-atomic-swap-deposit-withdrawal-htlc-design](0270-atomic-swap-deposit-withdrawal-htlc-design.md) — Design sketch — atomic-swap deposit/withdrawal for the cross-chain rails, using paired HTLCs. WithdrawalHTLC.cash (BCH side, burn-on-claim) sketched in full; DepositHTLC.cash sibling (BCH side, burn-on-refund) sketched in outline; mocked driver walks the choreography (Phases 1-5). Fixes the deposit-time and withdrawal-time trust window in the current bonded-operator rails (0267-0269). Honestly bounded: does NOT reduce accumulated custody trust in the DEX's source-chain address — that still needs MPC/multi-sig + slashable-bond scaffolding. Design-only, not committed to any live rail. · _cross-chain, atomic-swap, htlc, design, deposit, withdrawal, covenant, sketch, mpc, trust-model, deposit-covenant_
|
||||
- [0271-cross-chain-atomic-swap-primary-rail-decision](0271-cross-chain-atomic-swap-primary-rail-decision.md) — Design decision — the DGB rail commits to ATOMIC-SWAP-PRIMARY. Two alternatives fully explored and killed: (a) self-custodial Taproot vault with owner-fallback creates a cross-chain double-spend rug-pull because Alice can sell CashToken to Bob then recover DGB via fallback leaf; (b) any pool-with-cosign design that hopes to gate the DGB spend on a BCH burn is impossible on DGB Script alone — DGB is completely detached from BCH and doesn't care if CashToken burned. Atomic swap sidesteps both because it never asks DGB to know about BCH — the cryptographic linkage is a shared preimage that unlocks both sides. Snapshot 0270's three covenants (WithdrawalHTLC, DepositHTLC, Deposit.burn) are the BCH-side foundation and need no changes; the remaining lift is DGB-side HTLC primitives + a swap driver + a matching layer (Anthemus) + MM float bootstrap. · _cross-chain, atomic-swap, dgb, design-decision, deposit, withdrawal, htlc, non-custodial, trust-model, deposit-covenant, anthemus, digibyte_
|
||||
|
||||
## Games / Tote / AnyHedge / Pari-mutuel `(14)`
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue