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 platform operator which can result in the following benefits for traders, developers and operators:
- Distributing trust between trading platform 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 platforms 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 information 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 unnecessary 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.
The current NostrClient code only uses an in memory local test relay, which must be started before testing.
By now we use the relay at [email protected]:rodant/bucket.git. To start the relay locally:
- Checkout the master branch from the repo above.
- Run
yarn, only needed the first time. - Start the relay with
yarn start.
Before running the trader clients and the coordinator, start also 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
Alternatively you can checkout the cachubtc/nutshell repo from Github and run it locally, see the instructions for that in the README.md of that repo.
Currently only the common package has some tests implemented.
To run the tests:
- Start the local relay as explained above.
- Then execute
cargo test.sh.
Of course you can also run single tests as simple as cargo test test_name.
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.