The Unforeseen: Navigating a Contract Malfunction and V2 Relaunch

By DeHub Team — 2022-10-01

In Q4 2022 the tax triggers in our contract malfunctioned. The token froze. The liquidity pool froze with it. We were forced to relaunch as v2.

This is the most serious technical failure in DeHub's history and it deserves a straight account.

What happened

The contract carried tax logic in the transfer path — the standard design for the period, where a percentage of each transaction is diverted to liquidity, marketing or holders.

Those triggers malfunctioned under real conditions. The result was not a degraded experience. The token could not move, and because the pool depends on transfers, the liquidity locked with it. Holders could not trade. We could not fix it from outside, because the behaviour was in the deployed contract's own logic.

There was no patch. Immutability is the property you want right up until the moment the thing that is immutable is broken.

Why an audit did not prevent it

We had commissioned a full Certik audit the previous year and taken security seriously since the v1 vulnerability.

This was not an exploit. Nobody attacked us. The contract did what it was written to do, under a combination of conditions that had not been modelled. Audits look hard at whether code can be abused. They are much weaker at whether a design behaves sensibly at the edges of its own assumptions, and that is where this lived.

It is the clearest illustration we have of the limits of an audit, which is why we have never used the word as a guarantee since.

What we did

Relaunched. There was no smaller option.

That meant a new contract and migrating more than 25,000 holders onto it — an enormous operational undertaking carried out under exactly the circumstances in which you have least credibility.

It also meant deciding what the new contract should be, and we went to plain standard ERC-20 tokenomics with nothing clever in the transfer path at all. No tax triggers. No conditional logic between a holder and their own tokens.

What we actually learned

Complexity in the transfer path is the risk. Every clever tokenomic mechanism is code that runs on every transaction forever, in market conditions nobody has seen yet. The cleverness has to earn its place against that.

Immutable means immutable. Design for the case where you cannot intervene, because that is the case you will get.

The community carries the cost of your design decisions. Holders could not access their own positions through no fault of their own. Whatever the technical explanation, that is what happened, and it is the frame we have kept.

Afterwards

V2 shipped, holders migrated, and trading resumed on Gate.io in Q1 2023. The simplified contract has run without incident since.

Late 2022 was the worst stretch DeHub has had — this, immediately after the Palawan venture collapsed and a $1m raffle missed its minimum. All three are in this archive at full length.

For anyone designing tokenomics now

The specific advice we would give, having paid for it:

Anything in the transfer path must be justified against the worst case, not the intended one. Ask what this code does at 100x the volume you expect, at 1% of it, during a liquidity event, and when a integrating contract behaves in a way you did not anticipate. If you cannot answer all four, it does not belong there.

And assume you will never be able to change it. The mental exercise that would have saved us is straightforward: write down what you would do if this contract started behaving badly tomorrow and you had no admin key. If the honest answer is "relaunch and migrate everyone", you have already accepted that outcome — you just have not scheduled it yet.