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, forming a chain of data called the blockchain.

[0004] The information stored within 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 previous block, which chains the blocks together to create a permanent, immutable record of all transactions 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 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." Tokens act as identifiers that allow a real-world asset to be referenced from the blockchain. Fungible tokens represent assets that can be substituted, while non-fungible tokens (NFTs) represent assets that cannot be substituted.

[0009] Each fungible token is identical to other fungible tokens of the same type and can be divided 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 indivisible from other tokens of the same class. Thus, the basic unit of a non-fungible token is the token itself.

[0010] Non-fungible tokens can thus be thought of as digital assets, or tokenized versions of real-world assets. 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. Identifying 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 explanation of the drawings]

[0012] It should be noted 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. [Figure 2] FIG. 2 is a block diagram of an example embodiment of a distributed blockchain system 200 implementing a computer-implemented ledger. [Figure 3] 3 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. [Figure 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 INVENTION

[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. 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 appropriate network protocols 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 a smart contract.

[0020] The transaction analyzer 114 can examine and extract relevant data from transactions executed 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 that users use to query 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 standard input and output to a user, including a keyboard, display, and audio 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] The blockchain 106 can be any system that implements a distributed ledger in which smart contracts for non-fungible tokens are transacted, stored, and maintained.

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

[0026] In an exemplary 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] Address profile 122 may comprise a model for each wallet address involved in a transaction on blockchain 106. Each model may comprise attributes of the wallet address, which may 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 enables 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 asset; a royalty percentage to be passed on to the creator for each resale; a smart contract address on the blockchain; whether the underlying asset can be resold; the address on the blockchain of the creator of the non-fungible token; the edition number of the underlying asset; the title of the underlying asset; a link to the sales list for the non-fungible token; a downloadable file for the underlying asset; the name of the underlying asset; and the total number of editions of the underlying asset.

[0032] The blockchain system 200 comprises a number of 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. Nodes 202, 204, 206, and 208 exchange messages within blockchain network 210 to update and synchronize the ledgers stored and maintained by each of 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 exemplary 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, when 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 skilled 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 particular non-fungible tokens.

[0039] In another embodiment, the blockchain 106 is regularly scanned to identify relevant blocks for a particular non-fungible token. Once identified, the 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 is retrieved, the server 102, in S308, retrieves the ownership history for the particular non-fungible token from the retrieved metadata.

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

[0043] An ownership issue can be determined based on several factors, including: Factors that may contribute to a reduced provenance score include 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 been on the blockchain for a longer period of time.

[0045] Another factor that can contribute to a reduced provenance score is an address that deploys a smart contract on a blockchain that has not previously been 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] For 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 its analysis of the most recent smart contract code for a particular non-fungible token.

[0052] The server 102 then generates, at S318, a permanence 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 its 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 can affect the extent to which the underlying asset can be modified or actually deleted. Specifically, what is stored on the blockchain is permanent and immutable. What is stored outside the blockchain can potentially be lost, and for non-fungible tokens, the reference can be corrupted, affecting their value.

[0054] In an exemplary 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. A low permanence risk can reflect a scenario in which the metadata and underlying assets are stored on the same blockchain. A high permanence risk can reflect a scenario in which 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 that implements 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, predefined scenarios may include the following on a blockchain: direct instruction to decentralized storage using pinning; direct instruction to decentralized storage without pinning; indirect instruction to decentralized storage using pinning; indirect instruction to decentralized storage without pinning; and centralized storage. Each of these scenarios may be assigned a number reflecting its persistence risk. Specifically, storage on a 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 numbers between one (1) and six (6) according to their respective persistence risks.

[0059] Finally, the server 102 generates a comprehensive risk score for the particular non-fungible token at S320. The generated comprehensive risk score indicates how risky the 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 which 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 exemplary 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 the transaction history stored in the blockchain 106 for each owner included in the ownership history of a particular non-fungible token.

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

[0064] For example, for a smart contract that conforms to 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; Calculate percentage ownership by dividing the number of unique wallet addresses by the token supply; The lower the calculated percentage, the greater the risk of ownership concentration.

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

[0066] For example, a wallet can 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 previous 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 in the transaction history of any owner included in the ownership history of the particular non-fungible token. Any layering or concealment attempts regarding stolen cryptocurrency can 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 exemplary embodiments, provenance risk may be assigned a numerical value that reflects the risk associated with the ownership history of the non-fungible token. For 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 rule-based expert system or artificial intelligence model implemented on the server 102 .

[0073] An expert system or artificial intelligence model can be provided and trained using multiple parameters related to the ownership history of the non-fungible token.

[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 this 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 frauds, 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 regular transactions with other sanctioned accounts.

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

[0081] 5 is a flow diagram of an exemplary 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 may 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 the token holder out of access to the asset.

[0084] As another example, this specific 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 by 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 have a globally unique and persistent contract address and token ID pair and implement 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 no 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] An expert system or artificial intelligence model can be provided and trained using multiple parameters related to the ownership history of the non-fungible token.

[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 over a defined period of time through 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.

[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 exemplary 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 the permanence 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] Next, the server 102, at S606, retrieves the smart contract score for the particular non-fungible token.

[0102] Finally, in S608, the server 102 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 exemplary embodiments, 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 rule-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: receiving a request for valuation for 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 includes 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 within 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; 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; 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; A system for evaluation configured to:

6. 10. The system for valuation 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 evaluation of claim 1, wherein the smart contract score reflects a risk associated with code associated with the particular non-fungible token.

Images