Dragonereum: Why you will want at least one DRAGON?
by hipster on 2018-11-28
Today is special day. After one year of development Dragonereum will be born. For me this is a very important milestone and in this post I will explain you why.
Last time I dedicated the whole post for some blockchain system 3.5 years ago. That was also very special day: We launch Ethereum. Those post was not very popular. Nobody those days give a shit to the most important developments. There are a lot exciting thoughts there. There are quite precise speculations which are still relevant. But one thing must especially catch your attention: DApps Economy. This list was crafted by me during research before Ethereum genesis. Only two of apps from this list is now (somehow) operational: Augur and Digix. With deep respect to both projects we hardly can say that they are successful in some sense. Further I am going to discuss what my criteria for success expectation of dapps, discuss some examples and demonstrate that we are still nowhere.
Still no killer dapp
Here I am claiming that three and a half years since inception we still fail to deliver one example of rrrrreally awesome dapp.
A have about 30 ethereum tokens in my portfolio. In order to make this decisions about 3000 projects was accessed by me (economic protocol and implementation) for the last 5 years. During this way I defined 5 very simple criteria for success expectation:
- Openness and verifiability since inception
- Purposeful, value-add distribution
- Rich internal economy with feedback loops
- Fully working app with retention signals so loved by VCs
- Harness full power of blockchain technology
I will dedicate standalone post to discuss this criteria later. But because less than 2 hours left before dragons arrive I will throw you some examples. The following project are loved by me because of early signals of (4) and I do have them in my portfolio. Yet: - DAI: Really useful thing, but MKR fail to meet (2) - REP: Check funded amount in ETH, compare against current cap in ETH and you will see that this projects do not satisfy (2). Also (4) is not here yet as I regularly use this app. - MLN: No (2) and (4) - MANA: No (2) because founders too greedy (2⁄3) and still no awesome VR world (4) - SPANK: No (2) because founders too greedy (2⁄3) and (3) because cybernomics it too weak
I can continue, but you catch the idea.
Why I decide to help found Dragonereum?
Investing in Ethereum ecosystem I:
- Tiered of greed
- Tiered of stupid desire to bring something to the masses that was not intended for them, e.g. Ethereum.
- Because last years I see how rush harms products
- Because I saw how willingness to solve legal problems first which are not exist yet (in reality either an unwillingness to meet a risk or a desire to suck the govs because of fear) is a good way to kill key, revolutionary product features
- Because I believe that blockchain gaming is the best use case for technology
So when I met guys from Dragonereum during hackathon in Minsk with fire in the eyes and real ability to do something great I decided that this is a good chance for me to prove for myself that my decision to invest in Ethereum during genesis is not a complete bullshit.
Meet Dragonereum
- Openness and verifiability since inception
- Purposeful, value add distribution
- Rich internal economy with feedback loops
- Fully working app with retention signals so loved by VCs
- Harness full power of blockchain technology
During game development I do believe we solve some really hard problems such as onchain EVM randomness. Also we have create brand new branch of science: digital genetics. But it is better for you to reason yourself reading our whitepaper.
But now I will better elaborate on economics because that is my area of expertise.
About GOLD cybernomics
Cybernomics is a non-existent yet branch of cybernetics. It explores behaviour of a systems in in which every signal of any agent to any agent can be proven for everybody. An art of cybernomics is to design an abstract systems using free market principles and game theory which can provably sustain and evolve.
Dragonereum’s cybernomics stems from willingness of gamers to evolve better DRAGONs in order to earn more GOLD.
The more DRAGONSs are fighting the more expensive is GOLD to earn from Treasury. Treasury is guaranteed to be replenished using players GOLD for incubation through embedded genetics: stronger DRAGONs are likely to earn more GOLD. This basic feedback loop stimulates GOLD internal liquidity.
Cybernomics programs population control as well. DRAGONs are very cheap to generate at Genesis stimulating aggressive growth in order to become dominant species in Ethereum universe. Then DRAGONs are incentivised for rapid population growth as available for players supply of GOLD inflates faster than deflation as result of environmental cost of incubation. So like in real world evergrowing population is limited by available resources. Once environmental resources become more scarce deflation starts dominate over inflation thus guarantying store of value for gamers who earn more GOLD.
There is embedded economic measure to ensure that dragon population growth will be limited by target game design constraints. Our simulation shows that if players will use basic game mechanics using only 100k dragons it is highly unlikely that Ethereum foundation network will be able to compute enough even counting for gas limit growth according to the Moors law in the following years. Hence after 10000th dragon will be born half of incubation costs will be permanently burned in order to cover the costs of environmental harm for all players. Given that cost of incubation is constant 1000 GOLD, and 500 GOLD will be burned every incubation relative price of every next incubation will be higher thus limiting theoretical supply at the level of 109999 DRAGONs and 500 GOLD. Nonetheless this theoretical bound is likely can not be reached.
Enjoy our game and exploit the full power of web3.
original-cid: QmXeNFw7iWei2Ho3nvsVwk7isZH5eNveSCo7LmwpZreDz8 signed-from: 0x7C4401aE98F12eF6de39aE24cf9fc51f80EBa16B proof-of-existence: 0x6e72a9882d1b02e9e18a38bd5c3ad9c42a2ec63647879b7bd7d08aa610b9034c