How NFTNDX prevents NFT Sleepminting attacks

With the hype that has been going though the NFT space, a lot of terminologies and attacks started popping up everywhere.

In this blog post, we will be talking about how the Sleepminting attack works and how NFTNDX will help you to prevent and avoid such type of attacks on your solution or platform in the future.

What's a Sleepminting attack?

If some of you isn't aware about the type of attack, in simple terms, the hacker tries to fake the provenance of a token by faking the initial minter/buyer addresses and then transferring it to himself later on in order to sell it on NFT marketplaces as the "original token".

How does it work?

Essentially it's done by faking the provenance of a token and simulating fake mint and transfer transactions coming from a known address that the hacker doesn't control.

In order this type of attacks to work, a pre-requisite needs to take place:

A "back-doored" Contract:

NFTs implementations should always respect the ERC-721 and ERC-1155 industry standards, but of course you can't force all developers to follow these standards.

Depends on the terminology that could be used here, some might call it "non respected convention", some might call it a "back-doored contract" or even a "buggy" contract, it all depends on the perspective and intention of the developer in the end.

By the industry standards, once a token has been minted and now it's owned by an address and only a couple of actors who are able to initiate the transfer:

• The owner of an NFT
• The approved address of an NFT
• An authorized operator of the current owner of an NFT

Basically, It's like the hacker is a "SuperAdmin" that has the highest permission level who could initiate such types of transactions.

To sum it up, the attack process looks like this:

• The hacker creates a contract that he controls (which is completely different than the original contract where the original token has been minted on)
• Initialize a mint process to the same address of the original token creator on that contract and does a couple of fake transfers if he wants to simulate some liquidity.
• Lists the fake token minted on his contract on other NFT marketplaces as the "original token"

In case someone is more interested to learn about this type of attack, you could definitely check the post that has been published by Tim.

Example of a Sleepminting attack:

Beeple's $69 million NFT has been minted on a different contract than the original one where the hacker has "simulated" the provenance of the token 40914 like it's coming from Beeple himself.

Rarible's Listings:

Original Authentic Beeple's NFT: https://rarible.com/token/0x2A46f2fFD99e19a89476E2f62270e0a35bBf0756:40913

Accessible also on NFTNDX: https://nftndx.io/token/0x2A46f2fFD99e19a89476E2f62270e0a35bBf0756-40913

Fake NFT (No longer publicly accessible): https://rarible.com/token/0x5FBbACf00ef20193a301a5BA20acf04765fb6DaC:40914

How does NFTNDX prevents such type of attacks?

All Contracts are authenticated:

All contracts that are listed within our platform are verified and authenticated after an extensive audit process, so an attacker's contract or other types of contracts where the provenance isn't proven aren't listed on our index.

ERC-721, ERC-1155 Standards:

We make sure that the contracts listed on our index are authenticated and respect the industry standards, with of course some occasional exceptions that we should consider within our system, but the provenance is always proven.

In order to prevent such type of attacks with your solutions/platforms that use NFTs, you could soon integrate our APIs in order to verify the authenticity of the NFTs that we are tracking, feel free to sign up on our form to keep yourself updated on https://nftndx.io/api-signup, or you could reach out to us for further partnership on contact@nftndx.io.