Case study: Bitmarkets and mutual deposits
Bitmarkets was VoluntaryLabs' P2P marketplace protocol and desktop client, using Bitmessage for communication and Bitcoin for payment. It is distinct from present-day similarly named trading brands and from an AMM.
Its question was sharp: could both parties be discouraged from cheating without a third party deciding who receives the money? That leads to the distinction between making dishonesty expensive and establishing what actually happened.
What it is
Users published goods, received bids, exchanged messages and arranged Bitcoin payments. The original macOS application combined Tor, Bitmessage and BitcoinJ. Public channels carried listings; direct messages carried negotiations and delivery information. Project description.
Its subject was a complete purchase, including physical delivery outside the chain's observation, rather than only an exchange of on-chain tokens.
History and active period
| Period | Evidence |
|---|---|
| 2014–2016 | The original macOS repository was created in 2014 and records its last push in 2016 |
| Subsequent status | The README deprecates the macOS implementation and describes work toward JavaScript/Electron |
These dates identify the original implementation's development record, not measured start and end dates for all network trading. A proposed successor is not proof of delivery. Repository metadata, status notice.
How the protocol works
The project's two-party escrow design uses deposits from buyer and seller alongside the purchase funds. Release requires cooperation. Misbehavior can leave the offender's own money locked, changing the incentive to cheat. Protocol presentation.
Consider a hypothetical secondhand camera purchase. The seller says it shipped; the buyer says the parcel was empty. Arbitration tries to assess evidence. Mutual deposits mainly change the cost of disagreement and non-performance. A Bitcoin signature cannot establish what was inside the box.
What is worth preserving
The design exposes assurance conditions as protocol terms instead of hiding them behind platform support. Participants can see who locks funds, whose cooperation releases them and what disagreement can cost.
Deposits, reputation, third-party escrow and same-chain atomic exchange rely on different assumptions. They should be comparable choices rather than being flattened into a single “secure trade” label.
Costs and limitations
Mutual deposits tie up capital. Participants do not always act as rational profit maximizers. Griefing, lost keys and unequal urgency to release funds can prolong a deadlock. These are mechanism-level concerns, not claims of documented Bitmarkets incidents.
Making dishonesty expensive does not make external facts verifiable. Removing an arbitrator can also remove an actor capable of ending a dispute. Small purchases may struggle to justify the operational overhead; large purchases magnify locked-capital costs.
Reliable messages, updates and local data protection remain necessary. Removing a central trading server does not remove computer failure or missed messages.
What our proposed design addresses
Persistent personal state and agents can follow messages, track deadlines, compare assurance terms and propose actions within user limits. Wallets and deterministic executors must preserve those limits even when a model wants to complete a deal.
Same-chain digital assets can use atomic exchange rather than copying physical-goods escrow. For goods and fiat, AI cannot replace verification of external facts. The lesson is to make capital exposure and exit conditions legible before the user chooses, not to promise every intermediary can disappear. The OTC analysis compares alternative assurance and execution paths.