Hey guys,
I'd like to describe a scheme I've been working on (for the PAKET project), which implements a very specific type of escrow with a Stellar smart contract. I would love to hear comments, ideas, criticism, and offers for improvement. I'll start with the requirements:
- Alice needs to promise a payment to Bob in return to him providing a service for Judy, so the escrow needs to hold Alice's payment, and release it to Bob only if Judy approves.
- If Bob fails to provide the service within a given time, Alice needs to be refunded, so we need a time-locked transaction releasing the payment from the escrow back to Alice.
In our solution, we create an escrow account and set its threshold to 2 and its signers like so:
- Master key: 0 (so the escrow will not be accessible by its creator)
- Time-locked refund transaction with sequence n sending the payment back to Alice: 2 (so it can simply be submitted once the time-lock expires)
- Payment transaction with sequence n sending the payment to Bob: 1 (so it is not valid in itself)
- Judy: 1 (so she can sign the payment transaction and validate it)
- Merge transaction with sequence n+1, merging the account into the creator's account (Alice, in our case) and reclaiming any XLM left in it
So far it's a pretty straightforward escrow, but here things get a bit more complicated:
- Without altering the previous requirements, Bob needs to be able to dynamically promise some of the payment to Carol, in return for providing the same service to Judy. Note: Bob does not need to lock up any more funds - he has to promise the funds already locked up by Alice.
- Carol needs to be able to dynamically promise some of her part in the payment to Dan, who can do the same for Frank, and so on.
Once the service is provided, and only once the service is provided, Bob, Carol, and anyone else on that chain should be paid. If the service is not provided by the deadline, Alice should get the entire payment back.
Please stop at this point and give it some thought, before I pollute your heads with our own solution ?
Our solution was to replace Bob's personal account in the payment transaction to a new account, specifically created for this purpose. If Bob manages to provide the service, he gets paid, but if he opts to promise some of the payment to Carol, he sets the threshold of this account to 1 with the following signers:
- Master key: 0 (so the escrow will not be accessible by its creator)
- Payment transaction with sequence n, sending the payment to a special account controlled by Carol: 1 (so it is valid as soon as there are funds in the account)
- Merge transaction with sequence n+1, merging the account into the creator's account (Bob, in this case) and reclaiming any XLM left in it
The two main problems I see with this scheme is that it is somewhat fragile (e.g. if the wrong transaction gets submitted at the wrong time it might advance the sequence number and ruin the chain, if trust and limits aren't carefully set and someone sends tokens to the escrow, the merge transaction will fail and the XLM in that account will be lost forever) and that every added payee has to create a new account in which XLM will be "stuck" until the service either succeeds or fails.
Does anyone have a better idea?