Digital Twin NFT Listing

Listing NFTs associated with physical items is described. Input specifying at least one obligation to be performed as a condition for transferring an NET from a first digital wallet to a second digital wallet is received. A listing for the NFT is then generated with information that describes the NET and the at least one obligation. A smart contract template is also generated, which includes instructions that are configured to ensure performance of the at least one obligation and transfer the NET from the first digital wallet to the second digital wallet. Responsive to purchase of the NFT via the listing, a smart contract is generated by updating the smart contract template with an identifier of the second digital wallet, and the NFT is transferred by executing the smart contract using a distributed state machine implemented on a blockchain.

BACKGROUND

Advances in technology, such as dramatic increases in computing power for smaller and smaller devices and development of more user-friendly tools for creating digital content, have led to the proliferation of digital content. Many creators of and/or persons responsible for popular digital content want to receive a benefit for their role in making such digital content popular and have the digital content treated as a digital asset (e.g., original digital content or digital content representing a physical item). Non-fungible tokens (NFTs) are one mechanism that enable digital content to be treated as digital assets, and do so by programmatically encoding a unique identity of an original asset that distinguishes it from copies of the asset. By using NFTs, an ownership lineage of the digital asset is also tracked via programmatic features of NFTs that ensure digital memorialization of any NET transfers.

Because of this ability to uniquely identify an asset from other assets and because of the functionality to record every transaction involving the asset, developments are being made to use NFTs in connection with physical items (e.g., unique and luxury goods). In contrast to transactions purely involving exchange of these physical items, however, transfer of a corresponding NET, either separately or together with its physical item counterpart, poses vastly different problems.

SUMMARY

To overcome these problems, listing NFTs associated with physical items is described. Input specifying at least one obligation to be performed as a condition for transferring an NET from a first digital wallet to a second digital wallet is received. A listing for the NFT is then generated with information that describes the NFT and the at least one obligation. A smart contract template is also generated, which includes instructions that are configured to ensure performance of the at least one obligation and transfer the NET from the first digital wallet to the second digital wallet. Responsive to purchase of the NFT via the listing, a smart contract is generated by updating the smart contract template with an identifier of the second digital wallet, and the NET is transferred by executing the smart contract using a distributed state machine implemented on a blockchain.

DETAILED DESCRIPTION

Overview

Conventional platforms that enable transferring ownership of physical items, such as online marketplaces, do not offer functionality that enables transferring ownership of digital twin NFTs for physical items. In contrast to conventional processes for transferring ownership of a physical item, where the physical item is materially delivered from a selling entity to a purchasing entity, transferring ownership of a digital twin NFT cannot be performed by physically placing the digital twin NFT “in the hand” of a purchasing individual. Consequently, offers for sale of digital twin NFTs involve considerations that are not contemplated by offers for sale of physical items, and conventional listing systems are not equipped with user interfaces or tools configured for listing digital twin NFTs.

To address these problems, a system and techniques for listing NETs associated with physical items are described. To facilitate generation of a listing for an NFT, the system identifies one or more NFTs stored in a digital wallet and generates an NFT dashboard configured for that particular digital wallet. The NET dashboard includes a bespoke collection of information presented in a user interface that displays information describing each of the one or more NFTs stored in the digital wallet, such as an identifier of the NET, a description of the NET, an ownership type of the NET, an estimated value of the NFT, properties of other NFTs that are similar to the NFT, and so forth. The NFT dashboard thus provides an entity associated with the digital wallet with a consolidated display of information describing NFTs that are available to be listed for sale and an indication of recommended properties for the listing (e.g., description, listing price, and the like). In some implementations, the NFT dashboard is configured to provide an alert indicating when an NFT associated with the digital wallet is detected as trending based on user behavior. One example of user behavior indicating that an NFT is trending includes an increased amount or frequency of keywords associated with the NFT being included in comments posted to social networking sites, search queries submitted to search engines, online and/or print publications, and so forth, relative to normal (e.g., historical averages) amounts or frequencies of the keywords. Other examples of user behavior indicating that an NFT is trending include increased views of listings related to the NET, increased purchase intent actions (e.g., adding to cart, adding to watchlist, bidding, etc.) made with respect to listings related to the NET, and so forth. The NFT dashboard is further configured to include a control for each NFT that is selectable to initiate generating a listing for sale of the NFT.

In response to detecting input at the control specifying that an NET is to be listed for sale, the system presents a plurality of user interfaces that include prompts for information describing aspects to be included in the NFT listing. In addition to prompting for input specifying a description of the NFT to be included in the listing, the user interfaces are configured to obtain input specifying conditions for transferring the NFT from a selling entity to a purchasing entity. Conditions for transferring the NFT may be specified in the form of obligations that must be performed to complete an NFT transfer, such as an obligation performed by a selling entity (e.g., ship physical item to a third-party for authenticity verification), an obligation to be performed by a purchasing entity (e.g., payment of a purchase price), or combinations thereof. The system codifies the obligations for transferring the NFT into a smart contract template for the listing, which includes code that is executable by a distributed state machine implemented by a blockchain to both ensure performance of the obligations and transfer the NFT from a selling entity to a purchasing entity responsive to verifying performance of the obligations.

The system then publishes the listing for viewing by a plurality of computing devices. In response to receiving a transfer request indicating a request to purchase the subject NET and agreement to perform obligations set forth in the listing, the system generates a smart contract for the listing. The system generates the smart contract for the listing by updating the smart contract template using an identifier associated with the computing device or entity from which the transfer request was received. Finally, the system facilitates transfer of the NFT by causing the distributed state machine implemented on the blockchain to execute the smart contract. By virtue of execution on the blockchain, a record of the listing, its associated obligations, and operations performed by the smart contract are memorialized in blockchain transaction data. The system is thus configured to automatically transfer the NET, ensure performance of obligations associated with the listing, and create an accurate ledger of transfer-related information without requiring involvement of an intervening third party.

In the following discussion, an exemplary environment is first described that may employ the techniques described herein. Examples of implementation details and procedures are then described which may be performed in the exemplary environment as well as other environments. Performance of the exemplary procedures is not limited to the exemplary environment and the exemplary environment is not limited to performance of the exemplary procedures.

Example of an Environment

FIG.1is an illustration of an environment100in an example implementation that is operable to employ techniques described herein. The environment100includes a blockchain system102, a service provider system104, and a plurality of client devices (represented in the environment100by client device106and client device108) that are communicatively coupled, one to another, via a network110.

Computing devices that implement the environment100are configurable in a variety of ways. A computing device, for instance, is configurable as a desktop computer, a laptop computer, a mobile device (e.g., assuming a handheld configuration such as a tablet or mobile phone), an IoT device, a wearable device (e.g., a smart watch), an AR/VR device, a server, and so forth. Thus, a computing device ranges from full resource devices with substantial memory and processor resources to low-resource devices with limited memory and/or processing resources. Additionally, although in instances in the following discussion reference is made to a computing device in the singular, a computing device is also representative of a plurality of different devices, such as multiple servers of a server farm utilized to perform operations “over the cloud” as further described in relation toFIG.14.

In accordance with the described techniques, the blockchain system102is implemented by a node112of a network114(e.g., a distributed network) of the nodes112. Each of the nodes112is a runtime implemented using processing, memory, and network resources of respective computing devices that operate as the infrastructure of a blockchain116. Here, the blockchain system102is illustrated including blockchain manager118and storage120, with storage120being an example of one or more computing resources leveraged to implement the node112. The blockchain system102also includes other resources of the one or more respective computing devices made available for operating as the node112. In this manner, the blockchain manager118is configured to leverage resources of the one or more respective computing devices made available for operating as the node112to implement the node112on behalf of the one or more computing devices.

By way of example, the blockchain manager118manages the storage120of the one or more computing devices implementing the node112, such as by causing a copy of the blockchain116to be maintained in the storage120. The copy of the blockchain116stored at the storage120may be a partial or full copy of the blockchain116, depending on one or more characteristics of the node112(e.g., a type) and/or a time (e.g., whether updates have been made to the blockchain116via other nodes112in the network114). In some implementations, the blockchain manager118manages other resources of one or more computing devices implementing the node112in connection with operation of the blockchain116, such as memory and processors of those devices to perform computations (e.g., transaction validation), operating systems of those devices, and network connections of those devices (e.g., to commit changes to the blockchain116and to receive updates to the node112's copy of the blockchain), and so forth. Thus, the nodes112are representative of computing resources configured to store, communicate, process, and manage data that makes up the blockchain116. As illustrated inFIG.1, the nodes112are interconnected to exchange data via the network110, e.g., as a peer-to-peer network in a distributed and decentralized manner.

Blockchain116is formed using a plurality of blocks122, illustrated inFIG.1as each including a respective hash124and transaction data126. The transaction data126of the blocks122includes batches of validated transactions that are hashed and encoded. Each of the blocks122includes hash124, which is a cryptographic hash of a previous block122in the blockchain116, thereby linking the blocks122to each other and forming the blockchain116. Consequently, individual ones of the blocks122cannot be altered retroactively without altering each block122subsequently added to the blockchain116, thereby protecting blocks122of the blockchain116from attacks by malicious parties.

In order to publish the blocks122for addition to the blockchain116, at least one node112is implemented as a “miner” configured to add a block of transactions to the blockchain116. In one or more implementations, other nodes communicate transactions received at those nodes to one or more mining nodes for validation. Mining nodes are configured to perform peer-to-peer computations to determine whether transactions intended for the blockchain116are valid and, if validated, add validated transactions to a block122that those nodes are building. If the transactions are determined to be valid, the transaction data126describing valid transactions is encoded in, or otherwise stored on, a respective block122, which is linked to the blockchain116such that the new block is “at the end” or “at the top” of the blockchain116(e.g., through inclusion of the hash124of a previous block122in the chain).

The nodes112are configured to broadcast this transaction history via the network110for sharing with other nodes112. By broadcasting and sharing the transaction history with other nodes112, the blocks122of the blockchain116are synchronized across the distributed architecture of computing devices that make up the distributed network114. A variety of “types” of nodes112may be used to implement the blockchain116. By way of example, the blockchain116may be implemented at least in part using “full” nodes, which are nodes that store an entirety of the blockchain116(e.g., locally in computer-readable storage media of respective computing devices of the nodes112). Other types of nodes may also be employed to implement alternative or additional functionality such as governing voting events, governing execution of protocol operations, enforcing rules, and so forth.

The blockchain116is thus configured to provide a diverse range of functionality. Due in part to the storage and updating of the blockchain116over the distributed network114of nodes112, the blockchain116is configured to store its data in a decentralized manner, without a centralized database (e.g., run by a clearinghouse or intermediary entity), and thus operate as a distributed ledger. The decentralized storage of the blockchain116advantageously avoids susceptibility to a single point of failure compromising the entire storage system, which is a primary shortcoming of centralized storage. In one or more implementations, the blockchain116is configured as a public blockchain (e.g., as an Ethereum or a Bitcoin public blockchain), such that transactions on the blockchain116are generally viewable with a connection to the Internet. Alternatively, in some implementations the blockchain116is configured as a private blockchain. When the blockchain116is configured as a private blockchain, the computing devices used to implement the nodes112are controlled by a centralized authority, such as a company or a consortium of entities that restricts access to transactions stored by the blockchain116ledger (e.g., the transaction data126).

As a distributed ledger, the blockchain116supports secure transfer of digital assets, such as transfer of a cryptocurrency and/or tokens. As referenced herein, cryptocurrencies (e.g., coins of the cryptocurrency) refer to assets native to blockchains, in contrast to tokens, which are created “on top” of these blockchains. For example, tokens are created “on top” of the blockchain116using a “token standard,” which enables the token to interoperate with the blockchain116's network of nodes112according to one or more protocols of the blockchain, such that the transaction data126and the hashes124of the blocks122are leveraged to create, trade, and update tokens. By way of example, the Ethereum blockchain's native asset is ether (ETH), a cryptocurrency. Nevertheless, tokens may be created on top of Ethereum's blockchain by using one or more of Ethereum's token standards for creating tokens, such as by using ERC-20, ERC-721, ERC-1155, and EIP-2309, to name just a few.

The tokens created on top of the blockchain116are configured to be “programmable,” meaning that the tokens run on software protocols and can be configured to include logic executed by computing resources (e.g., computing resources provided by the nodes112). In this manner, the tokens are configured to implement smart contracts that define conditions for rules of engagement between the token and the distributed network114. As referenced herein, a “smart contract” refers to an application including code configured to carry out a set of instructions that define terms of a contractual relationship between blockchain entities. When executed, a smart contract causes the blockchain116to validate and enforce the set of instructions included in the smart contract. For instance, executing the code of a smart contract may be performed by sending the code to an address on the blockchain116as a blockchain transaction and, at the address, validating the received code (e.g., by a consensus mechanism of the blockchain116). Once validated, this transaction may be included in a block122, such that the smart contract is initiated and irrevocable.

Smart contracts are thus useable to automate the execution of an agreement between parties on the blockchain116(e.g., an agreement between client device106and client device108). As described in further detail below, a smart contract can be configured to automate a portion or entirety of a workflow by triggering performance of actions responsive to satisfaction of one or more conditions described in the code of the smart contract (e.g., coded as a series of if/when/then statements on the blockchain116). In this manner, a smart contract is not limited as to a number or type of included stipulations, thereby enabling blockchain116participants to freely establish terms and conditions for establishing and facilitating a contractual relationship and ensure performance without the need for a third-party intermediary. Because the terms of a smart contract and results of workflow transactions initiated by the smart contract are necessarily stored in transaction data126of the blockchain116, the smart contracts described herein provide trust and transparency between parties by ensuring performance of stipulated obligations and generating accurate transaction records that are securely maintained by the blockchain116.

In some implementations, contractual relationships on the blockchain116involve tokens (e.g., implemented according to a token standard such as ERC-721 or ERC-1155). By leveraging the architecture and protocols of the blockchain116, tokens are configured to be programmatically encoded as non-fungible assets that are individually unique and cannot be directly interchanged with other similar tokens “like-for-like.” For instance, the architecture and protocols of the blockchain116are configured to create non-fungible tokens (NFTs) on the blockchain116. By using the transaction validation carried out by the nodes112, the blockchain116certifies that a given NET is digitally unique and thus not interchangeable with other NFTs. When an NFT is minted (i.e., programmatically brought into existence), the blockchain116's protocols generate a unique token identifier that is encoded in the NET—the unique identifier may be generated using one or more randomization approaches. As used herein, the term “non-fungible” refers to the property of a token to uniquely represent an asset, such that a digital signature of the token represents the underlying asset in a way that is not directly interchangeable with (e.g., “like-for-like”), or equal to, any other tokens. This contrasts with cryptocurrencies, which are “fungible” because two coins of a same cryptocurrency (e.g., two Ether or two Bitcoins) can be traded or exchanged for one another and are of equal value.

Instead, each NFT is programmatically created to include a unique, non-transferable identity that distinguishes it from other NFTs. In one or more implementations, an NET encodes underlying digital content (e.g., digital art, an image, music, a video, in-game content, a textual composition, a file, a 3D-model, combinations thereof, and so forth). Alternatively or additionally, an NFT encodes an association with or to the digital content (e.g., a uniform resource locator (URL) or other location information that describes a location where the digital content and/or data about the digital content is stored). For instance, rather than encoding the digital content for storage in the NFT, the digital content may be stored in third-party storage (e.g., storage of the service provider system104or storage of another service provider). As described herein, an NFT created and maintained on the blockchain116is configured to encode other information in addition to underlying digital content, or an association with the underlying digital content.

In accordance with the techniques described herein, the service provider system104includes a variety of functionality for creating NFTs and executing transactions involving NFTs. For instance, the service provider system104is configured to facilitate listing NFTs for sale (e.g., recommending a price for an NET listing, providing templates to generate an NET listing, etc.), purchasing NFTs, creating smart contracts with different terms defining obligations (e.g., royalties, temporal ownership conditions, fractional ownership structures and rules, etc.) that govern transactions involving an NET, initiating execution of smart contracts encoded by NFTs, and so forth. As illustrated herein, the service provider system104includes a minting system128, a fingerprint capture system130, and a listing platform132. The listing platform132is configured to include an obligation module134, which is representative of functionality of the listing platform132to provide user interfaces that facilitate designation of one or more obligations for an NFT transaction and create smart contracts that enforce the designated one or more obligations. The listing platform132is further configured to include an NFT dashboard module136, which is representative of functionality of the listing platform to output information pertaining to one or more NFTs stored on the blockchain116, such as trending searches for keywords related to the NFT, an estimated value for the NFT, and so forth.

Although depicted in the illustrated example ofFIG.1as being implemented separately from the service provider system104, in some implementations the service provider system is configured to incorporate functionality of an authentication service system138. The authentication service system138is configured as including storage140, which includes distinguishing feature data142. The distinguishing feature data142is useable by the authentication service system138to authenticate physical items, such as physical items for which digital twin NFTs are created in accordance with the techniques described herein.

The illustrated example ofFIG.1is merely representative of an example configuration of the service provider system104, and in implementations the service provider system104may include more, fewer, and/or different components than illustrated without departing from the spirit or scope of the described techniques. Additionally, portions or entireties of one or more of the components may be implemented at client devices, such as part of applications at the client device106and/or the client device108. For instance, at least a portion of the fingerprint capture system130(and/or the other illustrated components) may be implemented at the client devices106and/or108(e.g., as at least part of an application, as a plug-in, via a web page output by the client devices, and so forth).

The illustrated environment100also includes physical storage vault144, which is representative of a physical location configured to store physical items having digital twinned NFTs for safe keeping. In some implementations, the physical storage vault144is a physical location controlled by an entity associated with the service provider system104. Alternatively, in some implementations the physical storage vault144is controlled by a third party contractually associated with the service provider system104to securely store and maintain physical items having one or more digital twin NFTs.

To enable respective users to initiate operations to create NFTs and to perform transactions involving NFTs, the client device106and the client device108include components to interact within the environment100. The client device106is illustrated including application146(e.g., a computer application) and storage148, which is depicted storing digital wallet150. The client device108is illustrated including application152(e.g., a computer application) and storage154, which is depicted storing digital wallet156. The applications146and152may be configured in a variety of ways in accordance with the techniques described herein. For example, the applications146and152may be mobile applications, plug-ins, or web-browsers to access web pages providing NET-based services, to name just a few. The applications146and152may be separate installations of a same application (e.g., a mobile application of the service provider system104). Alternatively or additionally, the applications146and152may correspond to a digital wallet service provider (not depicted), which provides respective digital wallets150and156. Alternatively or in addition, the digital wallets150and156may be accessible to the respective applications146and152(e.g., via an application programming interface (API)), to carry out operations involving NFTs on the blockchain116.

By way of example, the respective applications146and152are configured to receive user input via a user interface to initiate ownership transfer of an NET from a user associated with the client device106to a user associated with the client device108, e.g., by transferring the NFT from the digital wallet150to the digital wallet156. The digital wallets150,156are configured to store public and private cryptographic keys that digitally link transactions on the blockchain116to user accounts corresponding to the wallets. Generally, the information stored on the wallets may point to assets' locations in terms of blocks on the blockchain and there is a unique cryptographic address issued by a wallet, such that the transaction data126encodes wallet addresses of parties to the transaction. In some implementations, minting a digital twin NET for a physical item includes encoding a wallet address, user account information, or other identifier of an entity minting the NET.

To mint an NFT, the minting system128causes the NET to be created on the blockchain116and programmatically encodes an association of metadata with the NET. In accordance with the described techniques, for example, the minting system128is configured to mint digital twin NFTs of physical items. The metadata for a digital twin NFT may include a fingerprint of the physical item (e.g., a high-resolution image of one or more features of the item, a LIDAR scan of the physical item, etc.) and digital content of the physical item (e.g., an image of the physical item for presentation, a video of the physical item, and/or a 3D model of the physical item). The metadata may also include other information, such as a description of the item, a condition of the physical item (which can change over time), an indication that the physical item is an authentic physical item, an indication that the physical item is not an authentic physical item, a physical location where the item was minted (e.g., at a residence, at a location corresponding to a facility of the service provider system, at an event such as a concert or sporting event, and so on), locations of transactions involving the physical item, public addresses of wallets of owners of the NFT, and/or a current location of the physical item, to name just a few.

The minting system128is configured to encode an association of this metadata with the digital twin NET by, for example, encoding the actual data (e.g., the unique fingerprint and/or the digital content) in the digital twin NFT, encoding unique identifiers of the actual data in the digital twin NFT, and/or encoding one or more addresses where such data is located (e.g., a storage location) in the digital twin NET. In operation, the minting system128provides data as specified by a token standard associated with the blockchain116to one or more of the nodes112to mint a new digital twin NFT of a physical item. For example, the minting system128packages and communicates the actual metadata to be encoded and/or packages and communicates the association (e.g., identifier and/or addresses) to be encoded according to the token standard to the one or more nodes112. In some implementations, the minting system128is configured to verify that an entity is authorized to mint a digital twin NET of a physical item prior to minting the digital twin NFT. For instance, absent any restrictions, an entity is permitted to mint any number of digital twin NFTs for a single physical item. Using the techniques described herein, a listing for a physical item and/or its associated digital twin NFT may be generated with a restriction against minting further digital twin NFTs for the physical item, as described in further detail below.

The fingerprint capture system130is configured to generate digital fingerprints of physical items that uniquely identify a given physical item and differentiate the given physical item from other physical items. The fingerprint capture system130generates a fingerprint based on captured features of a physical items, such as features captured using sensors of one or more devices. As discussed below, the features may be captured using one or more sensors of client devices (e.g., the client devices106,108), one or more sensors of the fingerprint capture system130(e.g., when configured with hardware to capture the features of physical devices), and/or sensors of other devices. By way of example, the client devices and/or the fingerprint capture system130may include a high-resolution digital camera to capture high-resolution digital image features of physical items.

The authentication service system138is configured to verify whether a physical item corresponds to an authentic physical item. The authentication service system138may verify whether a physical item corresponds to an authentic physical item by matching the fingerprint of a physical item, as generated by the fingerprint capture system130, to distinguishing feature data142of a known authentic physical item. The authentication service system138may do so by comparing a fingerprint, or captured features encoded in the fingerprint, to portions of the distinguishing feature data142, e.g., searching the distinguishing feature data142for data having at least a threshold similarity to the fingerprint or portions of the fingerprint. The authentication service system138may then return a response indicating that a physical item is or is not an authentic physical item (or is unsure whether the physical item is or is not authentic) based on whether the fingerprint matches any of the distinguishing feature data142.

The listing platform132is configured to generate listings for items and to expose those listings (e.g., publish them via a digital marketplace) to one or more client devices. For example, the listing platform132may generate listings for items for sale and expose those listings to client devices, such that the users of the client devices can interact with the listings via user interfaces to initiate transactions (e.g., purchases, add to wish lists, share, and so on) in relation to the respective item or items of the listings. In accordance with the described techniques, the listing platform132is configured to generate listings for physical items or property (e.g., collectibles, luxury items, clothing, electronics, real property, physical computer-readable storage having one or more video games stored thereon, and so on), services (e.g., babysitting, dog walking, house cleaning, and so on), digital items (e.g., digital images, digital music, digital videos) that can be downloaded via the network110, NFTs, combinations thereof, and so forth. Notably, the listing platform132is configured to generate a listing that specifies one or more obligations for transferring a subject (e.g., an NET) of the listing between contracting parties (e.g., between digital wallet150and digital wallet156).

To facilitate specification of these one or more obligations, the listing platform132includes an obligation module134, which is configured to output display of user interfaces that prompt user input defining parameters for the one or more obligations. In some implementations, user interfaces provided by the obligation module134are output in response to input received at an interface presented by the NET dashboard module136, as described in further detail below with respect toFIGS.3-5. Based on user input received by the obligation module134from a client device associated with a user account (e.g., of the service provider system104), the listing platform132generates a listing together with a smart contract template that includes executable instructions for enforcing performance of the one or more obligations and facilitating transfer of the subject(s) of the listing responsive to verifying performance of the one or more obligations. The smart contract template can then be updated by the service provider system104with an identifier of an entity purchasing the subject(s) of the listing to generate a smart contract, which is executable by the blockchain system102to facilitate a transfer of the subject(s) of the listing according to obligations defined by the listing.

In some implementations, the service provider system104is configured to store physical items associated with a listing at the physical storage vault144, such as valuable physical items having digital twin NFTs. Storage of the underlying physical item at the physical storage vault144allows ownership of the digital twin NET and the physical item to be easily transferred between owners without the hassle of physically moving the item to transfer possession (e.g., shipping the item or exchanging it between hands). Instead, the item may be transferred to the physical storage vault144for storage and remain in the physical storage vault144while ownership of the physical item and/or its digital twin NET is transferred a number of times. The physical storage vault144may also maintain physical items where ownership is divided, using a digital twin NFT, into a number of fractions of ownership of the physical item, e.g., “shares” of the physical item issued according to terms of the digital twin NFT. Alternatively or additionally, the physical storage vault144may be leveraged to store physical items in implementations where digital twin NFTs are sold with an option to purchase the physical item counterpart at a later date, such that storage in the physical storage vault144ensures a maintained quality and condition of the physical item.

Having considered an example of an environment, consider now a discussion of some examples of details of the techniques for generating listings for NFTs in accordance with one or more implementations.

Listing of Physical Items' Digital Twin NFTs

FIG.2depicts an example of a system200to generate listings for NFTs associated with physical objects.

The illustrated example ofFIG.2includes the blockchain116, the fingerprint capture system130, the authentication service system138, the minting system128, and the listing platform132with its obligation module134and NFT dashboard module136, as introduced inFIG.1.

InFIG.2, the fingerprint capture system130is depicted obtaining sensor-captured features202of physical item204. In accordance with the described techniques, the sensor-captured features202correspond to data describing one or more aspects of the physical item204captured using sensors of one or more devices. For instance, the sensor-captured features202may be obtained using one or more sensors of the client device106, the client device108, the fingerprint capture system130, combinations thereof, and so forth.

By way of example, the fingerprint capture system130is implemented at least partially at a client device (e.g., a client device106,108) having the one or more sensors. Alternatively or additionally, the fingerprint capture system130is configured as, includes a receptable into which, or a platform onto which, physical items are placed so that sensors of the fingerprint capture system130scan the item to generate the sensor-captured features202.

Examples of sensors that are useable to generate the sensor-captured features202include, but are not limited to, imaging sensors (e.g., one or more high-resolution digital cameras, one or more low-resolution digital cameras), temperature sensors, LIDAR, biochemical sensors, and so on. Examples of the sensor-captured features202may include, but are not limited to, images (e.g., high-resolution images depicting features of the physical item204), videos of the physical item204, data derived from various electromagnetic spectrum features captured by the sensors about the physical item204, measured temperatures at different locations of the physical item204(or a map of them), a LIDAR scan of the physical item204, and/or measurements (or estimated values) of one or more elements or compounds at different locations of the physical item204, to name just a few. Thus, the sensor-captured features202may be produced by a variety of sensors of different devices and describe a variety of features about the physical item204without departing from the spirit or scope of the techniques described herein.

Using the sensor-captured features202, the fingerprint capture system130generates a fingerprint206of the physical item204. The fingerprint206is unique to the physical item204and may be used to uniquely identify the physical item204from other physical items, including from another specimen of the same item (e.g., two luxury watches of the same brand, make, model, etc.). For example, the fingerprint206may be configured as a unique digital signature that identifies the physical item204from other physical items. Notably, the fingerprint capture system130can generate the fingerprint206to digitally encode the sensor-captured features202of the physical item204at various points in time after manufacture of the physical item204. In other words, the fingerprint capture system130is not reliant on the manufacturing process to generate the fingerprint206so that it uniquely identifies the physical item204. In this manner, the fingerprint capture system130is configured to generate the fingerprint206without modifying the physical item204. This contrasts with techniques that rely on an identifier to be manufactured into or otherwise incorporated with the physical item204, examples of which include configuring a physical item with an RFID tag and/or applying (e.g., stitching in or printing) an identifier to the physical item.

In accordance with the described techniques, the authentication service system138is configured to authenticate the physical item204based on the fingerprint206. The fingerprint capture system130is configured to transmit the fingerprint206to the authentication service system138for authentication, in accordance with the techniques described herein. For instance, in implementations where the fingerprint capture system130is integrated at least in part at a client device, (e.g., as part of the application146at the client device106and/or as part of the application152at the client device108), the client device is configured to transmit the fingerprint206to the authentication service system138(e.g., over the network110).

The authentication service system138is configured to verify that the physical item204corresponds to an authentic physical item. To do so, the authentication service system138compares the fingerprint206to the distinguishing feature data142stored in the storage140. The distinguishing feature data142describes features of one or more physical items that are known to be authentic and is saved in the storage140. The authentication service system138is capable, through a computerized comparison of the digital fingerprint206and the distinguishing feature data142, of identifying authentic items and/or differentiating authentic items from items that are not authentic (e.g., knockoffs). Some of the comparison techniques used by the authentication service system138are not possible to be performed by humans alone due to humans lacking the sensory capacity to detect one or more of the same features and/or compare digital fingerprints to the distinguishing feature data142at the level required to identify a physical item as authentic.

If the authentication service system138identifies a match between the fingerprint206and the distinguishing feature data142, then the authentication service system138determines that the physical item204is an authentic physical item. Alternatively, if the authentication service system138does not identify a match between the fingerprint206and the distinguishing feature data142, then the authentication service system138may determine that the physical item204is not an authentic physical item. In one or more implementations, the authentication service system138identifies a match between the fingerprint206and the distinguishing feature data142based on identifying a threshold similarity between the fingerprint206and the distinguishing feature data142for the physical item204. In this way, a physical item that is not identical to a known authentic item but is “close enough” to have a high likelihood of being authentic, may be determined authentic by the authentication service system138, such that the physical item204is considered a “match” to an authentic physical item. For instance, consider an example scenario where a fingerprint206is generated for a certain model and colorway of shoes (e.g., Air Jordan l's in a black/red colorway). In this example scenario, the distinguishing feature data142against which the fingerprint206is compared may have been generated using a different pair of shoes in the same model and colorway as the “known authentic item.” Although the fingerprint206itself is not derived from the known authentic item in this example scenario, the authentication service system138is configured to identify the model and colorway of shoes as matching the known authentic item.

Based on matching the fingerprint206to data in the distinguishing feature data142, the authentication service system138provides an authentic response208, indicating that the physical item204is an authentic physical item. In the illustrated example, for instance, the authentication service system138communicates the authentic response208to the fingerprint capture system130. Alternatively or additionally, the authentication service system138is configured to communicate the authentic response to a system other than the fingerprint capture system, such as to the service provider system104, one or more of client devices106or108, and so forth. In an example scenario where the authentication service system138does not find a suitable match between the fingerprint206and the distinguishing feature data142, the authentication service system138may determine that the physical item204is not authentic and may communicate a response indicating that the physical item204is not authentic (e.g., to the fingerprint capture system130, to the service provider system104, to one or more of the client devices106or108, and so forth).

In implementations where the fingerprint206is to be used for minting a new NFT for the physical item204, the fingerprint206is communicated to the minting system128. Receipt of the fingerprint206by the minting system128may be responsive to the authentic response208indicating that the physical item204is an authentic physical item. In one or more scenarios, however, the minting system128may receive the fingerprint206for an item that is determined not to be authentic by the authentication service system138.

Upon receipt of the fingerprint206, the minting system128is configured to cause a digital twin NFT210of the physical item204to be minted on the blockchain116. To do so, the minting system128provides NFT minting instructions212to one or more of the nodes112in the distributed network114ofFIG.1. The NFT minting instructions212may be configured according to, and include data specified by, a token standard (e.g., ERC-721 or ERC-1155) for creating the digital twin NFT210. Once created, the digital twin NET210has a unique token identifier that uniquely identifies the token from other tokens. For instance, the token identifier may be a unit256variable. Information included in the NET minting instructions212enables a node112to programmatically encode in the digital twin NFT210information provided or indicated in the NFT minting instructions212. For example, the NET minting instructions212may include an association with metadata, such as an association with the fingerprint206, physical item digital content214, an identifier of a user account that initiated minting of the physical item204, an ownership history of the physical item204, a description of the physical item204, and so forth. The node112receiving the NFT minting instructions212is thus caused to encode the association with the metadata into the digital twin NFT210.

In the illustrated example, the digital twin NFT210is depicted as including the fingerprint206and the physical item digital content214. In one or more implementations, however, the digital twin NFT210may include references to the fingerprint206and the physical item digital content214instead of the actual content itself. Such references may be configured as pointers to the actual content (e.g., URLs or storage locations) and/or unique identifiers (e.g., GUIDE) of the actual content. By encoding associations with the actual content rather than encoding the actual digital content (e.g., the fingerprint206and/or the physical item digital content214), the minting system128may limit the use of hardware resources (e.g., processing) of the nodes112for minting the digital twin NFT210. By limiting an amount of resources used, the minting system128may proportionally reduce a “gas” fee required by the blockchain116to utilize those resources and mint the digital twin NET210.

As noted above, the digital twin NET210may also programmatically encode other information. For example, the digital twin NFT210may programmatically encode a public address of a digital wallet of a user associated with minting the NET, e.g., a public address of the digital wallet150in a scenario where a user associated with the client device106provides user input via a user interface to mint the digital twin NFT210. The digital twin NET210may also be configured to digitally record a provenance of the NFT, such that ownership information is captured each time the digital twin NFT210is transferred (in whole or in part). For example, if the minting user transfers the digital twin NFT210to a new user, then the transfer from the wallet address of the minting user to a wallet address of the new user is recorded in the digital twin NFT210's data on the blockchain116. As with other transactions on the blockchain116, one or more of the nodes112validates such a transfer so that only valid transfers are committed to the blockchain116.

The digital twin NFT210may be minted to encode other data, examples of which include smart contracts (e.g., to govern royalties, fractional ownership processes and events, end-of-life of the NFT events, and so forth), and/or a description of other aspects of the physical item204(e.g., a condition of the physical item204, provenance of different parts of the physical item204, maintenance record of the physical item204, and so forth). The digital twin NFT210may also be minted to encode various metadata, such as a description of the physical item204, a condition of the physical item204(which can change over time), an indication that the physical item204is an authentic physical item, an indication that the physical item204is not an authentic physical item, a physical location where the physical item204was minted (e.g., at a residence, at a location corresponding to a facility of the service provider system, at an event such as a concert or sporting event, and so on), locations of transactions involving the physical item204, and/or a current location of the physical item204, to name just a few examples.

With regard to a physical item's condition, the service provider system104may be configured to determine a condition of a physical item and capture the determined condition as a state in the digital twin NFT210or other data associated with the physical item204. In one or more implementations, the service provider system104may be configured to determine a condition of the physical item204using the sensor-captured features202. The service provider system104may further be configured to generate or set metadata (e.g., a state) describing the determined condition of the physical item204. To this end, the minting system128may also cause an association with metadata describing the condition of the physical item204to be encoded in the digital twin NFT210, i.e., in addition to encoding the association with the fingerprint206.

In this manner, a condition of the physical item204may be encoded separately from data that uniquely identifies the physical item204from other physical items, e.g., separately from the fingerprint206. Due to this separate determination and encoding, the condition encoded by the digital twin NET210may change over time, but the fingerprint206of the item may not change over time. By way of example, the digital twin NFT210may encode an association with metadata that describes a condition of the item in terms of “new” or “used,” an amount the item is used, a relative amount of use compared to other items, an age of the item, and/or changes to the item from one or more previous times features of the item were captured, to name just a few. Consider a scenario, after the digital twin NFT210is minted, in which additional features of the physical item204are captured e.g., by sensors of one or more devices. The service provider system104is configured to compare the newly captured features to the sensor-captured features202used in connection with minting the digital twin NET210. Based on this comparison, the service provider system104may determine that the condition of the physical item204has changed subsequent to minting the digital twin NET210. Based on determining that the condition of the physical item204has changed over time, the service provider system104may update the metadata of the digital twin NET210via generation of additional NFT minting instructions212to indicate the changed condition of the physical item204. Thus, the digital twin NFT210may encode a variety of information in relation to the physical item204in addition to the example described herein.

In the illustrated example, the listing platform132receives an NFT notification216. The NFT notification216is representative of information describing a location of the digital twin NFT210on the blockchain116. For example, the NFT notification216may include the token identifier of the digital twin NFT210and/or an address of a digital wallet of a current owner of the digital twin NFT210. Although depicted as being received from the minting system128, in implementations where a new NET is not to be minted for the physical item204, NET notification is received directly from the fingerprint capture system130. In implementations, the NFT notification216is received by the listing platform132in response to receiving a request to generate a listing for the digital twin NET210, either separately from or together with the physical item204.

In response to receiving the NET notification216, the listing platform132generates a listing218, which is representative of an offer for sale of the digital twin NFT210, either together with or separate from its counterpart physical item204. The listing218is depicted as including a smart contract template220, which is representative of executable code configured to ensure performance of one or more obligations specified by the listing218as conditions for transferring the digital twin NFT210(e.g., payment of a specified price for the digital twin NFT210, storage of the physical item204in the physical storage vault144, return the digital twin NFT210to a user account that generated the listing218after a specified duration, and so forth). As described in further detail below, the smart contract template220is useable to generate a smart contract that facilitates transaction of the digital twin NFT210between user accounts (e.g., between digital wallet150and digital wallet156) by updating the smart contract template220with information describing a purchaser of the digital twin NFT210via the listing218.

In the illustrated example ofFIG.2, the listing platform132is depicted as outputting the listing218. This output of the listing218may correspond to publishing the listing218to one or more client devices, e.g., associated with user accounts of the service provider system104or that navigate to user interfaces of the service provider system104. By way of example, the listing218may be displayed or otherwise output by a web application (e.g., the application146or the application152) via a user interface at the client devices106,108. In one or more implementations, the listing platform132exposes the listing218to a plurality of client devices, such that users navigating to the listing or searching for listings can view the listing218.

FIG.3depicts an example of a system300to transfer an NFT between digital wallets in response to purchase of the NFT via a listing. Functionality of the system300is described with reference to example user interfaces depicted inFIGS.4-12, which are representative of user interfaces output by the service provider system104for listing an NET associated with a physical item and transferring the NET between digital wallets.

The illustrated example ofFIG.3includes the client device106and its associated application146, storage148, and digital wallet150, the client device108and its associated applications152, storage154, and digital wallet156, and the listing platform132as introduced inFIG.1. The NET dashboard module136of the listing platform132is configured to output an NET dashboard302for display at the client device106. The NFT dashboard302is representative of one or more user interfaces configured to display information regarding NFTs for a user of the client device108, such as NFTs stored in the digital wallet156, NFTs related to those stored in the digital wallet156, NFTs listed on the listing platform132, NFTs transferred via the service provider system104, combinations thereof, and so forth. In some implementations, the listing platform132provides the NFT dashboard302to the client device108responsive to receiving a request to view the NFT dashboard302via input to the application152.

FIG.4depicts an example400of a user interface402including an NFT dashboard for a digital wallet. For instance, the illustrated example400depicts an example of the NET dashboard302configured for the digital wallet156and output for display at the client device108. The user interface402indicates that the NET dashboard302is configured as an “NFT Owner Dashboard,” customized for a user account404of the service provider system104associated with the digital wallet156, represented as the user “@brooks” in the illustrated example.

The user interface402of the example NET dashboard302depicts a plurality of NFTs owned by the user account404, such as one or more NFTs stored in the digital wallet156of the client device108. For instance, the user interface402indicates that the user account404owns NFT406, NFT408, and NFT410. NFT406represents a digital twin NFT of a physical rock hammer, NFT408represents a digital twin NFT of physical artwork titled “Dufresne,” and NFT410represents a digital twin NFT of physical artwork titled “Red.”

The user interface402of the NFT dashboard302is configured to display additional information regarding each displayed NFT. For instance, with respect to the NFT406, the user interface402includes a display of a title412for the NFT406along with an estimated value414for the NFT406. The user interface402further includes a description of ownership information416for the NFT406, which indicates that the user account404owns both the NFT406as well as its physical item counterpart (e.g., the physical rock hammer), and that the NFT406is the only digital twin NFT for the physical rock hammer. The user interface402additionally includes a selectable option418(e.g., a hyperlink) to view additional details regarding the NFT406and a selectable option420(e.g., a button) to generate a listing for sale of the NET406.

In some implementations, the user interface402of the NFT dashboard302is configured to provide an indication regarding NFTs owned by the user account404that are trending. For instance, the user interface402includes a visual indication422configured as a banner noting that the NET410is currently trending. The listing platform132is configured to identify that an NFT is currently trending in a variety of manners. For instance, the listing platform132may identify that an NET is trending based on a number of searches that include one or more keywords pertaining to the NFT, based on a transaction history for the NFT, based on transactions for related NFTs, combinations thereof, and so forth. By displaying the visual indication422for a trending NFT, the NFT dashboard302is configured to inform a user associated with the user account404regarding aggregate user account behavior on the listing platform that suggests market interest in individual NFTs.

FIG.5depicts an example500of a user interface of the NFT dashboard302, which includes additional details for NFT406and is presented responsive to user input selecting the selectable option418. In the illustrated example, the user interface402is modified to depict additional information pertaining to the NFT406. For instance, the user interface402is modified to depict information describing one or more trends502for the NFT406. The information describing one or more trends502for the NFT406include, for example, an estimated value for the NFT406, historical search terms related to the NFT406(e.g., submitted via user input to the listing platform132, search engine, and the like), combinations thereof, and so forth.

The user interface402is further modified to display information regarding one or more NFTs that are related to the NET406, such as related NFTs listed and/or transferred by the listing platform132that impact the one or more trends502. For instance, the illustrated example ofFIG.5includes a display of related NET504, along with a description506indicating that the related NET504is titled “Freedom” and is one of 50 digital twin NFTs for its physical item counterpart. In some implementations, the user interface402is modified to display information describing an estimated value508for the related NET504. The estimated value508may be gleaned from any suitable number of sources. For instance, in the illustrated example500, the estimated value508indicates that the related NFT504was transferred via the listing platform132three days ago for a value of 2 ETH, which may correlate to a monetary valuation of $6,672 based on a current exchange rate for ETH and USD.

Alternatively or additionally, the information for the related NFT504provides an indication describing aspects that caused the listing platform132to identify the related NFT504as being related to the NFT406. For instance, the illustrated example500includes relationship information510indicating that the NFT406and the related NFT504are both associated with the keyword “Shawshank.” In some implementations, the information displayed in the user interface402regarding the one or more NFTs that are related to the NFT406is updated based on a selection of the visual representation of the one or more trends502. For instance, in an implementation where the one or more trends502are configured as a graph representation of how the NFT406is perceived to trend over time, input to a certain location on the graph representation causes the user interface402to display information regarding at least one related NET504that influenced the value represented by the certain location on the graph representation. In this manner, the NET dashboard302is configured to provide various displays of information regarding NFTs associated with a digital wallet and facilitate generating listings for the NFTs via the listing platform132.

In response to detecting input at the selectable option420indicating an intent to list the NET406, the listing platform132is configured to prompt a user (e.g., a user associated with the user account404) to specify one or more listing obligations304to be included in a listing306for an NFT308(e.g., the NFT406). To do so, the obligation module134of the listing platform132is configured to cause the client device108to output one or more user interfaces (e.g., via the application152) that include prompts for user input defining various aspects of the listing306.

FIG.6depicts an example600of a user interface602output as part of generating a listing for an NFT associated with a physical object, such as NFT406. In the illustrated example600, the user interface602includes a prompt604regarding what is to be included as a subject of the listing for the NFT406. Because the user account404owns both the NFT406and the physical rock hammer item from which the NFT406was minted, the user interface602includes three selectable options for specifying a subject of the listing: a selectable option606to list both the physical item and the NFT, a selectable option608to list the NFT only (i.e., independent of the physical rock hammer), and a selectable option to list the physical item only (i.e., independent of the NFT406). User input at one of the selectable options606,608, or610thus defines the one or more subjects for the listing306. For instance, responsive to receiving input at the selectable option608, the listing platform132identifies the NFT406as the NFT308subject of the listing306and ascertains that any listing obligations304specified by the client device108define conditions for transferring the NET308from the digital wallet156to a different digital wallet. After identifying the one or more subjects of the listing306, the obligation module134is configured to prompt a user associated with the user account404to define the listing obligations304.

FIG.7depicts an example700of a user interface702output as part of prompting a user for feedback describing listing obligations304for generating a listing306for an NET308. In the illustrated example700, user interface702is depicted as identifying the NFT308that is the subject of the listing, such as NFT406, along with a prompt704to define one or more aspects of the listing. To assist a user in generating the listing306, the user interface702includes a recommended price706for the NFT406, along with a selectable option708to accept the recommended price706and a selectable option710to specify a different price for listing the NFT406. In response to detecting input specifying a price to be used for listing the NFT406(e.g., via input to one of the selectable options708or710), the obligation module134is configured to generate a smart contract template310for the listing306that includes code configured to ensure that the specified price is paid by a purchaser of the listing306before transferring the NFT308from the digital wallet156to a digital wallet associated with the purchaser. In addition to including a prompt for specifying a price for the NFT406, the user interface702is configured to include one or more prompts for input specifying a usage right to be conferred with the transfer of the NFT406. In some implementations, the user interface702may include a prompt to specify a manner in which the NFT308can be purchased. For instance, the user interface702may enable a user to designate the NET308for listing via auction and set parameters for the auction (e.g., reserve value, minimum bid increment, auction start time, duration, and so forth).

For instance, the user interface702includes a prompt712for user input specifying whether the listing306is for temporary ownership of the NET406. The prompt712is accompanied in the user interface702by a selectable control714to indicate that the NET308is not to be offered for sale with any temporal ownership restrictions. The prompt712is further accompanied by a selectable control716to specify a duration defining temporal constraints on ownership of the NET406when purchased via the listing306. In this manner, the user interface702enables a user to curate a listing306for rental of the NFT406and/or the physical item from which the NFT308was minted. Temporary ownership (e.g., rental) of an NFT may be attractive to a purchasing entity for a variety of considerations, such as in an example scenario where the purchasing entity intends to curate an art exhibit and showcase digital twin NFTs of artwork that otherwise cannot be transported to a common physical location due to import restrictions, transportation risks, and so forth. In response to detecting input at the selectable control716, the obligation module134is configured to generate the smart contract template310to include code that transfers the NFT308from a digital wallet associated with a purchaser to the digital wallet156upon expiration of the specified duration for temporal ownership. Alternatively, in an example implementation where input is detected at the selectable control714, the user interface702may be modified to remove display of the prompt712and its associated selectable controls and present one or more additional prompts for input defining listing obligations304for the listing306.

FIG.8depicts an example800of a user interface702output as part of prompting a user for feedback describing listing obligations304for generating a listing306for an NFT308, such as an updated version of the user interface702depicted inFIG.7displayed in response to detecting input at the selectable control714. In the illustrated example800, the prompt712is replaced by a prompt802for user input specifying whether the listing306is for a fractional ownership of the NFT406. Fractional ownership of an NET may be attractive to a purchasing entity in an example implementation where a value of the NET is cost-prohibitive for the purchasing entity to acquire outright ownership. The prompt802is accompanied by a selectable control804to indicate that a listing is to be generated offering full ownership of the NFT406. The prompt802is further accompanied by a selectable control806to indicate that the listing is to offer a fractional ownership share of the NET406(e.g., a 25% ownership stake in the NFT406). Based on input received at the selectable control804or the selectable control806, the obligation module134configures the smart contract template310for the listing306to convey the respective ownership portion to a digital wallet of a purchasing user upon purchase of the NFT308via the listing306and record a record of the conveyed ownership in transaction data126stored on the blockchain116.

FIG.9depicts an example900of a user interface702output as part of prompting a user for feedback describing listing obligations304for generating a listing306for an NFT308. In the illustrated example900, the user interface702includes a prompt902for user input specifying whether the NFT406is to be offered for sale with a right to purchase the counterpart physical item at a later date. For instance, consider an example scenario where the subject NFT308is a digital twin of physical artwork. A purchasing entity may display the NET308at a digital art exhibit and want the option to later purchase the physical artwork, based on an audience reaction to the NET308at the digital art exhibit. In such an example scenario, the option to purchase the counterpart physical item at the later date might encourage the purchasing entity to include the NET308in the digital art exhibit.

The prompt902is accompanied by a selectable control904configured to receive user input defining a later date by which a purchaser of the listing306reserves the right to purchase a physical item corresponding to the subject of the listing306(e.g., the physical rock hammer from which the NET406was minted). Although illustrated in the context of providing an option to purchase a physical item at a later date, the prompt902may alternatively be configured for purchasing a digital twin NFT at a later date when its physical item counterpart is designated as the subject of the listing306.

The user interface702in the illustrated example900further includes an option906to designate holding conditions for the physical item between a time of purchase of the NFT and the later date specified via input to the selectable control904. For instance, the option906includes a selectable control908to designate that the physical item is to be held and maintained by the seller (e.g., the user associated with the user account404generating the listing306) until the later date. The option906further includes a selectable control910to designate that the physical item is to be held and maintained in a physical storage vault (e.g., the physical storage vault144ofFIG.1) until the later date. A desirability of maintenance by a seller relative to maintenance in physical storage vault depends on the physical item to be stored, as well as a reputation of the particular seller. For instance, in an example scenario where the entity generating the listing306is a museum, maintenance by the museum may be more desirable than maintenance at a physical storage vault. Conversely, maintenance by an individual with minimal seller history may be less desirable than maintenance at the physical storage vault. In this manner, the selectable controls908and910are representative of functionality provided by the listing platform132to create a bespoke listing306customized according to a subject of the listing.

In response to input defining the later date at selectable control904and input at the selectable control910, the listing platform132designates the listing obligations304to specify that a seller of the NET406is obligated to transfer the physical item counterpart for the NET406to the physical storage vault144as a condition of transferring the NFT406from a digital wallet of the seller to a digital wallet of a purchaser of the NET406via a listing published via the listing platform132.

In response to receiving input at one or more of the selectable control904, option906, or selectable control908, the obligation module134configures the smart contract template310for the listing306to ensure performance of the associated obligation as a condition to effectuating transfer of the subject NFT308of the listing306. For instance, consider an example implementation where input at the user interface702of the illustrated example900indicates that the listing306is to offer the NFT308for sale with a right to purchase a physical item counterpart until a later date. If user input specifies that the physical item counterpart is to be stored in the physical storage vault144until the later date, the obligation module134configures the smart contract template310to verify delivery of the physical item counterpart to the physical storage vault144as a precondition of transferring the NFT308. Consequently, when executed, the smart contract314does not transfer the NFT308to a digital wallet of a purchasing user until verifying delivery to the physical storage vault144.

FIG.10depicts an example1000of a user interface702output as part of prompting a user for feedback describing listing obligations304for generating a listing306for an NFT308, such as an updated version of the user interface702depicted inFIG.7displayed in response to detecting input at the selectable control714or an updated version of the user interface702depicted inFIG.8displayed in response to detecting input at the selectable control804. In the illustrated example1000, the user interface702is updated to include a display of prompt1002, which requests user input indicating whether the listing306is to be associated with any restriction against minting additional digital twin NFTs of the physical item from which the NET406was minted. In this manner, display of prompt1002is conditional on input received at one of the selectable options606or610displayed in the illustrated example ofFIG.6, such that a physical item associated with a digital twin NET comprises at least a portion of the listing306.

In response to detecting input at the selectable option1004, the listing306is generated free of encumbrances against minting additional digital twin NFTs of a physical item from which the NFT308was minted. Alternatively, in response to detecting input at the selectable option1006, the listing306is generated to include an indication that the offer for sale of the physical item associated with the NFT308precludes a purchasing entity from minting more than a threshold number of additional digital twin NFTs of the physical item. In an example implementation where input is detected at the selectable option1006, the obligation module134is configured to generate the smart contract template310to include code that restricts the minting system128from generating NET minting instructions212for a fingerprint206corresponding to the physical item for the listing306from which the subject NET308was minted. The selectable option1006thus enables an entity generating the listing306to govern an exclusivity associated with the NET308(e.g., to ensure that the NET308remains a sole digital twin of the counterpart physical item) and otherwise define additional aspects of an NET-subject transaction not supported by conventional listing platforms.

FIG.11depicts an example1100of a user interface702output as part of prompting a user for feedback describing listing obligations304for generating a listing306for an NET308. For instance, the user interface702depicted in the illustrated example1100is output in response to detecting input at the selectable control714, detecting input at the selectable control804, or detecting input at the selectable option1004. In the illustrated example1100, the user interface702is updated to include a display of prompt1102, which requests user input indicating whether the listing306is to be offered with a trusted authentication guarantee. In response to detecting input at the selectable option1104, for instance, the listing306is generated to include an obligation for a seller of the NET406to transfer a physical item from which the NET406was minted (e.g., the physical rock hammer) to a third-party authenticator (e.g., the authentication service system138) to verify that the physical rock hammer is indeed authentic.

In response to detecting input at the selectable option1104, the obligation module134is configured to update the smart contract template310for the listing to include code that verifies authentication of the physical item counterpart for the subject NFT308of the listing306by the authentication service system138before transferring the NFT308from a digital wallet of a selling entity (e.g., digital wallet156) to a digital wallet of a purchasing entity. Thus, the obligation module134is configured to provide a variety of different user interfaces that enable a seller of a physical item, its digital twin NET, or a combination thereof, to specify particular obligations invoked as part of transferring the subject of the listing from the seller to a purchaser. In addition to providing these user interfaces, the obligation module134is configured to generate a smart contract template310that includes code configured to facilitate transfer of the subject of the listing306and ensure performance of the listing obligations304as a condition to transferring the subject of the listing306(e.g., the NET308).

Returning toFIG.3, the listing platform132is depicted as outputting the listing306. Output of the listing306is representative of publishing the listing306to a plurality of client devices, including the client device106as depicted in the illustrated example. For example, the listing306may be displayed as part of, or otherwise output by, an application (e.g., the applications146) via a user interface at the client device106. In implementations, the listing platform132is configured to expose the listing306to a plurality of client devices, such that users navigating to the listing or searching for listings can view the listing306. Although illustrated as including the NFT308, in implementations the listing platform132may not actually obtain the NFT308or the physical item counterpart from which the NFT308was minted. Instead, the listing platform132is configured to obtain an indication that the NFT308and/or its physical item counterpart are to be listed via the platform. In such implementations where the NFT308and/or its counterpart physical item are not obtained by the listing platform132, the listing platform132is configured to verify ownership of the NFT308and/or its physical item counterpart by a user account generating the listing306(e.g., by verifying that a public address encoded in the NET308corresponds to an address of the user account generating the listing306). As depicted inFIG.12, the listing306includes an option that is selectable by a user of the client device106to purchase the subject of the listing306(e.g., the NFT308).

FIG.12depicts an example1200of a listing for an NET associated with a physical item, such as an example of listing306. The illustrated example1200depicts a user interface1202that displays a listing for an NET1204and a physical item counterpart from which the NFT1204was minted. The user interface1202includes a title1206, a price1210, a brief description1212, and a selectable option1214to view a complete description for the listing, which collectively indicate that the listing offers “full ownership of both the physical rock hammer and an NFT of the rock hammer” for 36 ETH, which is estimated to equate to $119,828. The user interface1202further depicts an authenticity indicator1208, which indicates that the physical item rock hammer has been verified as being authentic by the authentication service system138.

The example listing of the user interface1202further includes lineage information for the subject of the listing, such as an indicator1216of an original creator of the NFT308and an indicator1218of a current owner of the subject of the listing (e.g., the NFT308and the physical item counterpart). The user interface1202further includes a selectable option1220to see full ownership history for the subject of the listing (e.g., an option to inspect a ledger tracking an ownership history of the NFT308). The user interface1202further includes a selectable control1222to accept the terms of the listing and initiate transfer of the subject of the listing from a seller account to a purchasing account. For instance, in an example implementation where a user account identifier @brooks purchases the rock hammer and the NET offered via the listing in the user interface1202, in response to verifying completion of the requisite listing obligations304(e.g., payment of the 36 ETH), then ownership of the rock hammer and NFT will be transferred from the @andy user account to the @brooks user account and the central ledger accessible via the selectable option1220will be updated to reflect the ownership transfer change.

In response to detecting input initiating an ownership transfer of a subject of the listing306(e.g., input purchasing the NFT308via the listing306through input at the selectable control1222), the client device106generates a transfer request312, which digitally persist the request by the user of the client device106to transfer ownership of the NFT308from the digital wallet156to the digital wallet150. The transfer request312also persists acceptance of the one or more listing obligations304associated with the listing306. In the illustrated example ofFIG.3, the listing platform132is depicted as receiving the transfer request312.

Based on the transfer request312, the listing platform132a smart contract314that includes NFT transfer instructions316and provides the smart contract314to at least one node112in the network114of nodes among which the blockchain116is distributed. In implementations, the listing platform132is configured to generate the smart contract314by updating the smart contract template310to include information describing an entity that purchases the subject of the listing306(e.g., an address of the digital wallet150). The NFT transfer instructions316are thus representative of data configured according to a token standard (e.g., ERC-721 or ERC-1155) that causes ownership transfer of the NET308.

Information included in the NET transfer instructions316of the smart contract314thus enables a node112to programmatically encode in the NFT308information included in the NET transfer instructions316. For instance, the NET transfer instructions316may include an identifier associated with a user account to which ownership of the NET308is being transferred and the nodes112encode this identifier into the NET upon validation of the transfer (e.g., upon validation of performance of the listing obligations304codified in the smart contract314. Once validated, the transfer is persisted in the transaction data126of the blockchain116, including details about the transfer such as the identifier associated with the user account.

By way of example, the NET transfer instructions316may include a first address of a digital wallet which corresponds to a user account that owns the NET308(e.g., digital wallet156) and include a second address of a digital wallet which corresponds to the user account to which ownership of the NET308is being transferred (e.g., digital wallet150). Here, the first and second addresses may correspond to the identifiers of the respective users of computing devices108and106. The NET transfer instructions316may also include public keys associated with the addresses of those digital wallets, which one or more of the nodes112use to validate the transaction (i.e., the transfer to the user account corresponding to the client device106and the digital wallet150). This validation may include interacting with the client device106and a device of the user account that owns the NET308(e.g., client device108), so that their private keys can be used to verify that the transfer is a legitimate transfer of the NFT308.

As with other transactions on the blockchain116, one or more of the nodes112determines whether the transfer of the NET308to the user account is valid (e.g., using a consensus mechanism). If the nodes112determine that the transfer to the user account is a valid transaction, the nodes112commit the valid transfer to the blockchain116. To do so, the nodes112may cause the public wallet addresses of the parties to the transaction (including the public address of the digital wallet150) to be digitally recorded in the NET308's data on the blockchain116. The NFT transfer instructions316may cause other data to be encoded into the NET308to describe the transaction.

Having discussed exemplary details of the techniques for listing an NET associated with a physical item and transferring the NET between digital wallets, consider now some examples of procedures to illustrate additional aspects of the techniques.

Example Procedures

This section describes examples of procedures for listing an NET associated with a physical item and transferring the NET between digital wallets. Aspects of the procedures may be implemented in hardware, firmware, or software, or a combination thereof. The procedures are shown as a set of blocks that specify operations performed by one or more devices and are not necessarily limited to the orders shown for performing the operations by the respective blocks.

FIG.13depicts a procedure1300in an example implementation of listing an NFT associated with a physical item and transferring the NET between digital wallets.

A request to list an NFT associated with a physical item as available for sale is received (block1302). By way of example, the listing platform132receives an NET notification216from a client device108to generate a listing for an NET308. Input specifying at least one obligation for transferring the NET from a first digital wallet to a second digital wallet is then received (block1304). The listing platform132, for instance, receives listing obligations304from the client device108. In example implementations, listing obligations304are received via input at one or more user interfaces provided by the obligation module134, such as the example user interfaces602and702as depicted inFIGS.6-11.

A listing is then generated for the NFT that describes the at least one obligation (block1306). The listing platform132, for example, generates the listing306for the NFT308with a smart contract template310that includes code configured to ensure performance of the listing obligations304and transfer the NFT308from the digital wallet156to a digital wallet of a purchasing user account in response to verifying performance of the listing obligations304. As part of generating the listing306, such as the example listing depicted in the user interface1202, the listing platform132publishes the listing306for access by one or more computing devices, such that the client device106can view the user interface1202via, e.g., the application146.

A purchase of the NFT is detected via the listing (block1308). The listing platform132, for instance, receives a transfer request312from the client device106, which is generated by the client device106in response to detecting user input at the selectable control1222of the example listing of the user interface1202. In response to detecting purchase of the NET, a smart contract configured to enforce performance of the at least one obligation and transfer the NFT from the first digital wallet to the second digital wallet is generated (block1310). The listing platform132, for instance, updates the smart contract template310of the listing306to include information identifying the digital wallet150of the client device106from which the transfer request312was received.

A distributed state machine implemented by a blockchain is then caused to transfer the NET from the first digital wallet to the second digital wallet by executing the smart contract (block1312). The listing platform132, for instance, communicates the smart contract314to a node112of the blockchain116and causes the node112to execute the NFT transfer instructions316included in the smart contract314by first verifying performance of the listing obligations304associated with the listing306and transfer the NFT308from the digital wallet156to the digital wallet150responsive to verifying performance of the listing obligations304. Execution of the smart contract314causes the112to record both the specific code set forth in the smart contract314as well as results of executing the specific code as transaction data126stored on the blockchain116.

Having described examples of procedures in accordance with one or more implementations, consider now an example of a system and device that can be utilized to implement the various techniques described herein.

Example System and Device

FIG.14illustrates an example of a system generally at1400that includes an example of a computing device1402that is representative of one or more computing systems and/or devices that may implement the various techniques described herein. This is illustrated through inclusion of the service provider system104. The computing device1402may be, for example, a server of a service provider, a device associated with a client (e.g., a client device), an on-chip system, and/or any other suitable computing device or computing system.

The computer-readable media1406is illustrated as including memory/storage1412. The memory/storage1412represents memory/storage capacity associated with one or more computer-readable media. The memory/storage1412may include volatile media (such as random-access memory (RAM)) and/or nonvolatile media (such as read only memory (ROM), Flash memory, optical disks, magnetic disks, and so forth). The memory/storage1412may include fixed media (e.g., RAM, ROM, a fixed hard drive, and so on) as well as removable media (e.g., Flash memory, a removable hard drive, an optical disc, and so forth). The computer-readable media1406may be configured in a variety of other ways as further described below.

Combinations of the foregoing may also be employed to implement various techniques described herein. Accordingly, software, hardware, or executable modules may be implemented as one or more instructions and/or logic embodied on some form of computer-readable storage media and/or by one or more hardware elements1410. The computing device1402may be configured to implement particular instructions and/or functions corresponding to the software and/or hardware modules. Accordingly, implementation of a module that is executable by the computing device1402as software may be achieved at least partially in hardware, e.g., through use of computer-readable storage media and/or hardware elements1410of the processing system1404. The instructions and/or functions may be executable/operable by one or more articles of manufacture (for example, one or more computing devices1402and/or processing systems1404) to implement techniques, modules, and examples described herein.

The techniques described herein may be supported by various configurations of the computing device1402and are not limited to the specific examples of the techniques described herein. This functionality may also be implemented all or in part through use of a distributed system, such as over a “cloud”1414via a platform1416as described below.

The cloud1414includes and/or is representative of a platform1416for resources1418. The platform1416abstracts underlying functionality of hardware (e.g., servers) and software resources of the cloud1414. The resources1418may include applications and/or data that can be utilized while computer processing is executed on servers that are remote from the computing device1402. Resources1418can also include services provided over the Internet and/or through a subscriber network, such as a cellular or Wi-Fi network.

The platform1416may abstract resources and functions to connect the computing device1402with other computing devices. The platform1416may also serve to abstract scaling of resources to provide a corresponding level of scale to encountered demand for the resources1418that are implemented via the platform1416. Accordingly, in an interconnected device embodiment, implementation of functionality described herein may be distributed throughout the system1400. For example, the functionality may be implemented in part on the computing device1402as well as via the platform1416that abstracts the functionality of the cloud1414.

CONCLUSION

Although the systems and techniques have been described in language specific to structural features and/or methodological acts, it is to be understood that the systems and techniques defined in the appended claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claimed subject matter.