Proof of Goods and Services :
Threshold multi-signatures demo

Warning

This multi-signatures demo is currently in the development phase and subjects to changes. Before proceeding, please be aware of the following:

• This sample is for demonstration purposes only, do not use in production systems or mainnet in the future.

• Do not transfer any ERC20 tokens to addresses generated by this demo as it can cause loss of funds.

Crypto.com is not liable for any potential damage, loss of data/files arising from the use of the multi-signatures demo.

Task lists :

• Merchant panel
• Escrow panel
• Support enviornment with fees

About this Demo

This demo is to demonstrate a 2-of-3 multisignature scheme under the setting of "Proof of Goods & Services Delivered" (PoGSD) collaterals in the Cryptop.com Chain protocol. For more detail, please refer to the use case example in the later section.

Build

Build Prerequisites

• Crypto.com Chain - Sample-chain-wallet.
  

  • To enable multi-sig feature please change to the branch multi-sig-demo on sample-chain-wallet.

• The current version only supports zero fee environment, to enable zero fee on Crypto.com Chain, please kindly:

  • Update below fields in .tendermint/config/genesis.json:

    "initial_fee_policy": {
        "base_fee": "0.0",
        "per_byte_fee": "0.0"
    }

• Install Diesel

  $ cargo install diesel_cli --no-default-features --features sqlite

Build instructions

• Multi-sig web backend

$ cd backend
$ diesel setup
$ cargo run

For ubuntu :

$ sudo apt-get install libsqlite3-dev

For fedora :

$ sudo dnf install libsqlite3x-devel

• Multi-sig web frontend

$ cd frontend
$ npm install
$ npm run start -- --port 4201

Once the backend and the frontend are running, you can navigate to http://localhost:4201/ and interact with the web interface. See also the graphical instruction for PoGSD demo frontend.

Use case example

The following use case example demonstrates the interaction between customer, escrow and merchant in where the customer is purchase items from the merchant with "Proof of Goods and Services"

• Customer selects items, and select “proof-of-goods-and-services”;
• Customer retrieves invoice info from merchant's web;
• Total amount (items price + deposit) and public keys from merchant and escrow retrieved through APIs.
• The customer then sends the total amount to a 2-of-3 multi-signature address generated based on the public keys from the parties involved.

Under this 2-of-3 multi-signature scheme, at least two of the three signatures (approvals) are required to "unlock" and spend the funds in the multi-signature address.

Scenario A: The item is shipped

A1) Normal case

• Signatures: Customer + Merchant

If the customer confirms and accepts the delivered item, he/she can complete the purchase by co-signing the transaction to the merchant with his/her signature.

A2) Payment dispute (Escrow involved)

• Signatures: Customer + Escrow

If the merchant has not received the payment after a certain period of time, he/she can contact and provide evidence of delivery to the escrow. Once it has been confirmed, the transaction will be co-signed by the escrow and the funds will be released to the merchant.

Scenario B: The item is not shipped/not as described

B1) Reimbursement (Without escrow)

• Signatures: Customer + Merchant

The customer can request a refund when the merchant failed to fulfil the order. If the merchant accepts the request, he/she can co-sign the transaction and refunds the customer.

B2) Refund dispute (Escrow involved)

• Signatures: Escrow + Merchant

In case of the merchant neither agree with the refund claim nor respond to customer's refund request, the customer can reach the escrow to resolve the issue. If the resolution outcome is in favour of the customer, escrow will issue a refund to the customer by providing the co-signature.

Transaction Flows:

License

Apache 2.0