DEF Protocol

Cemil Şinasi Türün
6 min readApr 17, 2020

By Defterhane Team (Onur Kılıç and C.Ş. Türün)

The vadeli check system of Turkey

1. How does the “vadeli cek” mechanism works?

Basics of the vadeli cek mechanism practiced in Turkey is emulated feature by feature for the DEF Protocol, since it has been in use successfully for over four decades. Most essential aspect of the mechanism is the trust bestowed upon the first signee of the contract. In this respect, any trustable business owner can create credit on the spot, just relying on her word and signature, similar to any sovereign bank. They are similar to paper IOUs, but here, bank issued checks are signed with a future maturity date and handed over from merchant to merchant many times for serial debt settlement. We observe that the banks whose checks are used in the process are not notified during the signing of their checks. Also, note that the banks insure only a limited amount on every check paper in the case of a default and the main credit here is assumed by the original signature carrier. Furthermore, this commercial credit mechanism should not be confused with the futures contracts of Wall Street. When the second merchant wants to pay his debt, he simply signs the empty (back) side of the check and passes it over to his payee. This peer-to-peer method empowers merchants and owners of small and medium size enterprises (SMEs), by permitting them to create and terminate cycles of contracts, in the logical flow of their daily business. Yearly turnover of the system in Turkey, in the year 2019 was estimated to be close to one trillion US dollars.

2. Our implementation of the DEF protocol

The solution we propose starts with a smart contract. For every cycle of credit, a new smart contract is created and kept alive during the lifecycle of transactions and terminated promptly on the maturity date. Within every smart contract, a tree of credit transactions is likely to be formed and many different parties are likely to be endorsers of the contract until the contract is terminated. At no point during the lifetime, the total value recorded within a contract can exceed the initial signed amount. Respective balances of all involved parties at any given time must be equal to the initial contract amount of the original issuer. For every endorsement transaction, the smart contract is called and transaction data recorded before it is signed by both parties. The previous balances of all signees, total amount of the contract and validity of their signatures are all checked by the smart contract logic.

Implementation using a smart contract

At the end of a credit cycle, i.e. when the maturity date is reached, the original issuer, Ali must keep his promise and pay his debt. Payments are made with the currency designated within the smart contact. The issuer can send her due amount to a discharging smart contract, and the discharger contract then distribute the amount to all the holders of the contract either as fiat currency or as stablecoin. The fiat currency bank accounts or stablecoin blockchain addresses of holders are kept securely in a separate contract or in an off-chain database. The fees necessary to maintain the network and servers are collected on every transaction, as a percentage of the transaction. Fees may be in the currency denominated in the smart contracts but must at one point be converted to the actual fee currency of the network maintainers. In the case of Ethereum, the fees should be collected or converted to gas values as explained in the EVM protocol.

End of a cycle: Discharging of the debt to holders

There is a series of peer-to-peer transactions from one business owner to another and at no time a third party (like a bank) is involved or acknowledged. Even though the piece of paper used in this mechanism is a page taken from a bank’s checkbook, this whole business depends on Ali’s keeping his word on the due date, and pay the amount written on the check, and the bank is not informed about these transactions at all. At the end of the maturity period, the last person to hold the check paper brings it to his bank and receive fiat currency in return. The paper check is destroyed after Ali pays the amount on the due date. From the bank’s point of view, the check is signed on the date it is paid, however, it is actually the last day of many serial transactions that took part in the preceding months.

3. Trust versus security

Commerce is carried on between parties who know and trust each other and the DEF Protocol is designed by keeping this essential notion in mind. DEF is not a trustless protocol, but every measure is taken to make it secure. DEF lives on a trusted decentralized platform such as Ethereum, and every smart contract is secured by the consensus of many thousand nodes. Every single transaction is signed by the two involved parties and recorded on the blockchain after their mutual agreement. There is no possibility of a transaction between two anonymous parties; every person or institution that is involved with the Protocol must have a unique secure signature. Ethereum platform is just one possible candidate for creating DEF contracts and any suitable decentralized blockchain can be used by other designers.

4. Electronic signature

Transactions carried out on the blockchain infrastructure must be signed by the parties performing the transactions. Contracts must be signed with an electronic signature equivalent to a wet signature, both at the time of creation and at the point of endorsement. In other words, users must use their electronic signatures for any changes, updates or any sort of transactions within the framework of pre-determined conditions. Identification of the protocol users for future legal responsibility is necessary, so a strong but easy to use form of electronic signature will be used.

5. Secrecy of transactions

Details of the transactions performed in most of the chain technologies used today are open to the public. This situation caused the enterprises not to prefer blockchain technologies for a long time. In the implementation of the DEF Protocol, we have decided to use the discreet approach and will hide all details of the individual transactions happening within the smart contracts. The Defterhane team has been working on a low-cost transaction scheme based on EVM-based chains, and our results has been published as open source code.

6. Legal ground

The new generation of credit instrument described in this paper, although inspired by its counterpart working on paper with wet signature, have almost zero legal similarity. The laws about commercial contracts go back to ancient times and are mutually agreed by all parties involved. The debt / credit contracts, which is located in the shared ledger of the protocol, makes the relevant parties legally responsible for any sanctions and practices. Therefore, none of the existing legal ground for checks and promissory notes are used in this protocol. In the case of default, the original issuer of the smart contract is fully responsible. No other parties within the cycle can be kept responsible for the debt unpaid by the issuer. There is a built in scoring mechanism within the DEF Protocol. There is also a pool of peer-to-peer insurance built-in within the protocol.

7. Credit score, insurance and interest

Peer-to-Peer insurance is a risk sharing scheme where a group of individuals pool their premiums together to insure against a risk. Within the DEF Protocol, a small amount of risk premium is cut for every transaction and added to a general pool. This pool is for covering the default risk, and for the example of vadeli cek system in Turkey, the default rate for the last 5 years, has consistently been less than 3%. The credit score for every responsible issuer is also recorded in the system for future reference. In the figure below, some potential third party services are shown, such as, billing, insurance, factoring (fiat facilitator) and other tools for additional development. However, as in the vadeli cek mechanism, the DEF protocol does not include a built-in interest rate calculation.

--

--