On December 2, Ankr’s contract deployed on the BNB chain was attacked.

Basically the hacker managed to deploy a malicious implementation contract, minted 10,000,000,000,000 aBNBc tokens, dumped these tokens on a DEX and exchanged them to other crypto assets.

Dumping this huge number of aBNBc tokens dramatically crashed the token’s price which shortly went from $300 before the incident to less than $2 after the dumping.

The hacker exploited crypto assets worth around US $5 million in this incident.

While this action is for sure considered as illegitimate, another actor “legitimately” made a profit of around US $15 million from this incident.

Here is what this actor did:

After this incident happened it deposited 10 BNBs in exchange for 180,000 aBNBc tokens, used the aBNBc tokens as collateral to borrow a huge number of Hay stablecoins from the lending platform Helio and eventually exchanged all the Hay tokens to BUSDs.

The whole process was perfectly and legitimately organized and executed such that it was suspected that this actor was very likely the hacker itself.

The reason why the actor had successfully made this profit is that Helio’s oracle didn’t act promptly to the price’s sudden dip thus still using the lagged price as aBNBc’s valid price. This vulnerability was leveraged by the actor to borrow extraordinary assets and make a huge profit.

Actually this is not the first time that such an issue happened. Early this year, when the price of Luna crashed, there were quite a few cases in which actors borrowed less volatile crypto assets by using Luna as collateral in lending applications in which their oracles’ didn’t update Luna’s price promptly.

Apparently this is an oracle issue, however if we dive deep into this issue we think this is more or less a tokenomics issue as well.

Among all these existing issues, ERC-20 tokens on Ethereum or fungible tokens deployed on EVM blockchains are often the exploited assets.

These tokens can be minted in either of the following two ways depending on their contract designs:

Either a token’s total supply or max supply is all minted on deployment and after the token’s contract is deployed, no subsequent minting is allowed any more.

Or the token can still be minted after its contract is deployed.

For the latter, whenever the access control to the token’s mint function is compromised, malicious minting could happen. And when this happens the additionally minted tokens will very likely either be dumped in DEXs or CEXs, or used as collateral to borrow less volatile crypto assets such as stable coins in particular from lending applications.

Compared to dumping tokens on DEXs or CEXs, using them as collateral to borrow stable coins from lending applications causes a devastating damage to these lending applications. Quite often a lending application that lent assets in this case was drained shortly and bore a huge burden of debt.

So how can we avoid this issue?

A quick idea is to improve the responsiveness and promptness of the oracles these lending applications use.

This is good but this is not enough because it may greatly increase their operation costs and in addition no matter how responsive an oracle is it can hardly respond in real-time.

Therefore we propose the following solutions:

The first one is a carefully designed collateral ratio could be applied to collateral tokens which can be subsequently minted after their contracts are deployed.

Yes, many lending applications apply a collateral ratio to a token that is used as collateral however quite often the setting of such a ratio doesn’t take into account the risk that the token might be maliciously minted. Therefore the setting may not be that resilient or fault-tolerant to this risk.

The second is a lending application should not only trace a token’s price but also monitor a token’s mint activity especially those tokens that can be minted subsequently after their contracts are deployed.

When an abnormal mint activity such as a large number of tokens being minted happens for a token, a lending application could suspend its lending service for those that use this token as collateral. After this abnormal mint activity is confirmed fixed or normal could this lending service be resumed again.

The third is a lending application could charge relatively more service fees for collateral tokens that can be minted subsequently after their contracts are deployed.

This is to hedge the risk economically.

These are some tentative thoughts we got after learning the big lessons from these incidents.

When tackling a cyber-security risk or issue Fairyproof always tries to find solutions not just from a purely technical point of view, but from multiple facets including tokenomics, governance and more.

Hope these thoughts could be of some assistance to mitigate this issue in the future.