Marmara Credit Loops Coin (MCL Coin)
BUSINESS REQUIREMENTS OF MARMARA FUNCTIONS FOR MARMARA CREDIT LOOPS DRAFT DESIGN for Version 1.0
Marmara Chain is a peer-to-peer credit creation and circulation system with self-assurance to be maintained by the credit creators and endorsers. It is inspired from a common culture related to use of post-dated cheques in countries such as Turkey, India etc. The original system works as a trust based one. The processes for credit creation and circulation are managed in so called Credit Loops. MCL Version 1.0, i.e. The Millennium Version is aiming at solving the problem with a trustless system approach based on the way of smart contracts in Komodo blockchain technologies. The trust based additions are planned to be in Version 2.0. The basic purpose of Marmara Chain is to solve the most basic and difficult problem in credit loops: It is defaulting. For doing this, MCL coin produced on Marmara Chain is utilized. MCL Coin is 25% mineable and 75 % stakeable with the condition of activation, i.e. timelocking. For Incentivizing the credit creation and redemption, activated coins in credit loops will be boosted with 2 times more chance during staking.
MCL MILLENNIUM EDITION: ZERO-NONREDEMPTION BY 100% SELF-INSURANCE
The Millennium edition of Marmara Credit Loops is very simple. Anyone can issue a credit if he/she has the enough activated coins in the wallet. Due to 100% collateralization, the credit is already available and hence redeemable. So the credits in this version are self-insured. Therefore, the first version mainly uses the trustless nature of blockchain without trust based agents which are planned in the Version 2. Somebody might question if this may be called a real credit since it is all redeemable at the beginning. When people are involved in credit loops, they will have much more chance of staking which will give them power of creating new credits since activated coins have in credit loops
2 times more chance than other activated coins not locked in credit loops.
The system is 100% collateralized which means 0% default and no double usage of same coins in different credit loops are allowed.
The system tries to solve the problem through non-redemption processes based on the following two layers:
Credit Loops Layer (Layer 1): In the credit loop layer, credit issuer and all circulators are responsible to pay the debt at the end of post-date specified during creation/issuance of credit. This version works only with both Autoinsurance and Automatic settlement modes on.
Community Layer (Layer 2): To be used in Version 2.0 with Trust Based Additions.
Blockchain Fund Layer (Layer 3): This is the blockchain fund. The fund will be used to maintain the transaction fees and and as a redemption source against the failures due to the small problems. A fund is maintained based on the transactions in blocks with approximately 5% annually. The fund is inaccessible from outside and is used only against defaulting. The funds are to build up for Version 2.0.
Basic differences with version 0.1.0
Earlier version of timelocking between 3 months to 2 years will be fixed to same maximum blockheight. All activated coins will be locked to the maximum value. marmaraunlockht will take maximum value of int32_t which is 2147483647.
Credit Loop: A credit loop is N number of nodes starting with the first node as being Issuer, many endorser who will circulate the credit and the holder as the last node.
Issuer: The first node, i.e. the credit creator, or issuer in the credit loop.
Endorser: All other nodes except the last holder node coming after the issuer in the credit loop.
Holder: The last node in the credit loop. All other nodes in the credit loop are responsible towards the holder to pay his/her debt.
1. marmaralock amount
Used to timelock amount of MARMARA to blockheight of 2,147,483,647 (for staking)
- Old Version: marmaralock amount unlockht
- New Version: marmaralock amount
2. Marmarareceive (Marmara Receive): Making a request from either credit issuer or endorser
- Old version: marmarareceive senderpk amount currency matures [batontxid]
- New version: marmarareceive senderpk amount currency matures avalcount=default_0 [batontxid]
avalcount: Reserved for Version 2.0.
When autosettlement is true the settlement should be automatic.
Important: Please note that when the credit is issued with automaticsettlement automaticsettlement cannot be changed to false in the consequent marmarareceive, marmaraissue, and marmaratranser operations.
3. Marmaraissue (Marmara Issue): Issuer creates the credit.
Old version: marmaraissue receiverpk amount currency matures approvaltxid
New version: marmaraissue receiverpk amount currency matures autosettlement=default_is_true autoinsurance=default_is_true avalcount=default_is_0 disputeexpires=default_3_years EscrowOn=default_false BlockageAmount=Default_is_0 approvaltxid
- autosettlement: Boolean. This parameter is always true in Version 1.0.
- autoinsurance: Boolean. In this Version 1.0, this parameter is also always true.
- avalcount: Integer. Reserved for Version 2.0.
- Dispute expires (Block Height): Reserved for Version 2.0.
- EscrowOn: Boolean. Reserved for Version 2.0.
- BlockageAmount in Marmara: Integer. Reserved for Version 2.0.
This version works based on autosettlement and autoinsurance without need of manual settlement.
The system works based on 100% collateralization without nonredemption. The full credit is issued by the issuer. The credit issuers have the highest chance of staking since they have their coins locked in credit loop where they have 2 times more chance for staking than other activated coins.
Note: The term “activated” is used for locked coins to stake. The term “boosted” may be used for locked coins in credit loops.
Process in the table is self-explanatory. Only the last changes are shown for the balances for Pubkeys. Three different accounts are maintained. One is normal account with transferable MCL. The second one is “activated” and used for staking. The third is “boosted” for locked coins in credit loops. The main purpose of “boosted” coins is to protect from overuse of coins duing credits and promoting the credit creation. Since 100% collateralization is maintained, the should have been a strong incentive to create a credit. That is the “boosted”. People will have power to create more credit by giving away.
4. Marmarabatonapproval (Marmara Baton Approval):
Baton is approved by endorser. Baton is transferred to next node with this function.
This is additional step to the Old Version 0_1_0. For marmaraissue, there are several parameters which exist only in marmaraissue but need to be carried out into the next functions in credit loop without repeating as parameters in consequent functions. So we need a function called marmarabatonapproval, to be finalized. Otherwise, the issuer or endorser would just transfer the baton on the contrary of will of endorser.
- Old Version: Not available.
- New version: marmarabatonapproval senderpk amount currency matures avalcount=default_is_0 batontxid
Note: Credit without marmarabatonapproval means “it is not issued or transferred YET.” In case of first node, when issuing a credit with marmaraissue, the baton will not be created without marmarabatonapproval. And in the consequent nodes, when transferring that credit with marmaratransfer, the baton will not be transferred without marmarabatonapproval.
BatonApproval means the endorser has accepted all initial conditions set during issuance. Therefore, we don’t repeat them here. The conditions that are accepted by each endorser are autosettlement. The parameters autosettlement, disputeexpires, EscrowOn, and BlockageAmount are defined during issuance whereas avalcount may be different for every endorser. Therefore, the parameter avalcount is added in marmarabatonapproval.
P.S. Very important: Baton will return back to Issuer at the end of settlements in order to display the credit loop later. Baton should not be destroyed.
5. Marmaratransfer (Marmara Transfer): Endorser transfers the credit to endorser, or holder.
- Old version: marmaratransfer receiverpk amount currency matures approvaltxid
- New version: marmaratransfer receiverpk amount currency matures avalcount=default_is_0 approvaltxid
6. Marmarasettlement (Marmara Settlement): The holder settles the credit when the autosettlement is true. It is now internal function.
marmarasettlement function was public/external function in the previous version. Now it is private/internal function and cannot be called from outside. This will be triggered by miners internally when they invoke marmaraclaimautosettlements.
- Old version: marmarasettlement batontxid
- New version: marmarasettlement batontxid
* Very important: Baton will return back to Issuer at the end of settlements in order to display the credit loop later. Baton should not be destroyed.
7. marmaraclaimautosettlements (Marmara Claim Autosettlements)
this call is made by miners to do autosettlements. This is to make sure that no eligible credit loop signed with autosettlement as true will go unsettled.
- Old Version: Not available.
- New Version: marmaraclaimautosettements startingblock endblock JL777 is to decide the parameters for this function not to increase the load in the blockchain. P.S: marmaraclaimautosettements uses the internal function marmarasettement internally.
Table 2. Before and After the Settlement
Marmara Credit Loops: Dr. B. Gültekin Çetiner and JL777, 2018-2019. Thanks to both Marmara and Komodo communities