Case study: Bisq and Bitsquare
Bisq is a P2P project for exchanging Bitcoin against national currencies or other digital assets. Originally called Bitsquare, it lets users run desktop clients to find counterparties and coordinate trades rather than first depositing everything into one exchange account.
Its importance is the working idea that a user's client can itself be a market node. That differs from an AMM's precommitted liquidity pool; Bisq is not merely an early, simpler Uniswap.
What it is
Bisq combines software, trading protocols and a participant network. Clients publish and receive offers, communicate and maintain trade state. Bitcoin supplies the relevant funding arrangements. Fiat still travels over external payment channels; dollars do not become assets inside Bitcoin's atomic execution boundary.
Reducing dependence on a single custodian therefore does not remove coordination, deposits or dispute resolution.
History and active period
| Period | Documented development |
|---|---|
| December 2014 | Bitsquare Alpha described the client, a DHT network and a Bitcoin multisignature trading/arbitration design |
| 2017 | The project announced its change of name to Bisq |
| Continuing development | Bisq evolved; Bisq 2 supports different protocols, including Bisq Easy's reputation-based approach |
There is no end year assigned here: Bisq continues to evolve. The Alpha architecture must not be used as the description of every current version. Alpha announcement, renaming, Bisq 2.
How the protocol works
Classic Bisq v1 combines offer distribution, BTC deposits, multisignature funding, payment deadlines and dispute handling. The process coordinates external fiat payment and Bitcoin release. Bitcoin can constrain spending, but cannot independently establish whether a bank payment is disputed or fraudulent. Trading rules.
A BTC/fiat trade is therefore not a completely trustless same-chain swap. Deposits and disputes address facts outside the chain. Bisq Easy instead uses seller reputation to allocate risk differently; v1's funding sequence should not be attributed to every Bisq trade. Bisq Easy.
What is worth preserving
The participant's software joins the network rather than simply displaying a company's selected results. Users have a place to retain identity, trade state and protocol interaction. Explicitly accommodating fiat uncertainty is also more honest than claiming a blockchain eliminates trust.
A useful benchmark follows: can users participate without surrendering asset control, and can their trade state survive a change of interface or service?
Costs and limitations
The official FAQ explains classic v1's online requirement: public offers remain visible while the client runs, disappear from the order book when it goes offline, and are republished on return. An offer's visibility is distinct from funds already involved in a trade. FAQ.
Alice may be online in the evening while Bob searches in the morning. Keeping a device running can address that, but adds updates, connectivity, sleep settings and recovery to the trader's work. Deposits, fiat steps and dispute participation add other costs.
These are architectural and usability costs, not a market-share measurement or proof that the project failed.
What our proposed design addresses
The proposed ArcSpace/ARC separation puts persistent communication and state at a personal endpoint while leaving keys and final authorization with the wallet. An agent can follow offers and compare sources without requiring its owner to watch the client continuously. Availability should not require surrendering a master key.
Hosting, synchronization and recovery still need implementation. Fiat disputes remain. Bisq's experience asks us to separate those problems: personal infrastructure can improve participation, while bank-payment risk requires its own protocol and responsibility arrangements. The personal architecture essay develops that separation.