How Marmara Credit Loops (MCL) Work

Marmara Credit Loops (MCL) is a Decentralized Finance (DeFi) system designed and getting developed to run in real economy since 2018. Thanks to Komodo Technologies, the system works on a natural and independent blockchain with smart contracts based on UTXO, Bitcoin way but enhanced with Turing completeness.

This document explains the credit loops according to Protocol 1 which is based on 100 % collateralization in credits issued and circulated.

Marmara Credit Loops; It is the first unique solution in the world that enables the creation and circulation of credits produced on all kinds of bases on the blockchain, not only Post-dated cheques but also Promissory Notes, Bills, Policies etc. It is a Decentralized Finance (DeFi) system designed to run in real economy.

Marmara Credit Loops project is inspired by post-dated cheques which is known in Turkey, India, Middle East, Far East and some Western countries such as Canada. Post-dated cheques still exist on paper as an analog blockchain in some countries such as Turkey and India having currently much greater size than entire crypto market. Marmara Credit Loops can run as a decentralized finance solution that enables the creation and circulation of credits of all kinds. The most basic feature of it is the design to run in real economy.

Before explaining how Marmara Credit Loops work, let’s introduce some concepts which are very easy to understand if you are familiar with use of post-dated cheques.

Marmara Credit Loops Concepts

Protocol 1: Trustless version of Credit Loops. Based on 100% colletaralization by issuers. The system automatic and there is no risk of non-redemption in credits.

Protocol 2: Involves money creation similar to banking but by any people in a decentralized manner. There is little or even no collateralization needed by the issuer before the date of maturity of a credit loop. It works around escrows and communities. It merges trustless nature of blockchain with trust based participants.

Issuer: The person who first creates a credit in a credit loop. It is the person who forms the first node in the credit loop. The credit may be collateralized 100% or with even zero-collateralization until maturity date of a credit.

Bearer (Holder): The last node in a credit loop is always called bearer (holder). When someone transfers a credit in a loop, that node becomes immediately an endorser.

Endorser: All other nodes that fall between the issuer, which is the first node in the credit loop, and the last node, and transfer the credit to the next node.

Maturity: The time a credit expires. It is measured as blocks in estimation. The block per day is 1440 (60 blocks an hour times 24 hours a day). Suppose a credit is for 100 days, the maturity is 1440x100, i.e. 144,000 blocks.

Settlement: When a credit matures, settlement is made to the holder, the last node in a loop. Settlement may be automatic or manual.

Escrow: Trust based parties for Protocol 2. If EscrowOn is false, then 100% collateralization is used and settlement is automatic. There is no need for escrows in protocol 1 which works as complete trustless version.

Avalist: Avalists support issuer or endorsers with MCL as additional colletarization and can earn with 3x staking with those support. In case of non-redemption, their funds are utilized. Avalists are available only in Protocol 2. The parameter avalcount is always zero for protocol 1.

BlockageAmount: This is again another term for protocol 2. An issuer may be asked to put some collateralization by a holder. In that case, the issuer gets benefit of 3x staking in protocol 2.

Dispute Expiry: It is grace period for solving non-redemption problem in credit loops in protocol 2. An issuer may have this time as blocks when creating a credit under protocol 2 without or insufficient collateralization. Before this period expires, an escrow should do all actions according to aggrement with the issuer to solve non-redemption. Otherwise, the escrow is penalized in the system.

2 DEFI PROTOCOLS IN MARMARA CREDIT LOOPS

Protocol 1 (Full Colleteralization): Protocol 1 which is the current one works in 100% collateralization mode. It works completely trustless. 100 % collateralization is made by issuer on behalf of both himself/herself and holder. Both issuer and holder have the 3x staking chance to get blockchain rewards. Issuer has the 3x staking chance until maturity date of credit whereas holder has the 3x staking chance until he/she endorses/transfers the credit to a new holder who will continue staking with the issuer. Holders (and endorsers) do not need to lock any single coin to participate in a credit loop. They can just sell goods or services to have the right for 3x staking power.

Protocol 2 (Under Collateralization): People can create money/credit not only in cryptocurrencies but also in any fiat currency supported and even some assets such as gold and silver. Any credit with protocol 2 requires the trust based escrows which are communities or other institutions who will be dealing with KYC procedures and collateralization as well as being responsible in solving non-redemption problem. The protocol 2 has 2nd and 3rd layer support in Marmara blockchain against non-redemption. The trust based parts benefit a separate fund on blockchain. The avals and other participants in community have 3x staking power according to blockage amount and collateralization.

HOW TO MAKE CREDIT LOOPS (IN PROTOCOL 1)

FUNCTIONS TO BE USED IN CREDIT LOOPS
It is quite simple to manage Marmara Credit Loops. You only need to know few function calls. If you are an issuser, i.e. creating credit, you need to lock coins with 100% collateralization.

The function call to be used for collateralization is the marmaralock command. If you do not have enough MCL coins, You can learn how to mine and stake, from this link or buy it from the relevant places such as AtomicDEX, i.e. Decentralized Exchange by Komodo Platform. Holders do not need any coin for 3x staking since they provide goods and services during shopping.

1. MARMARA RECEIVE
   Explanation: marmarareceive This command is used to get a credit from an issuer or an endorser. When asking a credit from an issuer, i.e. the first node, it has unique use. In other nodes, it is same.

USAGE:
a) The first holder when asking for credit from issuer node:

./komodo-cli -ac_name=MCL marmarareceive senderpk amount currency matures '"{"avalcount":"n"}'

b) In other nodes:

./komodo-cli -ac_name=MCL marmarareceive senderpk batontxid '{"avalcount":"n"}'

This marmarareceive call will generate hex code for issuer or endorser.

Please note that there is no batontxid in the first call.

‘matures’ shows when a credit loop expires. Since estimated interval time between two blocks is 1 minute for Marmara Chain, 60 means 1 hour, 1440 means a day and 525,600 (365*1,440) for one year.

MARMARA ISSUE
Explanation: marmaraissue is used only by issuer, the first node to create/issue a credit. By this, a credit is also transferred to the first holder, i.e. the second node. Many of the parameters for a credit loop is decided between the issuer and the first holder.

Usage: ./komodo-cli -ac_name=MCL marmaraissue receiverpk '{"avalcount":"n", "autosettlement":"true"|"false", "autoinsurance":"true"|"false", "disputeexpires":"offset", "EscrowOn":"true"|"false", "BlockageAmount":"amount" }' requesttxid

A typcial example for protocol 1 is as follows:-

./komodo-cli -ac_name=MCL marmaraissue receiverpk '{"avalcount":"0", "autosettlement":"true", "autoinsurance":"true", "disputeexpires":"0", "EscrowOn":"false", "BlockageAmount":"0" }' requesttxid

Protocol 1 is defined by the parameter “EscrowOn”:”false. Since there is no escrow is involved, the other parameter settings for protocol 1 should be “autosettlement”:”true” and “autoinsurance”:”true”. Obviously, by “disputeexpires”:”0”, “BlockageAmount”:”0”, the dispute expiry and blockage amount are also set to zero due to 100 collateralization.

MARMARA TRANSFER

Explanation: marmaratransfer is used to transfer a credit by the last node, i.e. holder. The last holder is entitled as endorser as soon as he/she transfers the credit to the new holder. In other words, all endorsers are previously holders.

Usage: ./komodo-cli -ac_name=MCL marmaratransfer receiverpk '{"avalcount":"n"}' requesttxid

SEND RAW TRANSACTION

Explanation: sendrawtransaction command is used after marmarareceive, marmaraissuse, marmaratransfer and marmaralock to make the results of commands to be executed on blockchain.

Usage:

./komodo-cli -ac_name=MCL sendrawtransaction "signedhex"

EXAMPLE CREDIT LOOPS (WITH 3 NODES)

There are 3 nodes in this sample credit loop. PUBKEY 1 is the credit issuer, i.e. the first node. PUBKEY 2, the second node is endorser and PUBKEY 3 is the holder, the last node. A credit may be circulated until 1000th node in a credit loop. Best thing about the credit loops is that a locked credit in a loop can be circulated to buy things during shopping. There is no meaning in circulating a credit in a loop besides shopping since endorsers lose the 3x staking power when a credit is transferred to a new holder. This feature as well as power of 3x staking for both issuer and holder make credit loops suitable to run in real economy.

Best thing about the credit loops is that a credit locked in a loop can be circulated to buy things during shopping. There is no meaning in circulating a credit in a loop besides shopping since endorsers lose the 3x staking power when a credit is transferred to a new holder. This feature as well as power of 3x staking for both issuer and holder make credit loops suitable to run in real economy.

PUBKEY 1 (FIRST NODE— ISSUER) ADDRESS

0386c24017574654bb6a5a7ccd28c63cd71f98cf205d59dccf328f359313e1b691

PUBKEY 2 (SECOND NODE— ENDORSER 1) ADDRESS

029e239bcefb34eddec284a1ee0c701fb14727aacef03efd8a0b307c7d6b181b0e

PUBKEY 3 (THE LAST NODE—HOLDER/BEARER) ADDRESS

031e6a12651fca44163e21fc03d41acdd8b2337a442ed99a64f6ae759e143e7374

SUMMARY FOR STEPS

1. PUBKEY 2 (First holder/Later Endorser) makes marmarareceive from PUBKEY 1 (Issuer) for 900 MCL. Please note that this amount should be available in activated fund. If not available, that needs to be activated through marmaralock 900.
2. PUBKEY 1 (Issuer) issues the whole credit with marmaraissue and transfers to PUBKEY 2 (first holder/endorser). Issuer locks the credit UTXO or both himself/herself and holder. Now, both can do 3x staking.
3. PUBKEY 3 (Holder) makes marmarareceive from PUBKEY 2 (endorser) to get the credit.
4. PUBKEY 2 transfers the 900 MCL credit info to PUBKEY 3 (holder) through marmaratransfer. Endorser (PUBKEY2) transfers the right for 3x staking to holder by this.

P.S.: After every step, a sendrawtransaction call is made to record the transaction on blockchain and the “Baton Tx Id” is forwarded to next node to use in relevant command.

DETAILS

1. PUBKEY 2 (First holder/Later Endorser) makes marmarareceive from PUBKEY 1 (Issuer) for 900 MCL. matures has 1,576,800 which means a credit for 3 years (1440 blocks a day*365 days*3 years).

./komodo-cli -ac_name=MCL marmarareceive “0386c24017574654bb6a5a7ccd28c63cd71f98cf205d59dccf328f359313e1b691” 900 MARMARA 1576800 ‘{“avalcount”:”0"}’
{
“result”: “success”,
“hex”: “04000xxxxxxxxxxxxxxxx0000000000000000000000”,“funcid”: “R”,
“createtxid”:“0000000000000000000000000000000000000000000000000000000000000000”,
“senderpk”: “0386c24017574654bb6a5a7ccd28c63cd71f98cf205d59dccf328f359313e1b691”,
“amount”: 900.00000000,
“matures”: 1698913,
“currency”: “MARMARA”
}

Copy the hex”: “04000xxxxxxxxxxxxxxxx0000000000000000000000” part and write in sendrawtransaction command. After sendrawtransaction, you will get Baton Transfer Tx Id to be used in later node.

./komodo-cli -ac_name=MCL sendrawtransaction "04000xxxxxxxxxxxxxxxx0000000000000000000000"

BATON TXID:

1b38f49b531c01a3b8c575c5dc5abf8cf25276580f2b863837cdcd2b1293ef73

2. PUBKEY 1 (Issuer) issues the whole credit with marmaraissue and transfers to PUBKEY 2 (first holder/endorser).

./komodo-cli -ac_name=MCL marmaraissue “029e239bcefb34eddec284a1ee0c701fb14727aacef03efd8a0b307c7d6b181b0e” ‘{“avalcount”:”0", “autosettlement”:”true”, “autoinsurance”:”true”, “disputeexpires”:”0", “EscrowOn”:”false”, “BlockageAmount”:”0" }’ 1b38f49b531c01a3b8c575c5dc5abf8cf25276580f2b863837cdcd2b1293ef73
{
“result”: “success”,
“hex”: “HEX CODE”,
“funcid”: “I”,
“createtxid”:“1b38f49b531c01a3b8c575c5dc5abf8cf25276580f2b863837cdcd2b1293ef73”,
“requesttxid”:“1b38f49b531c01a3b8c575c5dc5abf8cf25276580f2b863837cdcd2b1293ef73”,
“receiverpk”:“029e239bcefb34eddec284a1ee0c701fb14727aacef03efd8a0b307c7d6b181b0e”}

HEX CODE is send to blockchain with sendrawtransaction and Baton TX ID is obtained.

./komodo-cli -ac_name=MCL sendrawtransaction “HEX CODE”

BATON TRANSFER ID:

0c71e5066e50838314951797250905c985a787446c5c8a2a6abb97755c601d2f

NOW CREDIT IS ISSUED. It can circulate up to 1000th node within 3 years time to buy things.

DISPLAYING A CREDIT LOOP

Now credit loop exists between node 1 (issuer) and node 2 (first holder/later endorser). You can display it with marmaracreditloop.

./komodo-cli -ac_name=MCL marmaracreditloop 0c71e5066e50838314951797250905c985a787446c5c8a2a6abb97755c601d2f
{“result”: “success”,
“myNormalAddress”: “RGF7DRwTa9SBgbDgYnGKLPn3agviTF9wHg”,
“myCCaddress”: “RSxHXgb7wHWmynmNev6oh3eKqDExoeHp5S”,
“funcid”: “I”,
“currency”: “MARMARA”,
“batontxid”:“0c71e5066e50838314951797250905c985a787446c5c8a2a6abb97755c601d2f”,
“createtxid”:“1b38f49b531c01a3b8c575c5dc5abf8cf25276580f2b863837cdcd2b1293ef73”,
“amount”: 900.00000000,
“matures”: 1698913,
“batonpk”:“029e239bcefb34eddec284a1ee0c701fb14727aacef03efd8a0b307c7d6b181b0e”,
“batonaddr”: “RCnWFq1eHN9gogfxRTRr3kJae62QRtRDUn”,
“batonCCaddr”: “RER8TtHKA8vGZZdDvDbuoBAwxsNKQGVsXi”,
“ismine”: 0,
“LockedInLoopCCaddr”: “RD6ij1cbF2iWwwqqMzvfWBgnaK44mRUi8p”,
“LockedInLoopAmount”: 900.00000000,
“n”: 1,
“creditloop”: [
{“txid”:“1b38f49b531c01a3b8c575c5dc5abf8cf25276580f2b863837cdcd2b1293ef73”,
“funcid”: “B”,
“issuerpk”:“0386c24017574654bb6a5a7ccd28c63cd71f98cf205d59dccf328f359313e1b691”,
“issuerNormalAddress”: “RGF7DRwTa9SBgbDgYnGKLPn3agviTF9wHg”,
“issuerCCAddress”: “RSxHXgb7wHWmynmNev6oh3eKqDExoeHp5S”
}]}

3. PUBKEY 3 (Holder) makes marmarareceive from PUBKEY 2 (endorser) to get the credit.

./komodo-cli -ac_name=MCL marmarareceive “029e239bcefb34eddec284a1ee0c701fb14727aacef03efd8a0b307c7d6b181b0e”
0c71e5066e50838314951797250905c985a787446c5c8a2a6abb97755c601d2f ‘{“avalcount”:”0"}’
{“result”: “success”,
“hex”: “HEX CODE”,
“funcid”: “R”,
“createtxid”:“1b38f49b531c01a3b8c575c5dc5abf8cf25276580f2b863837cdcd2b1293ef73”,
“batontxid”:“0c71e5066e50838314951797250905c985a787446c5c8a2a6abb97755c601d2f”,
“senderpk”:“029e239bcefb34eddec284a1ee0c701fb14727aacef03efd8a0b307c7d6b181b0e”}

BATON Transfer Id is taken by using

./komodo-cli -ac_name=MCL sendrawtransaction “HEX CODE”

BATON TRANSFER ID:

8cba64ff05b3b6c16eb1d2d2fad9fd15da82c2836ce47a5e69f34bfc7cafb533

4. PUBKEY 2 transfers the 900 MCL credit info to PUBKEY 3 (holder) through marmaratransfer. Endorser (PUBKEY2) transfers the right for 3x staking to holder by this.

./komodo-cli -ac_name=MCL marmaratransfer “031e6a12651fca44163e21fc03d41acdd8b2337a442ed99a64f6ae759e143e7374” ‘{“avalcount”:”0"}’ 8cba64ff05b3b6c16eb1d2d2fad9fd15da82c2836ce47a5e69f34bfc7cafb533
{
“result”: “success”,
“hex”: “HEX CODE”,
“funcid”: “T”,
“createtxid”:“1b38f49b531c01a3b8c575c5dc5abf8cf25276580f2b863837cdcd2b1293ef73”,
“requesttxid”:“8cba64ff05b3b6c16eb1d2d2fad9fd15da82c2836ce47a5e69f34bfc7cafb533”,
“batontxid”:“0c71e5066e50838314951797250905c985a787446c5c8a2a6abb97755c601d2f”,
“receiverpk”:“031e6a12651fca44163e21fc03d41acdd8b2337a442ed99a64f6ae759e143e7374”}

Baton Transfer Id is obtained through

./komodo-cli -ac_name=MCL sendrawtransaction “HEX CODE”

BATON TRANSFER ID:

dc8edcdc4655e6e0e285d2ade8c06d0d4da41fdea80615a827610fb9d72ec3e4

NOW CREDIT IS ON NODE 3 (New/Last Holder)

Now credit is on Node 3.

You can display the credit loop by using the latest Baton Transfer Id.

./komodo-cli -ac_name=MCL marmaracreditloop dc8edcdc4655e6e0e285d2ade8c06d0d4da41fdea80615a827610fb9d72ec3e4
{
“result”: “success”,
“myNormalAddress”: “RCnWFq1eHN9gogfxRTRr3kJae62QRtRDUn”,
“myCCaddress”: “RER8TtHKA8vGZZdDvDbuoBAwxsNKQGVsXi”,
“funcid”: “T”,
“currency”: “MARMARA”,
“batontxid”:“dc8edcdc4655e6e0e285d2ade8c06d0d4da41fdea80615a827610fb9d72ec3e4”,
“createtxid”:“1b38f49b531c01a3b8c575c5dc5abf8cf25276580f2b863837cdcd2b1293ef73”,
“amount”: 900.00000000,
“matures”: 1698913,
“batonpk”:“031e6a12651fca44163e21fc03d41acdd8b2337a442ed99a64f6ae759e143e7374”,
“batonaddr”: “RVGnuC44Vx5W7hnjgjJqedcxVuvuE49VVg”,
“batonCCaddr”: “RTEKuDjLiKxpZKLVmPkajBUCbxUcmcNyka”,
“ismine”: 0,
“LockedInLoopCCaddr”: “RD6ij1cbF2iWwwqqMzvfWBgnaK44mRUi8p”,
“LockedInLoopAmount”: 900.00000000,
“n”: 2,
“creditloop”: [{
“txid”:“1b38f49b531c01a3b8c575c5dc5abf8cf25276580f2b863837cdcd2b1293ef73”,
“funcid”: “B”,
“issuerpk”:“0386c24017574654bb6a5a7ccd28c63cd71f98cf205d59dccf328f359313e1b691”,
“issuerNormalAddress”: “RGF7DRwTa9SBgbDgYnGKLPn3agviTF9wHg”,
“issuerCCAddress”: “RSxHXgb7wHWmynmNev6oh3eKqDExoeHp5S”
},{
“txid”:“0c71e5066e50838314951797250905c985a787446c5c8a2a6abb97755c601d2f”,
“funcid”: “I”,
“receiverpk”:“029e239bcefb34eddec284a1ee0c701fb14727aacef03efd8a0b307c7d6b181b0e”,
“receiverNormalAddress”: “RCnWFq1eHN9gogfxRTRr3kJae62QRtRDUn”,
“receiverCCAddress”: “RER8TtHKA8vGZZdDvDbuoBAwxsNKQGVsXi”}]}

P.S: You can read the whole article about Marmara Credit Loops from “Marmara Credit Loops: A Blockchain Solution to Nonredemption problem in Post-dated Cheques”

FOR MORE HELP

You can get help in related channels such as mining and staking on Marmara Discord server. You can also follow other resources below.

Discord Group: https://discord.gg/8mBSKC7
Twitter: http://twitter.com/marmarachain
Web: http://marmara.io
Marmara Blockchain Explorer: http://explorer.marmara.io
Marmara Chain Github: http://github.com/marmarachain