## Title: **zkLC (concept note)**

A traditional letter of credit product using algorithmic smart contract as the coordination layer instead of banks, with option for receipient to settle to a traditional bank account if required. Using smart contract platforms cuts the cost to a fraction what current LCs cost. This is enabled by proving shipping documents using zero knowledge cryptography to unlock funds from an algorithmic escrow smart contract. Privacy is enabled using succinct proofs of correct computation that can be verified. The product is compatible with existing legal frameworks and can constitute parts of an english law contract to govern the transaction.

Keywords: Ethereum, Aztec, zkemail, zero knowledge cryptpgraphy

## Background

### Smart Contracts

Smart contract platforms allow parties that wish to transact to program the logic and rules of transaction beforehand, and eliminating the need for a middleman to provide trust. The two parties can transact directly "trustlessly" meaning they do not need to trust each other's goodwill or holding their end of the bargain. This is possible because smart contract platforms like Ethereum host the program logic and neither party controls the platform itself because it is managed by a decentralized network of computers that enforce the execution. Ethereum for example is currently backed by ~$100bn worth of stake ([# validators x 32ETH x ETH price](https://beaconscan.com/validators#active))

While this type of infrastructure is not useful for many real world applications that require complex human factors, it is ideal for transactions and agreements whose logic is straightforward and programmable. One example of such an agreement is agreement in a letter of credit whose logic can be programmed.

### Letters of Credit

Letters of credit are trade finance instruments usually issued by banks for their customers. Customers are usually international buyers (eg. a wholesaler in Germany) and internatinal sellers (eg. a factory in Morocco) who are tranasacting with each other. In every such relationship the payment terms lie anywhere on a spectrum from most trust to buyer to most trust in seller with payment terms that on one end could be 100% payment upfront, to 100% payment upon delivery, and often lying somewhere in middle such as 50% upfront, 50% upon shipment...etc. Notice that even 50% upfront requires some trust.

In cases where neither trust each other at all, is where banks come in with the letter of credit service (product).

The need for a letter of credit arises when the buyer wants to buy goods from the seller but neither of them trust each other. The banks traditionally step in to provide this service where the buyer's bank guarantees payment to the seller's bank if the seller presents a set of documents that include proof of shipment and transfer of ownership of the goods to the buyer. This solves the issue of trust by "purchasing" trust from the banks and paying anywhere between 0.75 to 1.5% of the value of goods as a fee for this service. [see example breakdown of where the costs come from](https://comparetradefinance.com/commissions-%26-charges).

Since letters of credit are issued between banks, they use the [SWIFT](https://en.wikipedia.org/wiki/SWIFT) messaging network to transact which provides an elaborate infrastructure of standarized message formats, network of settlement accounting and rules. It is [estimated](https://www.imf.org/en/Publications/WP/Issues/2023/03/24/Currency-Usage-for-Cross-Border-Payments-531324) 13% of world trade is processed with MT700. Letters of credit use a message format called the MT700 with a sample provided [here](https://www2.swift.com/knowledgecentre/publications/us7m_20190719/1.0?topic=mt700-example.htm).

### Shipping documents (Bills of Lading, Sea Way Bills)

The [Bill of Lading](https://en.wikipedia.org/wiki/Bill_of_lading) is ussued by the carrier (the shipping company) once the goods are loaded on the ship. This documents acts as 1) reciept of cargo, 2) evidence of contract of carriage 3) title for goods. It governs the relationship between the owner of goods and the owner of vessle.

Since the BOL is the title, simply mailing these documents (three original copies) to someone constitutes transfer of ownership. The banks use this as the main condition to releasing funds to the seller, because once the bank receives these documents and verify their details, they technically have owenership of the goods (The sender even though they called up Maersk to ship the goods in first place, after sending the BOL they can no longer call them and dictate where the shipment goes)

While the physical BOL is still used today, especially in letters of credit transactions, a modern version of it emerged in the internet era called the [sea way bill](https://en.wikipedia.org/wiki/Waybill#Sea_waybills). It is a digital format where the buyer specifies beforhend the receiver, and registered in the database of the shipping company. It restrictive compared to the BOL because it is not easy to transfer ownership easily midway, whereas the BOL, all you have to do is mail those documents to whoever buys the goods).

Given the superiority of the BOL in transferring ownership and the non ambiguity of it by simply handing over documents, ownership can be transferred which is ideal for the Letter of credit case. The sea way bill in contrast requires the sender to commit to new ownership at time of shipement which works well for well established trading relationships with simple flows.

Sea way bills are usually PDF documents signed in person by the shipping company representative and can be passed around as recieipts to show the other party when a physical BOL is not needed.

We will leverage the sea way bill in our solution as it is the main digital format used today.

## zkLC Core Solution

### Overview


Once the buyer and seller decide to transact, this is the flow:
1. Initiate transaction by seller or buyer
2. Confirm: other party confirms
3. Lock funds: Buyer sends tokens to initiated escrow smart contract
4. Settlement: Seller submits proof of shipment and unlocks funds

### Transaction format

The MT700 SWIFT message format is governed by the Internatinal Chamber of Commerce in a standard known as [UCP600](https://iccwbo.org/news-publications/policies-reports/eucp-version-2-1-icc-uniform-customs-and-practice-for-documentary-credits/).

We believe the transaction formats used in zkLC should be compatible with the UCP600 rules, this allows for better compatibility with existing legal contracts. Moreover, the ICC is an international body that many rules are based on where our transacting parties are used to and already adhere to. We dont gain much by deviating, but gain by adopting it. Hence we will use the MT700 as reference format.

sample smart contract: https://github.com/0xSachinK/zkLC/blob/develop/contracts/contracts/LC.sol

### Shipping document proof

Once the buyer locks their tokens in the escrow smart contract, the seller is now required to ship the goods and provide proof of shipment. We will leverage the use of the sea way bil as its digital format allows for automated integrations.

To prove a seawaybill we simply need the shipping line to sign a digital document titled "Nonnegotiable sea way bill" which will include all the data regarding the shipment. The shipping lines already do this on BOLs and SeaWay Bills but with handwritten signatures automatically printed on these documents. Our advocacy effort with shipping lines will be centred around the use of digital signatures (like docusign).

So what is possible to prove with today?

1. **Email based**: Book the shipment with Maersk, receive the pdf in email. Since all emails are signed, we can use the email's signature which has the signature of the shipping company domain (eg. maersk.com) to prove that the pdf attachment content is indeed correct and original. This uses the dns registry as its reference and the risk is centred around the server generating these emails.
2. **Digitally signed PDFs**: A stronger guarantee is if we have a public registry of official document signers within the shipping company and we ask them to digitally sign the documents (eg. using docusign) this provides stronger guarantees than 1. and also allows for the possibility to enrich ux by having the signed document to be issued by a shipping agent acting on behalf of the seller, as is usually the case.

We can already generate proofs from emails using the 1. today without the need for advocacy with shipping companies or requesting any changes to their procedures (this concept is coined permissionless web2 by the zkp2p team). This already allows us to have a working e2e model to build upon, However for 2. requires advocacy with shipping companies which we will also pursue in direct advocacy effort.

*Note on Maersk shipping line: It is worth noting that Maersk led an ambitious project called tradelens along with IBM to provide a blockchain infra to digitize BOLs and create eBOLs that live in the blockchain. Sadly the project was [discontinued ](https://www.maersk.com/news/articles/2022/11/29/maersk-and-ibm-to-discontinue-tradelens) but the propensity to innovate is what we are betting on with shipping lines such as Maersk as we would like to have them as stakeholders and work closely with them and cooperate.

### Private Smart contracts

Smart contract platforms like Ethereum are completely public. They allow anyone to observe the network transactions even if its psuedononymous ([see this Ethereum transaction for a token swap](https://etherscan.io/tx/0x829a7085ee1c8ec123b3e561c3a8b9e2e181ccccf024ec47b9f8c5d7aa59bfe2) as an example), No names are mentioned and it just shows hexadecimal numbers as addresses.

However with time, these addresses become deanonymized and it is safe to assume that our users (buyers and sellers) do not wish to disclose which sources they purchase from or which customers they are selling to and how often. Having those transactions public completely alters how business is conducted historically and we do not assume this behaviour will change.

We will use a private smart contract platform such as [Aztec](https://aztec.network/) as our first prototype for its privacy featutes. Aztec provides a credibly neutral layer of private smart contract platform that allows users to hide key aspects of their transaction and it being only visible to the transacting parties.

### Legal framework

- The guiding principle for our legal approach is: We wish to provide a buyer with equivelant guarantees to current legals of LCs (based on banks). We know the cost of the zkLC will be a fraction of current LCs costs but the challenge is on providing similiar guarantees.
- The zkLC project itself remains a credibly neutral layer of technology providing simply the technical tools to conduct the transaction. We do not aim for it to hold custody of funds nor act with any power over the transaction.
- We aim to provide the users with a standarized set of legal contract that wrap the smart contract based transaction in case of dispute to be used at their discretion and with any laws they wish. We are inspired by the the [Q constitution](https://q.org/constitution#_preamble) for exploring a grey path of where tokens ownership comes with preagreed legal base. They use the ICC: [International court of arbitration](https://iccwbo.org/dispute-resolution/dispute-resolution-services/icc-international-court-of-arbitration/) as a fallback and dispute resolution.
- We wish to base the legal reference for our solution to be rooted in independent international bodies for best compatibility such as the ICC for UCP600 standard and International court of Arbitration for disputes and will pursue this path to legal compatibility.

### Known Challenges
- In traditional letters of credit there are other documents usually accompanying the BOL such as the packing list, commercial invoice, certificate of Origin. What makes these particularly hard to verify is their is that they are stamped by various local authorities along the way (local chamber of industry,ministry of trade, customs,..etc). Our challenge is to understand whether we can have a trust minized solution like zkLC with current formats.
- What happens if the smart contracts turn out to have bug? What is our relationship/obligations as developers to the users? Having the power to influence some locked funds raises trust concerns, not having it is potentially a terrible UX for the user. Whats the right balance?
-

## Development Plan (6 months horizon)

### Technical
- Develop an efficient Noir zkEmail library.
- Build the complete e2e smart contract logic in Noir Language with aztec.
- Adapt shipping email formats (Maersk,Evergreen ,etc...) and write ZK circuits for each one using the Noir zkEmail library.
- Experiment with docusign and pdf content regex and provide working proof of concepts.

### Legal
- Develop a solid reference example contract to govern a smart contract transaction providing users with comparable trust assumptions to traditional Letters of credit and banking framework. We will need to consult experts on maritime law, shipping law, contract law.

### Relationships
- Shipping lines: starting with Maersk and other shipping companies about signature infrastructure. Explain the value they can unlock.
- Users: engage with potential users that might act as our first cases. We will probe into physical commodity trading peoples and entities as they would benefit the most due to volumes.
- B2B onramps/offramps: understand the products offerrings and spec the best way to integrate. Search for reliable partners we can work with.

## Vision

- We see the zkLC a building a block that can be built on to enable financing of a trade by any third party entity that wishes to provide financing to the buyer. Traditionally the only entity the provides this financing if needed is the buyer's bank. We envision this can be provided by any third party that wishes to take on that risk.
- Open source: Having open source code allows for various entities to collaborate and any contributor to join. Moreover since this is a coordination tool, it should be build fully transparently.
- We envision this project to be a collaboration effort between any person/or entity that wishes to contribute in anyway possible to enrich this technology further and would like to always welcome and reward open contributions.

@m38mah
[e-mail]