In order to reach many more people and access the DECA Token more quickly, the DECA team is working fast to integrate it on Exchanges. This effort responds to the request of several users, investors and members of the DECA community to buy DECA in a more comfortable and faster way. Below, we present all the mathematical and economic information we have worked on to achieve this goal.
Generalities of the DECA Token
The first approach is the creation of DECA Token, which will eventually finance the development of DECA currency.
DECA token is already based on carbon credits, which will be registered before in OrbitDB: a decentralized database. Thus, it will have a social and environmental impact from the outset and give the token an intrinsic value, the carbon credits, apart from the security. [1]
The DECA token has the following technical developments for exchanges:
- Smart Contract based on ERC20 and audited by Quantstamp.
- OrbitDB, a decentralized database in which the carbon credits will be registered (IPFS address in the smart contract).
- Search Engine frontend for carbon credits.
- Wallet, based on Metamask.
DECA Lowest Price Model (Commodities Backup)
The following terms are defined in order to get an easier understanding of the base variable of our model:
- CCTS: which stands for Carbon Credits Total Supply.
- ETHTS: which stands for Ether Total Supply.
- DTS: which stands for DECA Total Supply and where DECA is the name of our token. This includes the token printed and the floating factor.
The DECA lowest price = CCTS / DTS as the backup percentage will be measured by the Carbon Credits Total Supply that will gradually increase in this semistable model proposal. This is the already backup held in intrinsic value by each DECA token in existence. With the ETHTS we get from the ICO we intend to gradually increase the CCTS and to fund some projects that ensure carbon credits income for their future integration. [2]
Carbon credits as a non-fungible token are not efficient as a medium for exchange:
* It Loses value over time (only if is not canceled). Example: a painting (that is unique or non-fungible) that gains value, some people consider this type of commodity as hard money. A carbon credit loses value with time and that is why Deca Lowest Price (HOW TO MAKE IT FUNGIBLE?):
DECA as a stable intrinsic value can be considered based on the fact that the calculated “Cabron Credits TOTAL Value” is a whole market capitalization, no matter what type of carbon credit it is, also, it has the advantage to be digitally signed and time-stamped on the exact price when it was retired. This is stored in our distributed database, that’s open and anyone can verify, also we provide the retirement certificate so that we ensure no double counting or someone else is going to use it.
Each DECA stored into our OrbitDB has a unique hash (sha256) that ensures no double counting on our platform and thus access to the retirement certificate file that the Backlog carbon standard gave us.
DECA Intrinsic Value now can be seen in two parts, DECAs are fungible, Carbon Credits Total Value is a whole market cap.
DECA Lowest Price (HOW DOES DECA MAKE CARBON CREDITS FUNGIBLE?):
DECA as a token with intrinsic value can be considered based on the fact that the calculated “Cabron Credits TOTAL Value” is a whole market capitalization, no matter what type of carbon credit it is, also, it has the advantage to be digitally signed and time-stamped on the exact price when it was retired. This is stored in our distributed database, that’s open and anyone can verify, also we provide the retirement certificate so that we ensure no double counting or someone else is going to use it.
Each DECA stored into our OrbitDB has a unique hash (sha256) that ensures no double counting on our platform and thus access to the retirement certificate file that the Backlog carbon standard gave us.
DECA Intrinsic Value now can be seen in two parts, DECAs are fungible, Carbon Credits Total Value is a whole market cap.
also can be seen as:
DECA Token Architecture
The DECA Token price mechanism requires its infrastructure that is an OrbitDB implementation, this includes the lowest layers like IPFS, multiple nodes with the same/similar configuration. The purpose of this document is to help to integrate the DECA Token intrinsic value which came from the DECA price mechanism named DECA Lowest Price [2] into exchanges, wallets, analytics and other DAPPs. As an example, we focus specifically on what an exchange needs to know.
In order to calculate the DECA Token intrinsic value (Lowest Price) we require the following variables taken from the price mechanism:
- Carbon Credits Total Supply (CCTS): This variable is calculated by getting the total value of the Carbon Credits that DECA holds, these are already stored and updated in the Carbon Credits database (also in OrbitDB), This value gets updated every 5 minutes by the DECA writing nodes. Note: Carbon Credits prices are evaluated over Ethereum Price for making the process more simple and easy to integrate.
- DECA Total Supply (DTS): This variable is calculated by getting the DECA total supply from the DECA smart contract (ERC20), This value gets updated every 5 minutes by the DECA writing nodes.
- Currencies Prices (Optional): This variable is requested and updated by the bitcoin average API, we include some currencies and cryptocurrencies prices which are BTC, ETH, LTC, USD GBP, CNY and EUR. This value gets updated every 5 minutes by the DECA writing nodes.
The DECA Price Mechanism depends on the Smart Contract and the Distributed Carbon Credits Database. These base variables are stored, distributed publicly and anyone can access to do their own verifications and other data analytics research. In an Exchange example, we are interested to get the DECA Lowest Price (1.0), in this case, we will require the Carbon Credits Total Supply and the DECA Total Supply that are already stored in their specific OrbitDB instance addresses.
There are two types of nodes that our DECA Distributed Database (OrbitDB) has, these are Writing nodes and Reading nodes. In order to fill these Distributed databases, the DECA team runs and manages specific programs that help us to write the data information, these programs run over writing nodes, meaning they have the right to add or remove data to these collections/databases. We can say that their main task is not only adding carbon credits but also to get System Data Resources as shown in Image 4.
In general, the writing nodes get the resource, integrate the data, and verify/control the data with the second instance of MongoDB (useful for fast testing and when the OrbitDB reload needs some verification). There is not only one but multiple nodes that handle these errors and fill the task, so if one node is unavailable or not working properly a secondary will do the task with a preconfigured time delay.
The second type of node our DECA Distributed Database (OrbitDB) has, is a Data Replication and Read node, by connecting to the official DECA Distributed Database respective addresses it is possible to access the multiple variables and also helping the distributed system to add a node.
The current problem with a reading node is that each time it reloads, it needs to download again the database, also it is hard to monitor and serve the data for specific types of applications, regarding these issues, the DECA team propose the following model in Image 6. This type of node inside a container helps to solve these issues. Currently, under development with a Data Control Program, MongoDB instance and this data served as an Application Programmable Interface (API), everything integrated into a Docker Container for fast deployment and Continuous integration, will be useful for developing all type of applications and integrations with the DECA Price Mechanism, DECA Lowest Price and even ton of CO2 hold by each DECA in a near future. In general to ensure faster developments while it also helps us to be more decentralized.
DECA Integrations
Currently, we have already a basic version of this implementation which is getting used by the deca website in order to create the charts and fill some indicators:
- For the DECA Price (CP) variable taken from https://api.deca.eco/decaprice, here is a collection data example:
2. For the Carbon Credits Total Supply (CCTS) variable taken from https://api.deca.eco/decaccts, here is a collection data example:
3. For the ETHER Total Supply (ETS) and the DECA Total Supply (DTS) variable taken from https://api.deca.eco/decageth, here is a collection data example:
Note: It is important to have the dates matching in order to process them and also make the proper charts and indicators.
Following the Exchange example, and with Equation (1). We Can get the DECA Lowest price from the 2. and 3. API outputs (CCTS/DTS), in this case, as follows :
Now, if you want the specific price at that specific time in USD units can be used the 1. API (“ETH”: 342.2584) output as follows:
Note: that some exchanges can use their own conversion rate or another historical conversion rate. our API takes as base ETH since it’s the one that we use to buy and retire the Carbon Credits on a specific timestamp.
References
[1] https://deca.eco/docs/Deca_Lightpaper_v1.4.pdf 2020–09–16
[2] https://deca.eco/docs/DECA_Price_Mechanism.pdf 2020–10–01
