The coordinator lives in wallet-api (#40) as a module, or beside it; decide and say why. It keeps the maker offer book (price, size, min/max, validity, exposure limits, maker's signed announcement), matches a taker to an offer, creates the trade record with a fresh nonce, hands the arbiter its per-trade template set, and relays signed messages between parties. It never holds a key that can move funds and never sees a BTC private key.
Data retention: a closed trade is reduced to the on-chain facts (multisig address, proposal ids, outcome) after a short window; BTC addresses and counterparties are not kept beyond the trade's life. At trade creation it enforces the maker's declared exposure and per-taker limits and the payment window (#62); there are no bonds and no identity.
Acceptance
Two maker daemons and one taker complete a trade through it on Planck plus signet; the coordinator's database after the retention window contains nothing that identifies the parties beyond public chain data. Killing the coordinator mid-trade does not lose funds: the parties and the arbiter can finish from chain state alone.
Parent: #54
## Scope
The coordinator lives in `wallet-api` (#40) as a module, or beside it; decide and say why. It keeps the maker offer book (price, size, min/max, validity, exposure limits, maker's signed announcement), matches a taker to an offer, creates the trade record with a fresh nonce, hands the arbiter its per-trade template set, and relays signed messages between parties. It never holds a key that can move funds and never sees a BTC private key.
Data retention: a closed trade is reduced to the on-chain facts (multisig address, proposal ids, outcome) after a short window; BTC addresses and counterparties are not kept beyond the trade's life. At trade creation it enforces the maker's declared exposure and per-taker limits and the payment window (#62); there are no bonds and no identity.
## Acceptance
Two maker daemons and one taker complete a trade through it on Planck plus signet; the coordinator's database after the retention window contains nothing that identifies the parties beyond public chain data. Killing the coordinator mid-trade does not lose funds: the parties and the arbiter can finish from chain state alone.
## Depends on
The protocol document; #40 (wallet-api).
grenade
added the child label 2026-09-15 14:42:19 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Parent: #54
Scope
The coordinator lives in
wallet-api(#40) as a module, or beside it; decide and say why. It keeps the maker offer book (price, size, min/max, validity, exposure limits, maker's signed announcement), matches a taker to an offer, creates the trade record with a fresh nonce, hands the arbiter its per-trade template set, and relays signed messages between parties. It never holds a key that can move funds and never sees a BTC private key.Data retention: a closed trade is reduced to the on-chain facts (multisig address, proposal ids, outcome) after a short window; BTC addresses and counterparties are not kept beyond the trade's life. At trade creation it enforces the maker's declared exposure and per-taker limits and the payment window (#62); there are no bonds and no identity.
Acceptance
Two maker daemons and one taker complete a trade through it on Planck plus signet; the coordinator's database after the retention window contains nothing that identifies the parties beyond public chain data. Killing the coordinator mid-trade does not lose funds: the parties and the arbiter can finish from chain state alone.
Depends on
The protocol document; #40 (wallet-api).