Escrow Challenge Guide

A very common operation which you may find in traditional and decentralized finance is the need for two parties to exchange assets between one another. However, this asset exchange needs to be done in a way such that both parties are safe and such that no party can take the other party’s funds without fulfilling its part of the exchange.

Solving this problem in traditional finance often requires involving a third party, an escrow. Both parties send their agreed-to assets to escrow. Once the escrow receives the amount in full from both parties, it performs the exchange and allows each party to take the other’s assets.

In the world of DeFi, escrow blueprints may be written to provide a trustless escrow service to parties that need it. The biggest advantage of DeFi escrow services is the fact that they are trustless and do not require the involvement of a human third-party to mediate between the two parties.

This challenge is to build the same escrow blueprint that you have seen during the earlier presentation. This guide will provide you with information and boilerplate code to get you started.

This section of the document provides you a guide on how you may think about building an escrow blueprint but leaves the implementation details up to you.

The essence of an escrow is ensuring that both parties walk away from the transaction satisfied. To do this, the trade should guarantee that both parties receive their specified and desired resource in exchange for the desired resource the other party specified.

This exchange can happen in multiple transactions, so long as both parties get what they want, or more specifically, one party receives their desired resource without having to send in their offered resource.

To assist with the challenge, the Escrow blueprint is provided in this link. This code has the blueprint state variables defined, but some of the methods are not implemented. The methods which you need to implement are the ones which include the todo!() macro.. It starts with an instantiation function which requires two arguments:

1. The requested resource of the person who wants to create an escrow.
2. The offered resource they are providing in exchange for their requested resource.

The instantiation will also mint an “EscrowBadge” which is a non-fungible resource that contains the offered resource in its NonFungibleData. This badge serves as a way for the instantiator to withdraw from the component when the escrow is complete. They may also use this badge to cancel the escrow if they are to change their mind. However, keep in mind that you will need to ensure that the other party should not be able to do the exchange if the escrow is cancelled.

When the Escrow component is instantiated, it returns the EscrowBadge and has the offered resource in its own vault. At this point, the other party may provide the requested resource in exchange for the offered resource by calling the “exchange” method. This method is done in a single transaction, so as soon as the other party provides the requested resource, they will also immediately receive the offered resource.

Now, the component should have the requested resource in its own vault and the instantiator may now be able to call “withdraw_resource” by passing in the EscrowBadge to which the instantiator can retrieve their requested resource.

This roughly describes the Escrow blueprint and you can find more details about the boilerplate in the repository. While this gives an example of an escrow implementation, this is not the only way. You may choose to design your own blueprint, however, the implementation must satisfy the expected Escrow Behaviour.

For a successful submission, the Scrypto package will require expected behaviour of an escrow. While the implementation is up to you, these behaviours are expected as part of the judging criteria:

1. At least one party is able to define their offer (requested resource and offered resource).
2. Both fungible and non-fungible resources must be capable of being accepted as offered resources.
3. Both parties are able to successfully execute the exchange.
4. Be able to cancel the offer.

A blueprint would be deemed to work if it satisfies all of the following requirements:

1. The Scrypto package is successfully deployed and the component(s) instantiated from its blueprints on Stokenet.

2. If the blueprint and component functions as expected.

Escrow challenge boilerplate.

While you can always use Scrypto 101 as a reference, the Scrypto documentation may provide quick navigation and access to information.

You may also find the Step-by-Step tutorials for more hands-on exercises while our official Scrypto examples repository can provide references as well.

Do you have questions about the challenge or need help with Scrypto? Join Discord to ask questions. The radix team and community will be answering your questions right away! Best place to start is the#scrypto-rust-beginners channel!