System and method for assessing risk scores for non-fungible tokens traded on a blockchain

Abstract

A system for assessing risk scores for non-fungible tokens (NFTs) traded on a blockchain, the system is configured to: generate a provenance score based on a derived ownership history for the particular NFT; generate a smart contract score based on a retrieved smart contract code for the particular NFT; generate a permanence score based on the retrieved smart contract code for the particular NFT; and generate a comprehensive risk score for the particular NFT based on the generated provenance score, smart contract score, and permanence score for the particular NFT.

Description

[Technical field]

[0001] The present application relates to a system and method for assessing risk scores for non-fungible tokens traded on a blockchain.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 336,993, filed April 29, 2022, the entire contents of which are incorporated by reference for all purposes. [Background technology]

[0003] A blockchain is a peer-to-peer (P2P) electronic ledger implemented as a distributed database shared among computer network nodes. The ledger comprises a series of data blocks, each capable of storing a certain amount of information. Once a block is full, it is closed and linked to the previous full block, thus forming a chain of data, which is called the blockchain.

[0004] The information stored in each block can include transactions, which are data structures that encode the transfer of control of digital assets between participants on a computer network that implements an electronic ledger and that contain at least one input and at least one output. Each transaction also contains scripts embedded in the inputs and outputs that specify who can access the transaction's outputs and how.

[0005] The information stored in each block also includes the hash of the block that preceded it; the hashes chain the blocks together to create a permanent, immutable record of every transaction that has been written to the blockchain since its inception.

[0006] In order for a transaction to be written to the blockchain, it must be "validated." Nodes on the network do the work to ensure that each transaction that is eventually written to the blockchain is valid.

[0007] Blockchains can be used to implement "smart contracts," which are computer programs designed to automate the execution of machine-readable contracts or agreements. A smart contract is a machine-executable program with rules that process inputs and take actions that depend on those inputs. These actions may include the transfer of property rights or assets. These assets may include real property, personal property, tangible and intangible property, digital assets such as software, or other types of assets.

[0008] Assets are represented and transferred on the blockchain using "tokens". A token acts as an identifier that allows a real-world asset to be referenced from the blockchain. A fungible token represents an asset that can be substituted, whereas a non-fungible token (NFT) represents an asset that cannot be substituted.

[0009] Each fungible token is identical to other fungible tokens of the same type and is divisible into smaller amounts. Thus, portions of fungible tokens can be transferred between users on the blockchain. In contrast, each non-fungible token is unique and, unlike other tokens of the same class, indivisible. Thus, the basic unit of a non-fungible token is the token itself.

[0010] Thus, non-fungible tokens can be considered as digital assets or tokenized versions of real-world assets, and within a blockchain network, they serve as verifiable proof of authenticity and asset ownership. Non-fungible tokens are therefore not interchangeable, bringing scarcity to the digital world. Identification information is embedded within the non-fungible token's smart contract, which supports its uniqueness. This uniqueness makes them ideal for recording and remembering ownership of digital items such as collectibles, games, and art.

[0011] However, there are also risks associated with using non-fungible tokens. Such risks may include money laundering risks, smart contract risks, etc. What is needed are systems and methods configured to provide insight into the various risks associated with non-fungible tokens and their underlying assets. [Brief description of the drawings]

[0012] Please note that the drawings are for illustrative purposes only and are not necessarily drawn to scale. The drawings are not intended to limit the scope of the invention. Wherever possible, like or similar reference numerals will be used in the drawings to refer to like or similar parts.

[0013] [Figure 1] FIG. 1 is a block diagram of an example embodiment of a system 100 for assessing a comprehensive risk score for non-fungible tokens traded on a blockchain. [Diagram 2] FIG. 2 is a block diagram of an example embodiment of a distributed blockchain system 200 implementing a computer-implemented ledger. [Diagram 3] 1 is a flow diagram of an example embodiment of a computer-implemented method 300 for assessing a risk score for a non-fungible token traded on a blockchain. [Figure 4]4 is a flow diagram of an example embodiment of a computer-implemented method 400 for assessing provenance scores for non-fungible tokens traded on a blockchain. [Diagram 5] 5 is a flow diagram of an example embodiment of a computer-implemented method 500 for evaluating smart contract scores for non-fungible tokens traded on a blockchain. [Figure 6] 6 is a flow diagram of an example embodiment of a computer-implemented method 600 for calculating a risk score for a non-fungible token traded on a blockchain. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] The present application relates to a system and method for assessing risk scores for non-fungible tokens traded on a blockchain.

[0015] 1 is a block diagram of an example embodiment of a system 100 for assessing a risk score for a non-fungible token (NFT) traded on a blockchain. The system 100 may include a server 102, a client host computer 104, a blockchain 106, a network-based storage or database 108, and a network 110.

[0016] The network 110 may enable the server 102, the client host computer 104, and the blockchain 106 to interact over a communications network. The network 110 may be a local area network (LAN), a wide area network (WAN), or the Internet, and may use any suitable network protocol and web services.

[0017] The server 102 can be a processor-based computing system that can execute instructions that specify actions to provide web-based activities and implement expert or artificial intelligence (AI) models. The processor-based computing system can comprise a single computing machine or a collection of computing machines that can individually or collectively execute sets of instructions that define web-based services and expert or AI systems.

[0018] In an exemplary embodiment, the server 102 may implement a blockchain interface 112, a transaction analyzer 114, a profiler 116, and a scoring application programming interface (API) 118.

[0019] The blockchain interface 112 can scan all blocks written to the blockchain 106 to extract transaction data and add the extracted data to a transaction depository stored in the database 108. The blockchain interface 112 can also interpret the application binary interface of smart contracts.

[0020] The transaction analyzer 114 can examine and extract relevant data from transactions performed on the blockchain 106.

[0021] Based on the data from the transaction analyzer 114, the profiler 116 can create address and contract profiles on the database 108 for each user's wallet address and contract address.

[0022] The scoring API 118 may be an interface through which a user queries the system 100 for the overall risk scores of smart contracts on the blockchain 108.

[0023] The client host computer 104 can be any processor-based device that allows a user to communicate with the server 102 and the blockchain 106 over the network 110. The client host computer 104 can provide a user with standard input and output, including a keyboard, display, and voice capabilities. The client host computer 104 can be any processor-based device, including a desktop computer, a laptop computer, a smartphone, or any other similar type of device known to those skilled in the art.

[0024] Blockchain 106 may be any system that implements a distributed ledger in which smart contracts for non-fungible tokens are transacted, stored, and maintained.

[0025] Network-based storage 108 may be any network-enabled third-party storage that allows for the storage and access of underlying assets that non-fungible tokens may reference over network 110. Network-based storage 108 may have a centralized or distributed configuration and may implement various types of file systems.

[0026] In the example embodiment, the network-based storage 108 may include a transaction repository 120 , an address profile 122 , and a contract profile 124 .

[0027] The transaction repository 120 may contain a record of each transaction associated with each smart contract implemented on the blockchain 106.

[0028] The address profile 122 can include a model for each wallet address involved in a transaction on the blockchain 106. Each model can include attributes of the wallet address, which can include transaction volume, cumulative value, and tags that define the behavior of the wallet address.

[0029] The contract profile 124 may comprise a model for each smart contract executed on the blockchain 106. Each model may comprise attributes for the smart contract, which may include token supply, total token circulation, lifetime transaction volume, weekly / daily rolling transaction volume, average transaction size, and smart contract event history.

[0030] FIG. 2 is a block diagram of an example embodiment of a distributed blockchain system 200 that implements a computer-implemented ledger.

[0031] The blockchain system 200 is a distributed ledger peer-to-peer network that allows for trustless processing and recording of transactions, including the movement and recording of tokens. The blockchain records transactions in the form of a cryptographically secured backlinked list of blocks. Each block can contain a record of a non-fungible token, including metadata about the non-fungible token. The metadata can include: a URL linking to an image file for the non-fungible token's asset; a percentage of royalties to be passed on to the creator for each resale; a smart contract address on the blockchain; whether the underlying asset can be sold again; an address on the blockchain of the creator of the non-fungible token; an edition number of the underlying asset; a title of the underlying asset; a link to a sales list of the non-fungible token; a downloadable file of the underlying asset; a name of the underlying asset; and a total number of editions of the underlying asset.

[0032] The blockchain system 200 comprises multiple computing devices configured as nodes 202, 204, 206, and 208 interconnected via a blockchain network 210.

[0033] Each node 202, 204, 206, and 208 locally stores and maintains an identical copy of the blockchain ledger 212, 214, 216, and 218. The nodes 202, 204, 206, and 208 exchange messages within the blockchain network 210 to update and synchronize the ledgers stored and maintained by each of the nodes 202, 204, 206, and 208.

[0034] Nodes 202, 204, 206, and 208 may also execute decentralized applications (e.g., smart contracts) for processing messages, including the exchange of tokens within blockchain network 210. The messages may include information about the confirmed transfer of tokens as well as the blockchain public keys for each party participating in the transfer.

[0035] 3 is a flow diagram of an example embodiment of a computer-implemented method 300 for assessing a comprehensive risk score for a non-fungible token traded on a blockchain. The computer-implemented method 300 begins at S302, where the server 102 accesses the blockchain 106 via the network 110, which contains transactions for a particular non-fungible token.

[0036] Once accessed, the server 102, at S304, scans the blockchain 106 to identify all blocks within that blockchain 106 that contain smart contracts for the particular non-fungible token.

[0037] The blockchain 106 can be scanned using any block explorer known to those of skill in the art for the particular blockchain type, such as Etherscan for the Ethereum blockchain.

[0038] In one embodiment, relevant blocks are identified based on a real-time scan of the blockchain 106 that contains smart contracts for a particular non-fungible token.

[0039] In another embodiment, the blockchain 106 is regularly scanned to identify relevant blocks for a particular non-fungible token. Once identified, information in the relevant blocks can be stored on the database 108 and can be regularly updated as needed based on subsequent scans of the blockchain 106. In this embodiment, the database 108 can store information from relevant blocks for multiple non-fungible tokens. The data stored on the database 108 can be indexed to retrieve stored information for a particular non-fungible token that was previously scanned in the blockchain 106.

[0040] Once the blocks are identified, the server 102, at S306, retrieves the metadata embedded within the smart contracts stored in each of the identified blocks.

[0041] Once the metadata has been retrieved, the server 102, in S308, retrieves the ownership history for the particular non-fungible token from the retrieved metadata.

[0042] The server 102 then generates, at S310, a provenance score for the particular non-fungible token based on an analysis of the retrieved ownership history. The generated provenance score reflects any ownership-related issues identified by the server 102 based on the server's 102 analysis of the ownership history of the non-fungible token.

[0043] An ownership issue can be determined based on multiple factors, one of which may contribute to a reduction in provenance score is if the address that deployed the smart contract is identified as high risk, either associated with a sanctioned account or previously identified as a malicious entity.

[0044] Another factor that may contribute to a reduced provenance score is the age of the smart contract since it was first deployed on the blockchain. Smart contracts that have only recently been deployed may be considered to pose more risk than others that have a longer history on the blockchain.

[0045] Another factor that may contribute to a reduced provenance score is an address that deploys a smart contract on a blockchain that has not been previously deployed on the same blockchain.

[0046] A factor that can increase the provenance score is an address that has deployed a smart contract on the blockchain and has a name service that resolves to that same address.

[0047] Next, the server 102, at S312, identifies a block in the blockchain in which the most recent transaction for the particular non-fungible token is stored.

[0048] Once the most recent block is identified, the server 102, in S314, retrieves the smart contract code stored in the identified block.

[0049] By way of example, the retrieved smart contract code can be bytecode, which can then be decompiled into a human-readable programming language.

[0050] The server 102 then generates a smart contract score, at S316, based on an analysis of the retrieved smart contract code for the particular non-fungible token.

[0051] The generated smart contract score reflects any code-related issues identified by the server 102 based on the analysis of the latest smart contract code for a particular non-fungible token.

[0052] The server 102 then generates, at S318, a persistence score for the particular non-fungible token based on further analysis of the current smart contract code.

[0053] The generated permanence score reflects issues associated with any asset identified by the server 102 based on the analysis of the current smart contract code, and more specifically, how the smart contract references the underlying asset of a particular non-fungible token. How the smart contract references the underlying asset may affect the extent to which the underlying asset can be modified or deleted in reality. Specifically, what is stored on the blockchain is permanent and immutable. What is stored outside of the blockchain can potentially be lost, and references to the non-fungible token may be corrupted, affecting its value.

[0054] In an example embodiment, the permanence score can range from zero (0) to one hundred (100), with zero representing low permanence risk and one hundred representing high permanence risk. Low permanence risk can reflect a scenario where the metadata and the underlying assets are stored on the same blockchain. High permanence risk can reflect a scenario where the metadata is stored on the blockchain but the underlying assets are stored on an external centralized server.

[0055] A range of moderate persistence risk scores can exist between the defined low and high risks, with scores ranging from one (1) to ninety-nine (99).

[0056] A first medium permanence risk can reflect a scenario in which the metadata and the underlying asset are stored on different blockchains. A second medium permanence risk can reflect a scenario in which the metadata is stored on the blockchain but the underlying asset is stored on distributed storage. Finally, a third medium permanence risk can reflect a scenario in which the metadata is stored on the blockchain and the underlying asset is stored on network storage implementing a distributed file system.

[0057] In another exemplary embodiment, the permanence score can be assigned according to predefined scenarios that describe different ways to store the underlying asset.

[0058] For example, the predefined scenarios may include the following on the blockchain: direct instruction to distributed storage with pinning; direct instruction to distributed storage without pinning; indirect instruction to distributed storage with pinning; indirect instruction to distributed storage without pinning; centralized storage. Each of these scenarios may be assigned a number reflecting its persistence risk. Specifically, storage on the blockchain may be assigned a number of one (1) as the lowest persistence risk, and centralized storage may be assigned a number of six (6) as the highest persistence risk. The remaining scenarios may be assigned a number between one (1) and six (6) according to their respective persistence risks.

[0059] Finally, the server 102 generates S320 a comprehensive risk score for the particular non-fungible token. The generated comprehensive risk score indicates how risky a smart contract for the particular non-fungible token is. The comprehensive risk score reflects a combination of the generated provenance score, smart contract score, and permanence score for the particular non-fungible token.

[0060] In embodiments, the overall risk score may be a weighted risk score with respect to all individual risk scores, including the provenance score, the smart contract score, and the persistence score. Each of the individual risk scores may be assigned a weight based on which of the individual risks is more important to the consumer in the overall risk score.

[0061] In an exemplary embodiment, the global risk score can be defined as:

number

[0062] 4 is a flow diagram of an example embodiment of a computer-implemented method 400 for assessing provenance scores for non-fungible tokens traded on the blockchain 106. The computer-implemented method 400 begins at S402, where the server 102 searches transaction histories stored in the blockchain 106 for each owner included in the ownership history of a particular non-fungible token.

[0063] Next, at S404, the server 102 identifies any high ownership concentrations within the blockchain 106 for any owners included in the ownership history for the particular non-fungible token based on the searched transaction history.

[0064] For example, for a smart contract that complies with the ERC-721 standard, ownership concentration can be determined in the following manner: Retrieve the token supply using the tokenURI() function; Identify the owner wallet address of each token using the ownerOf() function to determine the number of unique wallet addresses; and Calculate the percentage ownership by dividing the number of unique wallet addresses by the token supply. The lower the calculated percentage, the higher the risk of ownership concentration.

[0065] Next, the server 102, at S406, identifies any sanctioned accounts included within the transaction history of any owner included within the ownership history of the particular non-fungible token.

[0066] For example, a wallet may be identified as sanctioned if it is listed on a government sanctions list, such as the Specially Designated Nationals List maintained by the U.S. Department of the Treasury.

[0067] As another example, a wallet can be identified as sanctioned if there has been past on-chain interaction between the wallet and an entity on a sanctions list.

[0068] The server 102 then identifies, at S408, any fraudulent sources of funds used within the transaction history of any owner contained within the ownership history of the particular non-fungible token. Any attempts at layering or concealing stolen cryptocurrency may be identified and tagged.

[0069] For example, the source of illicit funds can be determined by tracing transaction traces on the blockchain from known hacking and theft cases.

[0070] Finally, the server 102 generates a provenance score for the particular non-fungible token, at S410. The provenance score reflects the risk associated with any ownership associated with the particular non-fungible token based on an analysis of the ownership history of the non-fungible token.

[0071] In an exemplary embodiment, provenance risk may be assigned a numerical value and may reflect the risk associated with the ownership history of the non-fungible token. By way of example, it may be assigned a numerical value ranging from zero (0) to one hundred (100), with zero (0) reflecting no risk and one hundred (100) reflecting a high degree of risk.

[0072] In another exemplary embodiment, the analysis of ownership history can be performed using a rules-based expert system or artificial intelligence model implemented on the server 102 .

[0073] The expert system or artificial intelligence model can be provided and trained using a number of parameters related to the ownership history of the non-fungible tokens.

[0074] For example, parameters may include the current balance of a wallet used to purchase non-fungible tokens, which may be compared to other wallet balances and tagged based on the comparison.

[0075] Another parameter is the timing and frequency of transactions of the wallet used to purchase non-fungible tokens.

[0076] Another parameter is the average transaction volume of wallets used to purchase non-fungible tokens.

[0077] Another parameter is the average time between the purchase and sale of a non-fungible token for the wallet used to purchase the same non-fungible token.

[0078] Another parameter is that the wallet used to purchase the non-fungible token is included in a list of known prevalent fraud, hacking incidents, or any other security events that are regularly maintained and updated to accurately reflect current transactions on multiple blockchains.

[0079] Another parameter is the interaction of the wallet used to purchase the non-fungible token with the sanctioned account, which may include the wallet itself being sanctioned or the wallet having routinely transacted with other sanctioned accounts.

[0080] Finally, another parameter is the validation status from the marketplace of the wallet used to purchase the non-fungible token.

[0081] 5 is a flow diagram of an example embodiment of a computer-implemented method 500 for evaluating a smart contract score for a non-fungible token traded on the blockchain 106. The computer-implemented method 500 begins at S502, where the server 102 analyzes the smart contract code for a particular non-fungible token to identify any potentially malicious backdoor type risks embedded within the code.

[0082] Malicious backdoor type risks can be identified by analyzing the decompiled bytecode of a smart contract for specific behavior, which can include, for example, the arbitrary transfer of tokens from the owner's wallet to another address.

[0083] As another example, this particular behavior may include allowing the smart contract owner to prevent the token holder from transferring the token; thereby effectively locking out the token holder from accessing the asset.

[0084] As another example, this particular behavior could include allowing the smart contract owner to blacklist some addresses for token transfers; thereby reducing the value of the tokens.

[0085] As another example, this particular behavior could include allowing the owner of the smart contract to issue an infinite number of tokens; thereby diluting the value of existing tokens.

[0086] As another example, this particular behavior may include allowing a smart contract to call other smart contracts that are not accessible to the bytecode.

[0087] Next, the server 102, at S504, analyzes the smart contract code for the particular non-fungible token to verify compliance with defined standards for non-fungible token contracts.

[0088] In an exemplary embodiment, smart contract code is analyzed for compliance with the Non-Fungible Token Standard, which, among other requirements, requires that each smart contract has a globally unique and persistent contract address and token ID pair and implements a defined API.

[0089] Finally, the server 102 generates a smart contract score for the particular non-fungible token at S506. The smart contract score reflects the risk associated with the code associated with the particular non-fungible token based on an analysis of the smart contract code.

[0090] Exemplary embodiments may assign a numerical value to a non-fungible token to reflect the risk associated with the token's smart contract code. By way of example, a numerical value ranging from zero (0) to one hundred (100) may be assigned, with zero (0) reflecting a lack of risk and one hundred (100) reflecting a high degree of risk.

[0091] In another example embodiment, the analysis of the smart contract code can be performed using a rule-based expert system or artificial intelligence model implemented on the server 102.

[0092] The expert system or artificial intelligence model can be provided and trained using a number of parameters related to the ownership history of the non-fungible tokens.

[0093] For example, the parameters may include the amount of fungible currency currently held within the smart contract used to purchase the non-fungible token.

[0094] Another parameter is the age and deployment frequency of the smart contract used to purchase the non-fungible tokens.

[0095] Another parameter is the average selling price of transactions during a defined period of time by smart contracts used to purchase non-fungible tokens.

[0096] Another parameter is the frequency of transactions by the smart contract used to purchase the non-fungible token.

[0097] Another parameter is whether the smart contract code used to purchase the non-fungible token is open source or not.

[0098] Finally, another parameter is whether the smart contract code used to purchase the NFT has been verified by a third party such as Etherscan.

[0099] 6 is a flow diagram of an example embodiment of a computer-implemented method 600 for calculating a risk score for a non-fungible token traded on the blockchain 106. The computer-implemented method 600 begins at S602, where the server 102 retrieves a persistence score for a particular non-fungible token.

[0100] Next, the server 102, in S604, retrieves the provenance score for the particular non-fungible token.

[0101] The server 102 then, at S606, retrieves the smart contract score for the particular non-fungible token.

[0102] Finally, the server 102, in S608, generates a comprehensive risk score for the particular non-fungible token based on the retrieved permanence score, provenance score, and smart contract score.

[0103] In an exemplary embodiment, a numerical value may be assigned to the provenance risk to reflect the risk associated with the ownership history of the non-fungible token. By way of example, a numerical value ranging from zero (0) to one hundred (100) may be assigned, with zero (0) reflecting no risk and one hundred (100) reflecting a high degree of risk.

[0104] In another exemplary embodiment, the analysis of ownership history can be performed using a rules-based expert system or artificial intelligence model implemented on the server 102 .

[0105] This disclosure is not intended to limit the invention to the particular arrangements and / or methods disclosed, but rather to cover all modifications, equivalents, and alternatives falling within the scope of the appended claims.

Claims

1. 1. A system for assessing a risk score for a non-fungible token (NFT) traded on a blockchain, comprising: A blockchain capable of implementing smart contracts for the creation, storage, and trading of non-fungible tokens; a processor-based server in electronic communication with the blockchain; a database in electronic communication with the processor-based server, capable of storing and retrieving data; The processor-based server comprises: receiving a request for valuation of a particular non-fungible token on the blockchain; scanning the blockchain to identify a block within the blockchain that contains a smart contract for the particular non-fungible token; retrieving metadata embedded within the identified block that contains a smart contract for the particular non-fungible token; deriving an ownership history for the particular non-fungible token from the retrieved metadata; and scanning the blockchain to identify a block in the blockchain that contains a last transaction for the particular non-fungible token; Retrieving a smart contract code from the identified block containing the last transaction for the particular non-fungible token; generating a provenance score based on the derived ownership history for the particular non-fungible token; generating a smart contract score based on the retrieved smart contract code for the particular non-fungible token; generating a permanence score based on the retrieved smart contract code for the particular non-fungible token; generating a comprehensive risk score for the particular non-fungible token based on the generated provenance score, the smart contract score, and the permanence score for the particular non-fungible token; A system for evaluation configured to:

2. 10. The system for evaluation of claim 1, wherein the processor-based server further comprises: inputting the derived ownership history for the particular non-fungible token into a provenance score model implemented by the processor-based server; generating the provenance score using the provenance score model; and A system for evaluation configured to:

3. 10. The system for evaluation of claim 1, wherein the processor-based server further comprises: inputting the retrieved smart contract code for the particular non-fungible token into a smart contract score model implemented by the processor-based server; generating the smart contract score using the smart contract score model; A system for evaluation configured to:

4. 10. The system for evaluation of claim 1, wherein the processor-based server further comprises: inputting the retrieved smart contract code for the particular non-fungible token into a persistence score model implemented by the processor-based server; generating the persistence score using the persistence score model; and A system for evaluation configured to:

5. 10. The system for evaluation of claim 1, wherein the processor-based server further comprises: inputting the generated provenance score, the smart contract score, and the persistence score into a comprehensive risk score model implemented by the processor-based server; generating the comprehensive risk score using the comprehensive risk score model; and A system for evaluation configured to:

6. 2. The system for assessment of claim 1, wherein the provenance score reflects the ownership history of the particular non-fungible token.

7. 2. The system for evaluation of claim 1, wherein the permanence score reflects how the retrieved smart contract code references an underlying asset for the particular non-fungible token.

8. 2. The system for assessment of claim 1, wherein the smart contract score reflects a risk associated with code associated with the particular non-fungible token.

Images