Krakin’t Miner Version 2.0 — The new Asynchronous mining approach

If you are an advanced user, you may skip the text and go to a verified contract on Etherscan. The address is 0xe24F992D6E34357cF67D741769eAAD7bC44E32DD

Connect to Web 3 and use the mine to deposit and getReward to withdraw. If you don’t have any tokens, use the pre-sale contract.


The pre-sale is currently under development and will be the next step to complete after the new version of the miner is completely covered.

Why the new version?

The old contract became obsolete with the controlled inflation variable, which prevented users to deposit more than 100 KRK tokens at once. Although the initial design was good, we weren’t able to predict exactly how it would reflect in the real-world scenario. Instead of fixing the contract, we have done something that (most likely) nobody else did before. We used the power of Krakin’t token, that is also a micro-framework, and simply ran an update, directly on the immutable block-chain… while doing a live and direct snapshot of the old contract. It is in a direct link to the token rather than acting as a wrapper, and this is how it is unique.

What are differences comparing the versions?

We have simplified the mining even further, but had to add some new mechanisms on top of the simplified version to be able to control the supply. In the old version, we were using the amount of minted tokens to increase or decrease the mining difficulty. Although the design was good, it was difficult and expensive to maintain it directly on the block-chain. To avoid such difficulties, taking a step backward and issuing a new miner was the best and the simplest option.

Difficulty is now calculated by registering the amount of time that passed from the moment the contract got initiated. It is also registered per account, so the accounts that made their deposits early will get the best mining-rate. This means that we track the mining difficulty per user. However, should the user add more tokens or withdraw the mined tokens, difficulty becomes greater. Furthermore, to control the overall starting difficulty, each time any user withdraws tokens, we increase the global difficulty by a small amount. It may sound a bit complicated and confusing, however, it isn’t. Assume two difficulties instead of one. One is the global difficulty, and the other is a difficulty assigned to each user. So, this is what happens. Whenever a user deposits or withdraws their tokens, we take the global difficulty, calculate the amount of time that has passed since the miner got deployed, and assign this new difficulty to a user. Now, when a user withdraws tokens, the global difficulty becomes slightly higher. If users were withdrawing tokens every 12 seconds, in 20 years, they would reduce the earning from 2% per day to 2% per year. Therefore, with this design, difficulty is asynchronous. The advantage of the Bitcoin or other currencies that have their own chain is that we can update the state of the automaton for everyone, without changing their earnings. However, we cannot do this using smart-contracts. Smart-contracts are simply forcing us to either waste a lot of GAS updating the tables for everyone, or make it asynchronous. Perhaps this is where Ethereum should take a weak hint solving the scalability issue…

To the best of our knowledge, asynchronous mining or staking is also something new that has not been done before. Please comment if we are wrong with this assumption.

OK, so what if someone constantly tries to earn tokens exponentially by making frequent withdrawals and deposits? We have added more statistics to a miner usage, and have added prevention functions to penalize such users. Furthermore, we can manually adjust difficulty variables too and keep things on the right track.

The UI part will most likely stay exactly the same since we have kept the original function calls that version 1.0 used. This is our next step, and a brief announcement will be made on Twitter and Telegram.

We sincerely hope that this simplified design will last much longer than the version 1.0 as we are looking forward to making the official pre-sale UI and getting the Token exposed to communities. However, should anything go wrong again, we can always re-deploy with a live snapshot.