Inspiration

Based on my experience, Escrow payment is very demanded feature especially for cross-boarder payment, because quite often buyer and sender have difficulties to build enough mutual trust prior to trading. Also, once some issue happened, it is practically hard to solve it due to different jurisdiction.

Although LC (Letter of credit), offered by bank, is often used for cross-boarder trading payment, this is expensive and takes quite some time to process so that it is not ideal solution for buyers and sellers point of view. This is the problem we would like to solve.

What it does

We would like to offer easy, quick, inexpensive and still reliable escrow solution to those cross boarder business traders. This time, I choose Stellar as infrastructure to build this service, because I heard Stellar platform is designed to focus on payment and remittance use case and has built in a number of related feature, which make it easier to build payment system on top it.
Make sure our system will support all basic business scenario of escrow should be supported such as normal payment, refund by cancel a deal or disputation.

How we built it

We use 2 of 3 multi-sig wallet, which gives us enough power to offer an escrow service when disputation happened between traders. At the same time, this doesn’t give us too much power to move the fund without trader’s consents so that trader does not even need to fully trust us when they use our service.

Challenges we ran into

Because we are new to Stellar platform features, we have to figure it out by hands-on trial to gether with reading blog post or technical documents. We first thought preAuthTx is the one we needed, but after hands-on trial, we conclude this is not what exactly we want and have chosen simpler multi-sig account feature to be embedded into our systems. It was challenging to understand product feature quickly in limited time span. Fortunately, stellar developer offered kind assist in discord channel during hackathon and it really helped us.

Accomplishments that we're proud of

In development during this hackathon, we have achieved proof of concept to cover all mentioned escrow business scenarios. In other words, with our system, basic escrow flow works fine. For more detail, please have a look at Github source code and demo video.

What we learned

I have heard the name of Stellar focusing on remittance use case and built in a couple of transfer function natively. However, I have not had chance to look into product detail until recently. So I took this hackathon as good opportunity to learn it I have learn the product nature and specification of Stellar, which is different from Ether, Bitcoin. Compared to Ether, the capability of smart token is limited. however since Stellar focus on asset transfer, a couple of important asset transfer feature is natively supported. Thanks to support person in Discord, i could also learned.

What's next for Escrow System on Stellar Network

In development during this hackathon, our system has covered the all mentioned escrow business scenario and basic escrow flow is working. However, there are still some future work to make this system practically applicable.

1) Support custom asset Currently, only native asset XML is supported. For real scenario fiat pegged asset should be supported.

2) Improve Non-functional feature(security, error-handling) Currently, no security or authentication mechanism (i.e. GWT) is implemented for backend API access, which should be improved. Also, input validation and error handling for various process is needed to prevent unexpected internal error.

3) Fee mechanism for escrow Newly created escrow account needs some balance to make it muti-sig wallet. In current testnet, this has been taken care by faucet bot, which is not applicable in production. One solution is to prepare separate fee channel account and ask user to make a payment there prior to use our service. (Our system validate if user made a payment or not.) Transaction submission to network will be done through fee channel account so that transaction fee is not imposed on escrow account. Similarly, we should design how we can charge the service fee to users, that is more like business specification matter, though. (Prior small fee + arbitration fee if needed)

4) FX service In real use case, Sender and Receiver may want to use different currency so that FX conversion during payment should be supported. and this can be done by leveraging DEX liquidities and path payment, though I need some research on that.

5) UI/UX improvement UI/UX design can be better

Built With

Share this project:

Updates