Incognito countermeasures against Kucoin hack

Does the team have some counter-measures against this and future-similar issues? Currently, we are not so visible. However, eventually, more hackers will be aware of Incognito chain. Today, someone advises hackers to use DEXes :slight_smile: Of course, she is wrong since public DEXes are traceable but our DEX is not (to some extent). Aside from legal issues, the assets of our liquidity providers are at risk. Please think about this situation:

  1. Hackers steal some USDT.
  2. They shield them.
  3. USDT-contract-owner freezes the fund in our vault. (like in Kucoin hack)
  4. They exchanged pUSDT for pBTC.
  5. They unshield pBTC.

We have some frozen USDT and lost BTC. Hackers have some laundered BTC. This is just one example. There are more scenarios.


I was thinking about this yesterday as I was scrolling through r/kucoin. Privacy has always walked a thin line. If one of these big hackers tried to run a bunch of various currencies through our nodes I think there would be a big target painted on this project.


Hey @abduraman

Regarding the Kucoin hack. We checked the Tether smart-contract the hacker’s address is already blacklisted and the stolen USDT is frozen. So with this case, there is no risk that those coins come to the Incognito.

Simultaneously, both UDST & USDC smart-contracts have functions to freeze tokens on any wallet or smart-contract. So risk remains for everyone who uses those coins. It doesn’t mean that they will do it, but you should keep it in mind while using any centralized, stable coins.

From the decentralization point of view, we recommend everyone use DAI (its smart contract doesn’t have a blacklist function), which means that the tokens can’t be frozen, making it truly decentralized.

From the core team perspective, we prioritize up usage DAI in the network and pay a higher reward for liquidity providers. Please help us maintain a bigger liquidity pool. Once it happens, we will be able to reduce USDT/C influence on the Incognito ecosystem)


Hey @andrey,

Thanks for your input but this does not answer what if my scenario happens. For my example scenario, what is your risk response strategy?

  • Avoidance: As you said, to apply this, the support for the centralized coins/tokens such as USDT/USDC should be removed from the network.
  • Transfer: Frozen USDT fund will be compensated by the resources of the network or the team or an insurance fund.
  • Acceptance: Risk occurs but no action. In this case, if all people with pUSDT balance try to unshield USDT, what will happen?
  • Mitigation: Before Step 2, the team will blacklist the related accounts immediately so that the hackers cannot shield the stolen money.

The coins can’t be just removed from the network, but what we can do to reduce risks is to stop incentivizing liquidity in centralized coins, and focus on DAI. After this step, we might see the outflow of USDT/C and the inflow of DAI into the network.

  • If USDT/C don’t have liquidity, one of the risks you described are illuminated
  • We do also blacklisted Kucoin hacker accounts so he/she/they will not be able to shield

Once we do not have liquidity for USDT/C, users will still be able to shield/unshield it, and they should accept the risk.

1 Like

Does this mean that if a hacker realizes my scenario, someone cannot unshield her pUSDT/C (since not enough USDT/C may exist in the vault) until another person shields the same amount of USDT/C? Is there any error message for this type of situation (not enough coins/tokens in the vault)? Doesn’t this (shield some amount of USDT/C but cannot unshield them for some time) raise a reputation problem?

1 Like