Cryptocurrency of the 3rd Generation: Lessons Learned

Disclaimer: the author has designed and implemented the subject and remained as authorship, copyright and other intellectual property owner, but actual current operator of a coin is a third party company which is not connected to the author anymore. So, it is not a promotion of the coin which turned out to be another scam.

Intro

As once pointed out by Ryan, the President of Energi Core Ltd. (not the same as the “Energi Core” team), Energi Gen 3 is not only a third generation of Energi (NRG) coin, but also a third generation of cryptocurrencies in general:

• the first generation was Bitcoin — the basic blockchain model,
• the second generation was Ethereum — programmable decentralized logic via smart contracts,
• the third generation is Energi Gen 3 — smart contract platform with heavy upgradeable governance consensus built on top of generic smart contracts.

What is inside the Energi Gen 3 Consesus

The features below are listed in comparison to Ethereum Constantinople hard fork as Energi Gen 3 is based on Geth 1.8.27 codebase.

1. Secure Gen 2 coin Migration without time limits.
2. Upgradeable Governance smart contracts.
3. Simple Proof-of-Stake with Denial-of-Service protection and Delegated Proof-of-Stake feature.
4. Masternodes to ensure network stability.
5. Treasury for decentralized budget.
6. Governance voting system for decision making.
7. Dynamic Block Rewards.
8. Dynamic Checkpoints to recover from network splits.
9. Dynamic Blacklists & Coin Recovery (aka EBI features).
10. Consensus zero-fee transactions.

Additionally, there are official Public API endpoints and DApp frontends.

A little background history

The author’s initial contribution to Energi was its Gen 2 with a secure Proof-of-Stake and some other latent features. The features to be described in comparison to Gen 3.

It must be mentioned that Energi Core had contracted another party in an attempt to create a smart contract platform in period from Nov 2018 till May 2019, but that initial attempt neither had required features nor could handle a production Masternode network. Unfortunately, it was not feasible to quickly “repair” and launch. That explains why the official roadmap shifted for 3 quarters.

As the author has invested his time into the coin, he could not let it fail with Gen 3 upgrade. So, the author started everything from scratch in Jun 2019 and produced a Minimal Viable Product (MVP) by the end of Aug 2019 with all essential features being ready. That went so fast because the author was the only person on the project to define requirements, design the architecture and implement that in code.

The original author’s Energi Gen 3 source code is available at GitHub: https://github.com/codingfuture/orig-energi3

The Software Requirements Specification (SRS) is also available: https://github.com/codingfuture/orig-energi3/releases/download/v3.0.2/Energi.Gen.3.SRS.v1.6.pdf . Unfortunately, a Business Requirements Document (BRD) was skipped to compress the timeline as Energi Core had not provided any input until late Dec 2019 when a change for 1,000 collateral Masternodes got requested.

As a fun fact, the author has also given the name of “Energi Gen 3” and defended that while there was a strong preference to market the product as “Energi v3” instead.

As a side duty beyond the main goal of Gen 3 development, the author had to act as Director of Technology in the community to build the current Energi Technology department from scratch by hiring, training and setting up processes.

The dark side of Energi which was publicly revealed in several interviews is that “Xenophon’s Cyrus the Great” is a holy handbook of the community. Internally, it is considered as a serious disrespect of Tommy the King to have own opinion on any subject. All contributors are no match to the King, they cannot negotiate any terms of cooperation, and they must blindly trust the King’s benediction and gratitude. As participation in such state of affairs was beyond good and evil for the author, it was clear that Gen 3 was going to be the last project done for Energi. After a successful Gen 3 launch, the author stepped down from the active position in the community. By a coincidence, the fun with Energi network started the next day, but the “King” refused any assistance as he was interested in network issues for a scam plot to keep deposits closed apparently. That’s just to explain why the author has not continued to maintain the project.

Feature: Migration

The base for Migration was the original idea of Energi Core to embed Bitcoin-based Gen 2 snapshot inside the Genesis block. Unfortunately, that would mean that a final software release could be created only once Gen 2 blockchain is stopped, all sorts of logistical and coordination issues would appear and a large bulk data would need to be put inside the source code.

So, the author decided it would be more cool to deploy Mainnet with Genesis in advance and let the network wait for block #1 with a special migration transaction.

Details of the process:

1. Gen 2 blockchain got halted with an invalid dynamic checkpoint at a block announced in advance.
2. The tail of Gen 2 blockchain got nailed by another dynamic checkpoint to ensure the same view across all nodes.
3. Then a snapshot at specific Gen 2 block got created with a JSON-RPC command. It was published.
4. Gen 3 migration miner node got launched with a special parameter pointing to the snapshot file.
5. The migration transaction is a one-time smart contract initialization call inside block #1.
6. Anyone could repeat the snapshot in Gen 2 and verify the Gen 3 migration transaction with a console or JSON-RPC command.
7. Gen 2 private key has to be used to sign a special message to proof ownership of the coins to be able to claim them into Gen 3 account.
8. There were many ways to claim coins: via Gen 2 Core Wallet directly, via private key dump and different modes of import inside Gen 3, via a WebIS dApp, etc.
9. There is no time limit for claiming, and any coin owner can do that by self.

Caveats:

• Ethereum default P2P message limit is 16M while block message limit is 10M. The latter got lifted for the migration block, but there is a high risk of running out of the limit what requires better mitigation techniques. Luckily, Energi Gen 2 snapshot was much smaller.
• Transaction size limits are much less, but the migration transaction is not broadcasted.
• The standard block gas limit is not enough for such large call. A dynamic gas limit was introduced.
• To ensure that it would work in Mainnet, the Gen 3 Testnet launch had both Gen 2 Mainnet and Testnet snapshot data combined.
• The initialization also sets blacklisted addresses from Gen 2.
• Availability of Gen 3 Public API allowed to claim coins directly from Gen 2 software, but a little trick with ephemeral key was necessary to create and sign Ethereum-like Gen 3 zero-fee transactions without re-implementing that in Bitcoin code.
• The Migration smart contract is initialized with the default balance of 100 NRG inside Genesis, but then the balance is set to correct value inside migration block #1 finalization logic based on the total coins available for claiming. The balance is used for initial DPoS staking by a migration miner.
• Unlike a regular miner, the migration miner never creates a block ahead of time and may also delay the block for up to 15 seconds to lower the difficulty. This is what ballast staking is.
• The migration transaction can be done only by a special migration signer address.
• Only P2PKH addresses are supported while Multisig and P2SH cases require a special recovery procedure.
• Obviously, there are very many other fine details.

Feature: Genesis smart contracts

There is a list of 13 predefined consensus smart contract addresses (SRS SC-13). Those addresses are hardcoded, and they also give immediate understanding of their relation to the Governance system. There are also other predefined addresses used as system faucet and as initial actual implementation of the upgradeable features.

By default, Ethereum assumes a contract creation when no destination account parameter is set while a new contract address is derived to some pseudo-random value in deterministic way. So, the contract creation logic had to be updated to allow specification of a custom address at Genesis time.

All consensus contracts are upgradeable via Governance voting, except for the Migration contract. Therefore, there is a universal GovernedProxy contract implementation which manages all proposals and upgrade procedures for a specific instance while the default handler forwards calls and amounts to an actual implementation. Such approach is gas hungry, but is quite robust. There is also a GovernedContract base for actual implementations to properly manage upgrade procedure security. The majority of contracts have a standalone secure storage to allow logic upgrades without data copying loops. That also consume gas on calls and blows up EVM memory usage.

Genesis gas limit is also lifted. So, the normal block gas limit starts only at height 2 after the migration block.

Caveats:

• Externals tools may get confused by such non-standard creation transactions.
• The upgrade procedure is still quite tricky due to large gas usage, if there is large data inside a contract implementation which cannot be deduced from a dedicated storage contract.
• There is a significant computational overhead for every block which has to be taken into consideration.

Feature: Proof-of-Stake

Gen 3 Proof-of-Stake (PoS) is based on the idea of Gen 2/PIVX kernel which is based on Peercoin in turn. In such idea, there is no accounting, ordering or collaterals. The block mining is very similar to Proof-of-Work, except that only time can affect generated hash. Such PoS hash is matched against a classical difficulty target. Those are compared as 256-bit integers, or more commonly known as “comparing leading zeros”. A special stake modifier as a source of entropy and stake maturity age are added to make it practically impossible to predict a winning stake in the future. That prevents stake mining attacks.

The original Gen 2 PIVX-derived stake modifier had all sorts of flaws what was described by the author in an article shortly after Gen 2 launch back in 2019: https://habr.com/ru/post/442862/ (in Russian). A new strategy was created to use the oldest block root state hash and the youngest block coinbase inside the stake maturity period of 60 minutes to make the stake modifier practically unpredictable. It was also tested in cancelled Gen 2 hardfork to mitigate stake mining problem. At the end, 50 to 75 percent of stakes were mined due to the shortsighted cancellation.

Another problem appeared in available stake weight calculation inside the maturity period as it was desired to allow to operate an account as usual without loosing chance to stake. In Gen 2, the stake maturity was applied to individual UTXOs, but Ethereum has an account model. So, an idea appeared to use the minimal untouched balance during the maturity period. That required to find out the minimal account balance and subtract all stake weight used by the account for block generation during that period.

Now, we come to “stake weight” — it is the amount used to generate a block or available for such action. The account balance is used to divide the PoS hash 256-bit integer before matching against the difficulty target. So, more funds — more chance to generate a block. Very often, only a fraction of that balance is required to go below the target. So, only that fraction is used as a “stake weight”, and that gets recorded in the original block Nonce field. So, it is possible to quickly lookup the last blocks to sum up total used weight by the staking account.

Another important aspect is that every block has to be signed by the staker account to prevent any block forgery flooding the network in Denial-of-Service attacks. The staker account is recorded in Coinbase while the signature is recorded in the additional data.

There is also Delegated Proof-of-Stake (DPoS) for smart contracts which can specify another account which can sign blocks on behalf of them via a conventional method. That opens a wide possibility for applications, but the main purpose was an initial bootstrap of the blockchain. This DPoS is used by a migration signer to create the migration block and the first 60+ minutes of blocks on behalf of the Migration contract. That’s because stakers need to claim their funds first and then wait the maturity period before they have a chance to generate a block.

Another topic is the difficulty algorithm as it needs to be very reactive to a situation — based on Peercoin/PIVX research. In short: the block target is 60 seconds, there is a minimum of 30 second block interval, there is an hour period for block target enforcement — time gap without difficulty change, the difficulty changes at generation time depending on current block time (not the previous), the difficulty may progressively jump up to around 17 times if block is too early or drop down around 17 times if block is too late.

Denial-of-Service (DoS) protection is another important part compared to Proof-of-Work where chain split attacks are much more difficult due to computational resource demand.

Staking requires an unlocked account. Therefore, unlocking for staking only was implemented. The private key may still be dumped from process memory, but that is much more difficult than just sending funds to another account via unlocked console. The most secure way is to use DPoS. Although, the DPoS feature is not marketed in fear of staking pool centralization.

There are lots of fine moments partially covered on seven dedicated pages of the SRS. It is definitely difficult to understand without much background knowledge. It would require a separate large article to explain. Check the Gen 2 article.

Feature: Zero-fee transactions

Transaction fees serve both as interest for block miners to include transactions and as a protection against Denial-of-Service flood attacks.

However, there are several types of consensus transactions like initial coin claiming, Masternode heartbeats, invalidations and checkpoint signing. There is an advanced transaction pool feature to check that any given zero fee transaction is valid and can be successfully executed. There is also a rate limit to avoid intentional abuse.

Altered block miner ensures that the first half of available block gas limit can be used by zero-fee transactions as they are critical for consensus operation.

Feature: Masternodes

Masternode (MN) functionality is based on three main parts: MN Token ERC-20 contract for collaterals, MN Registry contract and MN Service.

Management of funds is intentionally isolated to reduce risks. The registry had to be implemented a way which can handle at least 10,000 registered nodes. Each MN has a 2 hour window to send a heartbeat at a dynamic period relative to the current MN count. If the heartbeat window expires then MN gets inactivated and has to be re-announced at regular transaction fee.

There is also a Proof-of-Service functionality when a deterministically random MN has to verify another MN to check if that serves the network. There is a predefined number of checkers per MN payout cycle. If more than half of checkers invalidate any given MN then its reward goes to the Treasury instead. An invalidation collusion is possible, but there is no practical gains for that.

Masternode service has to be enabled on a node via configuration. Masternodes serve the network, send zero-fee heartbeats transactions, sign dynamic checkpoints also with zero-fees and perform Proof-of-Service validation of target MNs.

All MN operations are completely in-chain. That solves original Dash MN implementation issue of MN network state and related governance voting not being reflected in blockchain anyhow.

One of the latest hysterically requested features was so called auto-collateralization for MN collateral amounts which had to be enabled by default. The idea is to automatically add additional coins to MN collateral, if MN owner account is used for staking.

Caveats:

• Whole functionality needs to avoid loops as much as possible, and it needs control remaining gas, if loops are present.
• This is the most complex smart contract which is worth a couple articles.
• The auto-collateralization features is a major security problem which encourages users to keep MN owner keys unlocked in memory.
• The auto-collateralization enabled by default drains amounts available for staking and leads to network instability overall.

Feature: Treasury

The Treasury is rewarded at superblocks (Dash legacy), and it is a sink for various consensus fees, Migration DPoS block rewards, invalidated MN rewards, etc.

Anyone can raise a budget proposal for a specific amount for MN owner voting. Approved proposals get payed out proportionally to their amount until they are fully paid. This functionality is triggered on every block.

The behavior is absolutely different from Gen2 / Dash budget voting, where only approved budget got emitted and paid at superblock in proportional parts, if above the superblock limit.

Feature: Governance voting

In idealistic way, anyone can rise proposals of various types at a specific fee. For example: upgrade proposal at 10k coins, budget proposal at 100 coins, blacklist proposal at 1k coins, etc. Then MN owners may vote for accepting or rejecting a proposal. Voting requires fee to cover gas.

MN vote has a weight equal to MN collateral amount. Only MNs active at proposal block are eligible for voting. This is done such way to simplify protection against vote cheating via reusing of the MN collateral. There is a proposal-specific quorum based on the total active collateral weight. There is also a protection not to allow the total active collateral to go below a half of the ever recorded total collateral weight.

Every proposal also has a deadline for voting. Once the deadline is reached and the quorum is met then simple majority is used to decide. Any voting can be finished ahead of the deadline if an absolute majority of 51+% percent accepts or rejects the proposal.

However, the world is not ideal and Energi Core has two backdoors: one is an emergency consensus upgrade feature which allows to create immediately approved upgrade proposals, another is zero-fee blacklist proposals designed for rapid blocking of scammers. Both cases are justified though.

The third “backdoor” is an ability to organize a required MN voting weight for any proposal.

The above aspects may be considered as a centralization issue, but once they are misused any trust to the coin may vanish. Unlike with territory governments, coin owners would be able to switch to any other alternative coin. So, it is not that much of an issue so far.

Feature: Block rewards

Many may wonder what’s so new here, but it is a know-how feature which is based on smart contract execution as a special block finalization logic.

There is a general IBlockReward interface which has getReward() and reward() methods. Initially, there were five contracts implementing that:

1. StakerReward contract.
2. BackboneReward contract.
3. MasternodeRegistry contract.
4. Treasury contract.
5. Overall BlockReward contract which acts as registry for all other implementations.

As a part of the block finalization logic, a call against the fifth contract is performed to collect the total block reward amount. Then a consensus transaction is created to execute the reward() method with a given total block reward amount. Internally, that creates a myriad of internal calls touching almost all consensus contracts.

Caveats:

• The consensus gas must not be limited by the block gas limit.
• The consensus transaction needs to be reflected in a block for simpler integration with third-parties.

Feature: Dynamic Checkpoints

Dynamic Checkpoints is an important feature as a matter of last resort to ensure network integrity which may easily run into splits due to low computational difficulty of building Proof-of-Stake chains and interference from a mandatory Denial-of-Service protection. The original implementation was introduced by the author in Gen 2. It helped to ensure that all nodes are getting onto the best chain after a hard fork from Proof-of-Work in Gen 1.

This is a truly a Chicken and Egg problem. Dynamic checkpoints are also in-chain, but they are supposed to affect nodes which potentially run on a side chain. So, the peer-to-peer network protocol was extended to support dynamic checkpoint distribution.

Originally, it was planned that checkpoints are proposed at some fee and then Masternodes automatically sign the checkpoint if they are on the correct chain. Then all nodes would be able to decide if enough of known MNs confirmed the checkpoint is valid to enforce that.

That was implemented, but the logic got changed to allow checkpoint proposal only by a special account under Energi Core control. At the moment, all nodes immediately obey any checkpoint signed by such account.

Unfortunately, Energi Core has heavily misused this feature after the author left the project. The original target was to have no more than 100 checkpoints until the functionality is redesigned, but they decided to create a checkpoint every 20 minutes. That quickly exhausted design limits on various levels.

Feature: Dynamic Blacklist & Funds Recovery

This is possibly one of the most controversial features, but it has proven to be useful against scammers, and it can help to recover personal funds when private keys are lost.

The original feature was introduced by the author for Gen 2. It was a centralized spork-like feature which allowed to issue blacklists for addresses with some expiration time. Gen 2 blacklisted addresses got embedded into the migration snapshot as hardcoded blacklists which can only be recovered, but not claimed.

In Gen 3, blacklists are proposals made against the Blacklist Registry smart contract. It requires MN owner voting to enforce the blacklist. After a blacklist proposal is enforced, it is possible to make a revoking proposal for the blacklist or to drain the blacklisted account into a special treasury-like compensation fund. Another proposal against the compensation fund is required to distribute any drained amounts.

Obviously, blacklists make no sense in fight against scammers unless they can be immediately enforced. So, blacklist proposal enforcement is in effect even during voting if there is 2:1 or better ratio of approved to rejected votes. However, that is still not enough. So, blacklist proposals made by a special Energi Bureau of Investigations (EBI) key get enabled immediately when the proposal transaction is broadcasted and is effective for 1 hour. EBI account is exempt from the proposal fee.

During the first migration days, this had helped to fight against a known Energi antagonist, so called Bashful, who got quite upset BTW. Spoiler: Bashful identify is also known, and Bashful knows that it is known, but he is curious where he has failed.

Caveats:

• Even though Bitcoin and Ethereum addresses are created a different way, they both use 20 bytes for identification. That answers how Gen 2 addresses are recovered with Gen 3 blacklist features.

Feature: WebIS — Web Information System (aka Nexus)

Once Gen 3 MVP got ready, it became obvious that a headless/console node is not something what the majority of end users would like to see. The author in role of Director of Technology had launched a Gen 3 Web Information System project with codename WebIS. Later, Energi Core gave a “Nexus” name to that.

WebIS supposed to become a dApp which covers all extended features and to take a position of a general system portal. The actual project was developed by a dedicated web team. Unfortunately, the target has not been reached yet.

WebIS heavily depends on extended JSON-RPC API which are exposed in Energi Core Node through highly available Public API.

Caveats:

• Blacklisted accounts can still receive funds, but they cannot transfer anything or mine new blocks.
• There is also a whitelist created from predefined consensus smart contract addresses and their current implementations.

How the migration has gone

Everything went exactly as planned except a small forgotten protection — Mainnet Genesis timestamp was intentionally put too far in the future to protect against accidental launch in the very beginning of the project. That was forgotten as no special comment was added. Everything was tested and code reviewed, but this moment got out of attention. So, a quick v3.0.1 release was necessary.

After some time, it was noticed that Masternodes start to heavily invalidate each other. There is a complex issue with a known solution. So, another v3.0.2 release was necessary to “temporary” disable the Proof-of-Service functionality.

After that, the network had successfully operated for one week, and it was clear that there are essential things to cover for v3.1.0 release. However, the author left the project.

In general, for such complex project, it is really considered a success. It is especially a success in comparison to much simpler, but problematic changes other crypto projects have run into.

Lessons learned

1. The first and the major epic was Genesis timestamp. It could be noticed in pre-release code review, it could be even simulated by launching an alternative mainnet with any different parameter (e.g. key), but happened the way it happened.
2. The second major issue was failure in Proof-of-Service connectivity on scale due to the max connections limit. It happened that the problem was not uncovered in testnet while unit tests could not reveal the problem. However, it could be foreseen and that is a mistake of the author. The default max connection limit also causes network clusterization with broken interconnection triggered by some chain splits and DoS protection events.
3. The third problem was caused by uneven staking weight what led to quite disruptive difficulty. The author has noticed the problem, but it was compensated by Migration contract DPoS staking as a ballast to ensure steady block times. So, the network had been stable for a week. After the author left the project and the ballast staking got disabled, many chain splits started to appear due to a combination of many factors, including too few number of stakers, uneven distribution of staking power, possible multiple nodes staking with the same account, the miner bug which may issue more than one block, DoS protection being triggered and the auto-collateral feature for MN owners which minimized total amount at stake.
4. It appeared that the miner may issue more than one block in some race condition when new transactions arrive when miner finds a block. The behavior for miner to continue mining was intentional to continue trying to find the best block even if someone submits a weaker one. That has to be extra protected to avoid DoS triggers.
5. Another block miner issue, is that it tends to go into wild split chains on large staking nodes when difficulty significantly drops because blocks get delayed for too long. It is possible to design a miner “blowoff valve” in case of serious difficulty fall and rapid block generation. In general, the miner should stop if network connectivity is lost, but that is not the case with network clusterization.
6. In some way, it can be considered a luck that Gen 2 snapshot was enough to fit into Gen 3 block size. The situation had been monitored for the last three months before the release. This approach may not fit other cryptos which may require to change peer-to-peer message handling for the migration block.
7. Proof-of-Stake Denial-of-Service protection was taken from Gen 2 almost with no changes. However, the change in difficulty handling and the issue in the miner have led to heavily split chains. The author understands what needs to be improved there, but DoS protection was simply disabled by Energi Core.
8. Energi Core have not faced the problem yet, but the author considers it is a good idea to deploy more GovernedProxy instances with predefined address in Genesis to reserve for future extensions in consensus. It was not done solely because of code freeze.
9. The Genesis contract creation transactions were not recorded, but that appears to be a problem for third-party systems like block explorers. Again, that was not fixed due to the code freeze.
10. The same applies to consensus transactions, but that was fixed before the code freeze.
11. Consensus block finalization transaction tracing appears to be a significant problem both for the Geth codebase and for Blockscout block explorer. One of the major problems is that Solidity does not re-use memory in loops and function calls. The memory grows with quadratic use of gas. A special tracing mode had to be implemented which records only meaningful call operations and related parts of stack, memory and storage.
12. It appears that lack of transparency in internal transactions and their effect on account balances and state in general can be considered as a nuance of Ethereum. The change in account balance is reflected only in the state. If that is done via some consensus logic then it cannot be detected any other way than via ineffective polling. At the same time, the standard tracing has shown its inability to handle a large gas transaction.
13. As anticipated, many exchanges and other third-party service providers were a bit confused by the migration instead of a well-know swap. Perhaps, the situation will change over time.

The ten months of development have revealed too many internal Ethereum gotchas what possibly has brought the author close to authors of Ethereum itself in understanding of many fine details of its internal operation.

Postmortem

At the moment, Energi network has many flaws:
- Proof-of-Service has not been fixed and allows ghost Masternodes.
- The critical Denial-of-Service protection is disabled what opens floodgates. (UPD 2020–04–30: v3.0.6 just reverted to the original code and called that an accomplishment)
- The network is still unstable and some features like dynamic checkpoints are partially malfunctioning now (UPD 2020–04–30: a ready solution has been provided much before v3.0.6 release).
- Chain splits continue to happen. (UPD 2020–04–30: sorry, ballast staking got disabled)
- There seems to be a problem of network propagation because of network inter-connection failures caused by several mentioned aspects (UPD 2020–04–30: mitigation solution was also provided).
- Masternode owners and stakers have to constantly monitor their nodes.
- The account system has revealed a problem of staking power centralization which was hidden in Gen 2 UTXO days.
- Energi Core continues to manually “fix” the chain based on what they consider being the main one, what leads to thoughts that the large staking nodes of Energi leaders actually cause issues when they get “disconnected” from the rest of the network. (UPD 2020–04–30: yeah, looks like an artificial lesson for those exchanges which did not obey closed deposits).

At the moment, the author is just an ordinary coin owner (UPD 2020–04–30: well, Energi Core has blocked author’s coins) who is irritated by incompetence of Energi Core to handle the situation for more than three weeks already. As a little help to that, the ballast staking infrastructure has been restored. Its work is visible here: https://explorer.energi.network/address/0x0000000000000000000000000000000000000308/validations (UPD 2020–04–30: not anymore)

This situation is quite appealing for Energi Core as it is a great excuse to direct all exchanges to close deposits, but leave withdrawals open to increase the demand by reducing supply on exchanges. Meanwhile, exchanges seem to accept manual deposits from Energi Core for market making purposes. That essentially creates a situation when Energi Core is making large amounts on selling NRG while legit coin owners are denied from such possibility. Can it be called any other way than a scam?

More details can be found in the summary at BitcoinTalk.

Conclusion

Energi Gen 3 is the first cryptocurrency to use a secure migration instead of a common very doubtful swap procedure. It also appears to be one of the first cryptocurrencies of the third generation. It has extraordinary complex upgradeable in-chain governance system with relatively simple and robust Proof-of-Stake solution.

Obviously, not everything went as smooth as it could. There is definitely room for improvements.

This article has not gone much into technical details. Many aspects are worth a dedicated article as long as this one. Please do not forget to “like” and tell what aspects you would want to get with in-depth details.

P.S. There is a paid troll factory called Energizers who publicly worship and defend the King and the company in social networks, so their appearance won’t be a surprise to the author.