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?

Nested escrow scheme

israellevin

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?

fracek

What about creating an asset for the delivery, then when Bob picks up the parcel he is given this asset. Bob gives a fraction of the asset to Carol, and so on. Then, instead of transferring the funds directly, the escrow account would put and offer on the SDEX to buy the asset.

israellevin

Thank you for your reply (and for reading that long message). So... Create a new asset for every time a service is requested? That sounds interesting, but I don't fully understand how it will work.

Let's see: Alice issues a new asset and gives it directly to Bob, who gives it directly to Carol and so forth. How does Judy confirm the service was provided? Once she does, how can we make certain that anyone holding that new token can convert it to our own token, and specifically to the tokens Alice is holding? How do we even stop Alice from issuing more of this new asset than she can cover? Theoretically, being the issuer, she can issue an unlimited amount of it...

fracek

The problem of making sure Alice/Judy agree to pay/release the funds is common to all escrow schemes. I played around with implementing this kind of contract tonight and I think I have a solution, didn't have time to write it down nicely yet tho!

The basic idea is that you create a new account for the escrow contract, this contract will also be the issuer of the delivery-specific asset. After that you add 2 pre-authorized transactions to the contract:

create offer for the delivery-specific asset
refund Alice

you also add Alice and Judy as signers and you set the weights so that Alice cannot issue any more of the asset, refund themselves or submit any transaction in general (to avoid invalidating the sequence number).

israellevin

I would love to hear more details. If I understand correctly, what you are saying is that Alice deposits our own main token (could even be XLM) into the escrow account, issuing a limited amount of a new asset "against" the main token, and Judy's signature is all that is required to convert the new asset back into the main token. Correct?

This means that the new asset can be traded and sent from participant to participant very easily, but only when Judy confirms that the service was provided does it become exchangeable with the main token, which gives it value.

My only concern here is that we are using the concept of assets in a different way than what was intended... But it does sound very handy. I would really appreciate it if you found the time to describe your scheme more fully. I think it will be very interesting.

fracek

Yes, I think you understood perfectly fine! As you said, the contract account issues a token that is worthless until Judy signs and submit the transaction to the network. I think you would need to build an UI for it since my impression is that asset trustlines are not clear to most users.