A little background on our just deployed token, its design and some other stories
Due to the large availability of source codes of ERC20 tokens, launching and branding a new coin is something very easy these days: you set the name, the symbol and the total supply and you’re ready to go!
Is it, really?
In fact, no.
People often disregard the key difference between the ‘entity’ token — the thing that you transfer and store in your wallet — and its significance in terms of utility and economic expression.
This is easy to demonstrate. Think about Ether. On one side, there is the ‘real’ Ether, the Ether you trade and buy things with; on the other, you have the Ether that is mined in any Ethereum testnet, such as Rinkeby. You can’t buy anything with Rinkeby Ether, but you can buy pretty much anything with mainnet Ether. There is no tecnhical difference between real and ‘test’ Ether. However, while the first is worthless, the second is worth around $400 each.
How can we explain this?
Simple: the value of Ether is connected with its utilities and, therefore, supply and demand. While ‘test’ Ether is used only for testing purposes, ‘real’ Ether is used to pay for mainnet gas + be traded with basically any other coin (crypto or not)+ be used as a mean to buy things.
While the sources may be the same, the utilities are widely different.
It is not different with tokens. The value of a new token is not necessarily related with its code, but rather connected to its utilities and the various economic aspects of its existence.
People asked us a couple of times why we took our time to deploy our token, being there so many standard sources available to download. The answer couldn’t be more simple: we needed something secure to fit perfectly the economic model we designed for the NIC.
1. Ballast Interactions
NIC is one of the first token, if not the only, to be connected to a ballast DAO.
Why connecting a token to a ballast DAO?
Iconic is building an entire economy of new projects and companies to be all living under its ecosystem. We want to launch projects, trade their tokens/assets and interact with them during their whole existence within Iconic’s ecosystem. And we wanted it to happen quickly, so we could bring to the market our way to have ICOs running: with Assurance.
But simply creating a new coin wasn’t enough to the purpose of establishing a whole new environment. Well, at least to build a strong one.
We then came up with the idea of building a decentralized autonomous organization (DAO) for the sole purpose of being a ballast to support our NIC coin and this whole new economy we are creating.
This DAO will not be controlled by Iconic by any mean. The DAO will be fully operated by the NIC owners, that would be able to decide by themselves what to do with the ballast resources. They will be able to get out of NIC if they want to, or at the same time keep with the coin to use the fund in order to make it even stronger.
In a certain sense, the idea behind the NIC ballast DAO is like delivering to the NIC owners the ability to be a decentralized central bank, so they can control the main aspects of the token economy. Well, except for one: inflation. As we hate inflation, the NIC will be always limited to its original supply with the possibility of deflation.
For this to be possible, our team took a loot of time with tests regarding the possibility of an external smart contract (the ballast DAO contract) handling normally the NIC.
Finally, after we were sure that our economic model (token-fund) was entirely viable, we prepared our NIC source to have it done in the future.
2. Freezing Rules Automatically Set
We think that stakeholders must not only say that they believe in Iconic’s project but act accordingly.
It would be very easy for a partner or advisor to afirm to the whole community how much they believe in the project and then sell every token they own the first day it is publicly traded.
Having this in mind we set a freezing rule for every project stakeholder. The partners must set the example, so they will have the longest freezing period. Advisors and community members are also included in this rule, although for half of the freezing period (lucky them!).
This was a key element of our offering: stakeholders should really believe in the project, as we did not have on the table any immediate reward.
For all this to be done, we decided to write this in our smart contract. The freezing and unfreezing shouldn’t be manual, otherwise we would have control to (re)define situations we shouldn’t be controlling.
Our NIC contract came to live, then, with every freezing rule previsouly set, so everyone would be sure that our promises would be kept in any case.
This also took some time of our time: they needed to be sure that everything would be happening as designed. Imagine how awful would be a token that is by mistake frozen foreven…
3. Gas Optimizations
Finally, the NIC source code was optimized so its functions would be as cheap as possible.
This is something that some projects sometimes miss: how much Ether would be needed to run regular transactions. Imagine if a token costs as much as 50% more Ether than necessary to run transfers, and then multiply it for millions of transfers: it is simply Ether thrown down the toilet.
Having the code optimized without compromising its safety, we ended up with a token that is not expansive to transfer and handle in general.