Draft Concept of a Mechanism for a Decentralized, Stable Priced Cryptocurrency (STABC)

Disclaimer: this is a draft theoretical concept only. With publishing I make this concept public and I will not claim any ownerships of these ideas and the concept ever. I acknowledge if there are technological and potentially logical hurdles identified that may prevent such an idea to become reality ever. However in case the above theory or its parts may be of interest of you please feel free to use for any type of projects you may be willing to launch.

I.
Indexing

Indexing is an interesting question as the price of STABC would need to be pegged to an index already – e.g. ETH/USD price index. To be able to take off USD from this pair a timestamped genesis block-pair seems to be a valid option to peg the price of STABC with a timestamp to the actual ETH price/value at the given moment.

Let’s take a pool of 10M ’value-less’ STABC and complete a transaction timestamped in 1:1 ratio with ETH at a given ETH/USD price. Now the price and value of 1 STABC is equal to 1 ETH price in USD at the time of the first transaction (timestamped). Performing a second genesis transaction (timestamped) will enable us to take off the USD pair from the ETH/USD index. Due to the fact that the ETH/USD index is different at the time of the second genesis transaction the rate of exchange of ETH to STABC will not be in a 1:1 ratio – this can be more or less (or equal with a quite low probability).
With completing the two genesis transactions from that point only the continuous change of percentage of ETH will be relevant compared to the first genesis transaction and not the actual ETH/USD index.

Example:
First genesis transaction: 1 STABC = 1 ETH = 1000 USD
Second genesis transaction: 1 STABC = 0.8 ETH = 1000 USD (at the time of second genesis transaction the price of STABC is 1250 USD consequently).

In case ETH price fluctuates against USD STABC will only recognize the value against the first genesis transaction in percentage.

To enable the mechanism to work however a continuous global ETH/USD price index consensus would need to exist.

II.
Introducing ’Assset Indicator Value’ (AIV) and ’Interest and Exchange Token’ (IET)

10M ’value-less’ STABC can be generated during the genesis that is available in a ’liquid pool’ and after the genesis transactions these can be purchased on the fixed value. This value will never be changed if the mechanism works.

What is the ’Asset Indicator Value’?

The ’Asset Indicator Value’ (AIV) is an indicator – and has two types such as a starting ’AIVTotal’ and an ’AIVcurrent’. The ’AIVTotal’ is 10M and AT the time of stabilizing the price of STABC 10M AIVTotal= 10M STABC.

’AIVcurrent’ is the current asset at a given moment in the ’liquid pool’ that fluctuates depending on how much ETH are set in the pool and how the price changes of ETH. As a consequence ’AIVcurrent’ can be more or less or equal to 10M at a given moment.

The ratio of these two will be important - AIVcurrent:AIVTotal

’Interest and Exchange’ Token – multifunctional (IET). Every single STABC transaction between external wallets is an IET transaction as well in 1:1 ratio (minus transaction fee). STABC/IET payment from the ’liquid pool’ to wallets is proportional to the IET held in wallets (interest). This mechanism will enable handling critical situations such as low pool STABC volume, transferring STABC to liquid pool in case decreased ETH/USD market price.

In the initial state the followings are minted – 10M STABC, 10M AIVTotal, 10M IET.

In the case soemone is purchasing 1M STABC on the fixed price from the liquid pool which is at the time of purchase is 1M ETH exactly (for the example only) the purchaser will receive 1M STABC and 1M IET in his/her wallet (this is a decision point whether transaction fees may apply for transactions in and out of the ’liquid pool’).

The status is the following –

Liquid Pool
10M AIVTotal and 10M AIVCurrent (let’s take that there is no price fluctuation for ETH in this given example only).
9M STABC
9M IETpool (10M – 1M IET shifted to purchaser’s wallet) and 9M IETcurrent
AIVCurrent: AIVTotal and IETcurrent: IETpool are both 1

Purchaser’s wallet
1M STABC and 1M IET

Transaction verifier
0

In another block transaction will be completed between two external wallets (the previous purchaser and a merchant for example). 500k STABC will be transferred between these two wallets. Let’s consider transaction fee as 0.1% (it is a question whether transaction fees can/should be trailed – e.g. transactions with higher amount may have a lower transaction fee percentage).

Let’s introduce here another ratio – Liquid Pool/Verifier ratio for the transaction fee. In this particular scenario let’s consider this as 1:1 – meaning 50% of the transaction fee will be transferred to verifier while 50% will be shifted back to liquid pool. This ratio can change depending on overall asset status (please see scenarios later).

So now we have the following overall status –

Liquid Pool
10M AIVTotal and 10M AIVCurrent (let’s take that there is no price fluctuation for ETH in this given example only).
9,000,250 STABC
9M IETpool (10M – 1M IET shifted to purchaser’s wallet) BUT 9,000,250 IETcurrent
AIVCurrent: AIVTotal * IEtcurrent: IETpool is 1.0000277778.

This value is now more than 1. In that case there is opportunity to pay interest to wallets holding IET in the proportion of their IET holdings (in this example purchaser’s wallet, merchant’s wallet and verifier’s wallet).

Purchaser’s wallet
499,500 STABC és 499,500 IET
STABC/IET ratio is 1

Merchant’s wallet
500,000 STABC és 500,000 IET
STABC/IET ratio is 1

Verifier’s wallet
250 STABC és 250 IET
STABC/IET ratio is 1

At a subsequent block the 250 STABC and 250 IET now available as surplus in the liquid pool will be paid in 1:1 ratio based on the held IET to each ’external’ wallets (purchaser, merchant, verifier).

III.
Scenarios

1. AIVcurrent is < 1 due to decreased price of ETH compared to the reference as fixed during genesis transactions.

Example – ETH price is decreased by 20% (current ETH/USD index is 20% lower)

In that case AIVTotal is still 10M (no new STABC has been minted as of yet).
AIVCurrent – Let’s go back to the transaction when 1M STABC was purchased from liquid pool in exchange for 1M ETH and stop here. ETH/USD index is then decreased by 20%. So our AIVcurrent will be 9M STABC available in liquid pool PLUS 1M ETH but the value of this 1M ETH is only 0.8M STABC. So overall AIVCurrent is 9.8.
In that scenario AIVCurrent:AIVTotal < 1

In case channeling in the above transactions as appear in section II.

AIVTotal slightly will increase as 250 STABC is shifted back to liquid pool, however the AIVCurrent:AIVTotal is still < 1 (9,000,250 STABC and 1 M ETH (only worth 0.8M STABC))
While IETcurrent:IETpool ratio 1.0000277778

Conclusion:
AIVCurrent:AIVTotal ratio multiplied by IETcurrent:IETpool ratio is < 1.

In this period interest payment will not occur. By using externally the purchased STABCs (generating transaction fees) and the improvement in ETH price may increase the AIVCurrent:AIVTotal ratio multiplied by IETcurrent:IETpool ratio above 1 and in that case payment of interests can be re-initiated.

Sidenote: consequently IETCurrent:IETPool ratio can never be less than 1 while AIVCurrent:AIVTotal ratio can be more or less or equal to 1.

1. Transferring STABC into liquid pool in case of a decreased ETH/USD price.

In such situation it is worth purchasing STABC from liquid pool and so there is a need for a compensating mechanism that likely prevents this to occur – in such case the 1:1 ratio of parallel STABC/IET transfer is changed as an inverse of the ETH/USD price decrease.

In case purchaser is purchasing STABC from the liquid pool while the ETH/USD price index is 20% lower compared to what was fixed during genesis transactions the STABC/IET ratio will be modified to 1:1.25. By doing that the purchaser will have STABCs locked in purchaser’s wallet because there will be no allocated corresponding IET to transact further while in the liquid pool there will be less STABC than IET. Technically to keep the 1:1 ratio let’s introduce virtual STABC (vSTABC) that will be burnt.

Consequences:

Let’s stay at the above example:

Liquid Pool
AIVCurrent:AIVTotal=0.98 while IETCurrent:IETTotal=1 (9M:9M). This is in the curent example is equal to 1M ETH and 9M STABC with the 20% decreased ETH value. In that case there was only one transaction made so far on the network and in the meantime after ETH/USD index decreased with 20%.

Purchaser’s wallet
1M STABC/1M IET

Purchaser is willing to purchase ETH from the liquid pool and to keep the fix priced STABC. If the purchaser was enabled to do this the purchaser would fix the nominal value decrease of the liquid pool asset. However with locking STABC in purchaser’s wallet with the inverse shifting of STABC/IET transaction ratio the following scenario may occur –

Presume that purchaser is willing to take off 0.5M ETH from the liquid pool. In this scenario the purchaser can do it by transferring only 0.4M STABC into the liquid pool however this transaction will cost 25% more IET. So the complete transacation looks as the below:
0.5M ETH is taken off of the liquid pool.
0.4M STABC/0.5M IET is transferred to liquid pool.
0.1M vSTABC is minted.

The status after this transaction is the below:
Liquid pool
0.98 AIVcurrent:AIVTotal ratio
9.4M STABC + 0.1M vSTABC
0.5M ETH (worth 0.4M STABC with 20% decrease ETH/USD price)

Now there is 0.6M STABC allocated to purchaser’s wallet and while the IETCurrent:IETPool ratio is 9.5M:9.5M there is no STABC allocated behind 0.1M IET and as a consequence 0.1M vSTABC is minted. It is important to recognize that transactions in and out to and from the liquid pool impacts IETcurrent:IETpool ratio diferently than transaction fees. So there are two types of transactions and this is an important difference.

Purchaser’s wallet
0.6M STABC and 0.5M IET – 0.1M STABC is locked, the IET:STABC ratio in the wallet is < 1.
0.5M ETH

In this scenario in case of an improvement of external environment (increased ETH/USD index) or with more STABC usage by the Network in case of paying interests those wallets that have <1 IET:STABC ratio will only receive IET + vSTABC (vSTABC is burnt then) until these wallets’ IET:STABC ratio reaches 1 again. Let’s continue the above scenario and assuming ETH/USD gains 20% compared to the value fixed during the genesis transactions.

Liquid pool
9.4M STABC + 0.1M vSTABC
0.5M ETH (currently is worth 0.6M STABC with 20% increased ETH/USD index).
1.01 AIVCurrent:AIVTotal ratio
IETcurrent:IETpool 9,5M:9,5M
AIVCurrent/AIVTotal * IETcurrent:IETpool > 1

Purchaser’s wallet
0.6M STABC and 0.5M IET – 0.1M STABC is locked, the IET:STABC ratio in the wallet is < 1.
0.5M ETH

And now after paying the interest:

Liquid pool
0.5M ETH (currently is worth 0.6M STABC with 20% increased ETH/USD index).
9.4M STABC but burnt 0.1M vSTABC
AIVCurrent:AIVTotal ratio is 1
IETcurrent:IETpool 9,4M:9,4M

So now again there is a balanced status – no vSTABC exists. In purchaser’s wallet as only vSTABC and IET were paid as interest and as vSTABC was burnt now the 0.1M locked STABC is considered as unlocked.

1. Low liquid pool STABC volume

In case demand for STABC is significantly increased this can decrease the available STABC volume in the liquid pool in a critical manner. Sequential mechanisms can be implemented to prevent such –

a. Transferring STABC to the pool in change of external asset (ETH). In case of low STABC volume in the pool such needs to be incentivized.
b. Shifting liquid pool/verifier transaction fee ratio.
c. Minting new STABC

Let’s assess these mechanisms and their impacts –

a. Transferring STABC to the pool in change of external asset (ETH):

In such case the similar happens as it was highlighted in scenario #2 above however with opposite mechanism. Under pre-determined liquid pool STABC levels when transferring STABC and IET into the liquid pool the 1:1 STABC/IET ratio will be changed to 1:x and this ratio will be <1. Technically more IET will remain in the purchaser’s wallet with minting virtual vIET. As the interest payments are proportional based on the IET + vIET holdings in external wallets (e.g. the purchaser’s wallet) this particular wallet will get a proportionally higher interest payment in case the purchaser can go without some STABC for some time (which is not determined and is impacted by the rate of interest payments). With the subsequent interest payments vIET will be burnt for real IET/STABC pair payments.

Example –
Liquid pool
9M ETH and 1M STABC (critically low STABC pool)
Let’s consider AIVCurrent:AIVTotal as 1
Let’s consider IETcurrent:IETpool as 1

Purchaser’s wallet 1
4.5M STABC és 4.5M IET

Purchaser’s wallet 2
4.5M STABC és 4.5M IET

Let’s consider that at this STABC pool level a 10% reward mechanism is implemented that can incentivize transferring some STABCs to the liquid pool. Purchaser’s wallet 1 decides to transfer 2 M STABC into the liquid pool and so 0.2M vIET will be minted due to the 10% reward mechanism. The status after the transfer is the following –

Purchaser’s wallet 1
2.5 M STABC és 2.5 M IET + 0.2M vIET
2M ETH

Purchaser’s wallet 2
4.5M STABC és 4.5M IET

In case AIVcurrent/AIVTotal* IETcurrent/IETpool becomes > 1 interest can be paid – let’s consider 0.2M STABC and IET. In that case the following payments can occur – 2.7/7.2 part to Purchaser’s wallet 1 and 4.5/7.2 part to Purchaser’s wallet 2. By presuming that the ETH/USD index has not changed proportionally Purchaser’s wallet 1 gained some benefit as the following status will apply –

Purchaser’s wallet 1
2.5 M STABC és 2.5 M IET + 2.7/7.2 * (0.2 STABC + 0.2 IET)
2M ETH

Purchaser’s wallet 2
4,5M STABC és 4,5M IET + + 4.5/7.2 * (0.2 STABC + 0.2 IET)

b. Shifting liquid pool/verifier transaction fee ratio.

In case of low liquid pool STABC volume with pre-determining certain levels the transaction fee liquid pool/verifier ratio can be increased – higher proportion of transaction fees can be transferred to liquid pool.

c. Minting STABC/AIV/IET
In case of low liquid pool STABC volume with pre-determining levels new STABC/AIV/IET can be minted. Let’s consider the following scenario –

Liquid pool
9.9M ETH and 0.1M STABC
Presume AIVCurrent:AIVTotal ratio as 1.01 and so the ETH/USD index is increased and in this current scenario let’s mean 10.1/10 actually
Presume IETCurrent: IETPool ratio as 1.01 and it means now 0,101:0,1

Due to the low liquid pool STABC volume 1M new STABC/AIV/IET is minted (trigger points and algorithm are to be determined). So how this changes the above status?

Liquid pool
9.9M ETH and 1.1M STABC
AIVCurrent:AIVTotal is 11.1/11!!!!!! So the ratio is 1.009 – decreased
IETCurrent: IETPool is 1.101:1.1=1,0009

So as a consequence due to newly minted STABC/AIV/IET the interest rate is decreased and then a new balance will be reached.

Liquid pool
9.9M ETH and 1.1M STABC
AIVCurrent:AIVTotal is 11/11!!!!!! So the ratio is 1 but AIVTotal starting from now is 11.
IETCurrent: IETPool is 1.1:1.1

1. Low STABC liquid pool volume together with low external coin (ETH/USD index) price.

There is a need to balance 2 opposed mechanisms -

Referring to scenario 2 above – Transferring STABC into liquid pool in case decreased ETH/USD price
Referring to scenario 3a. above - Transferring STABC to the pool in change of external asset (ETH)

These 2 are opposed mechanisms however with implementing vSTABC and vIET the 2 mechanisms work in parallel and leads to negative or positive sum. In case low external ETH/USD index the vIET/vSTABC balance is positive theoretically this may be worth transferring STABC to the liquid pool and so increase the liquid pool STABC volume.
In case vIET/vSTABC balance would be negative with such a transfer the incentive to do such is not that attractive.
In case of critically malevolent external price environment the additional 3b. and 3c. mechanisms can be activated.

IV.
Verifiers

Ethereum’s Casper like Proof-of-Stake mechanism can be an option and may allow to introduce a token that verifiers can hold and so proportionally can be rewarded from transaction fees.

Conclusion:
Theoretically the above concept may warrant a fixed value of STABC as originating from the genesis transactions. Pre- and well-determined algorithms are required especially for the compensating mechanisms to ensure safety of the liquid pool asset in critically borderline situations of external price volatility of ETH/USD or any other utilized asset indices.