On-chain crypto assets applied to off-chain electronic game leveling and progression

Abstract

A computer system operates an off-chain electronic game that includes in-game assets stored outside of a blockchain. The computer system detects the occurrence of a progression event related to a particular in-game asset associated with a particular player. In response to the occurrence, the computer system increases the upgrade capacity of the particular in-game asset. The upgrade capacity controls the maximum number of attribute upgrades that can be applied to the particular in-game asset at one time. The computer system then allows or prevents the application of the attribute upgrade to the particular in-game asset based on the upgrade capacity. The computer system further allows or prevents the application of the attribute upgrade based on whether the attribute upgrade has been applied to another off-chain electronic game. An interoperability API is used to determine whether a given attribute upgrade is used in another game.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application is a continuation of U.S. Non-Provisional Application No. 18 / 327,409, filed June 1, 2023, entitled "ON-CHAIN ​​CRYPTOGRAPHIC ASSETS APPLIED IN OFF-CHAIN ​​ELECTRONIC GAME LEVELING AND PROGRESSION," U.S. Non-Provisional Application No. 18 / 327,460, filed June 1, 2023, entitled "CROSS-GAME INTEROPERABILITY INTERFACES WITHIN A GAMING ENVIRONMENT WITH ON-CHAIN ​​CRYPTOGRAPHIC ASSETS," and U.S. Non-Provisional Application No. 18 / 327,460, filed June 1, 2023, entitled "GAME-SPECIFIC APPLICATION OF CRYPTOGRAPHIC ASSETS FOR ELECTRONIC GAME PROGRESSION IN A GAMING ENVIRONMENT." This application claims priority to and benefit of U.S. Non-provisional Application No. 18 / 327,488, entitled "ON-CHAIN ​​CRYPTOGRAPHIC ASSETS APPLIED IN OFF-CHAIN ​​ELECTRONIC GAME LEVELING AND PROGRESSION," filed October 31, 2022, and U.S. Provisional Application No. 63 / 381,699, entitled "ON-CHAIN ​​CRYPTOGRAPHIC ASSETS APPLIED IN OFF-CHAIN ​​ELECTRONIC GAME LEVELING AND PROGRESSION," filed October 31, 2022. The contents of each of the foregoing applications are incorporated herein by reference in their respective entireties.

[0002] FIELD OF THE INVENTION The present disclosure relates generally to techniques for the digital management of crypto-assets, as well as gaming applications and ecosystems that implement crypto-assets. [Background technology]

[0003] Computer games include electronic games that involve interaction with user interfaces or input devices, such as joysticks, controllers, keyboards, or motion-sensing devices, to generate visual feedback. The feedback is typically presented on a video display device, such as a TV set, monitor, touchscreen, or virtual reality headset. Video games may also be augmented by audio feedback delivered through speakers or headphones, or by other types of feedback, including haptic technology. Video games can be defined based on their platform and include arcade video games, console games, and personal computer (PC) games. More recently, gaming has expanded into mobile gaming through smartphones and tablet computers, virtual reality and augmented reality systems, and remote cloud gaming.

[0004] A non-fungible token (NFT) is typically a unique digital identifier that cannot be copied, substituted, or subdivided. Traditional NFTs are recorded on a blockchain and used to prove authenticity and ownership. Ownership of an NFT is recorded on the blockchain and can be transferred by its owner, allowing the NFT to be sold and traded. NFTs typically contain references to digital files such as photos, videos, and audio. However, traditional NFT business models rely on “selling” NFTs, while traditional video game business models rely on selling content upfront or in small increments through in-app purchases. Computer game players may want to “keep” game items accumulated throughout the game, even if the game servers are shut down. Therefore, the use of traditional NFTs poses challenges for traditional games and limits the use cases for blockchain-backed “game collectibles.” [Brief explanation of the drawings]

[0005] A detailed description of implementations of the present technology will be described and explained through the use of the accompanying drawings.

[0006] [Figure 1] FIG. 1 is a block diagram illustrating an example structure including a portion of a blockchain.

[0007] [Figure 2A] FIG. 1 illustrates an exemplary hashing algorithm.

[0008] [Figure 2B] FIG. 1 is a block diagram illustrating an exemplary crypto wallet.

[0009] [Figure 3] FIG. 1 is a flow diagram illustrating an exemplary process for cryptographic application of non-fungible tokens to electronic gaming.

[0010] [Figure 4] FIG. 1 is a flow diagram illustrating an exemplary process for cryptographic application of non-fungible tokens to electronic gaming.

[0011] [Figure 5A] FIG. 1 illustrates exemplary in-game items and characters.

[0012] [Figure 5B] FIG. 1 illustrates exemplary in-game items and characters.

[0013] [Figure 6] FIG. 1 is a flow diagram illustrating an exemplary process for cryptographic application of non-fungible tokens to electronic gaming.

[0014] [Figure 7] FIG. 1 is a flow diagram illustrating an exemplary process for cryptographic application of non-fungible tokens to electronic gaming.

[0015] [Figure 8] FIG. 1 is a flow diagram illustrating an exemplary process for cryptographic application of non-fungible tokens to electronic gaming.

[0016] [Figure 9] FIG. 1 is a block diagram illustrating an example machine learning (ML) system.

[0017] [Figure 10] FIG. 1 is a block diagram illustrating an exemplary computer system.

[0018] The technology described herein will become more apparent to those skilled in the art upon review of the detailed description in conjunction with the drawings. The embodiments or implementations illustrating aspects of the present invention are shown by way of example, and like reference numerals may refer to similar elements. While the drawings depict various implementations for illustrative purposes, those skilled in the art will recognize that alternative implementations may be employed without departing from the principles of the technology. Thus, while specific implementations are shown in the drawings, the technology is susceptible to various modifications. DETAILED DESCRIPTION OF THE INVENTION

[0019] Embodiments of the present disclosure are described more fully herein with reference to the accompanying drawings. Like numbers represent like elements throughout the several views, and exemplary embodiments are shown. However, aspects of the examples listed herein and concepts described herein can be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. The examples set forth herein are non-limiting examples, and are merely examples, among other possible examples.

[0020] Throughout this specification, multiple instances (e.g., "610") may implement a component, operation, or structure (e.g., "610a") that is described as a single instance. Furthermore, multiple instances (e.g., "610") collectively refer to a set of components, operations, or structures (e.g., "610a") that are described as a single instance. A description of a single component (e.g., "610a") applies equally to a similarly numbered component (e.g., "610b") unless otherwise indicated. These and other aspects, features, and implementations may be expressed as methods, apparatus, systems, components, program products, means or steps for implementing a function, and in other ways. These and other aspects, features, and implementations will become apparent from the following description, including the examples listed at the end of this specification.

[0021] The disclosed technology includes methods, devices, and systems for the cryptographic application of non-fungible tokens to electronic games. The term electronic games may be referred to as computer games or video games. Computer games include electronic games that involve interaction with a user interface or input device, such as a joystick, controller, keyboard, or motion-sensing device, to generate visual feedback. The feedback is typically presented on a video display device, such as a TV set, monitor, touchscreen, or virtual reality headset. Video games may also be augmented by audio feedback delivered through speakers or headphones, or by other types of feedback, including haptic technology. Video games can be defined based on their platform and include arcade video games, console games, and personal computer (PC) games. More recently, gaming has expanded to mobile gaming through smartphones and tablet computers, virtual reality and augmented reality systems, and remote cloud gaming.

[0022] The disclosed technology improves upon traditional game progression, incorporating blockchain-verified ownership of in-game assets (e.g., characters, items, environments) without significantly impacting game operation and performance. According to aspects disclosed herein, electronic games are operated off-chain, with the in-game assets, game engine, game servers, etc. for the electronic game residing outside the blockchain. In-game asset progression is characterized by increasing capacity, “slots,” or opportunities for in-game assets to be stocked with attribute upgrades or modifications. Attribute upgrades or modifications modify attributes, parameters, characteristics, or data associated with the in-game asset, and the attribute upgrades are represented by on-chain digital assets such as NFT attribute cards. For example, a given NFT attribute card represents a 10-point increase to the damage parameter of an in-game item asset, and application of a given NFT attribute card to the in-game item asset increases the damage parameter by 10 points. As another example, the number of hit points (HP) of an in-game character asset may be increased based on application of a given NFT attribute card to the in-game character asset. Thus, as discussed, an in-game progression event (e.g., a level-up event) for an in-game asset is tied to the in-game asset's capacity for attribute upgrades (through the application of NFT attributes) rather than to the attribute upgrades themselves. As such, upon the occurrence of an in-game progression event, the in-game asset's ability parameters are modified, and the in-game asset's attributes, parameters, characteristics, or data are not necessarily upgraded in the in-game progression event.

[0023] The attribute upgrades or modifications are represented and defined by on-chain cryptographic assets (e.g., NFTs) owned by the player. Thus, while the electronic game and in-game assets are located off-chain to reduce dependency on slow blockchain-related operations, the ownership verification functionality provided by the blockchain is leveraged to provide players with ownership of the attribute upgrades for their in-game assets. Indeed, in some instances, ownership of in-game attribute upgrades is not managed by the game itself, thereby reducing the game size and resource footprint of the game. Instead, the ownership functionality provided by the blockchain (e.g., via cryptographic wallets and on-chain consensus) is used to authenticate that a player owns a particular in-game attribute upgrade for use in the game and / or to authorize a player's ability to use a particular in-game attribute upgrade in the game.

[0024] The disclosed method for "leasing" NFTs in a crypto wallet across multiple games enables prevention of multiple spending and misuse of NFTs across multiple games. That is, while a player's ownership of an NFT attribute upgrade can be verified via the blockchain, the present disclosure includes techniques for simultaneously controlling and managing the authorization and use of NFT attribute upgrades in different games within a gaming network or ecosystem.

[0025] The disclosed "smart contract" component of the generated NFT includes attributes to improve the characteristics of the player character and in-game items. Because the digital art is not part of the smart contract, game designers have increased flexibility in designing the digital art compared to traditional approaches. Furthermore, players can transfer their attribute cards to any other game within the supported ecosystem.

[0026] Additionally, the disclosed technology addresses technical challenges associated with managing the computational load of game servers, computing systems, and the like. In a multiplayer electronic game, or generally in electronic applications that serve multiple clients, the timing of certain event occurrences places significant computational and processing loads on application servers and computing systems. For example, in the context of an electronic game, the timing of multiple level-progression events, each triggered by a different player, traditionally requires significant processing effort to upgrade and modify in-game data for in-game assets associated with the different players (e.g., calculating new statistical and attribute data for the in-game assets).

[0027] The disclosed technology reduces the computational and processing load required to handle such simultaneous in-game events. According to embodiments disclosed herein, a level progression event results in the modification of a capacity parameter of an in-game asset. That is, instead of the in-game asset data being modified, recalculated, etc., in response to the level progression event, only the capacity parameter associated with the in-game asset data is modified. The modification of the capacity parameter allows attribute upgrades to be applied to the in-game asset at a time detached from the level progression event itself. Thus, the disclosed technology allows for a temporal separation or independence between the level progression event and the significant processing required to modify the in-game asset data to reflect the level progression event. As such, the disclosed technology reduces the amount of computational load required to handle multiple simultaneous level progression events.

[0028] In one example, a computer system operates a particular electronic game among one or more electronic games being played by one or more players. Each player of the one or more players is represented by a player character stored outside the blockchain. The computer system determines that a particular player character representing a particular player among the one or more players has reached a first level of the particular electronic game. In response to determining that the particular player character has reached the first level, the computer system increases a modification capacity of the particular player character. The modification capacity indicates a maximum number of attribute modifications (also referred to herein as attribute upgrades, NFT attributes, etc.) that can be applied to the particular player character at one time. In response to user input by the particular player, the computer system applies a number of attribute modifications to the particular player character that fills the modification capacity of the particular player character. Each of the attribute modifications is defined by an on-chain cryptocurrency owned by the particular player. The computer system sends a notification to an application programming interface (API) executed by the computer system. The notification indicates that one or more respective on-chain cryptocurrency assets for the number of attribute modifications have been used within the particular electronic game. The notice indicates that the particular NFT attribute is being used in an electronic game.

[0029] In one example, a computer system operates an electronic game being played by one or more players. Each player is associated with one or more in-game assets of the electronic game. The one or more in-game assets are stored off-chain by the computer system. The computer system detects the occurrence of a progression event related to a specific in-game asset associated with a specific player. The progression event is defined by one or more game conditions related to at least one of the specific player or the specific in-game asset. In response to the occurrence, the computer system increases an upgrade capacity of the specific in-game asset. The upgrade capacity controls a maximum number of attribute upgrades that can be applied to the specific in-game asset. The attribute upgrades are defined by an on-chain cryptographic asset. Based on a determination that the number of attribute upgrades currently applied to the specific in-game asset is less than the upgrade capacity, the computer system applies a specific attribute upgrade defined by a specific on-chain cryptographic asset owned by the specific player to the specific in-game asset. The computer system sends a notification to an application programming interface (API) executed by the computer system. The notification indicates that the specific on-chain cryptographic asset is being used in the electronic game.

[0030] In one example, a computer system operates a particular electronic game among a plurality of electronic games in a shared ecosystem. The particular electronic game includes a plurality of in-game assets associated with a plurality of players. The plurality of in-game assets are stored off-chain. The computer system detects the occurrence of a progression event for a particular in-game asset of the particular electronic game. The progression event is based on one or more conditions associated with the particular in-game asset being satisfied. In response to the occurrence, the computer system modifies a capability parameter associated with the particular in-game asset. The computer system identifies a set of on-chain cryptoassets owned by a particular player associated with the particular in-game asset. The computer system displays, for the particular player, a number of on-chain cryptoassets of the set of on-chain cryptoassets for application to the particular in-game asset. The number of on-chain cryptoassets is based on a capacity parameter and a current number of on-chain cryptoassets to be applied to the particular in-game asset.

[0031] In one example, a computer system operates a first electronic game of one or more electronic games. The first electronic game is being played by a player represented by a player character. The player character is stored off-blockchain. The computer system applies one or more attribute modifiers to a player character in the first electronic game according to a modification capacity associated with the player character, the modification capacity defining a maximum number of attribute modifiers for the player character. The one or more attribute modifiers are defined by one or more on-chain cryptographic assets on the blockchain. The computer system receives a request to apply one or more attribute modifiers to in-game assets in a second electronic game of the one or more electronic games. The in-game assets are stored off-blockchain. In response to receiving the request, the computer system determines that the one or more attribute modifiers are currently applied in the first electronic game based on representing the one or more on-chain cryptographic assets to an API. In response to determining that the one or more attribute modifiers are currently applied in the first electronic game, the computer system prevents the one or more attribute modifiers from being applied to the in-game assets in the second electronic game via the API.

[0032] In one example, a computer system operates a first electronic game among a plurality of electronic games. The computer system receives a request from a computer device of a player of the first electronic game to apply an on-chain cryptocurrency asset to an in-game asset of the first electronic game. The in-game asset of the first electronic game is stored off-blockchain. The on-chain cryptocurrency asset defines an attribute modification for the in-game asset. In response to receiving the request, the computer system queries a game interoperability API to determine whether the on-chain cryptocurrency asset has been applied to a given in-game asset of a second electronic game among the plurality of electronic games. In response to receiving a response from the game interoperability API indicating that the on-chain cryptocurrency asset has been applied to the given in-game asset of the second electronic game, the computer system prevents the on-chain cryptocurrency asset from being applied to the in-game asset of the first electronic game.

[0033] In one example, a computer system operates a first electronic game in an ecosystem of electronic games. The computer system determines a set of on-chain cryptographic assets owned by a particular player and defining attribute modifiers applicable to a given in-game asset in the first electronic game. The computer system uses a game interoperability API to identify a subset of the on-chain cryptographic assets that do not apply to in-game assets in other electronic games in the ecosystem of electronic games. The computer system provides, to the computer system of the particular player, a visual representation within the first electronic game showing the subset of the on-chain cryptographic assets.

[0034] In one example, a computer system operates an electronic game stored off-blockchain. The electronic game is being played by a player. The computer system mints non-fungible tokens (NFTs) on the blockchain. The NFT includes a smart contract corresponding to at least one attribute modifier used by the player for an in-game asset in the electronic game. The NFT references digital art associated with the in-game asset in the electronic game stored off-blockchain. The computer system receives a request from the player's computing device to apply the at least one attribute modifier to the in-game asset. In response to determining that application of the at least one attribute modifier would exceed a performance parameter associated with the in-game asset, the computer system prevents the at least one attribute modifier from being applied to the in-game asset.

[0035] In one example, a computer system operates an electronic game stored off-blockchain. The computer system mints an on-chain cryptographic asset on the blockchain. The on-chain cryptographic asset is associated with a smart contract corresponding to at least one attribute modifier applicable to an in-game asset of the electronic game. The on-chain cryptographic asset references digital art associated with the in-game asset for use in the electronic game. The computer system receives a request from a computer device of a particular player of the electronic game to apply the at least one attribute modifier to the in-game asset. In response to receiving the request, the computer system determines a modification capacity of the in-game asset. The computer system indicates to the computer device of the particular player whether or not the computer device is permitted to apply the at least one attribute modifier to the in-game asset based on the modification capacity.

[0036] In one example, a computer system mints an on-chain crypto asset on a blockchain. A smart contract associated with the on-chain crypto asset defines an attribute modification for a particular in-game asset in an electronic game operated off-blockchain. The computer system receives a request from a computer device of a particular player of the electronic game to apply the attribute modification to the particular in-game asset. The computer system applies the attribute modification to the particular in-game asset based at least on a determination that the on-chain crypto asset is owned by the particular player.

[0037] FIG. 1 is a block diagram illustrating a portion of an example blockchain system 100. The blockchain system 100 includes a blockchain 104. In embodiments, the blockchain 104 is a distributed ledger of transactions (e.g., a continuously growing list of records, such as records of transactions of digital assets such as cryptocurrency, Bitcoin, or electronic money) maintained by the blockchain system 100. For example, the blockchain 104 is redundantly stored on multiple nodes (e.g., computers) of a blockchain network. Each node in the blockchain network may store a complete replica of the entire blockchain 104. In some embodiments, the blockchain system 100 implements storing an identical blockchain at each node, even if the nodes receive transactions in a different order. The blockchain 104 illustrated by FIG. 1 includes blocks 104a, 104b, and 104c. Similarly, embodiments of the blockchain system 100 may include different and / or additional components or may be connected in different ways.

[0038] The terms "blockchain" and "chain" are used interchangeably herein. In an embodiment, the blockchain 104 is a distributed database shared among nodes of a computer network. As a database, the blockchain 104 stores information electronically in a digital format. The blockchain 104 can maintain a secure, decentralized record of transactions (e.g., transactions 124a, 124b). For example, the ERC-721 or ERC-1155 standards are used to maintain a secure, decentralized record of transactions. The blockchain 104 provides fidelity and security of data recording. In an embodiment, the blockchain 104 collects information together in groups known as "blocks" (e.g., blocks 104a, 104b), which hold sets of information.

[0039] The blockchain 104 structures its data into interlocking chunks (blocks) (e.g., blocks 104a and 104b). A block (e.g., block 104c) has a certain storage capacity and is closed when filled and linked to the previously filled block (e.g., block 104b), forming a chain of data known as a "blockchain." New information following the just-added block (e.g., block 104b) is accumulated in a newly formed block (e.g., block 104c), which is also added to the blockchain 104 when filled. The data structure, when implemented in a decentralized nature, inherently creates an irreversible timeline of data. When a block is filled, it becomes part of this block's timeline. Each block (e.g., block 104a) in the chain 104 is given a precise timestamp (e.g., timestamp 112a) when it is added to the chain 104. In the example of FIG. 1, the blockchain 104 includes multiple blocks 104a-c. Each of blocks 104a-c can represent one or more transactions and can include a cryptographic hash of the previous block (e.g., previous hash 108a-c), a timestamp (e.g., timestamp 112a-c), a transaction root hash (e.g., 116a-c), and a nonce (e.g., 120a-c). The transaction root hash (e.g., transaction root hash 116b) indicates proof that block 104b contains all transactions in the proper order. Transaction root hash 116b proves the integrity of the transactions in block 104b without presenting all of the transactions.

[0040] In embodiments, the timestamp 112a-c of each corresponding block 104a-c includes data indicating a time associated with the block. In some examples, the timestamp includes a sequence of characters that uniquely identifies a given point in time. In one example, a block's timestamp includes the previous timestamp in its hash, allowing the sequence of block generation to be verified.

[0041] In an embodiment, the nonce 120a-c of each corresponding block 104a-c includes an arbitrary generated random or semi-random number. The nonce can be used by miners during proof of work (PoW), which refers to a form of adding a new block of transactions to the blockchain 104. This work refers to generating a hash that matches the target hash of the current block. For example, the nonce is an arbitrary number that can be changed by a miner (e.g., a device validating blocks) to modify the header hash and produce a hash that is less than or equal to a target hash value set by the network.

[0042] As described above, each of the blocks 104a, 104b, 104c of the exemplary blockchain 104 may include a respective block hash 116a, 116b, 116c. Each of the block hashes 116a-c may represent the hash of the root node of a Merkle tree for the block's contents (e.g., the transactions of the corresponding block). For example, a Merkle tree may include leaf nodes that correspond to hashes of components of a transaction, such as references, attachments, and commands that identify outputs of previous transactions that are inputs to the transaction. Each non-leaf node may include hashes of the hashes of its child nodes. A Merkle tree may also be thought of as having each component as a leaf node, whose parent node corresponds to the component's hash.

[0043] In the example of FIG. 1, block 104b records transactions 124a-d. Leaf nodes 128a-d each contain a hash corresponding to transaction 124a-d, respectively. As described above, the hashes (e.g., the hash in leaf node 128a) can be hashes of components of a transaction (e.g., transaction 124a), such as references identifying outputs of previous transactions, attachments, and commands that are input to transaction 124a. Each of non-leaf nodes 132a, 132b can contain hashes of hashes of its child nodes (e.g., leaf nodes 128a-b). In this example, node 132a can contain hashes of hashes contained in nodes 128a, 128b, and node 132b can contain hashes of hashes contained in nodes 128c, 128d. Root node 116b can contain hashes of hashes of hashes of child nodes 132a-b.

[0044] A Merkle tree representation of a transaction (e.g., 124a) allows an entity needing access to transaction 124a to be provided with only the portion containing the components the entity needs. For example, if an entity needs only the transaction summary, the entity can be provided with the nodes (and each node's sibling nodes) along the path from the root node to the node of the transaction summary's hash. The entity can verify that the transaction summary was used in transaction 124a by generating a hash of the transaction summary and computing the hash of the nodes along the path to the root node. If the computed hash of the root node matches the hash 128a of transaction 124a, the transaction summary is verified as being used in the transaction. Because only the portion of the Merkle tree related to the components the entity needs is provided, the entity does not have access to the other components. Therefore, the confidentiality of the other components is not compromised.

[0045] In some examples, the blockchain 104 is the Bitcoin system, which was developed to allow digital assets, such as electronic cash, to be transferred directly from one party to another without going through a central authority, such as a financial institution (e.g., as described in the white paper entitled "Bitcoin: A Peer-to-Peer Electronic Cash System" by Satoshi Nakamoto, which is incorporated herein by reference in its entirety). Bitcoin (an electronic coin) can be represented by a chain of transactions that transfer ownership from one party to another.

[0046] To transfer ownership of a digital asset, such as Bitcoin, using the blockchain 104, a new transaction, such as one of transactions 124a-d, is created and added to the stack of transactions in a block, e.g., block 104b. To record a transaction on the blockchain, each party and asset involved in the transaction requires an account, identified by a digital token. For example, if a first user wants to transfer an asset they own to a second user, both the first and second users create accounts, and the first user also creates an account uniquely identified by the asset's identification number. The asset's account identifies the first user as the asset's current owner. The first user (i.e., the current owner) creates a transaction (e.g., 124a) to the asset's account, indicating that transaction 124a is a transfer of ownership, and outputs a token identifying the second user as the next owner and a token identifying the asset. Transaction 124a is signed with the private key of the first user (i.e., the current owner), and transaction 124a is evidence that the second user is now the new current owner and that ownership has been transferred from the first user to the second user.

[0047] A new transaction 124a containing the public key of the new owner (e.g., a second user whose digital assets are assigned ownership in the transaction) is digitally signed by the first user with the first user's private key to transfer ownership to the second user (e.g., new owner) as represented by the second user's public key. The owner's signature of the bitcoins is their authorization to transfer ownership of the bitcoins to the new owner via the new transaction 124a. When a block is filled, it is "capped" with a block header, i.e., a hash digest of all transaction identifiers in the block. The block header is recorded as the first transaction in the next block in the chain, creating a mathematical hierarchy called the "blockchain." To verify the current owner, one can follow the blockchain 104 of transactions, verifying each transaction from the first to the last. The new owner only needs to have a private key that matches the public key of the transaction that transferred the bitcoins. The blockchain creates mathematical proof of ownership of entities represented by security identities (e.g., public keys), which, in the case of the Bitcoin system, is pseudo-anonymous.

[0048] Additionally, in some embodiments, the blockchain 104 enables more complex transactions using one or more smart contracts. A smart contract includes computer code that implements the contract's transactions. The computer code can run on a secure platform (e.g., the Ethereum platform, which provides a virtual machine) that supports recording transactions (e.g., 124a-d) within the blockchain. For example, a smart contract can be a self-executing contract in which the terms of an agreement between a buyer and a seller are written directly into lines of code. The code and the agreements contained therein exist across a distributed, decentralized blockchain network.

[0049] Additionally, the smart contract itself may be recorded as a transaction 124a in the blockchain 104 using a token that is a hash 128a of the computer code so that the executed computer code can be authenticated. When deployed, the smart contract's constructor is executed to initialize the smart contract and its state. The smart contract's state is persistently stored in the blockchain 104. When a transaction 124a is recorded for a smart contract, a message is sent to the smart contract, and the smart contract's computer code is executed to carry out the transaction (e.g., debiting an account balance by a certain amount). The computer code ensures that all terms of the contract are adhered to before the transaction 124a is recorded on the blockchain 104.

[0050] For example, a smart contract may support the sale of an asset. Inputs to the smart contract for selling an asset may be a token identifying the seller, the buyer, the asset, and the sale price in US dollars or a cryptocurrency. Computer code is used to ensure that the seller is the current owner of the asset and that the buyer has sufficient funds in their account. The computer code records a transaction (e.g., 124a) that transfers ownership of the asset to the buyer and a transaction (e.g., 124b) that transfers the sale price from the buyer's account to the seller's account. If the seller's account is in US dollars and the buyer's account is in Canadian dollars, the computer code may retrieve the currency exchange rate, determine how many Canadian dollars to debit from the seller's account, and record the exchange rate. If either transaction 124a, 124b is unsuccessful, neither transaction is recorded.

[0051] When a message is sent to the smart contract to record transaction 124a, the message is sent to each node that maintains a copy of the blockchain 104. Each node executes the smart contract's computer code to implement transaction 124a. For example, if 100 nodes each maintain a copy of the blockchain 104, the computer code executes at each of the 100 nodes. When the nodes complete execution of the computer code, the result of transaction 124a is recorded in the blockchain 104. The nodes employ a consensus algorithm to decide which transactions (e.g., 124c) to keep and which transactions (e.g., 124d) to discard. While execution of the computer code at each node helps ensure the authenticity of the blockchain 104, supporting such redundant execution of computer code requires significant computer resources.

[0052] While a blockchain can effectively store transactions 124a-d, the large amount of computer resources, such as storage and computing power, required to maintain all copies of the blockchain can be problematic. To overcome this problem, some systems for storing transactions 124a-d do not use a blockchain, but rather have each party to the transaction maintain its own copy of the transaction 124a. One such system is the Corda™ system, developed by R3™, which provides a decentralized distributed ledger platform in which each participant in the platform has a node (e.g., a computer system) that maintains each participant's portion of the distributed ledger.

[0053] Once the parties agree to the terms of transaction 124a, they submit transaction 124a to a trusted node, a notary, for notarization. The notary maintains a consumed output database of transaction outputs that were input to other transactions. When transaction 124a is received, the notary checks the input to transaction 124a against the consumed output database to ensure that the output referenced by the input has not been consumed. If the input has not been consumed, the notary updates the consumed output database to indicate that the referenced output has been consumed, notarizes transaction 124a (e.g., by signing the transaction or a transaction identifier with the notary's private key), and sends the notarized transaction to the party that submitted transaction 124a for notarization. When a party receives the notarized transaction, the party stores the notarized transaction and provides the notarized transaction to its counterparty.

[0054] In embodiments, the notary is a non-verifying notary or a verifying notary. When a non-verifying notary notarizes a transaction (e.g., 124b), the non-verifying notary determines that the previous output of the previous transaction (e.g., 124a), i.e., the input of the current transaction 124b, has not been spent. If the previous output has not been spent, the non-verifying notary notarizes transaction 124b by signing the transaction's hash 128b. To notarize transaction 124b, the non-verifying notary only needs the identity of the previous output (e.g., hash 128a of previous transaction 124a and the output's index) and the portion of the Merkle tree necessary to compute hash 128b of transaction 124b.

[0055] As described herein, in some embodiments, the blockchain 104 enables more complex transactions using one or more smart contracts. For example, a validating notary verifies a transaction (e.g., 124d), which includes verifying that the preceding transactions 124a-c in the transaction's backchain are valid. The backchain refers to the collection of transaction 124d's predecessors (e.g., 124c), as well as the predecessors 124a-b of those predecessors 124c, etc. To verify transaction 124d, the validating notary invokes transaction 124d's verification code. In one example, the validating notary invokes transaction 124d's smart contract's verification code. The verification code performs the checks necessary to comply with the conditions applicable to transaction 124d. In some implementations, the checking includes retrieving the owner's public key from the preceding transaction 124c (pointed to by the input state of transaction 124d) and checking the signature of transaction 124d, ensuring that the preceding outputs of the incoming preceding transactions have not been spent, and checking the validity of each transaction (e.g., 124c) in the backchain of transactions. If the verification code indicates that transaction 124d is valid, the verifying notarizer notarizes transaction 124d and records the output of the preceding transaction 124c as spent.

[0056] In some examples, to verify the accuracy of transactions 124a-d in a ledger stored at a node, blocks 104a-c in the blockchain 104 can be accessed, from oldest 104a to newest 104c, to generate a new hash of block 104c and compare this new hash to the hash 108c generated when block 104c was created. If the hashes are the same, the transactions in the block are verified. In one example, the Bitcoin system also implements techniques to ensure that it would be infeasible to modify transaction 124a and regenerate the blockchain 104 by employing computationally expensive techniques to generate nonce 120b, which is added to blocks when they are created. The Bitcoin ledger is sometimes referred to as the Unspent Transaction Output ("UTXO") set because it tracks all transaction outputs that have not yet been spent.

[0057] 2A shows a process 200 for generating a non-fungible token (NFT) or conducting a cryptographic transaction on a blockchain using a hashing algorithm. For example, a blockchain 104 as shown in FIG. 2A is also shown and described in detail with reference to FIG. 1. Process 200 can be performed by a computer system and / or by a node of blockchain 104 as described with reference to FIG. 10. Some embodiments include different and / or additional steps, or perform steps in a different order.

[0058] In embodiments, a digital message, electronic art, digital collectible, any other form of digital content, or a combination thereof 204a is hashed using a hash algorithm 208a. A hash algorithm 208a (sometimes called a "hash function") can be a function used to map data of any size (e.g., content 204a) to a fixed-size value (e.g., hash value 212a). The hash value 212a returned by the hash function 208a can be referred to as a hash value, hash code, digest, or hash. The hash value 212a can be used to index into a fixed-size table called a hash table. A hash table, also known as a hash map, is a data structure that implements an associative array or dictionary, which is an abstract data type that maps keys (e.g., content 204a) to hash values ​​212a.

[0059] The output (e.g., hash value 212a) of the hashed content 204a can be inserted into a block (e.g., block 104c) of the blockchain 104 (e.g., including blocks such as blocks 104a-d). Block 104c can include information such as timestamp 112c, among other things. To verify that block 104c is correct, a new hash value 212b is generated by applying a hash algorithm 208b to the digital content 204b. The new hash value 212b is compared to the hash value 212a in the blockchain 104 in a comparison step 216. If the new hash value 212b is the same as the hash value 212a of block 104c, the comparison results in an indication that they match. For example, a decision 220 can indicate that hashes 212a-b are the same or different. Hashes can be indicated as the same if the characters of the hashes match. The hash algorithms 208a-b can include any suitable hash algorithm. Examples include Message Digest 5 (MD5) and Secure Hashing Algorithm (SHA).

[0060] Components of process 200 can generate or verify an NFT, which is a cryptographic asset with a unique identification code and metadata that uniquely identifies the NFT. In one example, digital content 204a can be hashed and minted to generate an NFT, or content 204a can represent an NFT that is verified using process 200 and content 204b. An NFT can include digital data (e.g., 212a) stored on the blockchain 104. Ownership of an NFT (e.g., 212a) is recorded on the blockchain 104 and is transferable by the owner, allowing the NFT 212a to be sold and traded. The NFT 212a includes a reference to a digital file, such as a photo, video, or audio (e.g., content 204a). Because NFTs are uniquely identifiable assets, they differ from fungible cryptocurrencies. Notably, NFTs function like cryptographic tokens, but unlike cryptocurrencies such as Bitcoin or Ethereum™, NFTs are not interchangeable and therefore not fungible.

[0061] NFTs can be associated with specific digital or physical assets, such as images, art, music, and sports highlights (e.g., content within block 104a), and can grant licensing rights to use the asset within a particular block 104a for a specified purpose. Like other assets, NFTs are recorded on the blockchain when the blockchain 104 concatenates records containing cryptographic hash sets of characters that identify sets of data on previous records, creating a chain of identifiable data blocks 104a-d. The cryptographic transaction process allows for authentication of each digital file by providing a digital signature that tracks NFT ownership. In embodiments, a data link that is part of the NFT record points to details about where the associated art (content within block 104a) is stored.

[0062] Minting an NFT (e.g., 212a) can refer to the process of turning a digital file (e.g., 204a) into an encrypted collectible or digital asset 212a on the blockchain 104 (e.g., the Ethereum™ blockchain). Digital items or files (e.g., content 204a) can be stored on the blockchain 104 and typically cannot be edited, modified, or deleted. The process of uploading a particular item to the blockchain 104 is known as "minting." For example, "NFT minting" can refer to the process by which digital art or digital content 204a becomes part of the Ethereum™ blockchain. Thus, the process turns the digital content 204a into a crypto asset 212a, which can be easily traded or purchased with cryptocurrency in a digital marketplace without an intermediary.

[0063] FIG. 2B is a block diagram 250 illustrating an exemplary crypto wallet 260. In overview, crypto wallet 260 is an electronic entity that allows a user to securely manage digital assets. According to various embodiments, crypto wallet 260 can be a hardware-based wallet (e.g., it can include dedicated hardware components), a software-based wallet, or a combination thereof. Exemplary digital assets that can be stored and managed using crypto wallet 260 include digital coins, digital tokens, etc. In some embodiments, the tokens are stored on a blockchain system, such as blockchain system 100 described in FIG. 1. In some embodiments, crypto wallet 260 is capable of connecting to and managing assets native to or associated with multiple different blockchain systems.

[0064] As defined herein, the terms “coin” and “token” refer to digital representations of particular assets, utilities, ownership rights, and / or access rights. Various embodiments of crypto wallet 260 can be used to manage any suitable type of coin or token. In some embodiments, tokens include cryptocurrencies such as exchange tokens and / or stablecoins. Exchange tokens and / or stablecoins can be native to a particular blockchain system 100 and, in some cases, can be backed by a stable asset such as fiat currency, precious metals, oil, or another commodity. In some embodiments, tokens are utility tokens that provide access to products or services offered by an operator (e.g., a token issuer) of blockchain system 100. In some embodiments, tokens are security tokens, which can be securitized cryptocurrencies derived from particular assets such as bonds, stocks, real estate, and / or fiat currency, or a combination thereof, and can represent ownership rights in an asset or combination of assets.

[0065] In some embodiments, the token is an NFT or other non-fungible digital certificate of ownership. In some embodiments, the token is a decentralized finance (DeFi) token. DeFi tokens can be used to access the functionality set of DeFi software applications (dApps) built on the blockchain system 100. Exemplary dApps can include decentralized lending applications (e.g., Aave), decentralized cryptocurrency exchanges (e.g., Uniswap), decentralized NFT marketplaces (e.g., OpenSea, Rarible), decentralized gaming platforms (e.g., Upland), decentralized social media platforms (e.g., Steemit), decentralized music streaming platforms (e.g., Audius), and the like. In some embodiments, tokens provide access to various computing systems and can include authorization keys, authentication keys, passwords, PINs, biometric information, access keys, and other similar information. The computing systems to which tokens provide access can be both on-chain (e.g., implemented as dApps on a particular blockchain system 100) or off-chain (e.g., implemented as computer software on a computing device separate from the blockchain system 100).

[0066] As shown, crypto wallet 260 of FIG. 2B is communicatively coupled to a host device 280 (e.g., a mobile phone, laptop, tablet, desktop computer, wearable device, point-of-sale (POS) terminal, automated teller machine (ATM), etc.) via communications link 255. In some embodiments, host device 280 can expand the set of functionality available to a user of crypto wallet 260 when crypto wallet 260 is coupled to host device 280. For example, the host device can provide a user with the ability to perform balance inquiries, convert tokens, access exchanges and / or marketplaces, conduct transactions, access computing systems, etc.

[0067] In some embodiments, crypto wallet 260 and host device 280 may be owned and / or operated by the same entity, user, or group of users. For example, an individual owner of crypto wallet 260 may also operate a personal computing device that acts as host device 280, providing an enhanced user experience for crypto wallet 260 (e.g., by providing a user interface that includes graphical features, an immersive reality experience, a virtual reality experience, or the like). In some embodiments, crypto wallet 260 and host device 280 may be owned and / or operated by different entities, users, and / or groups of users. For example, host device 280 may be a point-of-sale (POS) terminal at a merchant location, and an individual owner of crypto wallet 260 may use crypto wallet 260 as a payment method for goods or services at the merchant location by communicatively coupling the two devices for a short period of time (e.g., via a chip, via near-field communications (NFC), by scanning a barcode, by having crypto wallet 260 generate and display a quick response (QR) code, etc.) to transmit payment information from crypto wallet 260 to host device 280.

[0068] Crypto wallet 260 and host device 280 can be physically separate and / or removably coupled. The ability to physically and communicatively separate crypto wallet 260 from host device 280 and other devices allows air-gapped crypto wallet 260 to act as "cold" storage, with stored digital assets moved offline and inaccessible to host device 280 and other devices. Additionally, the ability to physically and communicatively separate crypto wallet 260 from host device 280 allows crypto wallet 260 to be implemented as a larger block of physical memory, which expands the storage capacity of crypto wallet 260, similar to a safety deposit box or vault at a brick-and-mortar facility.

[0069] Thus, in some embodiments, crypto wallet 260 and host device 280 are physically separate entities. In such embodiments, communication link 255 may include a computer network. For example, crypto wallet 260 and host device 280 may be paired wirelessly via a short-range communication protocol (e.g., Bluetooth, ZigBee, infrared communication) or another suitable network infrastructure. In some embodiments, crypto wallet 260 and host device 280 are removably coupled. For example, host device 280 may include a physical port, outlet, opening, etc., for receiving and communicatively coupling to crypto wallet 260, either directly or via a connector.

[0070] In some embodiments, crypto wallet 260 includes a tangible storage medium such as a dynamic random-access memory (DRAM) stick, a memory card, a secure digital (SD) card, a flash drive, a solid state drive (SSD), a magnetic hard disk drive (HDD), or an optical disk, and may be connected to a host device via a suitable interface such as a memory card reader, a USB port, a micro USB port, an eSATA port, or the like.

[0071] In some embodiments, crypto wallet 260 may include an integrated circuit, such as a SIM card, a smart card, or the like. For example, in some embodiments, crypto wallet 260 may be a physical smart card that includes an integrated circuit, such as a chip, that can store data. In some embodiments, crypto wallet 260 is a contactless physical smart card. Advantageously, such an embodiment allows data from the card to be read by a host device as a series of application protocol data units (APDUs) in accordance with conventional data transfer protocols between payment cards and readers (e.g., ISO / IEC 7816), which enhances interoperability between crypto payment ecosystems and payment card terminals.

[0072] In some embodiments, crypto wallet 260 and host device 280 are non-removably coupled. For example, various components of crypto wallet 260 may be co-located with components of host device 280 within the housing of host device 280. In such embodiments, host device 280 may be a mobile device, such as a phone, wearable, or the like, and crypto wallet 260 may be embedded within the host device. Integration between crypto wallet 260 and host device 280 may enable an improved user experience and allow for an expanded feature set of crypto wallet 260 while conserving computing resources (e.g., by sharing computing resources such as a transceiver, processor, and / or display or host device 280). Integration may also facilitate asset transfers between parties. Integration may also enhance loss protection options because recovering a password or similar authentication information, rather than recovering a physical device, may be sufficient to restore access to digital assets stored in crypto wallet 260. In some embodiments, the non-removably coupled crypto wallet 260 can be air-gapped, for example, by disconnecting the host device 280 from the internet.

[0073] As shown, crypto wallet 260 may include a microcontroller 262. Microcontroller 262 may include at least one secure memory 264 or may be communicatively coupled (e.g., via a bus or similar communication path) to at least one secure memory 210. Crypto wallet 260 may further include a transceiver 282a, input / output circuitry 284a, and / or a processor 286a. However, in some embodiments, some or all of these components may be omitted.

[0074] In some embodiments, crypto wallet 260 may include transceiver 282a and thus may be able to independently connect to a network and exchange electronic messages with other computing devices. In some embodiments, crypto wallet 260 does not include transceiver 282a. Crypto wallet 260 may be able to connect to or be accessible from a network via transceiver 282b of host device 280 when crypto wallet 260 is docked to host device 280. For example, in some embodiments, a user of crypto wallet 260 may be able to participate in token swap activities of a decentralized exchange when crypto wallet 260 is connected to host device 280.

[0075] In some embodiments, crypto wallet 260 can include input / output circuitry 284a, which includes user-interactive controls such as buttons, sliders, gesture-responsive controls, etc. The user-interactive controls can enable a user of crypto wallet 260 to interact with crypto wallet 260 (e.g., perform balance inquiries, convert tokens, access exchanges and / or marketplaces, conduct transactions, access a computing system, etc.). In some embodiments, a user can access an expanded set of functionality via input / output circuitry 284b of host device 280 when crypto wallet 260 is docked to host device 280. For example, host device 280 can include computer-executable code structured to securely access data from secure memory 264 of crypto wallet 260 and perform operations using the data. The data can include authentication information, configuration information, asset keys, and / or token management instructions. The data can be used by applications running on or by host device 280. The data can be used to build application programming interface (API) calls to other applications that request or use the data provided by crypto wallet 260. The other applications can include any on-chain or off-chain computer application, such as dApps (e.g., decentralized lending applications, decentralized cryptocurrency exchanges, decentralized NFT marketplaces, decentralized gaming platforms, decentralized social media platforms, decentralized music streaming platforms), third-party computing systems (e.g., financial company computing systems, social networking sites, gaming systems, online marketplaces), etc.

[0076] Secure memory 264 is shown to include authentication circuitry 266 and digital asset management circuitry 272. Authentication circuitry 266 and / or digital asset management circuitry 272 include computer-executable code that, when executed by one or more processors, such as one or more processors 286a and / or 286b, performs dedicated computer-executable operations. For example, authentication circuitry 266 may be configured to cause crypto wallet 260 to establish, maintain, and manage a secure electronic connection with another computing device, such as host device 280. Digital asset management circuitry 272 may be configured to cause crypto wallet 260 to permit a user to manage digital assets accessible via crypto wallet 260. In some embodiments, authentication circuitry 266 and digital asset management circuitry 272 are combined in whole or in part.

[0077] As shown, authentication circuit 266 may include removably stored security, authentication, and / or authorization data, such as authentication key 268. Authentication key 268 may be a numeric, alphabetic, or alphanumeric value, or combination of values. Authentication key 268 may function as a security token that enables access to one or more computing systems, such as host device 280. In some embodiments, when crypto wallet 260 is paired or docked with host device 280 (e.g., establishing an electronic connection), a user is prompted to enter authentication information via input / output circuit 284a and / or 284b. Authentication information may include a PIN, password, passphrase, biometric information (e.g., fingerprint, set of facial features, retinal scan), voice command, etc. Authentication circuit 266 compares the user-entered information with authentication key 268, and if the items at least partially match, the electronic connection may be maintained.

[0078] As shown, authentication circuit 266 may include retrievably stored configuration information 270. Configuration information 270 may include numeric, alphabetic, or alphanumeric values ​​or combinations of values. These items may be used to enable an extensible authentication protocol. For example, configuration information 270 may include a timeout value for authorized connections between crypto wallet 260 and host device 280. Configuration information 270 may also include computer-executable code. In some embodiments, when a particular crypto wallet 260 is configured to pair with only one or a few pre-authorized host devices 280, configuration information 270 includes a device identifier and / or other device authentication information, and the computer-executable code is structured to verify the device identifier and / or other device authentication information against information associated with or provided by host device 280. When a pairing attempt is made, the computer-executable code may initiate, or cause host device 280 to initiate, electronic communications (e.g., email messages, text messages, etc.) using the user contact information stored as configuration information 270.

[0079] As shown, the digital asset management circuit 272 can include retrievably stored digital asset data, such as an asset key 274. The asset key 274 can be a numeric, alphabetic, or alphanumeric value, or a combination of values. In some embodiments, the asset key 274 is a private key in a public / private key pair, a portion thereof, or an item from which a private key can be derived. The asset key 274 thus proves ownership of a particular digital asset stored in the blockchain system 100. The asset key 274 can enable a user to conduct blockchain transactions involving digital assets. Blockchain transactions can include computer-based operations such as earning profits, lending, borrowing, going long / short, earning interest, saving, buying, investing in securities, investing in stocks, investing in funds, sending and receiving monetary value, trading value on a decentralized exchange, investing and buying assets, and selling assets. A crypto wallet 260 can be identified as a party to a blockchain transaction on the blockchain system 100 using a unique cryptographically generated address (e.g., a public key in a public / private key pair).

[0080] As shown, the digital asset management circuit 272 also includes removably stored asset management instructions 276. The asset management instructions 276 may include numeric, alphabetic, or alphanumeric values ​​or combinations of values. These items may be used to enable computer-based operations related to the management of the digital asset identified by the asset key 274. For example, the asset management instructions 276 may include parameter values, metadata, and / or similar values ​​associated with various tokens identified by the asset key 274 and / or identified by the blockchain system 100 associated with a particular token. The asset management instructions 276 may also include computer-executable code. In some embodiments, for example, asset management functions (e.g., balance inquiries, etc.) may be executable directly from the crypto wallet 260 rather than, or in addition to, being executable from the host device 280.

[0081] Smart Contracts with NFT Attributes Figure 3 is a flow diagram illustrating an exemplary process for cryptographic application of non-fungible tokens to electronic games. According to aspects of the disclosed technology, technical benefits are provided by controlling the capacity of an in-game asset for attribute upgrades (as opposed to controlling the attribute upgrades themselves) based on in-game progression events. In particular, the maximum number of attribute upgrades provided by an NFT for an in-game asset is modified in response to an in-game progression event. This allows player ownership of in-game assets to be managed on-chain and verifiable through consensus techniques. Thus, the game itself does not need to store ownership information of a player's NFT attributes.

[0082] In some embodiments, the process illustrated by FIG. 3 is performed by a game server. A game server (sometimes called a host) is a server that is the authoritative source of events in a multiplayer video game. The server transmits sufficient data about its internal state so that its connected clients can maintain their own accurate versions of the game world for display to players. The game server also receives and processes each player's input. In some embodiments, the process of FIG. 3 is performed by a computer system, such as the exemplary computer system 1000 shown and described in more detail with reference to FIG. 10. In other embodiments, a specific entity, such as a machine learning (ML) system, performs some or all of the steps of the process. An exemplary ML system 900 is shown and described in more detail with reference to FIG. 9. Similarly, embodiments may include different and / or additional steps or may perform steps in a different order.

[0083] At 304, the computing system operates an electronic game. In some examples, the electronic game is a single-player game or a multi-player game, e.g., the electronic game is played by one or more players. The electronic game includes a plurality of in-game assets, including player character or avatar assets, environment assets, item or object assets, etc.

[0084] At 308, the computing system manages the accessibility of different in-game assets to the player. For example, the computing system unlocks a particular character asset, item asset, etc. to the player in response to the player satisfying certain prerequisites. For example, the prerequisites define the number of other in-game item assets that must be owned by the player before another in-game item asset is unlocked for ownership and use by the player. Satisfying certain predetermined conditions and prerequisites for unlocking an in-game asset may be referred to herein as a progression event, level-up event, etc. Exemplary progression events include the player character earning a threshold number of experience points (XP), reaching a particular location in the in-game environment, performing a particular interaction with the in-game environment and / or item asset, etc. The computing system detects progression events while operating the electronic game based on monitoring player data and game data.

[0085] At 312, the computing system determines that the player has discovered or acquired NFT attributes. For example, at least some of the in-game assets unlocked for the player at 308 are NFT attributes. As discussed, NFT attributes represent and describe attribute upgrades for existing in-game assets in the electronic game. For example, a given NFT attribute may describe an increase in an HP attribute for an existing character asset, an increase in a damage attribute for an existing item asset, or the removal of a negative attribute for an existing item asset.

[0086] At 316, the computing system accesses the player's wallet. An exemplary wallet is shown and described in more detail with reference to FIG. 2B. In some embodiments, the player's wallet is a data entity that stores multiple cryptographic keys that reference multiple NFTs owned by the player. In some embodiments, the computing system accesses the player's wallet to add cryptographic keys that reference specific NFTs that represent and describe NFT attributes or attribute upgrades of in-game assets of the electronic game. For example, in response to 312, NFT attributes are newly minted on the blockchain, and keys are added to the player's wallet to assign the player's ownership rights to the newly minted NFT attributes. An exemplary blockchain 104 is shown and described in more detail with reference to FIG. 1. In another example, an electronic game or an entity associated with the electronic game (e.g., a developer, issuer, operator) is associated with a wallet that references multiple unlockable NFT attributes, and a computing system transfers ownership of the unlockable NFT attributes from the electronic game's or game entity's wallet to a player's wallet, mints new NFT attributes from the unlockable NFT attributes into the player's wallet, etc. In some embodiments, the computing system accesses the player's wallet to further identify other NFT attributes owned by the player. In some embodiments, the player's wallet is accessible by the computing system based on the player providing a public cryptographic address associated with the wallet. In some embodiments, prior to running or at the start of the game, the player is prompted for the public cryptographic address of the wallet associated with the player so that unlocked NFT attributes can be easily transferred to the player's wallet.

[0087] At 320, the computing system applies the NFT attribute to the in-game asset. In some embodiments, the computing system applied the NFT attribute in response to user input or selection of the NFT attribute. The computing system applied the NFT attribute to the in-game asset if the in-game asset includes sufficient capacity, slots, or opportunities for additional NFT attributes. For example, if the in-game asset is associated with a capacity parameter that specifies that up to four NFT attributes may be applied to the in-game asset, and if four NFT attributes have already been applied to the in-game asset, the computing system does not apply the NFT attribute to the in-game asset. However, in the described example, application of the NFT attribute to the in-game asset is permitted if three or fewer NFT attributes have been applied to the in-game asset. In some embodiments, the computing system applies the NFT attribute after determining that the player owns the NFT attribute. For example, the computing system uses blockchain to verify that the NFT attribute is currently owned by the player (based on the cryptographic address of the player's wallet) and has not been transferred or sold to another user.

[0088] In some embodiments, applying the NFT attribute to the in-game asset includes modifying (e.g., increasing, decreasing) an attribute of the in-game asset according to the attribute upgrade represented or described by the NFT attribute. For example, the computing system updates attribute data associated with the in-game asset, an attribute state associated with the in-game asset, etc. Thus, because the in-game asset attribute data is modified in response to the application of the NFT attribute (e.g., at 320) rather than in response to the occurrence of an in-game progression event (e.g., at 308), the computing system's ability to handle simultaneous in-game progression events for multiple players is improved.

[0089] In some embodiments, applying the NFT attribute to the in-game asset includes displaying or presenting the NFT attribute or an indication thereof. For example, a visual representation of the in-game asset is modified to reflect the application of the NFT attribute to the in-game asset. In some embodiments, the display or presentation of the NFT attribute is based on digital art or visual data referenced by the NFT attribute. For example, the digital art or visual data is stored by IPFS and retrieved by a computing system. In some embodiments, the digital art or visual data is combined with the in-game art or visual data to form a game-specific visual representation of the NFT attribute.

[0090] At 324, the computing system notifies the API that a particular NFT attribute has been applied to an in-game asset of the electronic game. The API is configured to manage the use or application of the NFT attribute across multiple electronic games in the ecosystem. For example, the API is configured to prevent one NFT attribute from being applied to multiple in-game assets in multiple electronic games. Thus, the computing system notifies the API that a particular NFT attribute has been applied such that the API prevents the application of the particular NFT attribute in other electronic games.

[0091] Game balancing using an interoperable application programming interface FIG. 4 is a flow diagram illustrating an exemplary process for cryptographic application of non-fungible tokens to electronic games. Generally, the exemplary process relates to an interoperable API that controls the application of NFTs in different electronic games of a gaming network or ecosystem. An exemplary gaming network or ecosystem may include games associated with a common entity (e.g., developer, publisher, operator), games sharing a similar theme or style (e.g., Star Wars-related games, a game and its sequels), games of a common genre (e.g., shooter games, fantasy games, role-playing games, strategy games), games running on a common game engine (e.g., Unreal Engine, Blender), games configured for operation on a particular gaming system, etc. In some embodiments, the interoperable API provides an aspect of control and regulation over attribute upgrades to in-game assets. According to some embodiments, a computer system implementing the interoperable API (e.g., exemplary computer system 1000 shown and described in more detail with reference to FIG. 10 ) performs the exemplary process of FIG. 4 . In some embodiments, the process is performed by a game server. Likewise, embodiments may include different and / or additional steps, or may perform steps in a different order.

[0092] At 404, the computer system uses an API to access a wallet of a player playing the first electronic game. For example, the API is a wallet API of a crypto wallet management platform. An exemplary wallet is shown and described in more detail with reference to FIG. 2B.

[0093] At 408, the computer system determines that the player owns certain NFT attributes. For example, the player's wallet includes a set of cryptographic keys that each reference an NFT on the blockchain, where the NFT represents and describes attribute upgrades for in-game assets of one or more electronic games. An example blockchain 104 is shown and described in more detail with reference to FIG. 1. In some embodiments, a player owns NFT attributes based on actions within a given electronic game. For example, a player earns NFT attributes based on completing certain objectives, meeting certain predefined conditions, reaching certain levels or locations, etc. within a given electronic game.

[0094] At 412, the computer system applies the specific NFT attributes to specific in-game assets of the first electronic game. For example, the computer system receives a request from a player's computing device to apply selected NFT attributes to selected in-game assets. In some embodiments, the computer system applies each of the specific NFT attributes (determined at 408) to one or more available in-game assets (e.g., depending on applicability rules and token capacity) such that every NFT attribute owned by the player is applied.

[0095] At 416, the computer system determines that the player is playing a second electronic game, e.g., another electronic game in an ecosystem that is shared and / or compatible with the first electronic game. For example, the computer system is associated with the first electronic game and is in communication with other computer systems associated with the other electronic games in the ecosystem. As another example, the computer system is associated with the ecosystem and is aware of player activity in each electronic game in the ecosystem.

[0096] At 420, the computer system receives a request to apply a particular NFT attribute to an in-game asset in a second electronic game. For example, in the second electronic game, a player attempts to insert a particular NFT attribute into a slot of an in-game asset of the second electronic game. As another example, the player inquires about which NFT attributes can be applied to the in-game asset of the second electronic game.

[0097] At 424, the computer system prevents application of the particular NFT attribute in the second electronic game while the particular NFT attribute is still applied to the particular in-game asset of the first electronic game. In some embodiments, the computer system prevents application based on implementing a token availability API. If the particular NFT attribute was previously applied to the first electronic game (at 412), the token availability API receives a notification indicating that the particular NFT attribute is not available outside the first electronic game. Thus, at 424, the token availability API indicates to the second electronic game (e.g., in response to a request from the second electronic game) that application of the particular NFT attribute is not permitted. In some examples, the token availability API receives a notification that the particular NFT attribute is no longer used in the first electronic game, thus permitting application of the NFT attribute to the in-game asset of the second electronic game.

[0098] In some embodiments, the API is configured with different usage constraints for NFT attributes. For example, instead of just allowing a particular NFT attribute to be applied to at most one game at any given time, the API is configured to allow the particular NFT attribute to be applied simultaneously in two games. In some embodiments, data or a smart contract associated with a particular NFT attribute indicates a maximum number of games to which the particular NFT attribute may be applied simultaneously, and the API is configured to use that data or smart contract to determine whether the particular NFT attribute may be applied to a second electronic game. In some embodiments, the usage constraints for a particular NFT attribute are based on the player and their characteristics / demographics. For example, the maximum number of games to which a particular NFT attribute may be applied simultaneously corresponds to a player's subscription level, an account status associated with the player, a player's tenure or experience level, etc.

[0099] Game leveling using off-blockchain game characters 5A and 5B are diagrams illustrating example in-game asset and NFT attributes. As discussed herein, aspects of the disclosed technology relate to implementing an in-game asset token capacity, which controls the maximum number of on-chain crypto assets or tokens (e.g., NFTs) that can be applied to the in-game asset, and which defines attribute modifications or upgrades for the in-game asset. An example blockchain 104 is shown and described in more detail with reference to FIG. 1. In some examples, token capacity may also be referred to as upgrade capacity, modification capacity, etc.

[0100] According to an exemplary embodiment, the token capacity of an in-game asset is dynamically modified during in-game progression events. Dynamically modifying the token capacity in response to the occurrence of in-game progression events (as opposed to modifying attribute data) provides technical benefits because it minimizes intensive computation and processing load from multiple simultaneous events.

[0101] 5A illustrates a first in-game asset 504 of an exemplary electronic game. FIG. 5A also illustrates the token capacity of the first in-game asset 504, represented as a first slot 508 into which an NFT attribute may be inserted, equipped, assigned, etc. In some embodiments, the token capacity of the first in-game asset 504 (specifically, one slot for one attribute upgrade) corresponds to the level, location, condition, classification, asset type, etc. of the first in-game asset 504. For example, in the illustrated example, the first in-game asset 504 is a level 1 turret or small turret, and therefore, the first in-game asset 504 has a token capacity of 1.

[0102] 5B illustrates a second in-game asset 512 of an exemplary electronic game. In the illustrated example, the second in-game asset 512 is an evolution or progression of the first in-game asset 504. For example, the second in-game asset 512 may be a level 2 turret, a medium turret, a turret on a different level / stage / location, etc. Because the second in-game asset 512 is an advanced or developed version of the first in-game asset 504, the token capacity of the second in-game asset 512 is increased. As shown, the token capacity of the second in-game asset 512 includes four slots 516, 520, 524, 528, which is increased from the one slot capacity of the first in-game asset 504.

[0103] Due to the increased slot capacity corresponding to the increased level or progression, the second in-game asset 512 has increased capacity for upgrading its attributes. However, the attributes of the second in-game asset 512 are not upgraded or modified until NFT attributes are equipped, inserted, or assigned to the four slots 516, 520, 524, 528. Thus, without the use of NFT attributes, the second in-game asset 512 features the same attributes, but only with increased potential compared to the first in-game asset 504. Indeed, the attributes of the in-game asset do not change when the first in-game asset 504 progresses or evolves into the second in-game asset 512, thereby saving significant computational or processing effort during progression / evolution.

[0104] Instead, computational operations to modify the in-game asset's attribute data are performed when a player equips an NFT attribute in an in-game asset's slot (e.g., 508, 516, 520, 524, 528). In some embodiments, a player equips NFT attributes owned by the player, and these NFT attributes are identified via the player's wallet, which stores cryptographic keys that reference the NFT attributes. An exemplary wallet is shown and described in more detail with reference to FIG. 2B. In some embodiments, an electronic game presents or displays a set of NFT attributes that are (i) owned by the player, (ii) not currently applied to other electronic games, and (iii) applicable to in-game assets.

[0105] In response to a user selection of an NFT attribute for the in-game asset, the computer system updates the attribute data for the in-game asset. In the illustrated example of FIG. 5B , an NFT attribute representing and describing a 25-point increase to the damage attribute of the second in-game asset 512 is equipped in slot 520. As a result, the computer system increases the damage attribute of the second in-game asset 512 by 25 points. Similarly, an NFT attribute representing and describing a 25-point increase to the fire rate attribute of the second in-game asset 512 is equipped in slot 524, and the computer system increases the fire rate attribute of the second in-game asset 512 accordingly.

[0106] Following application of the given NFT attribute to the given in-game asset, the computer system communicates with a token availability API, an interoperability API, etc. In particular, the computer system indicates to the API that the given NFT attribute has been applied to the given in-game asset. In response, the API prevents the given NFT attribute from being applied to in-game assets of other electronic games.

[0107] According to aspects of the disclosed technology, in-game assets and their attribute data are stored off-chain, for example, by a game server operating an electronic game to which the in-game assets belong, thereby reducing reliance on blockchain operation to provide and operate the in-game assets, while still allowing blockchain-related items to be used to enhance the operation of the off-chain in-game assets.

[0108] FIG. 6 is a flow diagram illustrating an exemplary process for cryptographic application of non-fungible tokens to electronic games. In some embodiments, the process is performed by a game server. A game server (sometimes called a host) is a server that is the authoritative source of events in a multiplayer video game. The server transmits sufficient data about its internal state so that its connected clients can maintain their own accurate versions of the game world for display to players. The game server also receives and processes each player's input. In some embodiments, the process of FIG. 6 is performed by a computer system, such as the exemplary computer system 1000 shown and described in more detail with reference to FIG. 10. In other embodiments, a specific entity, such as a machine learning (ML) system, performs some or all of the steps of the process. The exemplary ML system 900 is shown and described in more detail with reference to FIG. 9. Similarly, embodiments may include different and / or additional steps or may perform steps in a different order.

[0109] In step 604, the computer system operates a particular electronic game of one or more electronic games being played by one or more players. Each player of the one or more players is represented by a player character. A player character (also known as a playable character or PC) is a fictional character in the video game whose actions are controlled by the player. The player character is stored outside the blockchain. An example blockchain 104 is shown and described in more detail with reference to FIG. 1.

[0110] In some embodiments, an electronic game includes multiple in-game assets that are stored off-chain. For example, the in-game assets include player character or avatar assets, environment assets, item or object assets, projectile or dynamic assets, interactable assets, etc. In some embodiments, the in-game assets include attributes that define how each asset interacts with other assets and / or how it behaves in response to player actions.

[0111] In step 608, the computer system determines that a particular player character representing a particular player of the one or more players has reached a first level of the electronic game. In some examples, a level refers to a state, classification, tier, rank, etc. of an in-game asset, such as a particular player character. Level progression is generally achieved through the fulfillment or completion of predefined requirements, such as the player character accumulating a threshold number of XP or item assets, or the player character reaching a specific location within the in-game environment.

[0112] In-game assets that can progress through levels include items and objects within the game world that can be collected or used by the player, or in some cases, non-player characters. Items are sometimes called pickups. Items are most often beneficial to the player character. Some games include harmful items, such as cursed armor pieces that give the wearer a negative bonus and cannot be removed until the curse is lifted; the means to do this requires specific NFT attributes. In some embodiments, specific NFT attributes represent attribute modifications, upgrades, increases, etc., of in-game assets (e.g., in-game armor items). Some items can be required to complete quests or progress through the game. Items can be unique and often appear only once in a specific location after completing a specific task. In some embodiments, in-game items are associated with one or more slots, where NFT attribute upgrades or modifications are applied to the in-game item.

[0113] In some embodiments, the number of slots for an in-game item is defined as the token capacity, which controls the maximum number of NFT attributes that can be applied to an in-game item at one time. Inserting an NFT attribute into an in-game item slot applies the NFT attribute to the in-game item. Thus, a player can continue to apply NFT attributes to slots of an in-game item until capacity is reached. In some embodiments, the number of slots or capacity of an in-game item is dynamically modified, for example, when an in-game item or associated asset reaches a certain level, a certain location, a certain classification, a certain state, etc. For example, the capacity of an in-game item may increase linearly (e.g., 1 slot at item level 1, 2 slots at item level 2, and 3 slots at item level 3), geometrically (e.g., 2 slots at item level 1, 4 slots at item level 2, and 6 slots at item level 3), or exponentially (e.g., 1 slot, 4 slots, 9 slots, and 16 slots at item levels 1, 2, 3, and 4, respectively).

[0114] In step 612, the computer system increases the modification capacity or token capacity of the particular player character in response to determining that the particular player character has reached the first level. In some embodiments, the computer system dynamically changes the modification capacity of an in-game asset (including, for example, a player character, an in-game item, or an object) in response to a progression event of the in-game asset.

[0115] In some embodiments, the computer system unlocks certain items or objects for use by particular player characters at different levels, with each unlocked item associated with a token capacity for attribute upgrades for the respective attribute. In some embodiments, in-game items are unlocked for particular player characters based on certain predetermined conditions being met.

[0116] In some embodiments, the computer system rewards players with NFT attributes for completing or achieving various in-game conditions. The computer system mints one or more NFT attributes on the blockchain. For example, one or more NFT attributes are minted in response to a particular player character reaching a second level or in response to other in-game events (e.g., a level-up or progression event). Specifically, the NFT attributes are NFTs that represent or describe upgrades to attributes of an in-game item, and in some embodiments, the NFT attributes are minted on the blockchain in response to certain predetermined conditions within the electronic game being met. In some examples, existing NFT attributes exist on the blockchain and can be traded between players, purchased by players, sold by players, etc. The minting process publishes unique NFT attributes on the blockchain so that they can be bought, sold, and traded. In embodiments, the computer system is informed by the designer of the electronic game of the type of digital art or other digital collectible (e.g., player character, in-game item, game points, armor, game skin, or ammunition) represented by the NFT. Cryptocurrency from an internet-connected hot wallet can be used to pay for minting or purchase the NFT. For example, the NFT can be minted on a marketplace, and the digital asset can be added to a player's collection.

[0117] In some embodiments, the computer system stores one or more cryptographic keys within a particular player's wallet. An exemplary wallet is shown and described in more detail with reference to FIG. 2B. A cryptographic key is a string of data used to lock or unlock cryptographic functions, including authentication, authorization, and encryption. Cryptographic keys are grouped into cryptographic key types according to the functions they perform. A digital wallet is a device, physical medium, program, or service that stores public and / or private keys for cryptocurrency transactions. In addition to this basic function of storing keys, cryptocurrency wallets often also provide the ability to encrypt and / or sign information. Signatures may result in, for example, executing smart contracts, cryptocurrency transactions, or identities.

[0118] In some embodiments, the wallet operates by generating a theoretical or random number whose length depends on the algorithm size of the blockchain's technical requirements. This number can be converted into a private key using the specific requirements of the cryptographic algorithm. A public key can be generated from the private key using the cryptographic algorithm. The private key is used by the player to access and send the NFT and is private to the owner, while the public key is shared with any third party to receive the NFT. The blockchain records public address transactions when NFTs are minted and NFT attributes are added. One or more keys in the player's wallet reference one or more NFT attributes stored on the blockchain. For example, a key may point to a blockchain address that stores a certificate of ownership.

[0119] At step 616, the computer system applies one or more NFT attributes to the in-game item using the one or more keys. In some embodiments, applying the NFT attributes includes modifying the attributes of the in-game item according to the attribute upgrades represented or defined by the NFT attributes. For example, the in-game item may define a damage attribute associated with the in-game item (which defines how in-game damage actions are performed), and applying an NFT attribute associated with a damage increase includes changing the in-game item's damage attribute to reflect the damage increase. As discussed, a certain number of NFT attributes may be applied to an in-game item according to the in-game item's capacity (e.g., as defined by a capacity parameter associated with the in-game item), and in accordance with the disclosed technology, the in-game item's capacity changes in response to in-game progression events.

[0120] In some embodiments, the application of a given NFT attribute to a given in-game asset is controlled by various rules of an electronic game. For example, such rules may dictate that a given NFT attribute can only be applied when the given in-game asset is at a certain level, in a certain location, in a certain classification, in a certain state, etc. In some embodiments, the rules defining the game-specific parameters under which a given NFT attribute can be applied to a given in-game asset are included in a smart contract associated with the NFT attribute and stored on a blockchain. In other embodiments, the rules are stored and used off-chain.

[0121] In some embodiments, applying the NFT attributes to the in-game asset includes displaying an indication of the NFT attributes. For example, the indication of the NFT attributes includes digital art referenced by the NFT attributes (e.g., digital art referenced by an NFT stored on a blockchain, digital art stored on a blockchain), digital art associated with the electronic game, or a combination thereof. In some embodiments, the computer system displays an indication of each NFT attribute currently applied to the in-game asset along with a visual representation of the in-game asset.

[0122] In step 620, the computer system sends the notification to an application programming interface (API) executed by the computer system. In embodiments, the API implements communication between at least two of the computer system, one or more electronic games, one or more player wallets, or a blockchain. For example, an API is a type of software interface that provides services to one or more electronic games, one or more player wallets, or a blockchain. Game designers of one or more electronic games can incorporate APIs into the code or software of the one or more electronic games. Designers can also choose to call only a portion of an API. The calls that make up an API are also known as subroutines, methods, requests, or endpoints.

[0123] The notification indicates that a particular electronic game is using one or more NFT attributes referenced by one or more keys stored in the wallet. For example, the notification may be a trigger, a message, or an alert. The notification may be encoded in different formats. The format specifies how bits in the notification are used to encode information. In one example, the notification uses lossless data compression. In one example, the notification may serve as a container for other types of data and metadata. In one example, the notification may include any stream of characters, including possible control characters, and may be encoded in one of a variety of character encoding schemes. In some implementations, the notification is separated into a header, a payload, and a footer.

[0124] In some embodiments, the notification causes the API to prevent the simultaneous application of one or more NFT attributes to in-game assets in other electronic games. For example, the API is a token availability API. In some embodiments, the computer system determines that the NFT attributes are no longer applied to the in-game item. For example, the player removes the NFT attributes from one of the in-game item's slots, the player stops playing the electronic game, or the like. As a result, the computer system allows the transfer of the NFT attributes to in-game assets in other electronic games. For example, the computer system sends another notification to the API to stop the API from continuing to prevent the application of the NFT attributes in other games. Thus, for example, the player can transfer the NFT attributes to a player character in another game to reach the next level or complete an objective in the other game.

[0125] FIG. 7 is a flow diagram illustrating an exemplary process for cryptographic application of non-fungible tokens to electronic games. In some embodiments, the process is performed by a game server. A game server (sometimes called a host) is a server that is the authoritative source of events in a multiplayer video game. The server transmits sufficient data about its internal state so that its connected clients can maintain their own accurate versions of the game world for display to players. The game server also receives and processes each player's input. In some embodiments, the process of FIG. 7 is performed by a computer system, such as the exemplary computer system 1000 shown and described in more detail with reference to FIG. 10. In other embodiments, a specific entity, such as a machine learning (ML) system, performs some or all of the steps of the process. The exemplary ML system 900 is shown and described in more detail with reference to FIG. 9. Similarly, embodiments may include different and / or additional steps or may perform steps in a different order.

[0126] In step 704, the computer system operates a first electronic game of the one or more electronic games. The first electronic game is being played by a player represented by a player character. The player character is stored outside the blockchain. An example blockchain 104 is shown and described in more detail with reference to FIG. 1.

[0127] In some embodiments, the computer system stores one or more keys in a player's wallet. The one or more keys reference one or more attribute modifications or NFT attributes stored on the blockchain. The wallet is readable by an API executed by the computer system. For example, the keys are stored in the player's wallet based on an in-game or in-application purchase associated with the player to obtain one or more NFT attributes. As another example, the keys are stored in the player's wallet based on the player acquiring one or more NFT attributes by completing one or more in-game goals, satisfying one or more in-game conditions, etc. Thus, in some embodiments, one or more keys stored on the blockchain are unlocked for use by a player in a given electronic game based on the player's actions or activity in the given electronic game, and the one or more keys are stored in the player's wallet.

[0128] In some embodiments, the wallet is one of a software wallet or a hardware wallet, hi some embodiments, the hardware wallet comprises one of a Secure Digital (SD) card, an SD High Capacity card, an SD Extended Capacity (SDXC) card, an SD Ultra Capacity (SDUC) card, a Compact Flash (CF) card, a MicroDrive (MD) card, or a Universal Serial Bus (USB) drive.

[0129] At step 708, the computer system applies one or more NFT attributes to a player character in the first electronic game using one or more keys. For example, the computer system causes a display of NFT attributes owned by the player on the player's computing device so that the player can select one or more NFT attributes to apply to the player character. In response to a user selection of one or more NFT attributes, the computer system applies the one or more NFT attributes. In some embodiments, the computer system further indicates the number of slots or token capacity of the player character (or associated in-game assets) and the number of NFT attributes currently applied to the player character. By doing so, the player is informed of how many NFT attributes may be applied to the player character in the first electronic game.

[0130] In some embodiments, the computer system uses the API to determine that a player is playing a second electronic game of the one or more electronic games simultaneously with the first electronic game.

[0131] At step 712, the computer system receives a request from a player's computer device to apply one or more NFT attributes to an in-game item in a second electronic game. The in-game item is stored outside the blockchain. In some examples, the request is received in connection with an in-game progression event in which the token capacity of the in-game item in the second electronic game is modified.

[0132] In step 716, the computer system uses the API to determine, in response to receiving the request, that one or more NFT attributes be applied to a player character in the first electronic game. For example, the computer system indicates to the API on-chain crypto assets or NFTs that define one or more NFT attributes, and the API indicates whether each on-chain crypto asset or NFT is currently in use. The player character is an example of an in-game asset associated with one or more slots or token capacities for NFT attributes. As discussed herein, the number of slots or token capacity of an in-game asset is dynamically modified based on certain events, such as the player character reaching another level of the electronic game or the player completing one or more in-game goals. As discussed herein, the token capacity of an in-game asset can be increased linearly, geometrically, or exponentially.

[0133] In step 720, in response to determining that one or more NFT attributes are applied to a player character in the first electronic game, the computer system prevents the one or more NFT attributes from being applied to an in-game item in the second electronic game.

[0134] In some embodiments, the process further includes the computer system determining that one or more NFT attributes have become available and then allowing the transfer of the one or more NFT attributes from the first electronic game to the second electronic game. For example, the computer system detects that a player has removed an NFT attribute from an in-game asset of the first electronic game and sends a notification to the API to change the availability state of the NFT attribute from unavailable to available. Similarly, the token availability API is automatically re-queried after a predetermined length of time (e.g., by the computer system, by a computer system operating the second electronic game, or by the player's computing device). Based on the re-query and response provided by the token availability API, the NFT attribute can be applied to the given electronic game.

[0135] The transfer of one or more NFT attributes to a given in-game asset of a second electronic game remains subject to the token capacity of the second electronic game. Thus, as discussed herein, the application of NFT attributes to in-game assets is subject to at least interoperability conditions (NFT attributes may only be applied to one electronic game at a time) and capacity conditions (only a maximum number of NFT attributes may be applied to an in-game asset).

[0136] In some embodiments, the computer system identifies a subset of NFT attributes that are not applied in other electronic games and are therefore available for use in a given electronic game application. In some embodiments, the computer system provides a visual representation (e.g., within a given electronic game) of the subset of NFT attributes. By doing so, a ping-pong effect is avoided, in which a player repeatedly selects an unavailable NFT and faces an error or rejection. The player is directly presented with which NFT attributes are available for application in a given electronic game.

[0137] FIG. 8 is a flow diagram illustrating an exemplary process for cryptographic application of non-fungible tokens to electronic games. As discussed, on-chain cryptographic assets (e.g., NFTs) represent and define attribute modifications. For example, the NFT's smart contract components define each attribute modification, e.g., by defining the given attribute that the attribute modification modifies, the amount by which the given attribute is modified, and / or other parameters associated with each attribute modification. Because the smart contract components are primarily directed to defining attribute modifications, individual games may feature different visual representations of the attribute modifications and are not limited to digital art referenced by the NFT. In some embodiments, the process is performed by a game server or computer system, such as the exemplary computer system 1000 shown and described in more detail with reference to FIG. 10.

[0138] In step 804, the computer system operates an electronic game stored outside the blockchain. The electronic game is being played by a player. An example blockchain 104 is shown and described in more detail with reference to FIG. 1.

[0139] In step 808, the computer system detects a request within the electronic game to use a non-fungible token (NFT) attribute within the electronic game, the NFT attribute being associated with a smart contract stored on a blockchain that is configured to provide modification instructions to modify asset attribute data of an in-game asset of the electronic game.

[0140] In step 812, the computer system retrieves modification instructions for the NFT attribute and generic visual art for the NFT attribute referenced by the smart contract.

[0141] In step 816, the computer system uses the NFT attribute with the specified in-game asset of the electronic game based on modifying asset attribute data of the specified in-game asset in accordance with the modification instruction.

[0142] In step 820, the computer system causes the display of an in-game visual indication that the asset attribute data of the in-game asset has been modified, the in-game visual indication including a combination of generic visual art from the NFT and game-specific visual art of the electronic game. In some embodiments, the in-game visual indication is persistently displayed while the asset attribute data remains modified. For example, in response to the asset attribute data being reverted to its pre-modification state (e.g., based on player input, based on removal / cancellation of the NFT attribute via an interoperability API, based on removal / cancellation of the NFT attribute by purchasing or selling the NFT attribute), the computer system stops displaying the in-game visual indication.

[0143] In some embodiments, the computer system fails to derive generic visual art for the NFT attribute. Some exemplary NFT attributes lack visual art or digital artistic representation and simply provide attribute-modifying instructions (e.g., add 10 hit points to an asset, increase the asset's damage to 25). Thus, the computer system can generate game-specific visual art and use the game-specific visual art to represent the use of the artless NFT attribute.

[0144] In one example, the computer system operates an electronic game being played by a player, detects a request from the player in the electronic game to use a non-fungible token (NFT) attribute in the electronic game, the NFT attribute being associated with a smart contract configured to provide modification instructions for modifying asset attribute data of an in-game asset of the electronic game and lacking digital art representing the NFT attribute, retrieves the modification instructions, and modifies the asset attribute data of the specified in-game asset in accordance with the modification instructions, uses the NFT attribute with a specified in-game asset of the electronic game, and causes the display of an in-game visual indication that the asset attribute data of the in-game asset has been modified, the in-game visual indication including a game-specific digital art representation of the NFT attribute.

[0145] In one example, a computer system detects a request from a player in an electronic game to use a non-fungible token (NFT) attribute in an electronic game, the NFT attribute being associated with a smart contract configured to provide modification instructions for modifying asset attribute data of an in-game asset of the electronic game; in response to the request, operates the electronic game with a specified in-game asset having asset attribute data modified in accordance with the modification instructions; and during operation of the electronic game, provides a visual indication that the NFT attribute has been applied to the specified in-game asset, the visual indication including a game-specific digital art representation of the NFT attribute stored within the electronic game and off the blockchain.

[0146] Figure 9 is a block diagram illustrating an exemplary machine learning (ML) system 300. The ML system 900 is implemented using components of an exemplary computer system 1000 shown and described in more detail with reference to Figure 10. For example, the ML system 900 may be implemented on the computer system 1000 using instructions 1008 programmed into a main memory 1006 shown and described in more detail with reference to Figure 4. Similarly, embodiments of the ML system 900 may include different and / or additional components or may be connected in different ways. The ML system 900 may also be referred to as an ML module.

[0147] The ML system 900 includes a feature extraction module 908, which is implemented using components of an exemplary computer system 1000 shown and described in more detail with reference to FIG. 10 . In some embodiments, the feature extraction module 908 extracts a feature vector 912 from the input data 904. The feature vector 912 includes features 912a, 912b, ..., 912n. The feature extraction module 908 reduces redundancy, e.g., repeated data values, in the input data 904 to convert the input data 904 into a reduced set of features 912, e.g., features 912a, 912b, ..., 912n. The feature vector 912 includes relevant information from the input data 904, so that events or data value thresholds of interest can be identified by the ML model 916 using this reduced representation. In some example embodiments, the following dimensionality reduction techniques are used by the feature extraction module 908: independent component analysis, Isomap, kernel principal component analysis (PCA), latent semantic analysis, partial least squares, PCA, multifactor dimensionality reduction, nonlinear dimensionality reduction, multilinear PCA, multilinear subspace learning, semidefinite embedding, autoencoder, and deep feature synthesis.

[0148] In some embodiments, the ML model 916 performs deep learning (also known as deep structured learning or hierarchical learning) directly on the input data 904 to learn data representations, as opposed to using task-specific algorithms. In deep learning, no explicit feature extraction is performed; instead, features 912 are extracted implicitly by the ML system 900. For example, the ML model 916 may use a cascade of multiple layers of nonlinear processing units for implicit feature extraction and transformation. Each successive layer uses the output from the previous layer as input. Thus, the ML model 916 may learn in supervised (e.g., classification) and / or unsupervised (e.g., pattern analysis) modes. The ML model 916 may learn multiple levels of representations corresponding to different levels of abstraction, where the different levels form a hierarchy of concepts. In this way, the ML model 916 may be configured to distinguish features of interest from background features.

[0149] In one example, the ML model 916, e.g., in the form of a CNN, generates output 924 directly from the input data 904 without the need for feature extraction. In some examples, the output 924 is provided to a computing device 928 or a video display 1018. The computing device 928 is a server, computer, tablet, smartphone, smart speaker, etc., implemented using components of the exemplary computing system 1000 shown and described in more detail with reference to FIG. 10 . In some embodiments, the steps performed by the ML system 900 are stored in memory on the computing device 928 for execution.

[0150] CNN is a type of feedforward artificial neural network whose inter-neuron connectivity pattern is inspired by the organization of the visual cortex. Individual cortical neurons respond to stimuli in a restricted region of space known as a receptive field. The receptive fields of different neurons partially overlap so that they cover the visual field. The response of an individual neuron to stimuli in its receptive field can be mathematically approximated by a convolution operation. CNN is a variant of a multilayer perceptron that is based on biological processes and designed to use a minimal amount of preprocessing.

[0151] The ML model 916 can be a CNN that includes both convolutional and max-pooling layers. The architecture of the ML model 916 can be "fully convolutional," meaning that variable-sized sensor data vectors can be fed to it. For every convolutional layer, the ML model 916 can specify the kernel size, the convolution stride, and the amount of zero padding applied to the input of that layer. For pooling layers, the model 916 can specify the pooling kernel size and stride.

[0152] In some embodiments, the ML system 900 trains an ML model 916 based on training data 920 to train feature vectors 912 to correlate with expected outputs in the data 920. As part of training the ML model 916, the ML system 900 forms a training set of features and training labels by identifying a positive training set of features determined to have the desired properties of interest, and in some embodiments, a negative training set of features that lack the properties of interest.

[0153] The ML system 900 applies ML techniques to train an ML model 916 that, when applied to a feature vector 912, outputs an indication of whether the feature vector 912 has an associated desired property, such as the probability that the feature vector 912 has a particular Boolean property, or an estimate of a scalar property. The ML system 900 can further apply dimensionality reduction (e.g., via linear discriminant analysis (LDA), PCA, etc.) to reduce the amount of data in the feature vector 912 to a smaller, more representative data set.

[0154] The ML system 900 can train the ML model 916 using supervised ML, with feature vectors from the positive and negative training sets serving as input. In some embodiments, different ML techniques are used, such as linear support vector machines (linear SVMs), boosting for other algorithms (e.g., AdaBoost), logistic regression, naive Bayes, memory-based learning, random forests, bagged trees, decision trees, boosted trees, boosted strains, neural networks, CNNs, etc. In some exemplary embodiments, the validation set 932 is formed from additional features beyond those in the training data 920, which have already been determined to possess or lack the property of interest. The ML system 900 applies the trained ML model 916 to the features in the validation set 932 to quantify the accuracy of the ML model 916. Common metrics applied to measure accuracy include precision and recall. Precision refers to the number of correctly predicted outcomes out of the total predicted outcomes by the ML model 916, and recall refers to the number of correctly predicted outcomes by the ML model 916 out of the total number of features having the desired characteristic of interest. In some embodiments, the ML system 900 iteratively retrains the ML model 916 until a stopping condition occurs, such as an accuracy measurement indicating that the ML model 916 is sufficiently accurate or the number of training rounds performed. The validation set 932 can include data corresponding to identified anatomical features, tissue states, tissue conditions, diagnoses, or combinations thereof. This allows detected values ​​to be validated using the validation set 932. The validation set 932 can be generated based on the analysis to be performed.

[0155] 10 is a block diagram illustrating an exemplary computer system according to one or more embodiments. In some embodiments, components of the exemplary computer system 1000 are used to implement the blockchain system 100 or the ML system 900 shown and described in more detail with reference to FIGS. 1 and 9. At least some of the operations described herein may be implemented on the computer system 1000.

[0156] The processing system 1000 may include one or more central processing units ("processors") 1002, a main memory 1006, a non-volatile memory 1010, a network adapter 1012 (e.g., a network interface), a video display 1018, input / output devices 1020, control devices 1022 (e.g., a keyboard and pointing device), a drive unit 1024 including a storage medium 1026, and a signal generating device 1020 communicatively coupled to a bus 1016. The bus 1016 is shown as an abstraction representing one or more physical buses and / or point-to-point connections connected by appropriate bridges, adapters, or controllers. Thus, the bus 1016 may include a system bus, a Peripheral Component Interconnect (PCI) bus or PCI Express bus, a HyperTransport or industry standard architecture (ISA) bus, a small computer system interface (SCSI) bus, a Universal Serial Bus (USB), an IIC (IIC, I2C) bus, or an Institute of Electrical and Electronics Engineers (IEEE) standard 1394 bus (sometimes referred to as "firmware").

[0157] Processing system 1000 may share a computer processor architecture similar to that of a desktop computer, a tablet computer, a personal digital assistant (PDA), a mobile phone, a game console, a music player, a wearable electronic device (e.g., a watch or fitness tracker), a network-connected (“smart”) device (e.g., a television or home assistant device), a virtual / augmented reality system (e.g., a head-mounted display), or another electronic device capable of executing a series of instructions that specify actions to be taken (sequentially or otherwise) by processing system 1000.

[0158] Although main memory 1006, non-volatile memory 1010, and storage medium 1026 (sometimes referred to as a "machine-readable medium") are shown as a single medium, the terms "machine-readable medium" and "storage medium" are understood to include a single medium or multiple media (e.g., centralized / distributed databases and / or associated caches and servers) that store one or more sets of instructions 1028. The terms "machine-readable medium" and "storage medium" are also understood to include any medium capable of storing, encoding, or carrying sets of instructions for execution by processing system 1000.

[0159] Generally, the routines executed to implement embodiments of the present disclosure may be implemented as part of an operating system or a specific application, component, program, object, module, or sequence of instructions (collectively referred to as a "computer program"). A computer program typically includes one or more instructions (e.g., instructions 1004, 1008, 1028) that are configured at various times in various memory and storage devices of a computing device. When read and executed by one or more processors 1002, the instructions cause the computer system 1000 to perform operations to execute elements involved in various aspects of the present disclosure.

[0160] Additionally, while embodiments have been described in the context of fully functional computing devices, those skilled in the art will appreciate that various embodiments can be distributed as program products in a variety of forms, and this disclosure applies regardless of the particular type of machine or computer-readable medium used to accomplish the distribution.

[0161] Further examples of machine-readable storage media, machine-readable media, or computer-readable media include recordable media such as volatile and non-volatile memory devices 1010, floppy and other removable disks, hard disk drives, optical disks (e.g., Compact Disc Read-Only Memories (CD-ROMS), Digital Versatile Discs (DVDs)), and transmission-type media such as digital and analog communications links.

[0162] Network adapter 1012 enables computer system 1000 to broker data within network 1014 with entities external to computer system 1000 through any communication protocol supported by computer system 1000 and the external entities. Network adapter 1012 may include a network adapter card, a wireless network interface card, a router, an access point, a wireless router, a switch, a multi-layer switch, a protocol translator, a gateway, a bridge, a bridge router, a hub, a digital media receiver, and / or a repeater.

[0163] The network adapter 1012 may include a firewall that governs and / or manages permissions to access / proxy data within a computer network and tracks various levels of trust between different machines and / or applications. A firewall may be any number of modules having any combination of hardware and / or software components that can enforce a predetermined set of access rights between a particular set of machines and applications, machines and / or applications (e.g., to regulate the flow of traffic and resource sharing between these entities). A firewall may additionally manage and / or include access to access control lists that detail permissions, including the rights of individuals, machines, and / or applications to access and manipulate objects, and the circumstances under which the permissions exist.

[0164] The functions performed in the processes and methods may be implemented in differing orders. Additionally, the outlined steps and operations are provided by way of example only, and some of the steps and operations may be optional, combined into fewer steps and operations, or expanded into additional steps and operations without departing from the essence of the disclosed embodiments.

[0165] The techniques introduced herein may be implemented using programmable circuitry (e.g., one or more microprocessors), software and / or firmware, dedicated hardwired (i.e., non-programmable) circuitry, or a combination of these forms. The dedicated circuitry may be in the form of one or more application specific integrated circuits (ASICs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), etc.

[0166] The description and drawings herein are illustrative and should not be construed as limiting. Numerous specific details are set forth to provide a thorough understanding of the present disclosure. However, in certain instances, well-known details are not set forth to avoid obscuring the description. Furthermore, various modifications are possible without departing from the scope of the embodiments.

[0167] The terms used herein generally have their ordinary meanings in the art, within the context of this disclosure, and within the specific context in which each term is used. Certain terms used to describe this disclosure have been discussed above or elsewhere herein to provide additional guidance to practitioners regarding the description of this disclosure. For convenience, certain terms may be highlighted, for example, using italics and / or quotation marks. The use of highlighting does not affect the scope and meaning of a term; the scope and meaning of a term are the same in the same context whether or not it is highlighted. It will be understood that the same thing may be stated in more than one way. It will be recognized that "memory" is a form of "storage," and that these terms may sometimes be used interchangeably.

[0168] Accordingly, alternative language and synonyms may be used in place of any one or more of the terms discussed herein, and no special significance is attached to whether a term is recited or discussed herein. Synonyms for particular terms are provided. The listing of one or more synonyms does not exclude the use of other synonyms. The use of examples anywhere in this specification, including examples of any term discussed herein, is illustrative only and is not intended to further limit the scope and meaning of the disclosure or any exemplified term. Similarly, the disclosure is not limited to the various embodiments provided herein.

[0169] It should be understood that the embodiments and variations shown and described herein are merely illustrative of the principles of the present invention and that various modifications can be made by those skilled in the art.

Claims

1. 1. A computer-implemented method comprising: The computer system controls one or more players, each player of the one or more players is represented by a player character; The player character operates a particular electronic game among one or more electronic games played by one or more players, the electronic game being stored outside of a blockchain; determining that a particular player character representing a particular player of the one or more players has reached a first level of the particular electronic game; increasing a modification capacity of the particular player character in response to determining that the particular player character has reached the first level; a number of attribute modifications that fill the modification capacity of the particular player character in response to user input by the particular player, applying a number of attribute modifiers to the particular player character, each of the attribute modifiers being defined by an on-chain crypto asset owned by the particular player; and sending a notification to an application programming interface (API) executed by the computer system indicating that one or more respective on-chain crypto assets for the number attribute modifications are being used within the particular electronic game.

2. 2. The computer-implemented method of claim 1, wherein the attribute modification is identified using a cryptographic key corresponding to the particular player, the cryptographic key being associated with each on-chain cryptographic asset owned by the particular player.

3. 2. The computer-implemented method of claim 1, wherein at least one of the attribute modifiers is defined by a particular on-chain crypto asset owned by the particular player as a result of the particular player satisfying one or more predetermined conditions within one of the one or more electronic games.

4. 2. The computer-implemented method of claim 1, wherein at least one of the attribute modifiers is defined by a particular on-chain cryptocurrency as a result of a purchase by the particular player of the particular on-chain cryptocurrency owned by the particular player.

5. 2. The computer-implemented method of claim 1, wherein the API is configured to prevent the attribute modification defined by the one or more respective crypto assets from being applied in a second electronic game of the one or more electronic games.

6. the particular electronic game is a first electronic game of the one or more electronic games, and the computer-implemented method comprises: determining that the one or more attribute modifications no longer apply to the particular player character in the first electronic game; The computer-implemented method of claim 1 , further comprising: permitting use of the one or more crypto assets in a second electronic game of the one or more electronic games.

7. 7. The computer-implemented method of claim 6, wherein using the one or more crypto assets in the second electronic game includes applying the one or more modifications to a second player character in the second electronic game associated with the particular player.

8. 1. A computer system comprising: one or more hardware computer processors; and at least one non-transitory computer-readable storage medium storing computer instructions, which, when executed by the one or more computer processors, cause the system to: An electronic game being played by one or more players, comprising: each player associated with one or more in-game assets of the electronic game; operating an electronic game, wherein the one or more in-game assets are stored off-chain by the computer system; A progression event related to a particular in-game asset associated with a particular player, detecting the occurrence of a progression event defined by one or more game conditions associated with at least one of the particular player or the particular in-game asset; In response to said occurrence, an upgrade capacity of said particular in-game asset; Controlling the maximum number of attribute upgrades that may be applied to said particular in-game asset; The attribute upgrade increases the upgrade capacity defined by the on-chain cryptocurrency; applying a particular attribute upgrade defined by a particular on-chain cryptographic asset owned by the particular player to the particular in-game asset based on a determination that the number of attribute upgrades currently applied to the particular in-game asset is less than the upgrade capacity; A computer system that causes an application programming interface (API) executed by the computer system to send a notification indicating that the particular on-chain crypto asset is being used in the electronic game.

9. 9. The computer system of claim 8, wherein applying the particular attribute upgrade comprises determining that the particular on-chain cryptographic asset is owned by the particular player according to a cryptographic key associated with the particular on-chain cryptographic asset corresponding to the particular player.

10. 10. The computer system of claim 8, wherein the particular on-chain crypto asset is minted onto a blockchain in response to the particular player fulfilling one or more in-game conditions of the electronic game.

11. 9. The computer system of claim 8, wherein the upgrade capacity of the particular in-game asset increases linearly, geometrically, or exponentially in response to each occurrence of the progression event.

12. The instructions further include: The computer system of claim 8 , further comprising: a display of a plurality of attribute upgrades applied to the particular in-game asset in association with the visual representation of the particular in-game asset.

13. 13. The computer system of claim 12, wherein the display of the plurality of attribute upgrades comprises a visual representation of each attribute upgrade using a combination of (i) digital art referenced by the on-chain cryptographic asset for each attribute and (ii) game-specific digital art.

14. 10. The computer system of claim 8, wherein the notification to the API causes the API to prevent use of the particular on-chain crypto asset in other electronic games.

15. A non-transitory computer-readable storage medium storing computer instructions, the computer instructions, when executed by one or more computer processors, causing the one or more computer processors to: A particular electronic game among a plurality of electronic games in a shared ecosystem, the particular electronic game includes a plurality of in-game assets associated with a plurality of players; operating a specific electronic game in which the plurality of in-game assets are stored off-chain; detecting an occurrence of a progression event for a particular in-game asset of the particular electronic game, the progression event being based on the satisfaction of one or more conditions associated with the particular in-game asset; modifying a capacity parameter associated with the particular in-game asset in response to the occurrence; Identifying a set of on-chain crypto assets owned by a particular player that are associated with the particular in-game asset; For the particular player, the number of on-chain crypto assets in the set of on-chain crypto assets for application to the particular in-game asset; a non-transitory computer-readable storage medium that causes a display of a number of on-chain crypto assets based on the capacity parameter and a current number of on-chain crypto assets applied to the particular in-game asset.

16. The instructions further cause the one or more computer processors to: applying a specific on-chain cryptographic asset to the specific in-game asset, wherein applying the specific on-chain cryptographic asset comprises modifying an attribute of the specific in-game asset by an amount defined by the specific on-chain cryptographic asset; A notification indicating that the specific on-chain crypto asset is being used within the specific electronic game, 16. The non-transitory computer-readable storage medium of claim 15, wherein the API sends a notification that prevents use of the particular on-chain crypto asset in other electronic games in the shared ecosystem.

17. Applying the specific on-chain crypto asset combining digital art referenced by the particular on-chain crypto asset with in-game digital art to form a visual representation of the in-game asset; and causing presentation of the visual representation of the in-game asset.

18. 16. The non-transitory computer-readable storage medium of claim 15, wherein the set of on-chain cryptographic assets is identified via a cryptographic key corresponding to the particular player that is associated with the set of on-chain cryptographic assets on a blockchain.

19. 16. The non-transitory computer-readable storage medium of claim 15, wherein modifying the capacity parameter comprises increasing the capacity parameter by one of a linear factor, a geometric factor, or an exponential factor.

20. 16. The non-transitory computer-readable storage medium of claim 15, wherein the set of on-chain crypto assets is further identified based on one or more rules of the particular electronic game that control the applicability of a particular on-chain crypto asset to the particular in-game asset.

21. 1. A computer-implemented method comprising: a first electronic game of the one or more electronic games, the first electronic game comprising: the first electronic game being played by a player represented by a player character; The player character operates a first electronic game stored outside of a blockchain; one or more attribute modifications according to a modification capacity associated with said player character, said modification capacity defining a maximum number of attribute modifications for said player character; applying one or more attribute modifiers to the player character in the first electronic game, the modifiers being defined by one or more on-chain cryptographic assets on the blockchain; assigning the one or more attribute modifications to in-game assets in a second electronic game of the one or more electronic games, receiving a request to apply an in-game asset, the in-game asset being stored outside the blockchain; In response to receiving the request, determining that the one or more attribute modifications are currently applied within the first electronic game based on representing the one or more on-chain cryptographic assets to an API; and and in response to determining that the one or more attribute modifications are currently applied in the first electronic game, preventing, via the API, the one or more attribute modifications from being applied to the in-game asset in the second electronic game.

22. determining from the API that the one or more attribute modifications have been removed from the player character in the first electronic game; 22. The computer-implemented method of claim 21, comprising: in response to determining that the one or more on-chain cryptographic assets have been removed from the player character, allowing application of the one or more attribute modifiers within the second electronic game.

23. 22. The computer-implemented method of claim 21, comprising executing an in-application purchase associated with the player to acquire the one or more on-chain cryptographic assets, wherein in response to executing the in-application purchase, a cryptographic key corresponding to the player is associated with the one or more on-chain cryptographic assets.

24. 22. The computer-implemented method of claim 21, wherein at least one of the on-chain crypto assets is an NFT associated with a smart contract that defines a respective attribute modification.

25. 22. The computer-implemented method of claim 21, wherein the modification capacity associated with the player character is represented by one or more slots, in each of the one or more slots a respective attribute modification is applied, the number of slots corresponding to the level of the player character.

26. 22. The computer-implemented method of claim 21 , wherein applying the one or more attribute modifications comprises using the player's wallet to determine that the one or more on-chain crypto assets are owned by the player.

27. 22. The computer-implemented method of claim 21, wherein at least one of the second electronic game or the API is operated by the computer system.

28. 1. A computer system comprising: one or more computer processors; and at least one non-transitory computer-readable storage medium storing computer instructions, which, when executed by the one or more computer processors, cause the computer system to: operating a first electronic game of the plurality of electronic games; receiving a request from a computing device of a player of the first electronic game to apply an on-chain crypto asset to an in-game asset of the first electronic game; the in-game assets of the first electronic game are stored outside of a blockchain; receiving the on-chain crypto asset defining an attribute modification for the in-game asset; In response to receiving the request, querying a game interoperability API to determine whether the on-chain cryptographic asset has been applied to a given in-game asset in a second electronic game of the plurality of electronic games; and and in response to receiving a response from the game interoperability API indicating that the on-chain cryptographic asset has been applied to the given in-game asset of the second electronic game, preventing the on-chain cryptographic asset from being applied to the in-game asset of the first electronic game.

29. The computer instructions further include:

30. The computer system of claim 28, wherein the request to apply an on-chain crypto asset is received based on a user interaction with the player, the request causing a representation of a set of on-chain crypto assets owned by the player.

30. The computer instructions further include:

30. The computer system of claim 28, further comprising determining a set of on-chain crypto assets owned by the player based on accessing the player's wallet, the on-chain crypto asset being one of the set of on-chain crypto assets.

31. The computer instructions further include: causing the Game Interoperability API to be re-queried following a predetermined amount of time; 29. The computer system of claim 28, wherein in response to receiving a response from the game interoperability API indicating that the on-chain cryptographic asset has not been applied to the given in-game asset of the second electronic game, the computer system applies the on-chain cryptographic asset to the in-game asset of the first electronic game.

32. The computer instructions further include:

22. The computer system of claim 21, further comprising: causing the game interoperability API to send a notification indicating that the on-chain crypto asset has been applied to the in-game asset of the first electronic game.

33. 22. The computer system of claim 21, wherein the on-chain cryptocurrency is applied to the in-game asset of the first electronic game based on the number of on-chain cryptocurrency assets currently applied to the in-game asset being less than an upgrade capacity of the in-game asset.

34. 30. The computer system of claim 28, wherein the request is received in response to an in-game progression event of the first electronic game that modifies an upgrade capacity of the in-game asset of the first electronic game.

35. A non-transitory computer-readable storage medium storing computer instructions, the computer instructions, when executed by one or more computer processors, causing the one or more computer processors to: operating a first electronic game in the electronic game ecosystem; determining a set of on-chain cryptographic assets owned by a particular player and defining attribute modifications applicable to a given in-game asset of the first electronic game; using a game interoperability API to identify a subset of the on-chain crypto assets that are not applied to in-game assets of other electronic games in the electronic game ecosystem; a non-transitory computer-readable storage medium that causes a computer system of the particular player to provide a visual representation within the first electronic game that depicts the subset of the on-chain crypto assets;

36. 36. The non-transitory computer-readable storage medium of claim 35, wherein the one or more computer processors determine the set of on-chain cryptographic assets in response to an in-game progression event that causes an upgrade capacity of the in-game assets of the first electronic game to be modified.

37. 36. The non-transitory computer-readable storage medium of claim 35, wherein the computer instructions cause the one or more computer processors to determine the set of on-chain cryptographic assets based on a cryptographic key corresponding to the particular player being associated with each of the set of on-chain cryptographic assets on a blockchain.

38. 38. The non-transitory computer-readable storage medium of claim 37, wherein at least one of the on-chain crypto assets is owned by the particular player based on the particular player fulfilling one or more predetermined conditions in the first electronic game.

39. 38. The non-transitory computer-readable storage medium of claim 37, wherein at least one of the on-chain crypto assets is owned by the particular player based on a purchase of the at least one of the on-chain crypto assets by the particular player.

40. The computer instructions may further cause the one or more computer processors to: in response to a user selection of a particular on-chain cryptographic asset of the subset of on-chain cryptographic assets, applying the particular on-chain cryptographic asset to the given in-game asset based on modifying an attribute of the given in-game asset according to a particular attribute modification defined by the particular on-chain cryptographic asset; 36. The non-transitory computer-readable storage medium of claim 35, further comprising causing the game interoperability API to send a notification indicating that the particular on-chain crypto asset is being applied within the first electronic game.

41. 1. A computer-implemented method comprising: Operating, by a computer system, an electronic game stored outside the blockchain and played by a player; Detecting, by the computer system, a request in the electronic game to use a non-fungible token (NFT) attribute in the electronic game, the NFT attribute being associated with a smart contract stored on the blockchain, the smart contract being configured to provide modification instructions to modify asset attribute data of an in-game asset of the electronic game; Retrieving, by the computer system, the modification instructions for the NFT attributes and generic visual art for the NFT attributes referenced by the smart contract; using, by the computer system, the NFT attribute with a specified in-game asset of the electronic game based on modifying, by the computer system, the asset attribute data of the specified in-game asset in accordance with the modification instruction; and causing the computer system to display an in-game visual indication that the asset attribute data of the in-game asset has been modified, the in-game visual indication including a combination of the generic visual art from the NFT and game-specific visual art of the electronic game.

42. 42. The computer-implemented method of claim 41, wherein the in-game visual indication is persistently displayed while the asset attribute data remains modified according to the modification instructions.

43. 42. The computer-implemented method of claim 41, wherein the game-specific visual art is stored with the electronic game outside the blockchain.

44. 42. The computer-implemented method of claim 41, wherein the designated in-game asset is a player character controlled by the player.

45. 42. The computer-implemented method of claim 41, wherein the in-game visual indication is different from a second in-game visual indication in a second electronic game, the second in-game visual indication comprising a combination of the generic visual art from the NFT and game-specific visual art of the second electronic game.

46. 42. The computer-implemented method of claim 41, wherein the game-specific visual art for the electronic game is stored with a plurality of game-specific visual art corresponding to a plurality of electronic games in a gaming ecosystem, each of the plurality of game-specific visual art configured to represent the NFT attribute.

47. 42. The computer-implemented method of claim 41, wherein, in response to determining that an attribute capacity of the specified in-game asset has not been exceeded, the NFT attribute is used with the specified in-game asset.

48. 1. A computer system comprising: one or more computer processors; and at least one non-transitory computer-readable storage medium storing computer instructions, the instructions, when executed by the one or more computer processors, causing the computer system to: operating an electronic game being played by a player; Detecting a request from the player in the electronic game to use a non-fungible token (NFT) attribute in the electronic game, the NFT attribute being associated with a smart contract configured to provide modification instructions to modify asset attribute data of an in-game asset of the electronic game, and the NFT attribute lacking digital art representing the NFT attribute; and causing the NFT attributes to be used with the specified in-game asset based on retrieving the modification instruction and modifying the asset attribute data of the specified in-game asset of the electronic game in accordance with the modification instruction; A computer system that causes the display of an in-game visual indication that the asset attribute data of the in-game asset has been modified, the in-game visual indication including a game-specific digital art representation of the NFT attribute.

49. 49. The computer system of claim 48, wherein the in-game visual indication is persistently displayed until the property attribute data is returned to a pre-modification state.

50. 49. The computer system of claim 48, wherein the designated in-game asset is a player character controlled by the player.

51. 49. The computer system of claim 48, wherein the game-specific digital art representation of the NFT attribute is stored with the electronic game outside of a blockchain on which the smart contract resides.

52. 49. The computer system of claim 48, wherein the NFT attribute is used with the specified in-game asset in response to determining that the NFT attribute is not used in another electronic game within a gaming ecosystem to which the electronic game belongs.

53. The instructions further include:

49. The computer system of claim 48, wherein the NFT attribute is verified as owned by the player based on referencing a cryptographic wallet address of a wallet associated with the player on a blockchain, and in response to the NFT attribute being verified, the NFT attribute is used with the specified in-game asset.

54. A non-transitory computer-readable storage medium storing computer instructions, the computer instructions, when executed by one or more computer processors, causing the one or more computer processors to: Detecting a request from a player in an electronic game to use a non-fungible token (NFT) attribute in the electronic game, the NFT attribute being associated with a smart contract configured to provide modification instructions to modify asset attribute data of an in-game asset of the electronic game; In response to the request, operating the electronic game with the specified in-game asset having asset attribute data modified in accordance with the modification instruction; A non-transitory computer-readable storage medium that causes, during operation of the electronic game, visual indications that the NFT attributes have been applied to the specified in-game asset to be provided, the visual indications including game-specific digital art representations of the NFT attributes stored within the electronic game and outside of a blockchain.

55. 55. The non-transitory computer-readable storage medium of claim 54, wherein the visual indication is provided persistently until a second request to remove the NFT attribute from the specified in-game asset is detected.

56. The computer instructions may further cause the one or more computer processors to:

55. The non-transitory computer-readable storage medium of claim 54, wherein in response to a failure to obtain the digital artistic representation of the NFT attribute via the smart contract, causes generation of the game-specific digital artistic representation of the NFT attribute.

57. 55. The non-transitory computer-readable storage medium of claim 54, wherein the designated in-game asset is a player character controlled by the player.

58. The computer instructions may further cause the one or more computer processors to:

55. The non-transitory computer-readable storage medium of claim 54, wherein the asset attribute data of the specified in-game asset is modified based on retrieving the modification instruction from the smart contract for the NFT attribute.

59. 55. The non-transitory computer-readable storage medium of claim 54, wherein the game-specific digital artistic representation of the NFT attribute includes at least one portion based on a generic artistic representation of the NFT attribute provided by the smart contract for the NFT attribute.

60. 60. The non-transitory computer-readable storage medium of claim 59, wherein the generic art representation of the NFT attribute is retrievable from an off-chain location based on an Interplanetary File System (IPFS) protocol.

Images