TokenPatronus: A Decentralized NFT Anti-theft Mechanism

We design the TokenPatronus mechanism following the one-two-three-four principle, that is, one mechanism, two layers, three stages, and four modules. TokenPatronus mechanism covers the protection of NFT collections during the complete transaction flow, of which the scheme is shown in Fig. 1. When the target NFT is minted, the initial status is unlocked, and the user can choose to lock the token through the front-end page so that the contract will ban any further transactions. Once the user starts a new transaction with the NFT at the unlocked status, our DRM engine will begin to analyze the safety of this transaction. TokenPatronus will allow risk-free transfers and interrupt suspicious ones. The interrupted transactions will be frozen and reviewed by the decentralized arbitration. For the transfers that are determined to be hacked, the risk management engine will ask the smart contract to return the NFT to previous account automatically.

Specifically, we divide the transaction of the NFT into three stages, and design the corresponding role of TokenPatronus respectively, covering pre-event protection, in-event interruption and post-event process. Four modules make up the TokenPatronus anti-theft mechanism, including the decentralized identification module, decentralized risk management engine, decentralized arbitration system and ERC-721G contract standard. To ensure the trust and the robustness, we designed four decentralization-based modules to make up the TokenPatronus mechanism, containing the decentralized access control, the decentralized risk management engine, the decentralized arbitration system and the ERC-721G smart contract standard. The details of these three stages and four modules is described in the following sections.

The pre-event stage represents the status when the token is airdropped or transferred to a wallet address. The initial status of this token is unlocked, and TokenPatronus provide a function to lock it. When the owner wants to hold this NFT for a long time, he/she can choose to lock the token via the decentralized access control (DAC) module. Once the token status change to locked, any further transactions or listing on the trading market will be rejected. The verification in the DAC module requires an additional wallet signature. See Section IV-A for more description of the DAC module. In addition, we develop a front-end web to facilitate users in managing their NFTs, with the option to easily add and unlock operations, as shown in Fig. 2.

Since NFTs can be locked in pre-protection, they cannot be sold or transferred even if a hacker has all the access to the wallet. however, there is still a chance that NFTs in an unlocked state can be lost, and we design a risk control engine at this stage to block potentially stolen NFT transactions. Specifically, each NFT transfer is passed through a DRM engine to evaluate the security of that transaction. This process is similar to the risk control system of a bank, whereas we use the oracle to implement the DRM engine. The engine outputs three status for the corresponding transaction: safe, may lost and hacked. if the engine finds the transaction suspicious, it outputs the NFT state as may lost, and the contract will freeze the NFT transaction privileges for a period of time. If the engine outputs the NFT status as hacked, the NFT will be locked and transferred to the treasury. The real owner of this NFT has the right to recover the stolen NFTs through a decentralized arbitration system.

As discussed in the previous section, we cannot guarantee that all NFTs are not stolen, nor can we guarantee that the DRM engine can output 100% correct adjudication results. Therefore, we designed the decentralized arbitration system to handle NFTs stolen by hackers or incorrectly intercepted. Users can report a theft incident through the decentralized arbitration system, and if the system decides that the user is a victim, the NFT will be returned to the user’s wallet address. In the TokenPatronus mechanism, the decentralized arbitration system, as the core part of post-event replevin, is the last anti-theft safeguard, and it has the root permission to dispose of this NFT ownership.

When unlocking the NFT, the holder needs to confirm that they are operating on their own and accept the risk of transferring and transacting after unlocking, and that they bear some responsibility. If, during a transaction or transfer, the recipient does not register a sub address with the main address, then the transaction still stands. However, after the recipient receives the NFT, the NFT is locked by default and the next transfer or transaction must be registered and unlocked at the main address before it can continue. In this process, the DRM system will monitor the whole process and make risk prevention in advance.

As is shown in Fig. 3, we require a sub address to validate the ownership of the NFT. The NFT can only be displayed if the user is not registered on the front-end web. Once adding an auxiliary wallet and unlocking the NFT, the user is able to list this NFT or transfer it.

The decentralized risk management is the key component of the TokenPatronus mechanism, which provide the necessary validation of the smart contract. The diagram of the proposed decentralized risk management engine is shown in Fig. 4, which is based on the the big data analysis engine. The engine evaluates the risk via eight sources, i.e., the NFT collections, address information, connected wallet information, the contract status (locked or unlocked), decentralized data storage, filtration rule, trusted computing and open-sourced AI inference. We evaluate the credit score corresponding to both sides of this transaction by obtaining the number and price of the NFT collection at the target wallet address; the contract also allows us to obtain whether there is an abnormal record of previous transactions in this NFT; and to query whether there is suspicious behaviour flagged by Etherscan²²2https://etherscan.io/ through the high-frequency trading accounts associated with the trading account. In addition, we have designed some rule-based filters, such as marking the trade as may lost if the price is significantly below the floor price or the turnover rate is too high. We also design a deep learning model from the transaction history stored in the decentralized storage and open-source the corresponding inference code. The corresponding evaluation process is done via the trusted computing. The decentralized risk management will combine all the above information to assess the risk status of this transaction.

The Decentralized arbitration System (DAS) is a module for determining the ownership of NFTs when there is a reported loss. The victim must submit a deposit to ensure that no hacker takes advantage of the rule loophole to maliciously report the incident, and the price of the deposit fluctuates according to the value of the NFT, which is generated by a deep learning algorithm. Once the report is confirmed, the status of the corresponding NFT will be changed to may lost. The current owner of the NFT and the person reporting the theft incident can challenge the ownership of the NFT, such as uploading conversation log as an attachment to the system. The final ownership of the NFT is decided by a vote of the members of the referee DAO. This vote follows a Byzantine fault tolerance mechanism to prevent jury members from cheating. The jury members who ultimately participate in the decision are eligible to be assigned the corresponding honor and some monetary reward is given by the system. DAS results will interact with the contract and the contract reclaims the NFT to the post-verdict wallet address and the gas fee for the transaction is borne by the reporter.

TokenPatronus interacts with two smart contracts written in Solidity. One is the ERC-721G, a ERC-721 compatible standard with anti-theft features. The other is the oracle contract, which links ERC-721G to TokenPatronus risk control engine. The oracle contract is also the only legal operator of the ERC-721G when normal users lock/unlock their NFTs and the only legal proxy of risk control engine to reclaim or judge the NFTs.

The design and implementation of oracle contract is trivial, with two sets of functions: request methods and fulfill methods. ERC-721G NFT holders invoke transfer related functions on ERC-721G to transfer their assets. For a token in locked status, every transfer operation will trigger a request from ERC-721G to the oracle contract. After the request is invoked, a message will be logged on chain, which will later be captured by the risk contmrol engine and activate the risk control procedure. Fulfill methods are only invoked if a risk is investigated to reclaim a token and freeze it for future judgement.

ERC-721G is not built from nothing, but based on an existed ERC-721 implementation. The difference between ERC-721G and the standard ERC-721 is that ERC-721G contains the anti-theft part, which mainly extends following section:

First, we add a structure to the major contract, ERC-721G:

The _tokenStates map structure holds every state of token, namely OK, LOCKED and RECLAIMED. If _tokenStates[tokenID] is OK, it means the asset can be transferred without any resistance. Otherwise, the token cannot be transferred or approved. A reclaimed token cannot be unlocked by previous holders directly, which depends on the result of judgement.

Second, we create a modifier:

The modifier will extract the state of the token with exact tokenID, and check whether the token has a legal state to be approved or transferred.

Third, we add the above modifier to the following ERC-721 standard methods for protecting:

Finally, we also override setApprovalForAll method, making it supervised by risk control engine to prevent the asset from malicious (phishing)site/hacker.