This project originated from the Ecash Hackathon 2024.
An escrow solution for trading projects (e.g. online shops) facilitating their payments over the Cashu ecash protocol. The trading parties can agree upon an escrow coordinator which is either hardcoded or can be discovered through a Nostr announcement event. How the escrow coordinator is chosen depends on the software implementing the client library (e.g. reputation based ranking). Everyone can run an escrow coordinator and announce their service publicly trough Nostr. The buying party locks its funds in a 2-of-3 P2PK ecash token which can then be unlocked by the buyer and seller (happy path) or the coordinator and one of the trading parties (escrow mediation path).
This makes it possible to separate away the escrow coordinator from the trading plattform operator which can result in the following benefits for traders, developers and operators:
- Distributing trust between trading plattform operator and escrow operator
- Reducing operational burden of running a trading platform
- Formation of an escrow coordinator market due to low entry barrier (driving down fees and favouring honest coordinators)
- Simple integration of escrow features in all kinds of trading plattforms and applications
- No vendor lock-in to a single large escrow coordinator necessary
- Safer trading conditions in low trust environments (e.g. pseudonymous traders on nostr- or onion markets)
- Good privacy for traders in happy case (coordinator has few, ephemeral informations about trade and traders)
Both trading parties have to commit to their trade obligations to the coordinator. This commitment has to contain all information necessary for the coordinator to decide which trade party fulfilled their obligations in the case of an escrow mediation. This can include payout information, amounts, timeframes and a freely written trade contract. When possible, information can be submitted as hash to improve privacy against the coordinator.
To reduce uneccesary burden on relays we can aim to use ephemeral event types for communication between traders and coordinator.
The client could be distributed as wasm library and rust crate. There could also be a compilation flag that decides if the client gets built with nostr communication logic or only with nostr event creation logic. First would be useful for inclusion in traditional trading platforms and second would be useful for nostr based trading platforms already including relay/communication logic.
Berofe running the trader clients and the coordinator start a test mint using a fake funds source.
docker run -p 3338:3338 --name nutshell -e MINT_BACKEND_BOLT11_SAT=FakeWallet -e MINT_LISTEN_HOST=0.0.0.0 -e MINT_LISTEN_PORT=3338 -e MINT_PRIVATE_KEY=TEST_PRIVATE_KEY cashubtc/nutshell:0.15.3 poetry run mint
Special thanks to the following projects, without them this project wouldn't be possible:
If you want to discuss this project or contribute feel free to join the SimpleX messenger group
When submitting pull requests, please ensure your code is formatted using rustfmt to maintain consistent code style throughout the project.