1 Introduction

NFTs are changing the way we perceive and register ownership of assets, offering new opportunities and innovative business models. During the last years, several blockchain projects and technologies were proposed for social impact. In detail, NFTs are digital assets that cannot be exchanged, altered or split, which are minted on a blockchain so that they can be proven to be unique [32]. They are often utilised as collectables because they cannot be duplicated. Nowadays, NFTs are connected to the concept of the Metaverse [15] and digital art. However, despite the excitement around NFTs, and their popularity among artists, they may also be utilised to incentivise and propose good behaviour in our society. The most obvious case is the fundraising for non-profit organisations and charities. Selling NFTs can give non-profits access to new sources of funding outside of established channels and help them diversify their revenue-raising efforts. Another use case is legacy non-profit organisations that can monetise their physical assets without losing access to them, providing a method for digital ownership. Moreover, another important social impact has been the announcement of “The Ultimate Green NFT” to obtain funds used for the planting, cultivation, and maintenance of a local forest in one of Brazil’s regions,Footnote 1 but also the usage of NFTs in museums to sell paintings and art objects in form of digital assets [21, 30]. NFTs also have been employed to fund wildlife conservation initiatives [23].

From the technical point of view, an NFT contains two parts: the content represented by the NFT and its metadata [6]. The metadata serves as a description of the content and contains the unique identifier of the NFT, the current owner, and so on. The content represented by the NFT can either be stored inside the NFT or a logical link to the content is given, so that NFTs can represent any asset with specific characteristics [25]. When an NFT is created, through the minting process, a token ID is randomly generated which ensures that each NFT is unique. Then, it is stored on the blockchain, and no one can remove it because the blockchain is public. This guarantees not only the uniqueness of the NFT but also the ownership of this NFT.

From the application point of view, it is clear that NFTs represent an opportunity in several scenarios, but unfortunately, they are affected by issues related to the underlying technologies that can have an impact on the diffusion of this technology. Indeed, NFTs are typically implemented on top of blockchains that support smart contracts [6], such as the Ethereum blockchain, which is also the most used. The smart contract is deployed on a blockchain and contains the metadata of the NFTs of the collection managed by it, and a set of functions to manage the tokens. The smart contract can contain bugs or can be written with malicious intent, and in this case, it represents a vulnerability of NFTs, which can be exploited by impersonification attacks. An important attack which attracted a lot of attention is the sleepminting attack. Sleepminting is a form of fraud in the NFT scenario, where a hacker can exploit a vulnerability of an existing smart contract or deploy a custom-built NFT contract to mint NFTs in place of other users, or transfer tokens that are owned by other users. Sleepminting may ruin the credibility of NFTs, and can severely limit the scenarios of application of this technology. Due to these attacks, the blockchain is not perceived any more as secure, and people are losing trust in blockchain-powered technologies. In this paper, we provide a detailed overview of the sleepminting attack, by extending the work proposed in [13]. In detail, in our previous work, we formalised the phenomenon and conducted a preliminary analysis showing what it looked like in its infancy. Indeed, in the beginning, the most common type of attack was connected to the minting of NFTs. Since its introduction, the attack evolved considerably, therefore in this work, we revised our view on the attack by discovering that currently, the attacks are more related to NFT transfers. Through our analysis that covers multiple blockchain networks, we also discover that Polygon is the most targeted blockchain. Lastly, the analyses show that metaverse applications and blockchain games are becoming the most preferred targets.

Additionally, in this paper, we propose a sleepminting prevention system that can reduce sleepminting attacks. Our prevention system is based on analysing the transactions added to the blockchain, detecting those that are related to sleepminting attacks and keeping track of the addresses that are involved in these transactions. A dictionary-like data structure, called frequency dictionary, can be used to keep track of the addresses involved, where the key is the address and the value acts as a counter for the number of times the address is involved in sleepminting. With this information, block-creating nodes can add another verification step before adding a transaction to a block, which consists of blocking transactions when the addresses involved appear in sleepminting attacks a number of times greater than a threshold. By testing our sleepminting prevention system, we detect that it can block up to 87% of attacks, providing an effective method to limit the number of attacks. Moreover, we investigate the effects of having different values of the threshold, both in terms of the number of attacks blocked and the number of user or contract addresses blocked.

Our proposed sleepminting prevention system has numerous benefits. First of all, the approach only requires scanning the whole blockchain only once, which can be done during the chain synchronization phase, therefore block creator nodes experience a negligible overhead. Thanks to this fact, we also solve the cold start problem, as block creator nodes start with a list of untrustful addresses by synchronising the blockchain data. Additionally, once the frequency dictionary is built, nodes only need to scan this dictionary instead of the whole blockchain, making the approach computationally inexpensive. On top of that, since it is based on blockchain data, it cannot be tampered with, and because the approach prevents transactions involving suspicious addresses, attackers cannot spend what they manage to gain through sleepminting. Finally, thanks to its simplicity, the approach is fully explainable and can be customised by adjusting the values of the threshold used to decide if a transaction should be included in a block or not. To the best of our knowledge, no other sleepminting prevention systems have been proposed before.

The paper is structured as follows. In Section 2, we provide the background for this paper. In Section 3, we discuss the current vulnerability issues of NFTs. In Section 4 we propose an overview of the sleepminting attack, while in Section 5 we focus on its technical details. In Section 6, we describe the proposed sleepminting prevention system. In Section 7, we provide an updated evaluation of the sleepminting phenomenon, and of our proposed prevention approach. Section 8 concludes the paper, discussing potential future works.

2 Background

In this section, we introduce an overview of blockchain technology, which is used as the main supporting technology for NFTs, and a detailed description of what NFTs are.

2.1 Blockchain

A blockchain is a digital ledger of transactions maintained by a distributed network that facilitates the process of recording information. Each block is connected to the previous one through the hash of the previous block header. This enhances the security of a blockchain. Blockchain technology became famous thanks to Bitcoin [24]. Nowadays, the technology is evolved, principally after the introduction of smart contracts in Ethereum [5], which has simplified the application of the blockchain to not only financial applications [8, 12, 20].

Current literature categorises blockchain networks by using their permission model [18], which determines who can manage them. This classification divides current blockchains into two main categories: permissionless and permissioned. Permissionless blockchains allow anyone to read and write on the blockchain. Instead, permissioned blockchains require authorisation to interact with the blockchain.

Both categories have some drawbacks. Indeed, permissionless blockchains are considered more secure than permissioned blockchains, because there are many nodes that participate in the validation of transactions. However, they usually have long transaction processing times due to the large number of nodes and the large size of the transactions.

A key aspect of blockchain technology is the consensus algorithm used to determine who will be the producer of a new block. Several consensus algorithms have been proposed [28]. The most famous is the Proof of Work consensus model (PoW) [11] used in Bitcoin. Another used algorithm is the Proof of Stake consensus model (PoS) [27], recently adopted by Ethereum, based on the amount of cryptocurrency a user has invested into the system.

2.2 Non-fungible tokens (NFTs)

A non-Fungible Token (NFT) [32] is a unique asset in the crypto world. The term “Fungibility” means that digital assets are equal in value, for example, Bitcoin can be spent to buy another Bitcoin. Instead, NFTs have a digital signature that makes it impossible for NFTs to be exchanged for or equal to one another [26]. NFTs have gained popularity in the past year due to their unique quality to attach value to any digital and physical asset while recording ownership in the Blockchain. Thanks to their unique properties, NFTs can be used in several scenarios, such as virtual gaming, cultural heritage [10], digital identity [1], etc. NFTs exist on a blockchain, and from the technical point of view, they are composed of two parts: the content represented by the NFT and its metadata [6]. The metadata serves as a description of the content and it is usually specified in a JavaScript Object Notation (JSON) format [25]. When an NFT is created, through the minting process, a token ID is randomly generated which ensures that each NFT is unique. Then, it is stored on the blockchain, and no one can remove it because the blockchain is public. This guarantees the uniqueness of the NFT, but also it provides information about the ownership of this NFT.

Several NFT standards were proposed, but the most recurring ones are the Ethereum standards. The EIP-721 defines a standard, called ERC-721; the ERC-1155, called the Multi Token Standard, offers the possibility to define “semi-fungible” tokens; finally, the ERC-998, which is the standard which provides composable tokens.

Among the various standards for creating and issuing NFTs, Ethereum’s ERC-721 is the first and most widely used [7], containing an interface that must be implemented by a smart contract to give the mint and trade actions. The ERC-1155, called the Multi Token Standard extends the ERC-721 standard to provide semi-fungible tokens. ERC-1155 allows having many types of tokens from the same smart contract, useful for gaming and social media use cases.

3 Vulnerability issues of NFTs

NFTs are an important concept in the field of blockchain, in particular for their application to important research fields, such as the Metaverse [15] and Social Media [12]. In particular, in the case of Social Media, it was born the so-called Social Finance (SocialFi) [14] which tokenizes the user’s social influence. The increasing interest in NFTs and the linked economy have arisen several issues concerning their vulnerability, which can be from both the server side and the user side. A simple overview of NFT scams has been presented in [3], but it considers only a subset of the entire set of scams concerning the usage of NFTs. In this paper, we focus our attention on the vulnerability from the server side, because they represent an important issue concerning NFTs which does not depend directly depend on the fraudulent behaviour of users. Indeed, these vulnerabilities are strictly related to the server applications’ behaviour. We highlight three different types of vulnerabilities:

• Smart contract vulnerabilities (i.e. sleepminting).

• Off-chain Storage Vulnerabilities;

• Marketplace Vulnerabilities;

In the rest of the section, we will discuss in detail these types of vulnerabilities.

3.1 Smart contract vulnerabilities

NFTs use smart contracts to track the ownership of unique and non-replaceable digital assets. Smart contracts enable users to create, own, identify, manage, and exchange these items without a centralised entity. There are already multiple known ways to exploit smart contracts [2, 4], in particular through bugs in their source code [9].

The problem with smart contracts is unintended vulnerabilities. Since contracts are public, hackers can carefully study them and exploit them to steal tokens.

With the term vulnerability, we refer to errors in high-level code, such as Solidity, or Rust. A smart contract runs in a virtual environment, like the Ethereum Virtual Machine (EVM), that compiles the input from these programming languages in low-level bytecode. Therefore, any bugs in the smart contract source code will result in an undesired behaviour of the contract.

A way to reduce the presence of errors in smart contracts is to use an NFT audit, which is a comprehensive code review for verifying the technical and safety of a token, smart contract, and NFT trading platform to mitigate potential cyber threats. However, smart contract audits can not catch every bug, and usually, it is a voluntary process which is not required, and for this reason, this does not avoid the development of fake smart contracts. Indeed, an NFT audit is issued under payment and provided by a third-parties.

3.2 Off-chain storage vulnerabilities

Unstructured data in the form of documents, photos, and others do not need to be stored in main blockchain nodes. For this reason, off-chain storage has been taken into account, in particular concerning the NFT metadata. The off-chain storage offloads massive datasets from the blockchain nodes. Many implementations support off-chain storage Eg: IPFS [16, 17], Sia [31], StorJ [19], and BigChainDB [22].

If the metadata of an NFT is stored on the chain, then once the transaction has been confirmed, the metadata and ownership of the NFT cannot be maliciously tampered with. Instead, in the case of off-chain storage, the metadata is potentially manipulable. Furthermore, decentralised or centralised off-chain storage can not guarantee secure and reliable storage. Finally, the metadata of NFT is publicly accessible, which means everyone can download or get the URL link of the NFT content. This could be considered a vulnerability because users can download the metadata or directly use the URL to create a fake NFT.

3.3 Marketplace vulnerabilities

In an NFT marketplace, all the transactions are recorded on the blockchain, but NFTs are always vulnerable to security problems. While the majority of NFT marketplaces are decentralised, there are some that operate using a centralised model. In the context of an NFT marketplace, this can cause several major risks, including data tampering, censoring and even a potential loss of the NFTs collected. An important issue consists of the airdrop phishing attack [29]. NFT airdrops may be a marketing promotion of a new NFT collection or other, and they are sent to wallets for free. The attacker creates an NFT containing malicious code in it, then airdrops the NFT to the victim. In this way, the malicious code is on the victim’s wallet, and when the NFT will be opened, the code will be executed, and the communication with the wallet will be opened. Another important issue is the phishing email containing malicious links, asking the victims to sign a transaction that the victims thought was for migration.

A famous vulnerability consists of the pump-and-dump and rug-and-pull (R&P) advertisement [6]. In the context of NFT marketplaces, an NFT pump-and-dump scheme happens when the sellers artificially inflate the value of their NFTs by buying them up themselves and/or by spreading misleading information. Once the price goes up, they “dump” the NFT and disappear, leaving investors with worthless assets.

In the rest of the paper, we will treat the sleepminting attack, which can be considered one of the worst smart contract vulnerabilities.

4 NFT sleepminting

Sleepminting is a term that refers to a complex attack that can be made for NFTs. NFTs are usually implemented through the usage of smart contracts, that record their metadata and keep track of the ownership through time. An attacker can leverage a smart contract vulnerability thanks to which it can create counterfeit NFTs, and move them autonomously between wallets in a blockchain network.

The attack was showcased for the first time by a person that goes under the pseudonym of Monsieur Personne. This person developed an ERC721 smart contract for managing an NFT collection called NFTheftFootnote 2 and sleepminted an NFT. The NFT metadata pointed to a piece of art created by beeple, a well-known NFT artist, and the ownership of the NFT was initially assigned to the artist’s address. Shortly after, the NFT was transferred by the attacker to another address, without the owner’s consent.

In the beginning, the sleep minting attack has been associated in particular with the minting operation, as explained in [13], when an attacker mints an NFT directly to a famous creator’s wallet with permission to reclaim or pull the NFT back out of the creator’s wallet. More in detail, an attacker, can mint (create) a counterfeit NFT and assign it to the address of a famous artist. Once the mint is recorded in the blockchain, the attacker can claim to own an NFT of the target renowned artist.

However, thanks to the introduction of NFT 2.0Footnote 3 and with the proliferation of Metaverse platforms [15] and NFT applications/marketplaces, the mint operation is becoming less of a threat in the sleepminting attack. With many emerging NFT and Metaverse projects, users are encouraged to mint their own NFTs, and attackers can launch their projects so that users mint their NFTs legitimately. At a later stage, attackers can force the transfer of NFTs to reclaim them or directly sell them to another user address.

Another technique that is less common but more subtle, is related to the notion of authorised operators, i.e. addresses that are authorised to manage and transfer tokens owned by another address. Also adding authorised operators can be a technique used by sleepminting attackers. Indeed, an attacker can add their addresses as authorised operators of victims, without their noticing, and then transfer the victim’s tokens legitimately. This technique is much more subtle because it is harder to detect for victims, and it is more challenging to take countermeasures.

As discussed, this attack can take many shapes and cannot easily be detected and countered. Additionally, while it was initially reported for the ERC-721 standard, it is not directly tied to a specific standard. Since it is an attack related to how the smart contract is written, all smart contract-based NFTs could be affected, even those based on a non-EVM-like blockchain.

Sleepminting has a big potential to impact harmfully NFTs and the Metaverse, and represents a hurdle against their adoption and widespread use, because of its generality, and the fact that it is challenging to identify and block it.

In this paper, we propose a Sleepminting Prevention System that is based on extending the blockchain block creators’ behaviour. Transactions contained in new blocks can be scanned to search for sleepminting-related activity. New transactions including addresses involved in sleepminting-related activity are then blocked during the transaction validation procedure. Before describing the solution proposed, we provide a technical description of the sleepminting attack.

5 Sleepminting: technical details

Sleepminting is an attack that is caused by a smart contract containing vulnerabilities. Characterising this attack is difficult because there are different implementations of it, however, they are based on bugs unintentionally added in the code, or faulty behaviours intentionally added in the code of the smart contract. Additionally, the detection of smart contract vulnerabilities, and sleepminting attack prevention, is not an easy task for two reasons. Firstly, the most used standard for NFTs is the ERC-721 standard, which defines an interface for operating with the smart contract, but does not provide an actual implementation. Therefore, as shown in Fig. 1, a normal contract and a faulty contract may have the same interface, and a user <A> is able to interact with them in a similar way. Due to this, there is no easy way to separate normal contracts from faulty ones, just by analysing their interfaces and other methods exposed. Secondly, although smart contracts are implemented through high-level programming languages, when they are deployed on the blockchain their source code is compiled into EVM bytecode,Footnote 4 which is the machine-readable code with which smart contracts are executed. This makes the code of the deployed smart contracts hard to read and, in turn, sleepminting hard to prevent.

Fig. 1
figure 1

An Ethereum user A interacts with two NFT contracts in a very similar way

Full size image

The smart contract vulnerabilities that are at the base of sleepminting are related to the implementation of some sets of methods, in particular, those related to minting (creating) an NFT, transferring it (changing ownership), or approving addresses (enabling non-owner addresses to transfer an NFT). Indeed, it is in these methods that contracts manage to change the ownership of the NFTs, and faulty smart contracts either do not check that the address that calls the contract is the owner of the NFT involved or make use of administrator addresses (hard-wired in the contract’s code) whose calls will skip the ownership check. As an example, a typical behaviour of a faulty contract is shown in Fig. 2, where the address of the user who invoked the contract is not taken into account when calling a method that changes the ownership of an NFT. A normal contract, shown in Fig. 3, always checks that the address of the user who invoked the contract is allowed to transfer the specified token.

Fig. 2
figure 2

The faulty contract implementation omits important security checks, letting the attacker A perform illegal actions

Full size image
Fig. 3
figure 3

How a normal NFT contract is supposed to be handling requests

Full size image

An example of a sleepminting attack is shown in Fig. 4. On the left side of the figure, an attacker <A> creates a counterfeit NFT and mints it to another user <D>, which may be an important person in the NFT world (like an artist or a famous investor). A unique identifier id = 42 is assigned to the NFT, and when the smart contract is queried it shows that the NFT with id = 42 is owned by user <D>. At another time, as shown in the right side of the picture, the attacker <A> can send a transaction to the faulty smart contract to transfer the token with id = 42 to another address, even the same address used for the attack. The smart contract method invocation is successful because the smart contract does not check that <A> is the owner of the token. After the attack, <A> is now able to sell the counterfeit NFT, and can also claim that the NFT was created by <D> because it is the first owner.

Fig. 4
figure 4

An example of a sleepminting attack

Full size image

Due to the nature of sleepminting, it is impossible to distinguish when the NFT was sold by the owner or was transferred as a result of an attack. Indeed, the only trace left on the blockchain is the transactions used to transfer the NFTs, which can be used to understand if the contract is normal, as shown in Fig. 3, or faulty, as in Fig. 2. Moreover, while sleepminting detection mechanisms can be based on analysing the blockchain transactions, they provide no way to protect users because they do not prevent sleepminting.

6 Sleepminting prevention system

Sleepminting is an important attack as it stands because of its impact on NFT ownership and provenance. This imposes developers and researchers to find mechanisms that can help its detection and prevention. To prevent sleepminting, we propose to enrich the behaviour of blockchain block creators (i.e. miners, validators, witnesses) by keeping track of the addresses that appear in transactions containing sleepminting activity. This paper is the first to propose an actual sleepminting prevention system. However, the problem is well discussed online, and there are some sleepminting detection systems, such as the ones on the Forta NetworkFootnote 5.Footnote 6 There are several benefits of the proposed sleepminting prevention system over the sleepminting detection systems available online. First of all, we are able to actually prevent sleepminting attacks, while the tools available online are merely attack detection systems. Additionally, thanks to its simplicity, the approach is fully explainable and can be customised by adjusting the values of the threshold used to decide if a transaction should be included in a block or not.

6.1 Detecting sleepminting activity

As described in Section 4, sleepminting is the practice of counterfeiting NFTs and transferring them between addresses without the consent of the actual owner. This is usually done by creating an NFT on a collection that is managed by faulty contracts that permit the NFTs to be transferred in ways that should not be allowed. These NFTs can be linked to on- or off-chain resources, like pictures, so they appear to represent the ownership of these resources. Whenever a user address <A>, via a transaction to a smart contract <C>, manages to transfer tokens owned by another user address <D> and for which <A> is not an approved address, we label the transaction as a sleepminting activity. The detection of sleepminting activity is done by all block creators on the newly minted blocks, thus allowing the block creators to identify and label all the relevant transactions. This process cannot be done by analysing only the mempool (i.e. the public and distributed data structure containing unconfirmed transactions), because some transactions appear directly on the blockchain, without passing by the mempool. When a new block is created, the procedure defined in Algorithm 1 is executed. For each transaction in the block (line 2), the procedure checks whether the recipient of the transaction is an ERC-721 contract (line 6). In this case, the procedure identifies what method has been invoked and takes further action in the case the method is a mint (line 7), a transfer or an approve (line 11). In the case of mint, the procedure labels the transaction as sleepminting (line 9) if the created NFT is assigned to an address different from the transaction sender (line 8). In the case of transfer or approve, the procedure labels the transaction as sleepminting (line 13) if the owner of the token is not the transaction sender address (line 12). By labelling transactions as sleepminting, block creators can use the information contained in the transaction to build a frequency dictionary.

This dictionary uses as keys the addresses of the transaction issuers and the contract invoked, and as values, it uses counters that keep track of how many times each address is involved in transactions labelled as sleepminting activity. Every time a block creator identifies a transaction that is connected to sleepminting activity (line 17), it can increase the counter for both the attacker user address (line 18) and the contract address (line 19). Thanks to this procedure, all nodes have at their disposal a way to keep track of all the addresses that act as attackers, and all the contracts in which sleepminting is possible.

Algorithm 1
figure a

Pseudocode of the sleepminting activity detection

Full size image

6.2 Address blocking

The frequency dictionary built by block creators can be used when adding transactions to a block. In particular, a step in the transaction validation process can be added to check whether the address was previously involved in sleepminting activity and, if it is the case, the transaction is not included in the block. To make the approach customisable, we introduce a threshold value t that is used to decide when a transaction should be blocked. We show in Algorithm 2 the pseudocode of the sleepminting prevention algorithm. The procedure defined in the algorithm takes as input the transaction to be checked, the frequency dictionary, and the threshold t, and performs two checks. Firstly, the block creator checks if the value in the frequency dictionary associated with the address of the issuer of the transaction is higher than the threshold t (line 3). If it is the case, the transaction is blocked (line 4), otherwise, the value in the frequency dictionary associated with the address of the smart contract is retrieved. Also in this case, if the value is greater than the threshold t (line 6), the transaction is blocked (line 7). If both values are below the threshold, the transaction is accepted and will be inserted in a block.

This strategy has the following strengths:

  • The previously minted blocks can be used to initialise the frequency dictionary so that the method does not suffer from the cold start problem;

  • Since the data used to populate the frequency dictionary is completely available on-chain, the approach cannot be tampered with;

  • The approach is parametrised, to allow miners to adopt different strategies;

  • Although attackers could use new contracts to perform their attacks, each time they create new contracts they spend cryptocurrency to deploy them on the blockchain;

  • Even if sleepminting transactions are added to the blockchain, the attackers are not able to spend the cryptocurrency they gain through attacks.

Algorithm 2
figure b

Pseudocode of the sleepminting activity prevention

Full size image

7 Experimental results

In this section, we provide the results of our analysis. We start by briefly describing the dataset used, then we provide analyses to characterise the sleepminting phenomenon, and finally, we evaluate the proposed sleepminting prevention system. For consistency, in this paper, we use the same naming adopted in [13]. Briefly, in a sleepminting transaction, we call:

  • attacker, the address that issued the transaction;

  • defender, the address that owned the tokens before they were transferred;

  • contract, the address of the contract that implements the NFT collection.

7.1 Dataset

The sleepminting activity was collected by a Forta agentFootnote 7 that is able to detect transactions affected by the sleepminting attacks on seven Ethereum-like blockchain networks. The dataset considered in this study covers a 164 days time frame, from the 23rd of June 2022 to the 30th of November 2022, and consists of 636,517 sleepminting transactions. Of the transactions in our dataset, there are 595,633 NFT transfers, and 40,884 NFT approve. Furthermore, we can see that the sleepminting phenomenon has changed with respect to [13], where most of the attacks were detected during the minting of the tokens.

7.2 Sleepminting phenomenon

Figure 5 shows the daily distribution of the number of attacks divided by the seven blockchain networks analysed by the Forta agent. As shown, the agent detected thousands of attacks daily throughout the observed time. Despite Ethereum being the first and most well-known blockchain considered, the Figure clearly shows that it is not the main target for attackers primarily due to the fact that deploying contracts (and executing them) is very pricey. Other blockchains, with lower fees, like Avalance, BSC and, in particular, Polygon are much more common. Indeed, Polygon embraced the concept of NFTs and heavily promoted them for instance by creating a partnership in November 2022 that lets Instagram users create NFTs out of their pieces of content and sell them to their followers.Footnote 8 In the last few weeks of our dataset, we can see an increment in attacks on Avalance and Arbitrum blockchains, which recently launched dedicated NFT markets and community hubs to let users get acquainted with their infrastructure. A side effect of this increased interest in these blockchains is an increment in the number of sleepminting attacks.

Fig. 5
figure 5

Number of attacks per day per blockchain

Full size image

In Fig. 6, we show the distribution of the number of attacks per attacker, while in Fig. 7 we show the distribution of the number of times addresses were reported as defenders. To help the readability of the Figures, we used logarithmic scales on both axes. Both Figures show that in most cases addresses appear in the respective role less than 10 times. On the other hand, we can see that there are approximately 10 addresses there were reported as attackers between 104 and 105 times which constitute the majority of attacks. The distribution of attacks suffered by defenders is slightly different as only two addresses suffered more than 104 attacks while the majority of attacks were performed against a large set of addresses that were attacked only a few times. Among the most commonly recurring attacker addresses (i.e. addresses that appear more than 104 times), we find 5 addresses that are active on the Polygon blockchain, which also include the most active attacker address, 2 addresses from the Avalanche blockchain, and 1 from BSC. Among the most commonly recurring defender addresses, we find 2 addresses that are active on the Polygon blockchain, one of which is connected to SNKRZFootnote 9 (a slang for the word “sneakers”), which is a fitness metaverse, where users are encouraged to do physical activity to be healthy.

Fig. 6
figure 6

Number of times addresses are reported as attackers

Full size image
Fig. 7
figure 7

Number of times addresses are reported as defenders

Full size image

Figure 8 shows the distribution of the number of attacks per contract address. The vast majority of contract addresses were included in a modest number of attacks, in most cases less than 100. However, similarly to the distribution of the number of attacker addresses (Fig. 6), also this distribution has a very long tail, and indeed there is one contract that was used between 105 and 106 times to perform a sleepminting attack. We can conclude that although using new contracts could help fly undetected, attackers tend to use the same contracts mostly likely because deploying more contracts would be too costly to make the sleepminting attack profitable. This practice is also encouraged because there is no widely accepted strategy to mark potentially suspicious contracts, therefore NFT buyers are expected to make their own research before buying, but have no guarantee from the blockchain network concerning the goodness of an NFT. Among the most recurring contract addresses, we find 5 contracts deployed on the Polygon blockchain and only 1 on the BSC blockchain. Some of these contracts are associated with projects like Zed RunFootnote 10 that is a digital racehorse game, UnstoppableDomainsFootnote 11 that is a platform to buy tokenised domains, or Midnight SocietyFootnote 12 that is a game developer company that uses NFTs to manage premium supporters.

Fig. 8
figure 8

Number of times contracts are reported in an attack

Full size image

Figures 9, 10, and 11 show respectively the distribution of the number of attacker-defender, attacker-contract, and defender-contract pairs that were detected in our dataset. In all three plots, it is more common that a pair only once, meaning that it is an uncommon practice for an attacker to target the same defender or use the same contract multiple times, and for defenders to be targeted with the same contract multiple times. That being said, as we can see in Fig. 10, there are tens of pairs attacker-contract that appear more than 1000 times. This highlights that there is a considerable amount of attacks that are perpetrated by a small number of attackers using the same contracts, further confirming that the most active attackers work systematically, without trying to cover their track. All addresses, either user or contracts, that appear among the most recurring pairs were already detected as the most recurring addresses. This tells us that the most active attackers act systematically, by targeting the same defenders and using the same contracts.

Fig. 9
figure 9

Distribution of the number of times a pair attacker-defender was reported

Full size image
Fig. 10
figure 10

Distribution of the number of times a pair attacker-contract was reported

Full size image
Fig. 11
figure 11

Distribution of the number of times a pair defender-contract was reported

Full size image

We conclude our overview of the sleepminting phenomenon by showing in Fig. 12 a bivariate distribution of the number of attackers and defenders for each contract. In the figure, we include data from the 12,200 contracts involved in attacks, and we highlight in red and orange the top 10% and 25% contracts by the number of attacks. The Figure shows that most contracts are operated by 10 attackers, while there is a variable number of defenders, ranging from 1 to 104. The figure also shows that the contracts most used for sleepminting attacks have a heterogeneous number of attackers and defenders.

Fig. 12
figure 12

Bivariate distribution of the number of addresses that appear as attackers and defenders for each NFT collection

Full size image

In Fig. 13 we show the distribution of the interarrival time between subsequent attacks. The interarrival time can be understood as the number of seconds that pass between two sleepminting attacks on the same contract. The Figure shows that most attacks have an interarrival time that is equal to 0, and since the creation of a block usually takes a few seconds, these attacks must have been carried out in the same block as the previous attack. In addition, we see that a large number of attacks have an interarrival time that is less than 1000 seconds (16 minutes and 40 seconds). This is an important aspect of the sleepminting phenomenon because it shows that attacks can have a high frequency and that multiple attacks to the same contract in the same block are recurrent and a viable strategy. These are important repercussions if we want to ward off the problem of sleepminting, because the addressing techniques must take into account the possibility that multiple attacks are performed in quick succession, or even in the same block.

Fig. 13
figure 13

Distribution of the attack interarrival time

Full size image

Figure 14 shows the daily number of contracts involved in sleepminting attacks (orange line) and the daily number of contracts that were involved in a sleepminting attack for the first time (red line). The Figure shows that between 200 and 500 different contracts are involved in attacks on a daily basis, which emphasises the magnitude of the phenomenon, and highlights that it is still present up to this day. Additionally, we see that tens of new contracts are employed for attacks daily. This shows that a prevention technique should consider that the phenomenon is affected by a rapid contract turnover and that indeed it must be responsive to new contracts being employed to this goal.

Fig. 14
figure 14

Number of contracts on which attacks are performed. The red line shows the number of previously unseen contracts

Full size image

7.3 Prevention approach evaluation

We conclude this Section by providing an analysis of the proposed approach to prevent sleepminting attacks. In Fig. 15 we show the number of attacks that can be blocked by adopting our approach to prevent sleepminting. In the plot, each bar corresponds to a different value of threshold to start blocking attacks, ranging from 1 (the lowest possible value) up to 200. The figure shows that, as the threshold is increased, the number of blocked attacks is still high. As an example, with a threshold equal to 1 approximately 300,000 attacks can be blocked, with a threshold equal to 25, 250,000 attacks are blocked, and with a threshold equal to 90, 200,000 attacks are blocked. This figure shows that, while adopting a threshold equal to 1 prevents more than 87% attacks, being lenient and permitting a few suspicious transactions still blocks the majority of them.

Fig. 15
figure 15

Number of blocked attacks for different values of thresholds, up to 200

Full size image

We conclude our analysis by showing in Fig. 16 the number of addresses (user and contract) that would be blocked by adopting our prevention system. The Figure shows that by setting a threshold equal to 1, more than 20,000 addresses are blocked, with an equal proportion between user and contract addresses. The plot also shows that the number of blocked user addresses drops to 1000 with a threshold of 10, but afterwards, the number is stable as the threshold increases more. On the other hand, blocked contract addresses decrease as the threshold increases at a slower but more constant rate. Indeed, there are 1000 blocked contract addresses with a threshold of 20, and approximately 300 with a threshold of 50. From this plot, we can conclude that the threshold plays an important role in deciding what addresses can be blocked and that although setting a low threshold helps in blocking more addresses, most attacks are performed by a few addresses, and therefore increasing it is a viable strategy.

Fig. 16
figure 16

Number of blocked addresses for different values of thresholds, up to 200

Full size image

8 Conclusions and future works

NFTs are becoming an integral part of Web3 applications as blockchain-based tokens to represent the ownership of unique physical or digital assets. Lately, many concerns have been raised due to vulnerability issues around NFTs. Of all, smart contract vulnerabilities are among the most important ones because the information stored on the blockchain cannot be tampered with and cannot be modified.

In this paper, we focus on sleepminting, which is an attack where faulty contracts are deployed on the blockchain. Thanks to these contracts, an attacker can transfer NFTs even if they do not own them or are not approved addresses, cheating on the provenance and ownership of the tokens. Thanks to our analyses, we are able to characterise better the phenomenon, which has now migrated mainly to the Polygon blockchain. Moreover, thanks to our analyses we discovered that metaverse applications and blockchain games, in general, are more affected. We propose a sleepminting prevention system that is based on analysing the transactions that are added to the blockchain to keep track of the user and contract addresses that are involved in sleepminting activity. With this information, block-creating nodes can add another step when deciding to add a transaction to a block, based on the number of times a user or contract address appear to be involved in sleepminting, and blocking the transactions according to a threshold. We test our approach, which is able to block up to 87% attacks, and the effects of having different values of the threshold, both in terms of the number of attacks blocked and the number of user or contract addresses blocked. Our analysis of the sleepminting phenomenon enriches the knowledge about this kind of attack because it allows having an in-depth understanding of how the attacks are carried out and therefore how to prevent them. Principally, there are two aspects that play a crucial role: time and addresses. Time is important because, as we showed, attacks can be as frequent as happening more than once in the same blocks, and therefore a prevention system should be able to inspect transactions at the same rate at which they are validated. Additionally, the analysis of the addresses uncovers important patterns of the attacks, indeed, as we uncovered, the majority of attacks are performed by a limited number of attackers and contracts.

In future works, we plan to design a technique for setting a threshold to be used by miners using our technique and explore the possibility of having a moving threshold or separate thresholds for user and contract addresses. We also plan to implement a smart contract that keeps track publicly and transparently of the sleepminting activity of the addresses in the blockchain network. Additionally, we plan to tackle other NFT attacks and find specific solutions to these problems. Finally, as explained in the Introduction section, our approach has several benefits, however, it shows some limitations that need to be faced in future extensions. The main limitation concerns the frequency dictionary which could be growing up to the point where checking if a transaction does not involve a suspicious address could introduce delays in the validation process. For this reason, we plan to investigate a way to reduce the size of the frequency dictionary. Additionally, another important limitation concerns the fact that we are primarily focusing on EVM-like blockchains, therefore in future works we plan to extend our study and prevention system to other blockchains.