Project proposal for decentralized credit generation tooling and PoC app

We are going to build tools for an autonomous credit creation and circulation system which is highly influenced by the unique routine of SMEs in Turkey which they create cash-like transferable credit without permission of any central authority.

In this proposal, we want to use SNARK and DA gears to build core components that copy a similar structure in order not to compromise of any decentralized characteristic of existing system.

We also want to create a ground for discussion for economical/political aspects of this system alongside with technical features. So let's first elaborate how it works in practice and try to present why it is interesting.

Credit creation scheme in Turkey

An IOU is a cash-like transferable asset that carries promise of an issuer that they will pay a debt in future. With this simple asset, SMEs in Turkey creates an interesting p2p credit expansion system which is a major alternative to fractional reserve banking. Circulation occurs solely between merchants so the system operates without involvement of financial institutions.

In Turkey, there are above half of a million of issuers of this type of asset. In 2022 total face value sums approximately to 150 billion USD where GDP in same year is calculated around 905 billion USD. With a very conservative estimation volume of the circulation is covering at least 25% of the country total.

Issuer simply writes amount, unit and payment date (usually few months depends of kind of supply chain) and with a signature gives it to their vendor in exchange for goods and services. IOUs are bearer assets so holder can use them for their purchases through simply signing and passing it down to a supplier. As long as seller side accepts the IOU whether it's newly created or transferred there is absolutely no restriction on amount and payment due date.

The system is based highly on hard earned reputation and trust. Propagation of IOUs mostly takes place in supply chains such that issuers and holders are in long standing business relationship. IOUs are promises for future so issuers don't have to show or lock any collateral until the maturity date. Instead issuers stake their reputation as collateral against the risk of default. I think It should reflect effectiveness of reputation risk that default rate remarkably stayed below %1 in 2022 where most of them are not scams but inaccurate predictions. Whereas non performing banking loans are usually above 4%

At the payment due date issuer pays the amount to the final holder and we say lifecycle of an IOU finalizes at this point. Holder brings the IOU to a bank where wire transfer from issuer to holder is triggered. Aside from being payment facilitator in the end of a cycle, retail banks don't have a role in credit creation and transacting part of system.

Nevertheless cash out mechanisms through special kind of financial institutions are available. If an SME needs to get cash before payment due date they sell their IOUs at obviously under the face value priced on the date and risk of the issuer. This is actually similar kind of passing down but in return of cash rather than for goods & services. We cannot know the exact converted volume to cash but estimates say it is around 15%.

We should also stress that this is not p2p lending scheme. In p2p lending existing money moves from lenders to borrowers. Here instead we talk about money creation and termination between debtors and creditors which all are SMEs.

Intersection with our journey at PSE

At PSE, we develop tools and carry out research around SNARK technology and its applications. I believe this mechanism perfectly aligns with our ongoing efforts. Here we want to build a set of tools that both emulate and improve the credit creation system, while preserving and also increasing its autonomous characteristics.

Ideal final product briefly should cover such features:

• Settlement layer: This is where debts are settled and the life of IOUs are terminated. Traditionally managed by retail banks, this would require integrating of several banks to operate this step
• An authorized signatory system to manage permissions among employees within larger SMEs
• An optional insurance system runs through local pools among SMEs that helps to aid default risks
• An Investor API that applies the cash-out system to that helps SMEs to sell or assess the value of IOUs before payment due date. This serves a bridge between investors (buyers of IOUs) and SMEs (sellers of IOUs)

In the PoC we will exclude adding defi like integrations, actual marketing, and fully compatible wallet features. Our scope for this project is to be building core components: IOU creation and partially transferring system.

We would like to call our base layer as PCDCash. Every valid IOU should have a succinct PCD proof, ensuring propagation of assets is executed correctly from creation to end. Additionally, there should be publicly available nullifier set that blocks sending already exchanged IOUs. In the final part of this PoC we should demonstrate it works through a user client such as a mobile application.

We also want to utilize and improve existing PSE supported toolings wherever possible. For example zkp2p is a promising tool that could enable integration of off-chain settlement or cash out system without actually needing third party integration. Also  pse/folding-schemes library must be considered for our essential PCD scheme requirements.

First Milestone

In the first milestone we simply aim to build an end to end application that users can create, transfer IOUs and verify correctness of previous steps with minimal usage of DA layer. And It should be demonstrated with and example client application

1. Offchain UTXO Circuitry

This component covers data structures and circuits of functions on an asset. CRATE circuit is used at creation of an asset and SPLIT-TRANSFER circuit is used for partial transfer of assets. We are going to follow one variation of folding schemes. So that asset holder will be able to verify correctness of chain of transfer events happened correctly with a single proof. Addition to that, asset holder will only be able to know about the path that asset is coming from but not about remainder amounts in the UTXO splits. We should also apply account abstraction so that we need in circuit secp256r1 ECDSA verification.

Effort

• Research: 2 people, 2 month
  • should cover study of existing folding schemes
  • should cover to exploring PCD libraries
  • should bring comfort in usage of a PCD for a basic app
• Building, 2 people, 2-3 month:
  • develop circuits in specs such as  SPLIT_TRANSFER and CRATE

2. DA Layer

Each SPLIT-TRANSFER should throw a nullifier that indicates a certain path in an IOU tree is already spent. So these nullifiers must be publicly available to prevent double spend. This can be naively achieved if users publish nullifiers via L1 or L2 tx. This is something we don't want not only it would be much costly but also we want to apply account abstraction from day one. Instead, a sort of specialized rollup that only functions as publisher of nullifiers must be online.

Research on DA options and techniques will likely be ongoing work and in this PoC milestone. I guess we should apply the simplest one. Barry suggests that we can do this via multisig attester approach even without using a blockchain DA for the beginning. I agree and I think it can be even single attester for PoC implementation

Effort

• Research, 1 person:
  • timing is TBD it seems like it can be ongoing regarding the recent improvements in this area
• Building, 1 person, 1 month
  • develop a simple server that stores nullifiers that say yes or no against requested keys.

3. Integration

Integration should cover consitency between specs and PoC product. (TODO: ask Andy for help)

Effort

• Spec out: 1-2 month simultaneously with other research subjects.
  • alongside with in circuit UTXO and DA research we spec out the first working end to end application
• Testing and debugging finalized PoC in each level: 1 month

4. Client

A client works as wallet that performs proving and verification as well as consumes DA layer API. So that user will be able to monitor, crate and transfer their offchain UTXO assets.

Reference Client

A rust client as a reference implementation.

Mobile App

TBD