Payments Agreement

Introduction

- Banks in Web3: Just crypto custodians?
- Web3 as banks: Lending - Aave. Exchange - Uniswap.
- Smart Contracts can help Banks to streamline B2B transactions by providing transparent, immutable rules.
- Banks can be the trusted third-party to act as arbitrators for disagreements in the off-chain world.

Problem

B2B Transactions involve large sums of money taking place over a long period of time.
Client wants to release money to the provider only when the provider meets specific milestones.
Service Providers wants to know that the client can pay for services until the end of the project
Both parties want to know that the counterparty can hold up their end of a transaction, and for transactions to be carried out in a transparent and speedy manner.

Caveat

Smart Contracts are public. As such, values and parties are public as well, even with pseudonymous wallet addresses. Clients may not want to be too open with the budget for projects.

Solution

Payment Agreement Smart Contracts, for which payment details are obscured via a Merkle Hash
Service providers will not initially know the payments for other parties. With valid proofs, they can verify the final payment amounts according to the chain.
Bank as the trusted third party which can release payments, or stop payment in the event of issues
Wikipedia Article: Merkle Tree
Merkle Hash Tree
payments: {
    "0xABC": amounts[1],
    "0xDEF": amounts[2],
    "0xGHI": amounts[3],
    "0xJKL": amounts[4],
  }
We start by hashing each item (e.g. "0xABC": amounts[1]) to get a hash.
The four amounts will result in L1, L2, L3, L4 accordingly.
Each leaf is hashed to form the top hash, something which outsiders would not have the contents of.
Insiders can still verify details based on merkle proofs.
Merkle Proof
Writing data to the blockchain network can also be expensive. Merkle hashes mean that we are writing only a single string, saving on operational costs.
For the Smart Contracts, we will be using a factory contract to make clones of Payment Agreement Contracts. These clones only store the data for each individual agreement, and will point to a single contract which will hold the logic for execution. This help us to further save on deployment costs.

Benefits

Transparency: Proof of Funds on the part of the client. In a Web2 world, even if the banks can attest to the funds owned by the client, the providers do not know if the funds have been allocated to other projects
Clarity on Rules: Smart Contracts are public, anyone from both companies can read through the Smart Contract and understand the rules
Public Ledger: Accountants can use transactions logs to support accounting
Peudonymous: Wallet Addresses are pseudonymous
Initially obscured: Merkle hashes not only saves on network transaction costs to update or deploy, but also obscures transaction details initially
Fast settlement: Transactions can be cleared as soon as it is confirmed on the blockchain
Minimized human intervention: While the bank can provide the smart contracts and some admin support in terms of blocking/allowing payments, there is less need for other staff in terms of operations or legal

Role of the Bank

- Smart Contract maintenance and deployment
- Updating of milestones in Project SC, which will release payments to Service Providers accordingly
- Arbitration if projects unexpectedly end in the midst of a project

Benefits to the Bank

- Bank gets 0.3%(?) of every transaction until the end of the project, providing incentive to see through the process till the end. This can be programmed straight into the Smart Contract itself.
- Cost savings due to automation