Distributed ledger lending system with smart contract architecture and method thereof

Abstract

According to an embodiment of the present disclosure, a decentralized loan process is disclosed. An exemplary method includes receiving a request to initiate a loan process indicating a collateral item. The method also includes generating a collateral token corresponding to the collateral item. The method further includes instantiating a loan process smart contract instance configured to manage the loan process according to a loan process workflow, wherein the loan process smart contract instance configured to instantiate the loan smart contract receives a loan agreement notification indicating one or more loan term parameters of the loan agreed upon by the lender and borrower, and manages repayment of the loan based on the one or more loan term parameters. The collateral token is locked in an escrow account stored on a distributed ledger until the loan is fully repaid or enters default.

Description

[Technical Field]

[0001] This application claims priority to U.S. Provisional Patent Application No. 62 / 906,211, filed September 26, 2019, the entire disclosure of which is incorporated herein by reference.

[0002] The present disclosure relates to a decentralized loan system and method that leverages smart contracts and distributed ledgers such as blockchain to provide a trustless or substantially trustless secured loan ecosystem. [Background technology]

[0003] Traditional electronic commerce (e-commerce) processes are riddled with unnecessary friction. These processes are designed around use cases where a buyer places an order knowing exactly what they want, how to pay, where to ship, who to recipient, and they want it as quickly as possible. Traditional e-commerce does not allow for much flexibility in these purchasing decisions. For example, a user wanting to purchase a gift typically makes the purchase on a website or mobile application, enters the recipient's address (regardless of whether the recipient normally receives packages at that address), and pays for it. The gift is then sent to the recipient immediately, regardless of whether the recipient is available to receive the package. Therefore, there is a need in the art for an e-commerce platform that allows greater flexibility in all aspects of a transaction, including, but not limited to, purchase selection, payment, transfer of ownership, and location and timing of delivery.

[0004] Meanwhile, in video games and other media, virtual items, such as skins, weapons, and tools, are gaining popularity as players purchase and trade them with each other. Like other digital items, virtual items can be possessed, used, and transferred without the transportation, delivery, and storage constraints of physical items. However, because creators can create unlimited copies of virtual items, their value is transient, and what was initially highly rare may gradually lose value. Therefore, there is a need for a platform with a method and system that offers both the flexibility and convenience of virtual item trading and the reliability and value of physical item trading.

[0005] In most loan scenarios, a borrower seeks a loan from a lender. Typically, the lender may require collateral to secure the loan before agreeing to terms. Traditionally, a borrower can visit a physical pawnshop, where the pawnshop owner / agent is responsible for authenticating, appraising, safely storing, and disbursing funds. In exchange, the borrower can offer their item as collateral. This setup puts both the lender and the borrower at a disadvantage. The lender must trust the pawnshop owner / agent to fairly appraise and honestly store the collateral item, while the pawnbroker must trust that the collateral item is authentic and that the pawnbroker can liquidate it if the borrower defaults. This dilemma forces borrowers to significantly undervalue the collateral and places the pawnbroker at risk, resulting in lower loan amounts and higher interest rates and loan costs. As a result, pawnbrokers are seen as lenders of last resort, and borrowers are often exploited by loan sharks masquerading as pawnbrokers. This creates a need for a decentralized loan system that provides a trustless or virtually trustless loan ecosystem. Summary of the Invention

[0006] Provided herein are systems and methods for facilitating a decentralized loan process with a smart contract architecture. In embodiments, the decentralized loan process is carried out in a series of stages, including an authentication stage where the collateral item is authenticated, an appraisal stage where the collateral item is appraised, and a storage stage where the item is physically secured in a storage facility. In embodiments, the collateral item is "tokenized," allowing ownership of the collateral item to be transferred while it remains in storage using a digital collateral token that represents the physical collateral item. In embodiments, a set of smart contracts manages the loan process, including one or more stages of the loan process.

[0007] According to some embodiments of the present disclosure, the following method is disclosed. The method includes one or more processing devices receiving a request to initiate a loan process from a borrower device, the request indicating a collateral item, the collateral item being a tangible object. The method also includes one or more processing devices generating a virtual representation of the collateral item, the virtual representation including at least one of a description of the collateral item and one or more media content pieces each depicting at least a portion of the collateral item. The method further includes one or more processing devices generating a collateral token corresponding to the collateral item based on the virtual representation of the collateral item, the collateral token being a digital token stored on a distributed ledger distributed across a set of node devices. The method further includes one or more processing devices instantiating a loan process smart contract instance including computer-readable instructions configured to manage the loan process according to a loan process workflow, the loan process smart contract instance being executed by the set of node devices storing the distributed ledger. The loan process smart contract instance is configured to receive a loan agreement notice indicating one or more loan term parameters for the loan agreed upon by the lender and borrower, and instantiate a loan smart contract including computer-readable instructions configured to manage repayment of the loan based on the one or more loan term parameters, and the collateral tokens are locked in an escrow account stored on the distributed ledger until the loan smart contract instance determines that the loan has been fully repaid or is in default.

[0008] In some embodiments, the computer-readable instructions of the loan process smart contract instance are further configured to instantiate an authentication smart contract instance including computer-readable instructions configured to manage authentication tasks performed by an authenticator to authenticate the collateral item and to issue an authentication notification upon confirming that the appraisal tasks are complete. In some of these embodiments, the loan process smart contract instance instantiates the authentication smart contract instance according to a loan process workflow. In some of these embodiments, the loan process workflow is defined in a system-level governance document stored on the distributed ledger, the system-level governance defining the conditions for initiating authentication tasks. In some embodiments, the loan process smart contract instance instantiates the authentication smart contract instance in response to receiving a request notification indicating that a borrower has requested to initiate the loan process. In some embodiments, the computer-readable instructions of the loan process smart contract instance are further configured to receive an authentication report from the authenticator's authentication device, the authentication report including the authenticator's authentication opinion indicating an authentication status, including whether the authenticator deemed the collateral item authentic. In some of these embodiments, the authentication report further includes supporting documentation provided by the certifier to support the authentication opinion. In some of these embodiments, the authentication report further includes one or more attestations issued by one or more respective secondary certifiers, each attestation indicating that a respective secondary certifier confirmed the authentication opinion. In some of these embodiments, the authentication report is generated from a form template defined according to authentication stage-level governance that defines a set of rules and regulations related to the performance of authentication tasks.In some of these embodiments, the authentication stage-level governance defines an authentication task workflow, the authentication task workflow including one or more conditions that must be met to complete the authentication task and trigger the next stage in the loan process workflow to which the loan process conforms. In some of these embodiments, the authentication stage-level governance is defined at least in part by an authentication guild of which the authenticator is a guild member. In some of these embodiments, the authentication guild includes multiple different specialized authentication guilds, each specialized authentication guild specializing in authenticating a respective type of collateral item. In some of these embodiments, the plurality of different specialized authentication guilds includes at least a subset of the group including: a watch authentication guild specializing in authenticating watches, a shoe authentication guild specializing in authenticating shoes, a handbag authentication guild specializing in authenticating handbags, an art authentication guild specializing in authenticating art, a sports memorabilia authentication guild specializing in authenticating sports memorabilia, a toy authentication guild specializing in authenticating collectible toys, a jewelry authentication guild specializing in authenticating jewelry, a clothing authentication guild specializing in authenticating designer clothing, a musical instrument authentication guild specializing in authenticating musical instruments, a record authentication guild specializing in authenticating rare or collectible records, a wine authentication guild specializing in authenticating wine in units (e.g., barrels or bottles), a whiskey authentication guild specializing in authenticating whiskey in units (e.g., barrels or bottles), and an automobile authentication guild specializing in authenticating limited edition cars. In some of these embodiments, the authenticator belongs to a specialized authentication guild of the different specialized authentication guilds. In some of these embodiments, verifiers are assigned authentication tasks based on the specialized authentication guild to which they belong and the item type of the collateral item. In some embodiments, the authentication stage level governance defines an authentication smart contract from which authentication smart contract instances are instantiated.In some embodiments, the authentication smart contract instance initiates an escrow of currency tokens and / or tokenized tokens from the authenticator's account to an escrow account in response to an authentication report indicating that the authenticator has deemed the collateral item authentic. In some embodiments, at least a portion of the deposited amount is locked in escrow until the loan process is completed. In some embodiments, in response to receiving the authentication report from the authenticator device, the authentication smart contract instance outputs an authentication notification to the loan process smart contract, which causes the loan process smart contract instance to initiate the appraisal stage of the loan process. In some embodiments, the authentication smart contract instance is further configured to generate a data block including the authentication report and a cryptographic hash value generated based at least in part on the authentication report, and write the data block to the distributed ledger. In some embodiments, the authenticator's rating is updated based on results associated with the authentication task.

[0009] In some embodiments, the computer-readable instructions of the loan process smart contract instance are further configured to instantiate an appraisal smart contract instance including computer-readable instructions configured to manage appraisal tasks performed by an appraiser to determine the appraisal value of a collateral item, confirm completion of the appraisal task, and issue an appraisal notice. In some of these embodiments, the loan process smart contract instantiates the appraisal smart contract instance according to a loan process workflow. In some of these embodiments, the loan process workflow is defined in a system-level governance document stored on a distributed ledger, the system-level governance defining the conditions for initiating an appraisal task. In some embodiments, the loan process smart contract instantiates the appraisal smart contract instance in response to receiving an authentication notice indicating that an authenticator has authenticated the collateral item and deemed the collateral item authentic. In some embodiments, the computer-readable instructions of the loan process smart contract instance are further configured to receive an appraisal report from the appraiser's appraisal device, the appraisal report including a valuation of the collateral item including at least one of the appraisal value of the collateral item and a liquidation value of the collateral item. In some of these embodiments, the appraisal report further includes one or more of the physical condition of the collateral item, the new or used condition of the collateral item, the working condition of the collateral item, previous sales prices of similar items, and blue book valuations of similar items. In some embodiments, the appraisal report further includes one or more verifications issued by one or more respective secondary appraisers, each verification indicating that a respective secondary appraiser confirmed the appraisal value. In some embodiments, the appraisal report is generated from a form template defined according to appraisal stage-level governance that defines a set of rules and regulations related to the performance of the appraisal task.In some embodiments, appraisal stage-level governance defines an appraisal task workflow, which includes one or more conditions that must be met to complete an appraisal task and trigger the next stage in the loan process workflow. In some of these embodiments, appraisal stage-level governance is defined at least in part by appraisal guilds of which appraisers are guild members. In some of these embodiments, the appraisal guilds include multiple different specialized appraisal guilds, each specialized appraisal guild specializing in appraising a respective type of collateral item. In some embodiments, the plurality of different specialized appraisal guilds comprises at least a subset of the group including: a watch appraisal guild specializing in appraising watches, a shoe appraisal guild specializing in appraising shoes, a handbag appraisal guild specializing in appraising handbags, an art appraisal guild specializing in appraising art, a sports memorabilia appraisal guild specializing in appraising sports memorabilia, a toy appraisal guild specializing in appraising collectible toys, a jewelry appraisal guild specializing in appraising jewelry, a clothing appraisal guild specializing in appraising designer clothing, a musical instrument appraisal guild specializing in appraising musical instruments, a record appraisal guild specializing in appraising rare or collectible records, a wine appraisal guild specializing in appraising wine in units (e.g., barrels or bottles), a whiskey appraisal guild specializing in appraising whiskey in units (e.g., barrels or bottles), and an automobile appraisal guild specializing in appraising limited edition cars. In some of these embodiments, an appraiser belongs to one of the different specialized appraisal guilds. In some embodiments, appraisers are assigned appraisal tasks based on the professional appraisal guild to which they belong and the item type of the collateral item. In some embodiments, appraisal stage level governance defines appraisal smart contracts from which appraisal smart contract instances are instantiated.In some embodiments, in response to receiving the appraisal report, the appraisal smart contract instance initiates a deposit of currency tokens and / or tokenized tokens from the appraiser's account to an escrow account, where the amount of the currency tokens and / or tokenized tokens is less than or equal to the appraisal value. In some embodiments, at least a portion of the deposited amount is locked in the escrow account until the loan process is completed. In some embodiments, in response to receiving the appraisal report from the appraiser device, the appraisal smart contract instance outputs an appraisal notice to the loan process smart contract, where the appraisal notice causes the loan process smart contract instance to initiate a custody stage of the loan process. In some embodiments, the appraisal smart contract instance is further configured to generate a data block including the appraisal report and a cryptographic hash value generated based at least in part on the appraisal report, and write the data block to the distributed ledger. In some embodiments, the appraiser's rating is updated based on results associated with the appraisal task.

[0010] In some embodiments, the computer-readable instructions of the loan process smart contract instance are further configured to instantiate a custody smart contract instance including computer-readable instructions configured to manage custody tasks performed by a custodian to securely store collateral items during at least a portion of the loan process and to issue a custody notification upon confirmation that the custody tasks are completed. In some embodiments, the loan process smart contract instantiates the custody smart contract instance according to a loan process workflow. In some of these embodiments, the loan process workflow is defined in a system-level governance document stored on a distributed ledger, and the system-level governance defines the conditions for initiating custody tasks. In some embodiments, the loan process smart contract instance instantiates the custody smart contract instance in response to receiving an appraisal notification indicating that an appraiser has appraised the collateral items. In some embodiments, the computer-readable instructions of the loan process smart contract instance are further configured to receive a custodian report from a custodian device of the custodian, the custodian report including verification that the collateral items are stored at a facility associated with the custodian and including an indication of any visible damage observed by the custodian when the collateral items were received. In some embodiments, the custody report further includes supporting documentation provided by the custody as proof of completion of the custody task. In some embodiments, the custody report further includes photographic documentation of any visible damage observed by the custodian when the collateral item was received by the custodian. In some embodiments, the custody report is generated from a custody form template that is defined according to custody stage-level governance that defines a set of rules and regulations associated with the performance of the custody task; in some embodiments, the custody report defines the rules and regulations associated with the performance of the custody task.In some embodiments, the custody stage-level governance defines a custody task workflow, the custody task workflow including one or more conditions that must be met to complete the custody task and trigger the next stage in the loan process workflow. In some embodiments, the custody stage-level governance is defined at least in part by a custodian guild of which the custodian is a guild member. In some embodiments, the custody stage-level governance defines a custody smart contract from which a custody smart contract instance is instantiated. In some embodiments, the custody smart contract instance initiates a deposit of currency tokens and / or tokenized tokens from the custody account to an escrow account in response to receiving a custody report, the currency tokens and / or tokenized tokens being less than or equal to the appraised value of the collateral item as determined by an appraiser. In some embodiments, at least a portion of the deposited amount is locked in the escrow account until the loan process is completed. In some embodiments, the custodian smart contract instance outputs a custodian notification to the loan process smart contract in response to receiving the custodian report from the custodian device, where the custodian notification causes the loan process smart contract instance to initiate generation of the collateral token. In some embodiments, the custodian smart contract instance is further configured to generate a data block including the custodian report and a cryptographic hash value generated based at least in part on the custodian report, and write the data block to the distributed ledger. In some embodiments, the custodian's rating is updated based on results associated with the custodian task. In some embodiments, the custodian device provides one or more images of the collateral item that are used to generate a virtual representation of the collateral item. In some embodiments, the custodian smart contract instance is configured to execute a redemption workflow after the collateral token is unlocked from the escrow account.In some of these embodiments, the redemption workflow results in the redeemer of the collateral token taking possession of the collateral item from the custodian.

[0011] In some embodiments, the method further includes the loan smart contract instance being configured to initiate a liquidation process in response to determining that the loan is in default. In some embodiments, the collateral tokens are transferred to a buyer who purchases the collateral tokens during a liquidation event, and the buyer redeems the collateral tokens to own the collateral items from a custodian who holds the collateral items.

[0012] In some embodiments, the loan smart contract instance is configured to initiate the transfer of the collateral token from the escrow account to the borrower's account upon determining that the loan has been fully repaid. In some of these embodiments, the collateral token is transferred from the escrow account to the borrower's account by updating ownership data defining the current owner of the collateral token so that the ownership data includes the address of the borrower's account on the distributed ledger.

[0013] In some embodiments, the loan term parameters include a loan term and a loan amount. In some embodiments, the loan smart contract is configured to determine a loan repayment schedule based on the loan term and the loan amount, and the loan is considered to be in a default stage if a predefined amount of payments are not made according to the payment schedule.

[0014] In some embodiments, a loan process workflow including an authentication stage defining authentication tasks to be performed by an authenticator, an appraisal stage defining authentication tasks to be performed by an appraiser, and a custody stage defining custody tasks to be performed by a custodian is executed prior to generating a collateral token. In some embodiments, the authentication stage, appraisal stage, and custody stages are executed before the collateral token is generated. In some embodiments, a loan instance smart contract instance facilitates allocating rewards to the authenticator, appraiser, and custodian in response to completion of the loan process.

[0015] In some embodiments, the change in loan state that triggers the unlocking of the collateral token is at least one of the following: the loan becoming fully repaid; the loan becoming in default and the collateral item being successfully liquidated; and a repaid state where the collateral is no longer required as defined in the loan agreement.

[0016] In some embodiments, the collateral token encapsulates a virtual representation of the collateral item.

[0017] In some embodiments, the loan smart contract is configured to determine a loan repayment schedule based on the loan term and loan amount of the loan defined in the loan term parameters, and the loan is considered to be in a default stage if a predefined amount of payments are not made according to the payment schedule.

[0018] In some embodiments, the loan process workflow includes an authentication stage that defines authentication tasks to be performed by an authenticator, an appraisal stage that defines authentication tasks to be performed by the appraiser, and a custody stage that defines custody tasks to be performed by a custodian, and the authentication stage, authentication stage, and custody stages are performed before the collateral token is generated. In some of these embodiments, the loan instance smart contract instance facilitates allocating rewards to the authenticator, the appraiser, and the custodian in response to completion of the loan process.

[0019] In some embodiments, the collateral item is a tangible object. In some embodiments, the change in the state of the loan is at least one of the loan becoming fully repaid, the loan becoming in default and the collateral item being successfully liquidated, and a repaid state where collateral is no longer required as defined in the loan agreement.

[0020] In some embodiments, the distributed ledger is a blockchain.

[0021] A more complete understanding of the present disclosure will be obtained from the following description and accompanying drawings, and from the claims.

[0022] The accompanying drawings, included to provide a better understanding of the present disclosure, illustrate one or more embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure. [Brief explanation of the drawings]

[0023] [Figure 1] FIG. 1 is a schematic diagram illustrating an exemplary tokenization platform environment according to some embodiments of the present disclosure.

[0024] [Figure 2] FIG. 2 is a schematic diagram illustrating an example market system according to some embodiments of the present disclosure.

[0025] [Figure 3] FIG. 3 is a schematic diagram illustrating an example ledger management system according to some embodiments of the present disclosure.

[0026] [Figure 4] FIG. 4 is a schematic diagram illustrating an example trading system according to some embodiments of the present disclosure.

[0027] [Figure 5] FIG. 5 is a schematic diagram illustrating an example intelligence and automation system according to some embodiments of the present disclosure.

[0028] [Figure 6] FIG. 6 is a schematic diagram illustrating an example analytics and reporting system according to some embodiments of the present disclosure.

[0029] [Figure 7] FIG. 7 is a user interface displaying tokens in a wallet according to some embodiments of the present disclosure.

[0030] [Figure 8] FIG. 8 is a schematic diagram illustrating an example set of components of a tokenization platform according to some embodiments of the present disclosure.

[0031] [Figure 9] FIG. 9 is a flowchart illustrating a method for tokenizing an item according to some embodiments of the present disclosure.

[0032] [Figure 10] 10 is a flowchart illustrating a method for transferring tokens using a digital marketplace according to some embodiments of the present disclosure.

[0033] [Figure 11]FIG. 11 is a flowchart illustrating a method for transferring tokens between wallets via keyboard interaction, according to some embodiments of the present disclosure.

[0034] [Figure 12] FIG. 12 is a flowchart illustrating a method for redeeming tokens according to some embodiments of the present disclosure.

[0035] [Figure 13] FIG. 13 is a flowchart illustrating a method for collateralization and / or securitization according to some embodiments of the present disclosure.

[0036] [Figure 14] FIG. 14 is a flowchart illustrating a method for item authentication according to some embodiments of the present disclosure.

[0037] [Figure 15] FIG. 15 is a flowchart illustrating a method for rendering a VR environment according to some embodiments of the present disclosure.

[0038] [Figure 16] FIG. 16 is a flowchart illustrating a method for facilitating transactions using a distributed ledger with a sidechain of blocks, according to some embodiments of the present disclosure.

[0039] [Figure 17] FIG. 17 is a flowchart illustrating a method for facilitating user acquisition according to some embodiments of the present disclosure.

[0040] [Figure 18] FIG. 18 is a flowchart illustrating a method for managing a mystery box according to some embodiments of the present disclosure.

[0041] [Figure 19]FIG. 19 is a flowchart illustrating a method for video game integration according to some embodiments of the present disclosure.

[0042] [Figure 20] FIG. 20 is a schematic diagram illustrating an example decentralized lending system ecosystem according to some embodiments of the present disclosure.

[0043] [Figure 21] FIG. 21 is a schematic diagram illustrating an example of guilds, sub-guilds, and various types of governance that operate various stages of a decentralized loan process, according to some embodiments of the present disclosure.

[0044] [Figure 22] FIG. 22 is a flowchart illustrating an example sequence of operations of a method for performing an authentication workflow according to some embodiments of the present disclosure.

[0045] [Figure 23] FIG. 23 is a flowchart illustrating an example sequence of operations in a method for performing an appraisal workflow, according to some embodiments of the present disclosure.

[0046] [Figure 24] FIG. 24 is a flowchart illustrating an example sequence of operations in a method for performing an archival workflow, according to some embodiments of the present disclosure.

[0047] [Figure 25] FIG. 25 is a flowchart illustrating an example sequence of operations of a method for executing a loan workflow, according to some embodiments of the present disclosure.

[0048] [Figure 26] FIG. 26 is a flowchart illustrating an example sequence of operations of a method for performing a loan pre-clearance workflow, according to some embodiments of the present disclosure.

[0049] [Figure 27] FIG. 27 is a diagram illustrating a series of stages in a loan process workflow, according to some embodiments of the present disclosure.

[0050] [Figure 28] FIG. 28 is a diagram illustrating the sequential stages of a loan process workflow according to some embodiments of the present disclosure.

[0051] [Figure 29] FIG. 29 is a diagram illustrating the sequence of stages in a loan process workflow, according to some embodiments of the present disclosure.

[0052] [Figure 30] FIG. 30 is a diagram illustrating the sequential stages of a loan process workflow according to some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0053] The combination of blockchain technology and smart contracts has been proposed for use in systems and methods for conducting various transactions in a manner that automates many of such transactions while preserving and respecting legal constraints on the automation of such transactions. One of the constraints on the automation of such systems is the existence of jurisdiction-specific rules and processes for (i) creating legally binding contracts between parties and (ii) exchanging property in a manner that results in a legally binding assignment (transfer) of ownership, security interest, or other similar interest.

[0054] Some of the proposed systems depend on the future implementation of blockchain technology in legal systems for recording such transfers, including real estate records, the U.S. Uniform Commercial Code filing system, and other similar systems. This transition depends on government agencies creating and adopting blockchain-based recordkeeping systems. For example, real estate records in the United States are typically maintained at the county level by elected officials, and documents are subject to specific rules regarding the format and method of filing for records. Each such official utilizes its own system to accept and record documents. Therefore, if a blockchain-based recordkeeping system is adopted, each jurisdiction must select and implement such a system. This process could take years, even if the technology for such a system is developed and available for implementation. Furthermore, jurisdictions' willingness to adopt new technology may vary significantly, making it impossible to determine when, if ever, all jurisdictions will transition to blockchain-based systems.

[0055] Because the benefits of blockchain technology should not wait until government recordkeepers decide to begin implementing systems based on the technology, a hybrid system is needed that provides the benefits of blockchain technology while also interfacing with existing record-keeping and other legal systems to fill the gap. The system disclosed herein provides users of the system with the benefits of blockchain, interfaces with existing legal systems and methods, and makes it easier to transition to a fully blockchain-based system once it becomes available.

[0056] The distributed ledger transaction systems and methods described herein utilize distributed ledger technology (e.g., blockchain technology) in combination with smart contracts to enable users to negotiate, document, and / or execute a variety of different transactions. According to some embodiments, the different transactions include securitized decentralized loan transactions. These loan transactions include loan transactions secured by traditional types of collateral and / or by digital assets.

[0057] Distributed ledger technology generally forms the basis of cryptocurrencies, which are rapidly expanding in application and adoption. Such cryptocurrencies augment or replace existing payment methods such as cash, but also provide a decentralized system for processing cryptocurrency transfers. The basis of distributed ledger / blockchain technology is a linked list of data blocks. Each block contains encrypted data and a link to the previous block in the chain. In some implementations of distributed ledgers, the encrypted data can include transaction data documenting the exchange of digital currency, software such as executable digital contracts, and data related to the use of digital contracts by specific parties, but can also include other types of data, as described in more detail below. The data in each block of a distributed ledger includes a hash of the previous block in the chain as a means of identifying and preventing attempts to alter previous blocks in the distributed ledger.

[0058] In many implementations of distributed ledger technology, the management and expansion of the distributed ledger is decentralized and distributed across computer systems operated by many independent entities that provide computational power to the system. These decentralized contributors provide the infrastructure of the distributed ledger system by storing copies of the distributed ledger, running the algorithms necessary to process transactions, deploying them into new blocks on the distributed ledger, and distributing those blocks to the rest of the system. In some distributed ledger implementations, contributors are compensated for this service by receiving a fee denominated in cryptocurrency in return for processing new blocks on the distributed ledger. A key aspect of distributed ledger security is the difficulty of amending a block after it has been added to the ledger and accepted by the main branch, although distributed ledgers can temporarily have competing branches.

[0059] Distributed ledger technology has been enhanced by the concept of "smart contracts." A smart contract is an executable computer program compiled by a smart contract developer into data within a distributed ledger block. Once a smart contract is deployed to a distributed ledger, other users of the distributed ledger can execute the smart contract with confidence that it has not been tampered with by a malicious third party. These executable computer programs are called "smart contracts" because they may be used to represent and execute agreements between various parties regarding the transfer of digital currency or other types of assets, but they do not necessarily represent contractual arrangements. Software developers develop smart contracts by writing program code using scripting languages ​​such as JavaScript or Solidity, object coding languages ​​such as Java, or machine coding languages ​​such as C or C++. Once a smart contract is deployed to a distributed ledger, the program code is processed into a block by one of the system's contributors, just like any other transaction on the distributed ledger. A fee is typically paid to the contributor at the node that compiled the contract / program. The process of deploying a smart contract may involve compiling program code into bytecode, object code, binary code, or some other executable form. Once a smart contract is successfully deployed to the blockchain, it is assigned an address, just like any other distributed ledger transaction. This address is used to access the smart contract and execute the functions provided within it. Typically, an application binary interface (ABI), similar to an application programming interface, is provided to users of the contract or software that interfaces with the contract (such as a wallet application) to allow users to interact with the various features of the smart contract. The ABI describes the various functions and methods provided as part of the smart contract and how they can be accessed by the user or their software.

[0060] A contract / program deployed to the distributed ledger can then be used by anyone who has the contract's address on the distributed ledger. Executing a contract or part of it does not necessarily incur fees unless an update to the distributed ledger is required as part of that step. If a contract / program is properly implemented, many different users can use it simultaneously to manage their own specific agreements and transactions.

[0061] In embodiments, a smart contract / program may have multiple steps performed or completed by different parties to the contract. For example, a contract / program may be invoked by a first party to make an offer to a second party or group of potential contracting parties by instantiating a copy of a particular contract. The second party (or one of the group) may respond by "signing" its instance of the contract. The process of "signing" a contract may consist of invoking a program method defined as part of the contract. Some contracts may provide for multiple parties, such as a buyer, seller, lender, borrower, escrow agent, certifier, appraiser, and / or the like, all of which may independently interact with, sign, or perform other actions related to a particular instance of a smart contract.

[0062] Smart contracts are well suited to agreements involving digital assets or that can be executed entirely through programmatic interactions between contracting parties, distributed ledgers, digital assets, and resources on the internet or otherwise digitally connected. For example, a smart contract might be able to automatically transfer control and ownership of digital assets or transfer money between PayPal or bank accounts via ACH or other electronic payment systems. An application programming interface provided by an external system provides a way for the digital contract to execute the actual transfer of assets or funds between parties without non-programmatic processes.

[0063] It is less easy for smart contracts to fully enforce contracts involving tangible assets, such as real estate, personal property, and other types of assets under government or private registry systems. These registry systems are often paper-based and, even when electronic, are not designed for programmatic interaction by third parties. Examples of such systems include real estate title records, titled property personal property records, Uniform Commercial Code records, and patent and trademark registration databases. Many of these systems may be partially digitized but lack programmatic interfaces or are inherently proprietary, allowing smart contracts to interact with them in a fully automated manner. Other systems may be fragmented across many jurisdictions with their own separate filing systems, and a single smart contract would not work across all relevant systems. For example, Uniform Commercial Code filings are typically handled by different systems across different state jurisdictions, so a smart contract would need to implement various interfaces to handle transactions outside of a single jurisdiction and depending on whether such interfaces are available in a given jurisdiction.

[0064] One type of contract that could not be fully executed through the programmatic functionality of smart contracts / programs is a secured loan transaction. While many portions of such a transaction can be completed through interactions between the parties and smart contracts, other aspects of the transaction, such as ownership and transfer of ownership, and the creation of a security interest in favor of the lender, are not easily adapted to completion through smart contracts. According to embodiments of the present disclosure, a decentralized lending system is created that incorporates a set of distributed ledgers and a set of facilitating smart contracts to support one or more types of smart contracts. In various embodiments of the system, the set of distributed ledgers may host various types of smart contracts, such as guild governance smart contracts, authenticator smart contracts, appraisal smart contracts, loan smart contracts, and / or other smart contracts implemented to support the securitized decentralized loan process. Programmatic smart contracts are compiled into the distributed ledger and reside at specific addresses within each block of the distributed ledger. Users can utilize these smart contracts by invoking methods or functions associated with the address and smart contract. For example, an exemplary loan agreement may have methods for loan request, loan approval, collateral assignment, payment approval, and / or other similar functions necessary for forming and disbursing a loan, providing collateral, and repaying a loan in accordance with its terms.

[0065] Continuing with the loan contract example, when a user utilizes a smart contract and invokes a method or function of that contract, the user may submit parameters and other information specified by the particular method or function to the smart contract. The smart contract can programmatically execute the selected method or function according to those parameters. In the case of a loan request function, the loan smart contract may take parameters received from a user seeking a loan and incorporate the request information into a new block in the blockchain, making the request visible to potential lenders. In some embodiments, loan requests may not be incorporated into a distributed ledger but may be stored in a database programmatically available to potential lenders, such as via a web service.

[0066] The present disclosure relates to a tokenization platform that enables the creation of virtual representations (also referred to as "VIRL") of items such as goods, services, and / or experiences. As used herein, the term "item" can refer to digital assets (e.g., gift cards, digital music files, digital video files, software, digital photographs, etc.), physical goods, digital services (e.g., video streaming), physical services (e.g., chauffeur services, maid services, cleaning services), and / or purchased experiences (e.g., hotel packages, concert tickets, airline tickets, etc.), or any combination thereof. Note that an item may refer to a commodity that already exists or a commodity that can be produced at a later point in time. For example, an item may be a raw pizza or a piece of clothing. A buyer of such an item can purchase the item, and the item may be produced at a later point in time after the purchase. The term "virtual item" may refer to a virtual representation of a commoditized item. When creating a virtual representation for a product, many of the purchase decisions required in traditional e-commerce can be deferred and separated from the transaction itself, thereby creating added value for the buyer. For example, say a buyer wants to order a pair of shoes, but isn't yet sure when they'll need them or where they'd like them delivered to. The buyer can purchase a virtual representation of the shoes, which can then be redeemed at a later date by a redeemer (such as the buyer or gift recipient) who can specify a delivery time and location. In this way, creating a virtual item can add value to the buyer or gift, and hold it until it's time to redeem it.

[0067] Furthermore, traditional e-commerce platforms lack a reliable record-keeping mechanism for verifying the transfer of goods between unknown parties. Furthermore, there is no way to store sensitive financial information without a centralized entity. Accordingly, in some embodiments, a tokenization platform is configured to issue electronic tokens (or "tokens") that are configured to be stored in a cryptographically secure ledger, providing a virtual representation that enables the transfer of items between unknown parties while also providing a process by which anyone can verify the state of the token at any time and trust that it is correct. As used herein, unless otherwise indicated by context, "cryptographically" refers to the use of a cryptographic algorithm, such as a hash algorithm.

[0068] The e-commerce platform may be configured to support additional or alternative ecosystems. In embodiments, the tokenization platform is configured to support a token-based lending system, whereby lenders can create virtual items corresponding to collateral (e.g., jewelry, collectibles, art, etc.). The e-commerce platform may tokenize the virtual items and store the tokens on a distributed ledger. In this manner, loans may be sold and only tokens need to be transferred between lenders. In some embodiments, smart contracts may be used to manage loans, token ownership, and other transactions corresponding to the loans.

[0069] In some embodiments, the tokenization platform is configured to authenticate real-world items. In some of these embodiments, the tokenization platform may engage a subject matter expert to authenticate the item using a virtual representation of the item. The subject matter expert may provide an authentication report that includes notes of the underlying expert opinion. The authentication report may be used to deny or allow the item to be used as collateral or sold on the platform. Additionally, in some embodiments, the authentication report may be used to train machine learning models so that the platform may use machine vision, machine learning, sensors (e.g., scales), and / or other suitable technologies to authenticate the item.

[0070] In embodiments, the tokenization platform is configured to support "mystery box" games, which are variant games in which users can earn tokens from mystery boxes, where the tokens represent items, and where the tokens can be redeemed, traded, sold, gifted, etc. In some of these embodiments, the tokenization platform supports casino-style games, whereby mystery box games can be played in casinos and other brick-and-mortar locations.

[0071] In embodiments, the tokenization platform is configured to support in-video game streaming. In some of these embodiments, the tokenization platform may provide token indicators to instances of a video game, allowing video game makers to use the tokens in many different ways. For example, tokens may appear in a video game to enable a food delivery service to sell deliverable food within the game. In another example, tokens may represent digital items that can be used within the game but can then be redeemed to obtain real-world items that correspond to the digital items.

[0072] In embodiments, the tokenization platform may offer a reward-based user acquisition program whereby users can register a referral code. When users successfully refer users to the tokenization platform, they are rewarded with tokens. The tokens can represent monetary rewards or physical items (e.g., gift cards, shoes, music albums, DVDs, etc.).

[0073] 1 illustrates an exemplary ecosystem for a tokenization platform 100 (or "platform") according to some embodiments of the present disclosure. The environment includes platform 100, node computing devices 160, external data sources 170, content platform 180, and user devices 190. Platform 100, node computing devices 160, external data sources 170, content platform 180, and user devices 190 may communicate via a communications network 10 (e.g., the Internet and / or a cellular network).

[0074] In some embodiments, tokenization platform 100 manages one or more cryptographic ledgers (or “distributed ledgers”), providing flexible functionality for virtual representations of items, such as goods, services, and / or experiences, and for fulfillment and satisfaction of those items. In embodiments, platform 100 provides a marketplace for third-party sellers to trade items using tokens, whereby tokens are digital markers that define ownership rights in particular items. Additionally or alternatively, providers of platform 100 may sell, lease, transfer, or otherwise trade items offered by the providers. As used herein, the term “trade” may refer to selling / buying, leasing, gifting, pledging, or any other action that affects ownership of tokens. As described below, in some embodiments, tokens can be redeemed by token owners so that the token owners can own the items upon redemption.

[0075] In some embodiments, a seller of an item (or any other suitable user) can access platform 100 to define a virtual representation of an item that the seller is offering for trade. The virtual representation of the item may include information identifying the item (e.g., a serial number corresponding to the item, a model number of the item, etc.), information about the item (e.g., a classification of the item, a text description, images, audio, video, virtual reality data, augmented reality data, etc.), and / or code (e.g., a smart contract) that can be used to facilitate or verify transactions involving the item. In some embodiments, the platform can “tokenize” the item on behalf of the seller of the item by generating a set of tokens based on the virtual representation of the item and storing the tokens and associated metadata in a cryptographically secure distributed ledger, thereby making the tokens (and the virtual representation) verifiable, transferable, and trackable.

[0076] In embodiments, platform 100 may receive data from one or more external data sources 170. External data source 170 may refer to any system or device capable of providing data to platform 100. In embodiments, data sources may include merchant, manufacturer, or service provider systems and / or databases that provide platform 100 with data related to available items. External data sources may also include user devices 190, such that user devices 190 can provide relevant data (e.g., contacts, cookies, etc.). Examples of external data sources 170 may include e-commerce websites, organization websites, software applications, and contact lists (e.g., phone contacts, email contacts, messenger client contacts, and the like). Platform 100 may access external data sources 170 via network 10 (e.g., the Internet) in any suitable manner (e.g., crawler, user permission / API, etc.).

[0077] In embodiments, platform 100 interacts with content publishing platform 180. Content publishing platform 190 may refer to any system that publishes content on behalf of individuals and / or organizations. Content publishing platforms may include social networking platforms, blogging platforms, news sites, etc. In embodiments, consumers may output content corresponding to items via content publishing platform 190. For example, consumers may post content related to purchased items to a social networking platform or embed the content in a blog post. The content may include a link to the item (e.g., a link to a web page or application state corresponding to the item).

[0078] In embodiments, platform 100 interfaces with various user devices 190. User device 190 may refer to any computing device through which a user (e.g., a consumer, a merchant, a manufacturer, a provider, etc.) can access the platform. Examples of user devices include, but are not limited to, smartphones, tablet computing devices, laptop computing devices, personal computing devices, smart televisions, game consoles, etc. User devices may access platform 100 via websites, web applications, native applications, etc. In embodiments, platform 100 may provide a first graphical user interface to user devices 190 associated with merchants and a second graphical user interface to user devices 190 associated with end users. The first graphical user interface may enable users associated with merchants to offer items for sale and create new virtual representations corresponding to the items for sale. The second user interface may enable users to purchase tokens corresponding to the items for sale, transfer tokens, and / or redeem tokens. In some embodiments, platform 100 may support a digital wallet that stores users' tokens. A digital wallet may be a client application provided and / or supported by platform 100. In some embodiments, the digital wallet stores any tokens owned by a user associated with the digital wallet and provides an interface that allows the user to redeem, transfer, sell, exchange, or otherwise participate in transactions involving the tokens.

[0079] In embodiments, tokenization of items provides a framework for securely conducting transactions involving items represented by tokens. For example, tokens provide a mechanism by which items may be traded, rented, purchased, sold, exchanged, gifted, swapped, or transferred in transactions involving trusted or untrusted parties. In some embodiments, a token represents a single unit being traded (e.g., sold, traded, leased, gifted, etc.). For example, if a seller is selling 10 widgets, platform 100 may generate 10 tokens, each corresponding to a different widget. In this scenario, all 10 widgets may correspond to the same virtual representation of the widget, and the 10 tokens may represent instances of the virtual representation (also referred to as "virtual assets"). In embodiments, a token may be a digitally signed instance of the virtual representation of an item, whereby the digital signature may be used to verify the validity of the token.

[0080] In some embodiments, each virtual representation of an item may include or be associated with a smart contract that provides a set of verifiable conditions that must be met to self-execute a transaction (e.g., transfer of ownership or expiration) related to the item represented by the virtual representation. In some embodiments, each token corresponding to the virtual representation may be associated with a smart contract corresponding to the virtual representation. In some embodiments, a smart contract corresponding to the virtual representation may define conditions that must be verified to generate a new token, transfer ownership of the token, redeem a token, and / or destroy a token. A smart contract may also include code that defines actions to be performed when a particular condition is met. When engaged, a smart contract may determine whether a defined condition is met and, if so, fulfill the condition to self-execute an action corresponding to the condition. In some embodiments, each smart contract may be stored on and accessed on a distributed ledger. In some embodiments, a token that does not have a smart contract associated with it may be referred to as a placeholder token, and placeholder tokens may not be involved in transactions. In some embodiments, tokens may be gifted. In some embodiments, a recipient of a gifted token may be able to redeem the token, customize the virtual asset represented by the token before redemption, exchange it for another token, obtain a cash value equivalent, etc.

[0081] When platform 100 generates a token, the platform may update the distributed ledger to indicate the existence of the new token. As used herein, a distributed ledger may refer to an electronic ledger that records transactions. A distributed ledger may be public or private. In embodiments where the distributed ledger is private, platform 100 may maintain and store the entire distributed ledger on a computing device node 160 associated with the platform. In embodiments where the distributed ledger is public, one or more third-party computing node devices 160 (or “computing nodes”) unassociated with platform 100 may store the distributed ledger collectively. In some of these embodiments, platform 100 may also store the distributed ledger and / or portions thereof locally. In some embodiments, the distributed ledger is a blockchain (e.g., the Ethereum blockchain). Alternatively, the distributed ledger may conform to other suitable protocols (e.g., Hashgraph, Byteball, Nanoblock Lattice, and IOTA). By storing tokens on a distributed ledger, the state of the token can be checked at any time by querying the ledger and can be trusted to be correct. Implementing it in a tokenized manner means that tokens cannot be copied or exchanged for cash without permission.

[0082] In some embodiments, platform 100 is configured to shard the distributed ledger so that there are side chains that branch off from the distributed ledger's main chain. In some of these embodiments, a side chain may store virtual representations of items having a particular category or class. In embodiments, a side chain corresponding to a particular class of items may store tokens corresponding to items belonging to the particular class and ownership records indicating the current and previous ownership of those tokens. Whenever ownership of a token changes, the side chain containing the involved token may be modified to indicate the new owner of the token. In some embodiments, a side chain may store media content associated with the virtual representations. For example, a side chain may store videos, photos, audio clips, and other suitable media content referenced by each virtual representation.

[0083] In addition to item data (e.g., virtual representations), tokens, and transaction data associated with tokens, the distributed ledger may further store account information. For example, in some embodiments, the distributed ledger may store the public address of each valid account. In embodiments, a valid account may belong to an entity that has been verified by the platform and authorized to participate in transactions. Thus, in some embodiments, a party may only sell, buy, gift, receive, or otherwise transfer tokens if the party has a known account. Each account may be assigned a public and private key that can be used to transact on the platform 100. In embodiments, the account's address may be based on the account's public key (e.g., the address may be a hash value of the public key). These addresses may be stored in the distributed ledger, and addresses involved in transactions may be stored in the distributed ledger such that they can be verified as corresponding to valid accounts using the distributed ledger.

[0084] In operation, a merchant may instruct platform 100 to generate one or more virtual representations of each item, with each virtual representation representing a respective item available for trade. While many of the transaction examples in this disclosure involve the purchase of goods, services, and / or experiences, it should be noted that transactions may also include leases, rentals, loans, gifts, trades, rewards, or giveaways. In embodiments, a merchant may provide item attributes for a set of one or more items, such as the number of items available for trade, pricing information for the items, shipping restrictions for the items, expiration dates for the items (e.g., transaction validity periods), item descriptions, serial numbers (e.g., for physical items), media for the items (e.g., photos, videos, and / or audio content), etc. In response to the merchant providing the item information, platform 100 generates a set of tokens corresponding to the number of items available for trade. For example, if a seller indicates that they have 100 Model X widgets available for sale, platform 100 may generate a virtual representation of the Model X widget and generate 100 non-fungible tokens corresponding to the virtual representation, whereby each token corresponds to a respective instance of the virtual representation. The virtual representation may include a description of the widget, a price for the widget, shipping restrictions associated with the widget, photos of the widget, videos of the widget, virtual reality data associated with the widget, etc. Platform 100 may then store the virtual representation and the corresponding tokens on the distributed ledger. For each token, the distributed ledger may store the token, ownership data associated with the token, media content corresponding to the token (or the virtual representation to which the token corresponds), and / or other suitable data associated with the token. Ownership of the token may be initially assigned to the seller. Thus, the distributed ledger can indicate the existence of the token and that the seller owns it. Once tokenized, end users (e.g., buyers) can participate in transactions for items using the corresponding token.For example, a user may purchase tokens corresponding to an item from a merchant via a web interface or application provided or supported by the provider of platform 100. In response to the transaction, platform 100 may update the distributed ledger to indicate the allocation of the tokens to the user (e.g., to a wallet associated with the user's account). In an embodiment, a copy of the token may be stored in a digital wallet corresponding to the token's new owner (e.g., the buyer).

[0085] Tokens can be transmitted between users in any suitable manner. For example, tokens may be transmitted via email, instant message, text message, digital transfer, social media platform, etc. In some of these embodiments, tokens may be transmitted directly from the sender's user device 190 (e.g., from the user's digital wallet) to a user device 190 (e.g., a smartphone) or account (e.g., an email account or messaging application) associated with the intended recipient. Upon initiating the transmission, the digital wallet may send a transfer request to the platform 100 and may send a copy of the token to the recipient's user device 190 or designated account. In some embodiments, the transmitted token may be embedded in media content, such as an image, emoji, or video, such that the recipient may receive the media content and choose to accept the token. In this example, the token may be accompanied by a link and / or software instructions that cause the user device 190 receiving the token to add the token to the recipient's account upon accepting the token. Upon choosing to accept the token, the recipient's user device 190 may send a request to the platform to add the token to the recipient's account. Platform 100 may receive the request and may update the token's ownership record in the distributed ledger to indicate the transfer of ownership.

[0086] In some embodiments, a token owner may redeem a token. In some embodiments, a user may select a token to redeem from the user's digital wallet. In response to the selection, the digital wallet may send a redemption request to platform 100. The redemption request may include the token (or its identifier) ​​and the user's public address (or any other suitable identifier for the user). Platform 100 receives the redemption request and verifies the token's validity and / or ownership. Once verified, the user is granted permission to redeem the token. In some scenarios, a user may redeem a token corresponding to a digital item (e.g., a gift card, an MP3, a movie, a digital photo). In these scenarios, platform 100 may determine a workflow for redeeming the digital item. For example, platform 100 may request an email address from the user or may look up the user's email address from the distributed ledger. In this example, platform 100 may email a link to the user's email account to download the digital item or may attach a copy of the digital item to an email sent to the user's email account. In another scenario, a user may redeem tokens corresponding to physical goods (e.g., clothing, food, electronics, etc.) or physical services (e.g., maid services). In the case of physical goods, platform 100 may determine a workflow for redeeming the physical goods. For example, platform 100 may request shipping information from the user or may look up the user's shipping information from the distributed ledger. Platform 100 may then initiate shipping of the physical goods. For example, platform 100 may send a shipping request indicating the shipping information to a warehouse that handles the shipment of the goods. The above are examples of how tokens may be redeemed. Platform 100 may execute additional or alternative workflows to process the redemption of the tokens.

[0087] In some embodiments, the token may be printed on a physical medium so that it can be redeemed at a brick-and-mortar store. For example, the token (e.g., an alphanumeric string) may be encoded into a QR code or barcode. In these embodiments, the public key of the party used to digitally sign the token (e.g., a public key associated with platform 100) may also be provided on the physical medium. In this manner, the token may be verified by scanning the QR code or barcode using a client application associated with platform 100. The client application may provide the token and public key to platform 100, which may verify the validity of the token based on the token and public key. If the token and ownership are verified, platform 100 may send a confirmation of the verification to the client application. The store clerk may then allow the user to complete the transaction (e.g., take ownership of the item).

[0088] In some embodiments, the token may be perishable, meaning that it loses all value at a predetermined time or upon the occurrence of a predetermined event. In these embodiments, the merchant may provide the virtual representation with an expiration date that indicates the date and time when the virtual representation is no longer valid, such that the token may be considered invalid upon reaching the expiration date.

[0089] Tokens may be fungible or non-fungible. A fungible token may refer to a token that can be exchanged. For example, fungible tokens may all have the same identifier. A non-fungible token is a unique token. A non-fungible token is transferable but not interchangeable.

[0090] In some embodiments, platform 100 may implement one or more of a market system 102, a ledger management system 104, a trading system 106, an API system 108, an intelligence and automation system 110, an analytics and reporting system 112, and / or a virtual world presence system 114, all of which are described in more detail throughout this disclosure.

[0091] In some embodiments, platform 100 provides a marketplace system 102 that enables defining, creating, viewing, and / or redeeming virtual representations of items. In embodiments, marketplace system 102 may include a graphical user interface that enables merchants to define virtual representations, enables consumers to view virtual representations of items and trade for tokens corresponding to the items, and enables token holders to redeem tokens and thereby complete transactions for the items represented by the redeemed tokens. Marketplace system 102 may further include back-end functionality to support these operations.

[0092] In some embodiments, platform 100 provides a ledger management system 104 that manages one or more distributed ledgers, including generating tokens and managing ownership of the generated tokens. In embodiments, ledger management system 104 may also interface with one or more smart contracts involved in the distributed ledgers.

[0093] In an embodiment, platform 100 includes an API system 106 that manages one or more application programming interfaces (APIs) of the platform to expose the APIs to one or more associated applications (e.g., native and / or web applications offered by the platform 100 provider), third-party systems supported by or otherwise interacting with platform 100, and smart contracts configured to interface with platform 100. API system 106 may expose one or more APIs such that API system 106 may receive API calls from requesting devices or systems and / or push data to subscribing devices or systems. API system 106 may implement any suitable type of API, including REST, SOAP, etc. In an embodiment, API system 106 may include a smart contract API that allows smart contracts to interface with the platform, a utility API, a merchant API that allows merchants to create tokens corresponding to virtual representations of items, and any other suitable APIs. In some embodiments, platform 100 may implement a microservices architecture where services may be accessed by clients, such as through APIs and / or software development kits (SDKs). The services abstract complexities such as blockchain creation, object handling, ownership transfer, data integration, and identity management, allowing platform users to easily build, provide, and / or consume platform functionality. In embodiments, SDK types include, but are not limited to, Android SDK, iOS SDK, Windows SDK, JavaScript SDK, PHP SDK, Python SDK, Swift SDK, Ruby SDK, etc.

[0094] In some embodiments, the platform 100 includes a trading system 108 that supports any suitable transaction on the platform, including buying, selling, trading, renting, leasing, exchanging, swapping, transferring, and / or redeeming tokens representing corresponding items.

[0095] In some embodiments, platform 100 includes an intelligence and automation system 110 that performs machine learning and artificial intelligence tasks. For example, intelligence and automation system 110 may train machine learning models, make classifications and predictions based on machine learning models, recommend products to users, identify advertisements targeted to particular users, match service providers with service seekers, and / or automate user notifications.

[0096] In some embodiments, the analytics and reporting system 112 may perform analysis-related tasks related to various aspects of the tokenization platform 100 and report the resulting analysis to stakeholders (e.g., employees of the platform provider 100 and / or merchants on the platform 100).

[0097] In some embodiments, the platform includes or supports a virtual world presence system 114 that presents virtual representations of items in a virtual world environment. For example, the virtual world presence system 114 may present a virtual reality store to a user, whereby virtual representations of items are presented within the store and the user can “shop” for virtual items within the virtual world environment. In these embodiments, the virtual world presence system 114 may render a virtual world environment that can be displayed in a client application. The virtual world environment may be associated with a seller or group of sellers, whereby items sold by the seller or sellers are made available in the virtual world environment. In these embodiments, the virtual world presence system 114 may further render a 3D representation of the seller or items available from the seller based on the virtual representation of the item. The 3D representation may then be presented in the virtual world environment so that the user can inspect the 3D representation of the item (e.g., view the representation from different angles). If the user wants to purchase the item, the user can initiate a transaction (e.g., select a “Buy” button within the virtual representation). Once the user initiates a transaction, the virtual world presence system 114 may notify the transaction system 106 of the user's selection, and the transaction may proceed in the manner described above.

[0098] In embodiments, platform 100 includes a user management system 116. In some embodiments, user management system 116 can create new user accounts, assess risks associated with users, provide terms to users based on their respective risks associated with users when participating in transactions, and the like.

[0099] In some embodiments, the user management system 116 creates a new account for the user. In these embodiments, a new user may access the platform 100 and request a new account. In embodiments, the platform 100 may allow a user to link their account to an account on an external system (e.g., Google®, Facebook®, Twitter®, etc.). Additionally or alternatively, the user may provide an email address and log in. In some embodiments, the user management system 116 may require the user to provide additional authentication information, such as a home or business address, a passport number (and / or an image of the passport), a driver's license number (and / or an image thereof), a state ID card (and / or an image thereof), etc. The user management system 116 may further provide a mechanism for the user to link any financial information to the platform, including entering a credit card number, banking information, a cryptocurrency wallet (e.g., a Coinbase® account), etc. Upon receiving the requested information, the user management system 116 creates a new account for the user, including creating a new public address for the user's corresponding account. Once an account is created, the user can begin participating in transactions on the platform 100.

[0100] In some embodiments, the user management system 116 determines a user's risk score each time the user attempts to participate in a transaction using the platform 100. A user's risk score may indicate the degree of risk associated with facilitating a particular transaction involving the user. Examples of risk may include the risk that a seller will not deliver an item purchased by another user, the risk that a seller will deliver a counterfeit or substandard item to another user, the risk that the user will default on a loan, the risk that the user will engage in fraud, and the like. Factors that may be related to a user's risk score include, but are not limited to, whether the user has provided secondary authentication information (e.g., a passport or driver's license), whether the user has provided banking information, the number of purchases or sales the user has made on the platform 100, the size of those transactions, how many problems the user had with previous transactions (e.g., how many non-payments or non-deliveries, complaints, etc.), whether the user has defaulted on a platform-facilitated loan, and the like.

[0101] In some embodiments, the user management system 116 may determine a risk score using a risk scoring model trained to assess the risk associated with a user given a transaction. When a user attempts to engage in a transaction, the user management system 116 may determine characteristics of the transaction (e.g., type of transaction, size of transaction, etc.) and characteristics of the user (e.g., the results of the user's previous transactions, the type of those transactions, whether the user provided secondary authentication information, whether the user provided banking information, whether the user has had a history of problems, etc.). The user management system 116 may determine a risk score, for example, when a user requests to sell an item, requests a secured loan, etc. The user management system 116 may provide the characteristics to the intelligence and automation system 110, which may input the characteristics into the risk scoring model. The risk scoring model may output a risk score based on the characteristics, which indicates the probability of the transaction being successful given the characteristics of the transaction and the characteristics of the user. In embodiments, the risk scoring model may be trained by the intelligence and automation system 110 (e.g., machine learning system 502 of FIG. 5 ), as described below.

[0102] In some embodiments, the user management system 116 may impose a set of conditions on a user requesting to participate in a transaction based on the risk associated with the user. Example conditions may include requiring the user to deposit funds into escrow in an amount equal to the sales price of the item being sold on the platform (e.g., the amount that would be refunded if the seller did not deliver the item or delivered a counterfeit item), requiring the user to provide collateral in excess of the loan amount if the user is at high risk of defaulting on the loan, requiring the user to provide secondary authentication information if the user is requesting a loan but has not provided that information, etc. For example, if a user requests to sell an item on the platform 100 but has no history of selling items, the risk score associated with the potential transaction may indicate a risk that the seller will not successfully deliver the item, or that the item may be counterfeit or in an unsatisfactory state. In this example, the platform 100 may require the user to deposit (or have in their account) funds in an amount equal to or greater than the item or the sales price of the item the user wishes to sell. In this way, the platform 100 may issue a refund to the buyer if the user (i.e., the seller) does not successfully complete the transaction. In embodiments, the user management system 116 may implement a set of rules to determine what conditions, if any, should be imposed on a user for a particular transaction if the user wishes to engage in the transaction. In embodiments, the rules may define one or more conditions that correspond to a particular type of transaction (e.g., sale, trade, borrowing, etc.) and may define a risk score threshold that triggers the one or more conditions.

[0103] Platform 100 may also implement additional or alternative systems. For example, in an embodiment, platform 100 may include a gamification system (not shown) that gamifies aspects of platform 100 and / or a rewards system (not shown) that rewards users for participating in certain activities. For example, the gamification system may provide an environment that challenges users to compete for the most shared virtual items on a social media platform. In this example, the rewards system may reward users with tokens to redeem items when they are deemed to have shared the most virtual items on the social media platform. In another example, the rewards system may issue a reward (e.g., tokens for a particular item) to a user when they purchase a certain value or amount of virtual items.

[0104] In some embodiments, platform 100 may include a logistics system (not shown) that enables physical delivery of items, such as goods or food. The logistics system may be configured to manage logistics from a location where an item is located (e.g., a warehouse or restaurant) to a token redeemer (e.g., the redeemer's home or current location). In embodiments, the logistics system may include a geolocation system (not shown) for determining a delivery location. For example, if a holder of a token corresponding to a pizza with one topping from a pizza delivery chain redeems the token, the geolocation system may determine the recipient's current location for delivery. Geolocation information may be obtained by a smartphone, a web browser (e.g., an IP address), etc. In this example, the logistics system may generate an electronic notification based on the user's geolocation (or selected delivery location) and the user's order (e.g., the toppings selected by the user) and may send the electronic notification to the pizza delivery chain location closest to the intended delivery location.

[0105] 2 is a diagram illustrating an example of a marketplace system 102 according to some embodiments of the present disclosure. In embodiments, the marketplace system 102 may include an item management system 202, a buyer's market system 204, and a redemption system 206.

[0106] The item management system 202 allows an item seller to define a virtual representation of the item. In an embodiment, the item management system 202 presents a GUI to the seller's user device 190 that allows the seller to define the item's attributes. If the item has never been sold on the platform 100, the seller may select an option to add a new item. In response to doing so, the seller may provide an item taxonomy indicating the type of item (e.g., "shoes," "pizza," "photo," "movie," "concert ticket," "gift card," etc.) and a name for the item. The seller may then define one or more additional attributes for the item. For example, in embodiments, a merchant may provide a description of the item, media content related to the item (e.g., photos, videos, audio clips, etc.), related links (e.g., links to the merchant's website), the price of the item, restrictions on the item (e.g., "US shipping only" or "merchant's store hours are 10-6"), redemption instructions (e.g., whether in-store redemption is allowed, permitted, or required, whether the digital asset is downloaded or emailed, whether the item is transferable, etc.), the number of items available for trading (e.g., how many units are available), and / or any other suitable attributes. In response to a merchant providing item attributes, the merchant may provide a description of the item, media content related to the item (e.g., photos, videos, audio clips, etc.), related links (e.g., links to the merchant's website), the price of the item, restrictions on the item (e.g., "US shipping only" or "merchant's store hours are 10-6"), redemption instructions (e.g., whether in-store redemption is allowed, permitted, or required, whether the digital asset is downloaded or emailed, whether the item is transferable, etc.), the number of items available for trading (e.g., how many units are available), and / or any other suitable attributes. In response, the item management system 202 may generate a virtual representation of the item. In embodiments, the virtual representation may be a data record including attributes of the item. In scenarios where the virtual representation was previously defined, the seller may select the previously defined item and update one or more attributes. For example, the seller may offer additional media content, change the price, and / or update the number of items available. Whether it is an updated or newly defined virtual representation, the item management system 202 may output the virtual representation to the ledger management system 104, which may tokenize the instance of the virtual representation to obtain a set of tokens.

[0107] In some embodiments, the item management system 202 may also allow a merchant to provide merchant attributes. A merchant may provide information such as the physical location where a physical item can be shipped, the digital location where a digital item can be acquired, the physical location of the merchant's brick-and-mortar store, the merchant's hours of operation, etc. These attributes may be included in the virtual representation or may be stored in an alternative date record.

[0108] In some embodiments, the item management system 202 may include an asset type manager for creating and defining new types of items to enable the platform 100 to support the sale and trading of new types of assets. In these embodiments, the asset type manager may provide a GUI that allows a user to define new types of assets. In these embodiments, asset type attribute fields allow a user to add information specific to the new asset type when the new asset type is defined. The attribute information must be understandable to buyers as information that will inform their purchasing decisions, be unique to the asset type, and be displayable on the platform. Asset type attribute fields include, but are not limited to, an asset type name, an asset type image, an asset redemption URL, an asset descriptor (e.g., physical or digital), etc.

[0109] In embodiments, the item management system 202 may include an item type definition manager for defining new types of items to be listed on the platform. In embodiments, the item type definition manager may provide a GUI that allows a user to define the attributes of a new item. To define a new item type, a user may be prompted to select the appropriate asset type from a drop-down menu. The GUI may then allow the user to define item attributes in item attribute fields. The item attribute fields may include, but are not limited to, an item name, an item description, item notes, an item image, item pricing data (e.g., a suggested price, a suggested minimum price), a sale flag, an item URL that links to a web page to purchase the item, a quantity of the item, etc. Once the user provides the required item attributes, the item management system 202 can create a new virtual representation that defines the new item.

[0110] In some embodiments, the item management system 202 may require merchants without sufficient history to escrow funds in an amount equal to the value of the goods being sold on the tokenization platform 100. The merchant may sell tokens representing the items, and when the tokens are redeemed by the token holder (e.g., a buyer or downstream recipient), the funds are transferred out of escrow and returned to the merchant's account. In these embodiments, the merchant does not need to deposit a physical item, which would require at least one additional shipment to a warehouse or other storage facility.

[0111] In embodiments, the buyers' market system 204 allows consumers to browse or search for items, view virtual representations of items, and engage in trading of items. In embodiments, the buyers' market system 204 presents a GUI including a search bar that allows a user to enter a search query consisting of one or more search terms. In response to receiving a search query, the buyers' market system 204 may issue a query to one or more indexes that index virtual representations using the one or more search terms. The buyers' market system 204 may process the search query and perform a subsequent search using any suitable search technology. In response to performing a search, the buyers' market system 204 may retrieve virtual representations meaningful to the search and present the virtual representations in a visual manner. For example, the GUI may display a search engine results page (SERP) that displays one or more search results, each corresponding to a different virtual representation and linking to a respective page where the user can view attributes of the item defined in the virtual representation of the item, including any media content associated with the item and the item's price, and can choose to purchase tokens corresponding to the item.

[0112] In embodiments, the buyers' market system 204 may allow users to browse virtual items offered on the platform. For example, the buyers' market system 204 may present a GUI that allows consumers to filter items by category or by other attributes. The GUI may allow users to select a link corresponding to an item, which directs the user to a page where the user can view the item's attributes defined in the virtual representation of the item, including any media content associated with the item and the item's price, and can choose to purchase tokens corresponding to the item.

[0113] In embodiments, when a consumer selects to purchase an item, the buyers' market system 204 may notify the ledger management system 104 about the purchase. The buyers' market system 204 may provide the user's public address and an identifier for the virtual representation of the selected item to the ledger management system 104. The ledger management system 104 may realize the transaction by assigning tokens from a set of tokens corresponding to the virtual representation to an account associated with the user's public address and updating the distributed ledger to indicate that ownership of the assigned tokens has changed to the user's public address. For example, the buyers' market system 204 (or the trading system 106) may identify tokens currently owned by the seller and transfer ownership of the tokens to the buyer's account. When this occurs, a copy of the token may be deposited in the user's account. For example, the tokens may be deposited in the user's digital wallet.

[0114] In some embodiments, the buyers' market system 205 can depict items as individual thumbnail images. In some of these embodiments, a simple box-style user interface element can be added to the item detail page to display item attributes, including an item description attribute, an item notes attribute, and a seller URL attribute. The item description field on the GUI can support clickable URLs that can redirect platform users to pages with more information about the product or other related pages. A product description text box can be displayed and can support links to third-party domains.

[0115] In embodiments, the buyers' market system 204 may allow users to purchase custom items. For example, a user may order a customized pizza, a piece of furniture, a flower arrangement, etc. A user may digitally build an item consisting of multiple items from multiple merchants and have the item 3D printed at a 3D printing station.

[0116] 3 illustrates an example ledger management system 104 of the tokenization platform 100, which manages one or more distributed ledgers 210 according to some embodiments of the present disclosure. In an embodiment, the ledger management system 104 includes a token generation system 302, a ledger update system 304, and a validation system 306. The token generation system 302 may be configured to generate tokens corresponding to items made available for trading and based on respective virtual representations of the items. The ledger update system 304 receives requests to update the distributed ledger 310 and updates the distributed ledger 310 accordingly. The validation system 306 receives requests to validate tokens, accounts, etc., and attempts to validate tokens or accounts based on the distributed ledger.

[0117] In embodiments, the distributed ledger 310 may be a public ledger, with N node computing devices 160 storing N respective copies of the ledger 310, each copy including at least a portion of the distributed ledger 310. In other embodiments, the distributed ledger 310 is a private ledger, where the ledger is distributed among nodes under the control of the platform 100. In embodiments, the distributed ledger 310 is a blockchain (e.g., the Ethereum blockchain conforming to the ETC protocol). Alternatively, the distributed ledger 310 may conform to other suitable protocols (e.g., Hashgraph, Byteball, Nano-Block Lattice, or IOTA). By storing tokens in the distributed ledger 310, the state of the tokens can be verified at any time by querying the ledger and trusted to be correct. Using a token approach to implementation ensures that tokens cannot be arbitrarily copied and redeemed for cash.

[0118] The distributed ledger 310 may store any suitable data related to items, users, merchants, etc. In embodiments, the distributed ledger 310 may store item-related data, which may include, but is not limited to, an item identifier, an expiration date for the item, conditions or restrictions attached to the item, a description of the item, media content associated with the item (e.g., photos, logos, videos, etc.), item documentation, customization options, available sizes, available colors, available materials, functionality options, ingredients, price, special offers or discounts related to the item, location information (e.g., where the item can be delivered / served), availability times, owner / administrator data, reviews, item type, and the like. In embodiments, the distributed ledger 310 may store user data, such as identification information (e.g., user ID, email address, name, etc.), public address, financial information (e.g., credit card information), transaction history, location data (e.g., the user's region or user's country), preferences, wish lists, user subscriptions, items belonging to the user, user connections or contacts, media content associated with the user (e.g., the user's photos or videos), a user avatar, etc. In embodiments, the distributed ledger 310 may store merchant-related data, such as merchant-related data, which may include, but is not limited to, identification information (e.g., the merchant's name, merchant ID, and / or the like), merchant contact information, experience data, location data, availability hours, reviews, media content (e.g., photos, videos, and the like), and / or any other suitable merchant-related data. The distributed ledger 310 may store additional and / or alternative data.

[0119] In embodiments, the distributed ledger 310 includes a side chain 314. The side chain 314 may refer to a shard of the distributed ledger 310 that extends from a segment (e.g., a block) of the main chain 312 of the ledger 310. In embodiments, the main chain 312 may store data related to merchants and users who have accounts (e.g., public addresses). Additionally or alternatively, the main chain 312 may store item classification data, such as item classification descriptions. In embodiments, the side chain 314 may be associated with a particular classification of items. In some of these embodiments, the side chain 314 may store virtual representations of items belonging to a respective genus or class of items and data related to those items. For example, a first side chain 314-1 may store virtual representations of shoes available on the platform 100 and any token-related data associated with those virtual representations. In embodiments, the side chain 314 may store media content used in connection with items tradeable on the platform. For example, the second side chain 314-2 may store a photograph depicting the shoes represented in the first side chain 314-1, a video clip depicting the shoes represented in the first side chain 314-1, an audio clip related to the shoes represented in the first side chain 314-1, virtual reality content depicting the shoes represented in the first side chain 314-1, augmented reality content depicting the shoes represented in the first side chain 314-1, etc. The above describes one manner of sharding a distributed ledger. The distributed ledger 310 may be sharded in any other suitable manner.

[0120] In embodiments, the token generation system 302 receives the virtual representation and generates one or more tokens corresponding to the virtual representation. In embodiments, the virtual representation includes attributes of the item, including the number of available items (i.e., the number of items available for trading). In embodiments, the number of available items indicates the number of tokens the token generation system 302 will generate for a particular virtual representation. The attributes may also include other restrictions associated with the item, such as the token's expiration date (e.g., the period for which the token is valid). The token generation system 302 may also receive initial ownership data. The initial ownership data defines the initial owner of the token. By default, the entity providing the item represented by the virtual representation (e.g., the seller of the item) is the initial owner of the token. However, initial ownership may be assigned to a different entity.

[0121] In embodiments, a token is a wrapper around an instance of a virtual representation. In some of these embodiments, the token generation system 302 may generate a token identifier that identifies the token. In scenarios where the tokens are non-fungible, the token generation system 302 may generate a unique identifier for each token corresponding to the virtual representation. The token generation system 302 may generate the token identifier using any suitable technique. For example, the token generation system 302 may implement random number generation, case generation, simple generation, and / or token bridge generation to generate a value that identifies the token. In embodiments, the token generation system 302 may digitally sign the value using a private / public key pair. The token generation system 302 may digitally sign the value that identifies the token using a private / public key pair associated with the platform 100 or a merchant. The token generation system 302 may implement any suitable digital signature algorithm, such as the Digital Signature Algorithm (DSA) developed by the National Institute of Standards and Technology, to digitally sign the value that identifies the token. In embodiments, the resulting digital signature may be used as the token identifier. For each token, the token generation system 302 may generate a token wrapper that includes the token identifier and a virtual representation of the item. In embodiments, the token generation system 302 may embed or otherwise encode a public key in the token that is used to digitally sign the token. Alternatively, the token generation system 302 may store the public key separately from the token, so that it is communicated to the token owner's account each time the token is transferred to a new owner. Upon generating a non-fungible token, the token generation system 302 may output the non-fungible token to the ledger update system 304. The wrapper may wrap multiple tokens, including fungible and non-fungible tokens.

[0122] In some embodiments, the token generation system 302 may generate fungible tokens. In these embodiments, the token generation system 302 may generate identical tokens, with each token having the same token identifier. In these embodiments, the token generation system 302 may generate a single token identifier in the manner described above and use that token identifier to generate N fungible tokens, where N is the total number of tokens. Upon generating the N fungible tokens, the token generation system 302 may output the N fungible tokens to the ledger update system 304.

[0123] In embodiments, the ledger update system 304 is configured to update and maintain one or more distributed ledgers 310. As used herein, updating and maintaining the distributed ledger 310 may refer to writing data to the distributed ledger 310. In embodiments, the ledger update system 304 may generate blocks according to a protocol followed by the distributed ledger, where the blocks contain data to be written to the distributed ledger 310. In embodiments, the ledger update system 304 may update the distributed ledger 310 by broadcasting the generated blocks to the computing nodes 160 that store the distributed ledger 310. The manner in which the computing nodes 160 determine whether to amend a received block to their local copy of the distributed ledger 310 may be defined by the protocol followed by the distributed ledger.

[0124] In embodiments, the ledger update system 304 receives the token and updates the distributed ledger 310 accordingly. In some of these embodiments, the ledger update system 304 receives the token and ownership data (e.g., the public address of the entity to which the token is to be assigned) and updates the distributed ledger 310 accordingly. For example, the ledger update system 304 may generate a block with the token embedded therein. The generated block or a subsequently generated block may include the ownership data associated with the token. The ledger update system 304 may then write the generated block(s) to the distributed ledger 310. For example, the ledger update system 304 may amend the block(s) to a copy of the distributed ledger 310 maintained on the platform 100 and / or broadcast the block(s) to computing nodes 160 that store copies of the distributed ledger 310, which in turn amend their respective copies of the distributed ledger with the broadcasted block(s). In embodiments in which the distributed ledger 310 is sharded, the ledger update system 304 may designate the sidechain 314 (e.g., item classification) to which the token corresponds. In these embodiments, generated blocks are amended to the designated sidechain 314 to indicate the existence of the token and its current ownership.

[0125] In embodiments, the ledger update system 304 receives an ownership change request requesting to change ownership of a token to another account. For example, the ledger update system 304 may receive an ownership change request in response to a token purchase, token gifting, token resale, token trading, etc. In some embodiments, the ownership change request may define the token to be transferred and the public address of the token transferee (e.g., the token recipient). In some embodiments, the ownership change request may further include the public address of the token's current owner (assuming the token has a current owner). The ledger update system 304 may receive the ownership change request and may generate a block to indicate the new owner of the implied token. The ledger update system 304 may then write the generated block(s) to the distributed ledger 310. For example, the ledger update system 304 may amend the block(s) to the distributed ledger 310 and / or broadcast the block(s) to the compute nodes 160 that store the distributed ledger 310. In embodiments in which the distributed ledger 310 is sharded, the ledger update system 304 may designate the sidechain 314 (e.g., item classification) to which the token corresponds. In these embodiments, generated blocks are amended to the designated sidechain 314 to indicate the new owner of the token.

[0126] In embodiments, the ledger update system 304 receives new or modified virtual representations and updates the distributed ledger 310 to reflect the new or modified virtual representations. For example, the ledger update system 304 may receive new virtual representations when a seller defines a new tradable item. The ledger update system 304 may receive modified virtual representations in response to a seller changing one or more attributes of a previously defined virtual representation. In embodiments, the ledger update system 304 receives the new or modified virtual representations and generates one or more blocks based on the received virtual representations. The ledger update system 304 may then write to the distributed ledger 310 based on the generated block(s). For example, the ledger update system 304 may amend the block(s) to the distributed ledger and / or broadcast the block(s) to the computing nodes 160 that store the distributed ledger. In embodiments in which the distributed ledger 310 is sharded, media content associated with the virtual representations may be stored in a separate sidechain 314. In some of these embodiments, the media content may be stored in a separate block from the virtual representation, and the block containing the virtual representation may include a reference to the block containing the corresponding media content. The ledger update system 304 may specify the sidechain 314 (e.g., item classification) to which the virtual representation corresponds and the sidechain 314 to which one or more media content blocks should correspond. In these embodiments, a generated block is amended to each designated sidechain 314 to indicate the new or modified virtual representation. The ledger update system 304 may then write the one or more generated blocks to the distributed ledger 310. For example, the ledger update system 304 may amend one or more blocks to the distributed ledger 310 and / or broadcast one or more blocks to the computing nodes 160 that store the distributed ledger 310. In embodiments in which the distributed ledger 310 is sharded, the ledger update system 304 may specify the sidechain 314 (e.g., item classification) to which the burned token corresponds.In these embodiments, the generated blocks are modified to a designated sidechain 314 to indicate the new and / or modified virtual representation(s).

[0127] In embodiments, the ledger update system 304 is further configured to “burn” tokens. Burning a token may refer to a mechanism by which a token is deemed no longer redeemable. A token may be burned when the token expires or when the token is redeemed. In embodiments, the ledger update system 304 may update the token's ownership to indicate that the token is not currently owned (e.g., owner=NULL) and / or update the token's state to indicate that the token is no longer valid. In some of these embodiments, the ledger update system 304 may generate a block indicating that the token is not currently owned or that the token's state is not valid. The ledger update system 304 may then write the generated block(s) to the distributed ledger 310. For example, the ledger update system 304 may amend the block(s) to the distributed ledger 310 and / or broadcast the block(s) to the computing nodes 160 that store the distributed ledger 310. In some embodiments, the distributed ledger 310 is sharded. In these embodiments, the ledger update system 304 may designate the sidechain 314 (e.g., item classification) to which the token corresponds. In these embodiments, generated blocks are amended to indicate the burned token to the designated sidechain 314.

[0128] Ledger update system 304 may similarly update distributed ledger 310 to reflect other data. In embodiments, ledger update system 304 may maintain and update merchant data and / or user data on distributed ledger 310. For example, ledger update system 304 may maintain a list of public addresses for valid accounts. Ledger update system 304 may update the cryptographic ledger to reflect new accounts added to platform 310, along with the public addresses of those accounts. Ledger update system 304 may also store additional or alternative merchant and user data on the distributed ledger.

[0129] In embodiments, verification system 306 verifies data stored in distributed ledger 310. In embodiments, verification system 306 may verify the validity of tokens and / or verify the ownership of tokens. Verification system 306 may also be configured to verify other types of data stored in distributed ledger 310.

[0130] In embodiments, the verification system 306 receives a token validation request. The token validation request may include the token to be validated or its token identifier. In these embodiments, the verification system 306 may determine whether the token identifier of the token to be validated is stored in the distributed ledger 310. If not stored in the distributed ledger 310, the verification system 306 may determine that the token is invalid. In some embodiments, the token validation request may further include a public key used to validate the token. In these embodiments, the verification module 306 may use the received public key to determine whether the public key corresponds to a token stored in the distributed ledger 310. In some of these embodiments, the verification system 306 uses the received public key and the private key used to encode the digital signature to determine whether the received public key is the public key used to sign the token. For example, in embodiments, the verification system 306 may attempt to decrypt the digital signature using the private key and the received public key. If the private key and the received public key allow the digital signature to be decrypted to obtain the value used to generate the token, the validation system 306 may consider the token valid and notify the requesting system of the validation.

[0131] In embodiments, verification system 306 may be configured to verify ownership of a token. In these embodiments, verification system 306 may receive the public address to be verified and the token (or an identifier thereof). In some embodiments, verification system 306 may verify that the public address corresponds to an account on platform 100. For example, verification system 306 may determine whether the public address is stored in a public address list on distributed ledger 310. If so, verification system 306 may determine whether ownership data associated with the token is currently owned by the account indicated by the received public address. If so, verification system 306 may verify ownership of the token and output the verification to the requesting system.

[0132] 4 illustrates an example trading system 106 of the tokenization platform 100, according to some embodiments of the present disclosure. In some embodiments, the trading system 106 includes a token transfer system 402 and a redemption system 404. The trading system 106 may include additional or alternative systems without departing from the scope of the present disclosure. For example, the trading system 106 may include a digital wallet system 408, an express trading system 410, a payment integration system 412, an enrollment system 414, and / or a token bridge system 416.

[0133] In embodiments, the token transfer system 402 facilitates the transfer of tokens from the token owner's account to another user's account. In embodiments, the token transfer system 402 may include a smart contract that defines the conditions under which the tokens may be transferred. In some of these embodiments, the smart contract may reside on the token such that the smart contract may be executed on a node computing device and / or from a digital wallet. In some of these embodiments, the smart contract may interface with the token transfer system 402 via a smart contract API exposed by the API system 108.

[0134] In embodiments, the token transfer system 402 receives a transfer request requesting the transfer of a token to an account. The transfer request may be received from the token holder's account or from the account of the intended recipient of the token. In embodiments, the transfer request may include the public address of the account to which the token is being transferred and may further include or indicate the token to be transferred. For example, the transfer request may include a copy of the token or a value that uniquely identifies the token (e.g., an alphanumeric string). In some embodiments, the transfer request includes the public key of the entity that digitally signed the token. In some embodiments, the transfer request may include the public address of the token owner requesting the token be transferred.

[0135] A token holder may initiate a token transfer from the token holder's digital wallet. In some embodiments, the token transfer may be performed via platform 100. In these embodiments, the token holder may initiate a token transfer by instructing their digital wallet (e.g., via the digital wallet's GUI) to send a transfer request to the token transfer system 402. In these embodiments, the token transfer system 402 may receive the transfer request and determine whether the token is a valid token and whether the owner and / or recipient's public address is valid. If the token is valid and the owner and / or recipient's public address is valid, the token transfer system 402 may transfer a copy of the token to a user device and / or account associated with the intended recipient. Upon acceptance by the recipient, the token transfer system 402 may instruct the ledger management system 104 to update the distributed ledger to indicate the change in ownership of the token so that the distributed ledger indicates that the recipient is the current owner of the token.

[0136] 7A, an illustration of the display of wallet 700 is shown. The display of wallet 700 includes multiple tokens, such as tokenized tokens 702a-702n (collectively 702), non-fungible tokens 704a-704″ (collectively 704), and fungible tokens 706a-706n (collectively 706). As can be seen, in an embodiment, the tokens are grouped by token type. The tokenized tokens 702 may include a displayed indication 703 conveying the type, and in embodiments, the amount, of particular content 705 contained within each tokenized token 702. For example, a user's bitcoin within platform 100 may be divided between a balance of fungible tokens 706a and one or more tokenized tokens 702a. Furthermore, a user's fungible bitcoins 706a may be a linked balance or separate balances (e.g., a balance equal to the amount of bitcoins transferred to platform 100 in a single transaction).

[0137] The non-fungible token 704 may include a display indicator to convey appropriate information related to the token. For example, multiple purchasable skins 704a, 704b, and work for hire 704 may be grouped, each displaying an indication, such as an image of a product. The fungible tokens 706a-706n are tokens corresponding to fungible goods. For example, the fungible tokens 706a-706n may include currencies, cryptocurrencies, commodities, etc.

[0138] In embodiments, the digital wallet is configured to send the token directly to a user device 190 or an account (e.g., an email account, a third-party messaging app account) so that the recipient of the token can accept the token. In some of these embodiments, the recipient's digital wallet, in addition to sending a copy of the token to the intended recipient, may send a transfer request to the token transfer system 402 indicating a request to transfer the token to the recipient. In these embodiments, the token transfer system 402 may determine whether the token is a valid token and whether the owner and / or recipient's public addresses are valid. If the token is valid and the owner and / or recipient's public addresses are valid, the token transfer system 402 may allow the recipient to accept the token into the recipient's respective digital wallet. Upon acceptance by the recipient, the token transfer system 402 may instruct the ledger management system 104 to update the distributed ledger 310 to indicate the change in ownership of the token so that the distributed ledger 310 indicates that the recipient is the current owner of the token.

[0139] Alternatively, in some embodiments, the token owner's digital wallet does not send a transfer request to the token transfer system 402. In these embodiments, the user device 190 of the token recipient may present a mechanism by which the token owner can accept the token. For example, the user device 190 may present a link to accept the token. Once the intended recipient accepts the token, the user device 190 (e.g., via the recipient's digital wallet instance) may send a transfer request to the token transfer system 402. In this scenario, the token transfer system 402 may determine whether the token is a valid token and whether the owner and / or recipient's public addresses are valid. If the token is valid and the owner and / or recipient's public addresses are valid, the token transfer system 402 may instruct the ledger management system 104 to update the distributed ledger to indicate the change in ownership of the token so that the distributed ledger indicates that the recipient is the current owner of the token.

[0140] As described above, in response to a transfer request, the token transfer system 402 may determine whether the token is a valid token and whether the owner's and / or recipient's public address is valid. In embodiments, the token may be validated using a public key associated with the token. For example, the token transfer system 402 may provide the token (or an indicator thereof) and the public key indicated in the transfer request to the ledger management system 104. The ledger management system 104 may determine whether the token identifier is stored in the distributed ledger and, if so, may verify that the public key provided with the transfer request is the public key used to digitally sign the token. In embodiments, the token transfer system 402 may use the public address to verify the identity of the recipient and / or token owner wishing to transfer the token. In some of these embodiments, the token transfer system 402 may provide the recipient's public address and / or the token owner's public address to the ledger management system 104, which may in turn look up the respective public addresses to verify that the public addresses are stored in the distributed ledger. In response to determining that the token is valid and that the token owner's and / or recipient's public address is valid, the token transfer system 402 may authorize the transfer of the token and may instruct the ledger management system 104 to update the distributed ledger to indicate the change in ownership of the token, such that the distributed ledger indicates that the recipient is the current owner of the token.

[0141] In embodiments, the redemption system 404 enables a token owner to redeem a token. The redemption system 404 may receive a request to redeem a token (or a “redemption request”). The redemption request may include the token or an identifier for the token (e.g., an alphanumeric string) and may include the public address of the user seeking to redeem the token. In embodiments, the redemption request may further include a public key used to digitally sign the token. In response to receiving the redemption request, the redemption system 404 may provide the token, the public address of the user seeking to redeem the token, and the public key used to digitally sign the token to the ledger management system 104. The ledger management system 104 may then validate or reject the token / public address combination. The ledger management system 104 may reject the combination if the token is not a valid token and / or if the user is not the listed owner of the token. The ledger management system 104 may validate the token / public address combination if the token is deemed valid and the requesting user is deemed the owner of the token.

[0142] In response to verifying the token / public address combination, the redemption system 406 can execute a workflow corresponding to the virtual representation to which the redeemed token corresponds. For example, in some scenarios, a user may be redeeming a token corresponding to a digital item (e.g., a gift card, an MP3, a movie, a digital photo). In these scenarios, the redemption system 404 may determine a workflow for redeeming the digital item. For example, the redemption system 404 may request an email address from the user or look up the user's email address from the distributed ledger. In this example, the redemption system 404 may email a link to the user's email account to download the digital item or attach a copy of the digital item to an email sent to the user's email account. In another scenario, a user may redeem a token corresponding to a physical item (e.g., clothing, food, electronics, etc.) or a physical service (e.g., maid services). In the case of a physical item, the redemption system 404 may determine a workflow for redeeming the physical item. For example, the redemption system 404 may present the user with a GUI that allows the user to enter shipping information. Alternatively, the redemption system 404 may retrieve the user's shipping information, for example, from a distributed ledger or a user database. The redemption system 404 may then initiate the shipment of the physical goods. For example, the redemption system 404 (or a logistics system) may send a shipping request indicating the shipping information to a warehouse that handles the shipment of the goods. The above are examples of how tokens may be redeemed.

[0143] The redemption system 404 can execute additional or alternative workflows to process the redemption of tokens. For example, in some scenarios, the initial buyer of tokens may not have specified certain parameters of the item required to fulfill the transaction. For example, if the item is clothing, the initial buyer may not have specified the size and / or color of the item. In another example, if the item is food, the initial buyer may not have specified side orders, toppings, drink selections, etc. If the item is an experience, such as an airline ticket or hotel reservation, the initial buyer may not have specified the dates of travel. In these scenarios, the exchange system 404 may present a GUI that allows the exchanger of tokens to specify the necessary parameters and specify the transaction. In response to receiving the parameters, the redemption system 404 may attribute these parameters to an instance of a virtual representation or other appropriate data structure corresponding to the fulfillment of the transaction (e.g., a delivery order, a purchase order, etc.) so that the transaction may be fulfilled.

[0144] In embodiments, the transaction system 106 includes a digital wallet system 408 that supports digital wallets. The digital wallets may be tokens owned by the owner of an account associated with the digital wallet and may provide a graphical user interface through which users can view, redeem, trade, transfer, gift, deposit, withdraw, or otherwise transact with the tokens. In embodiments, the digital wallet system 408 provides an instant sell capability through which users can agree to sell tokens corresponding to items. For example, the instant sell feature may allow a user to sell an item at 90% of the floor price. In some embodiments, other users may be able to view some or all of the virtual representation instances owned by the account owner, subject to the user's privacy settings. A user may choose to hide or make private individual or all virtual representations.

[0145] In some embodiments, platform 100 and / or a user's digital wallet may provide visual indications that may be associated with a token when it is transferred to another person. For example, visual indicators that may be associated with a token may include emojis, images, GIFs, videos, etc. These visual indicators may be used by a user when transferring a token to another user. For example, if a token corresponds to a bouquet of flowers and the visual indicator is a flower emoji, the user may send the token in a message using the flower emoji. In this example, the user may access the token in the digital wallet (e.g., via a native application on the user device 190) and select an option to send the token to a recipient. The user may identify the recipient (e.g., select from a list of contacts) and be provided with an opportunity to enter a message. The client application (e.g., the digital wallet) may present a keyboard including a flower emoji, where the flower emoji represents the token. In response to the user selecting the flower emoji and subsequently "sending" the token, the digital wallet application may initiate sending of a message including the token / flower emoji. In this example, the digital wallet may also send a transfer request to the token transfer system 402 indicating that the transferor user has requested a transfer of the token. The transfer request may include a copy of the token and the public address of the transferor. In embodiments, the transfer request may further include the public address or other indicator of the intended recipient of the token (e.g., email address, phone number, user ID, etc.).

[0146] In embodiments, the trading system 106 includes an express trading system 410 that allows users to trade one or more assets without exchanging money. In these embodiments, the express trading system 410 provides a mechanism by which users can securely trade tokens, with each token representing a different item. In an exemplary operation, a first user may make a trade offer to a second user in a smart contract to exchange one or more tokens for one or more tokens in return. The second user may accept by transferring the requested virtual assets. The smart contract then marks the trade as complete. In embodiments, the express trade system 410 may provide a GUI that allows users to view an inventory of tokens, create offers, accept offers, and / or cancel offers.

[0147] In embodiments, the transaction system 106 includes a payment integration system 412. The payment integration system 412 allows users to purchase tokens corresponding to items. The payment integration system 412 may accept credit cards, different forms of currency, and / or cryptocurrencies.

[0148] In some embodiments, the transaction system 106 includes a subscription system 414. In these embodiments, via the subscription system 414, users can subscribe to services to receive items for consumption on a regular basis.

[0149] In embodiments, the trading system 106 includes a ledger bridge system 416. The ledger bridge system 416 provides a framework for securing or locking down original virtual assets in a first distributed ledger system (or any currency holder, including a traditional bank) and creating a tradable replica in a second distributed ledger system. In this manner, users may fund their accounts on the tokenization platform 100 with different currencies and different transfer methods and can then engage in transactions (e.g., trading, gifting, or redemption) using the different currencies. In some embodiments, the distributed ledger bridge system 416 provides escrow functionality between distributed ledger systems (e.g., ledger systems separate and distinct from the platform's 100 distributed ledger 310). In embodiments, the ledger bridge system 416 or a digital wallet may provide a token deposit GUI and / or a token withdrawal GUI.

[0150] In embodiments, the ledger bridge system 416 allows users to fund their accounts with one or more external currencies. For example, users may fund their accounts using Bitcoin, Ethereum coins, other suitable cryptocurrencies, and / or traditional currencies (e.g., U.S. dollars, British pounds, euros, Chinese yuan, Japanese yen, and / or the like). In the case of cryptocurrencies, users may facilitate the transfer of cryptocurrencies from external accounts using, for example, an unaffiliated digital wallet that stores the user's cryptocurrency. In the case of traditional currencies, users may transfer funds to their accounts using, for example, a credit card, direct transfer, ACH transfer, etc. In some embodiments, when a user transfers funds (cryptocurrency or traditional currency) to an account on the tokenization platform 110 (this may be referred to as a “funding transaction”), the ledger bridge system 416 may generate a record corresponding to the funding transaction, may provide the record to the ledger management system 104, and may update the distributed ledger to reflect the funding transaction. The record may indicate the account to which the funds were transferred, the account to which the funds were transferred, the amount transferred, the date and time of the transfer, and / or any other suitable data.

[0151] Once the account is funded, the user may then use the transferred funds to participate in any transaction on the tokenization platform 100. In some embodiments, at least a subset of the transferred funds are tokenized in a manner that conforms to a protocol supported by the tokenization platform 100 and / or its corresponding distributed ledger 312. In embodiments, the ledger bridge system 416 may tokenize one or more crypto coins (e.g., Bitcoin), any fraction of a crypto coin, or any amount of currency in response to a request corresponding to the user. A request to tokenize funds may be an explicit request or an implicit request. An explicit request may refer to when a user specifically requests the tokenization of an amount of currency. An implicit request may refer to when a user makes a transaction on the tokenization platform 100 that involves transferred funds in the user's account and requires that at least a portion of those funds be tokenized to facilitate the transaction (e.g., when the user purchases an item and chooses to pay for the item using a portion of the transferred funds in the user's account). Whether the request is implicit or explicit, the ledger bridge system 416 may tokenize an amount of currency.

[0152] In some of these embodiments, the ledger bridge system 416 tokenizes an amount of currency by minting a tokenized token that “wraps” the amount of currency. A tokenized token may refer to a non-fungible token having attributes that define the type of currency and the amount of currency represented by the coin (e.g., the amount of Bitcoin, Ethereum, dollars, pounds, etc.). In some of these embodiments, a tokenized token may refer to a non-fungible token having a set of attributes that define the characteristics of such tokens, in addition to having a set of fungible and / or non-fungible tokens that represent the digital currency balance(s) encapsulated within the tokenized token and / or other digital item(s). Furthermore, a tokenized token may include business rules that govern redemption, transfer, and other lifecycle mechanisms of the tokenized token. In some embodiments, the ledger bridge system 416 mints a new token by requesting the creation of a new token by the token generation system 302. The ledger bridge system 416 may provide the type of currency, the amount of currency, and ownership data (e.g., the account to which the new tokenized token will belong) to the token generation system 302. In response, the token generation system 302 generates the tokenized token, e.g., in a manner described above. In this manner, the token generation system 302 treats currency as an “item.” In this manner, tokenized tokens may be exchanged (e.g., with other tokenized tokens or tokenized items), gifted, and / or redeemed. In some embodiments, the types of transactions in which a tokenized token can participate may be limited. For example, a tokenized token representing a volatile currency may be restricted from being exchanged, but may be redeemed or gifted.

[0153] In embodiments, the ledger bridge system 416 further generates a visual indication corresponding to the tokenized token as part of the minting process. In some embodiments, the visual indication is a digital sticker (or “sticker”). For example, in some embodiments, the sticker may depict a symbol representing an amount and currency (e.g., a sticker representing the tokenization of $5 may depict “$5,” or a sticker representing the tokenization of one-tenth of a Bitcoin may depict “B5”). In this manner, the sticker may appear in the wallet of the owner of the tokenized token. As discussed, the visual indicator may be used to communicate to a user which tokenized tokens they own. Additionally, in some embodiments, the visual indicator may be used to transfer the tokenized token to another party (e.g., via text message, messaging application, email, etc.), as described elsewhere in this disclosure.

[0154] In some embodiments, the ledger bridge system 416 may instantiate (or request the instantiation of) a smart contract corresponding to a tokenized token as part of the minting process. In these embodiments, the smart contract may define one or more basic functions that govern the lifecycle mechanics of the tokenized token, such as ownership transfer and / or redemption logic. The basic functionality may include the ability to change ownership of the tokenized token, the types of transactions in which the tokenized token may be used (e.g., purchase, gift, exchange, redemption for cash, etc.), etc. When a new tokenized token is minted, the ledger bridge system 416 may instantiate an instance of a smart contract corresponding to the newly minted token. An instance of a smart contract may be executed each time a tokenized token is involved in a transfer (e.g., exchange, gift, or redemption). For example, each time a tokenized token owner requests a transfer of the tokenized token, an instance of a smart contract may be engaged by the request, and the smart contract instance may disallow or facilitate the transfer depending on the request and the content of the smart contract.

[0155] Once a tokenized token is minted, the funds represented by the tokenized token may be “escrowed” by the ledger bridge system 416. In this way, a user is prevented from withdrawing the funds from their account until the tokenized token is redeemed. In some embodiments, the ledger bridge system 416 may transfer the funds corresponding to the tokenized token from the user's account to a designated escrow account. Alternatively, the ledger bridge system 416 may freeze the funds corresponding to the tokenized token so that the funds cannot be transferred by the user until the tokenized token is redeemed. Once the tokenized token is redeemed, the funds represented by the tokenized token are released from escrow and credited to the redeeming user's account, and the tokenized token may be destroyed (also referred to as “voided”).

[0156] In embodiments, the ledger bridge system 416 updates or initiates an update to the distributed ledger. The distributed ledger may be updated at many different occurrences. As discussed, in embodiments, the distributed ledger may be updated when a user initially funds an account. In embodiments, the ledger bridge system 416 updates (or initiates an update to) the distributed ledger when a new tokenized token is minted. In these embodiments, the distributed ledger is updated to reflect the existence of the new tokenized token and the ownership of that token. In embodiments, the ledger bridge system 416 updates (or initiates an update to) the distributed ledger with instances of smart contracts corresponding to the tokenized token. In embodiments, the ledger bridge system 416 may update (or initiate an update to) the distributed ledger whenever a tokenized token is transferred. In these embodiments, the distributed ledger may be updated to reflect the new owner of the tokenized token. In embodiments, the ledger bridge system 416 may update (or initiate an update to) the distributed ledger when a tokenized token is redeemed and subsequently destroyed. In these embodiments, the distributed ledger may be updated to reflect that the tokenized token is no longer valid, the account that redeemed the token, and / or when the token was redeemed.

[0157] 5 illustrates an intelligence and automation system 110 according to some embodiments of the present disclosure. In an embodiment, a platform includes the intelligence and automation system 110. The intelligence and automation system 110 may include a machine learning system 502, an artificial intelligence system 504, a recommendation engine 506, a service matching engine 508, an advertising system 508, and / or a notification system 510.

[0158] In embodiments, the machine learning system 502 may train a machine learning model based on training data. Examples of machine learning may include various types of neural networks, regression-based models, hidden Markov models, scoring models, etc. The machine learning system 502 may train the model in a supervised, semi-supervised, or unsupervised manner. Training may be performed using training data that may be collected or generated for training purposes. The machine-learned model may be stored in a model data store.

[0159] In one example, the machine learning system 502 may be configured to train a gift prediction model. The gift prediction model (or predictive model) may be a model that receives recipient attributes (e.g., a profile associated with an intended recipient) and / or item attributes of one or more items that may be provided as gifts and outputs one or more predictions regarding sending gift tokens to that particular consumer. Examples of predictions may be whether to send a gift to that user, gifts that the user would rate, etc. In an embodiment, the machine learning system 502 trains the model based on training data. In an embodiment, the machine learning system 502 may receive vectors that include user data (e.g., transaction history, preferences, wishlist virtual assets, etc.), virtual asset data (e.g., price, color, fabric, etc.), and outcomes (e.g., redemption, exchange, etc.). Each vector may correspond to a respective outcome and attributes of a respective user and a respective item. The machine learning system 502 takes the vectors and generates a predictive model based thereon.

[0160] In an embodiment, the machine learning system 502 may analyze the characteristics of users participating in transactions, characteristics of the transactions (e.g., the type of transaction (e.g., purchase, loan, sale, etc.), the size of the transaction (e.g., etc.), and the outcome of the transaction indicating whether the transaction was successful or unsuccessful (e.g., whether the buyer paid for the item after purchase, whether the borrower paid off the loan or defaulted on the loan, whether the purchased item was delivered and in satisfactory condition, etc.). The training dataset may be based on transactions facilitated by the platform and / or transactions generated by experts.

[0161] In embodiments, the machine learning system 502 may store the predictive model in a model data store. In embodiments, the machine learning system 502 may be further configured to update the model based on captured results, also referred to as "reinforcement learning." In embodiments, the machine learning system may receive a set of circumstances (e.g., item attributes and user attributes) that led to the prediction and an outcome associated with the action (e.g., item redemption, item exchange, item refund), and may update the model according to the feedback. As used herein, machine learning techniques that may be utilized by the machine learning system include, but are not limited to, decision trees, K-nearest neighbors, linear regression, K-means clustering, deep learning neural networks, random forests, logistic regression, naive Bayes, learning vector clustering, support vector machines, linear discriminant analysis, boosting, principal component analysis, and hybrid approaches.

[0162] In embodiments, the artificial intelligence (AI) system 504 utilizes machine-learned models to make predictions or classifications regarding purchase, gift, or other e-commerce outcomes with respect to user data and asset data. Example predictions include whether a user will purchase an item, whether a user will exchange a gifted item, redemption options such as delivery timing and location, and the like. For example, the AI ​​system 504 may utilize a gift prediction model to make predictions regarding whether a recipient of a particular item will like the gift, return the gift, or exchange the gift.

[0163] In embodiments, the recommendation system 506 may be configured to provide recommendations for items to the user. The recommendation system 506 may request recommendations from the AI ​​system 504 based on attributes of the user. The AI ​​system 504 may output a set of recommendations, and the recommendation system 506 may provide the recommendations to the user or another party. For example, the recommendation system 506 may provide recommendations for items to purchase to the user based on the user's purchasing history.

[0164] In embodiments, the advertising system 508 is configured to determine advertisements to display to the user, the advertisements relating to items offered for trade on the platform. In embodiments, the advertising system 508 may present discounts, promotions, etc. to the user.

[0165] In embodiments, service matching system 510 is configured to match consumers with service providers for user-selected services. In these embodiments, a user may request a service, and service matching system 510 may identify the service provider best suited to provide the service. For example, service matching system 510 may match service seekers with service providers based on price, availability, location, etc.

[0166] 6 illustrates an intelligence and automation system 110 according to some embodiments of the present disclosure. In embodiments, analytics and reporting system 112 is configured to capture and report analytics related to various aspects of e-commerce platform 100. In embodiments, analytics and reporting system 112 may include analytics system 602, reporting system 604, and / or regulatory asset system 606. In embodiments, analytics and reporting system 112 may provide an analytics interface that allows users to access analytics and reporting system 112.

[0167] In embodiments, the analytics system 602 may track and analyze data related to, but not limited to, consumer data, item data, seller, manufacturer, or provider data, user behavior (e.g., purchasing behavior, telemetry, etc.), and transaction events (e.g., when an item was purchased, how an item was purchased, how an item was transferred, etc.).

[0168] In embodiments, reporting system 604 reports the analysis obtained by analytics system 602 to one or more interested parties. Stakeholders may access reporting system 604 and / or may subscribe to receive analytics reports. Reporting system 604 may be configured to generate reports based on the collected analytics and provide the reports to interested parties. In embodiments, the regulator GUI may then enable regulators to access platform 100. For example, regulators may access the platform to track and monitor regulated items, such as 3D printed firearms.

[0169] In an embodiment, the analytics and reporting system 112 includes a regulated asset system 606. In an embodiment, the regulated asset system 606 is configured to manage regulated items. For example, the regulated asset system 606 may manage access to weapons or firearms, pharmaceuticals, alcohol, tobacco products, food, event / venue admission, airline tickets, etc. In an embodiment, the regulated asset system 606 may track and monitor transactions involving regulated items and may notify certain regulatory agencies based on the transaction and corresponding workflow. In a non-limiting example, a token may be used to track a 3D printed firearm, where the item purchased would be a model used to print the firearm.

[0170] Referring back to FIG. 1 , in embodiments, platform 100 includes a virtual world presence system 114 for representing tokenized physical-world items within a virtual world environment. In some embodiments, the virtual world environment may depict a virtual world avatar. The virtual world avatar may represent a user (e.g., a potential buyer) and may interact with virtual items within the virtual world environment. A user may “shop” by controlling the virtual world avatar in a virtual world store. For example, the virtual world avatar may try on a virtual representation of a tokenized physical-world hat in a virtual world fitting room. In some embodiments, the virtual world presence system may include a virtual reality system that provides a framework for displaying the virtual world environment. In embodiments, the virtual world presence system may also include a virtual asset display system that displays items associated with a user, including, but not limited to, items owned by the user, items stored by the user, items desired by the user, etc. These items may be publicly displayed to other users or individually or collectively hidden from other users. In some embodiments, the virtual asset display system may determine the set of tokens owned by a user to determine the items the user owns or possesses.

[0171] In embodiments, the virtual world presence system 114 may include a content sharing system that allows users to share content related to virtual assets to a content platform. The content sharing system allows users to share content related to virtual assets that they own, have in their possession, or desire. Users may obtain additional information about the virtual asset or request to purchase, rent, borrow, trade, etc. The shared content may include data from the virtual world presence system. For example, a user may share a video of the user's associated virtual world avatar eating a virtual pizza at a virtual pizza place.

[0172] 8, the tokenization platform 100 may support a number of different applications and / or provide a number of different services. For example, the platform 100 may support a secured loan application, an authentication service, a "mystery box" application, a casino gaming service, and a video game streaming service.

[0173] In embodiments, platform 100 includes a collateral management system 802. In embodiments, collateral management system 802 enables borrowers to provide collateral and request loans. In some of these embodiments, a user wishing to borrow money can bring a collateral item (e.g., collectibles, jewelry, firearms, precious metals, etc.) to a facility affiliated with or otherwise supported by platform 100. At the facility, a facility employee may inventory the collateral item using an interface provided by collateral management system 802, which may include requesting an item identifier for the collateral item, associating the item identifier with the user's (i.e., the owner of the collateral item's) account, taking a high-resolution photo of the collateral item, weighing the collateral item using a scale, entering a description of the collateral item, a collateral item valuation, etc. Once inventoried, collateral management system 802 can create a virtual item representing the collateral item and subsequently generate a non-fungible token (which may be referred to as a "collateral token") corresponding to the virtual item. For example, collateral management system 802 may request ledger management system 104 to generate the virtual item and the collateral token. Once the collateral token is generated, the ledger management system 104 may update the distributed ledger to reflect the new collateral token and the borrower's ownership of the collateral token. The collateral token may then appear in the borrower's digital wallet. In some embodiments, the collateral token may be represented by a visual indicator in the digital wallet. The collateral item corresponding to the collateral token may be stored at the facility until the collateral token is redeemed. Upon redemption, the redeeming user (the borrower or the transferee of the collateral token) may pick up the collateral item from the facility, or the collateral item may be shipped thereto.

[0174] In embodiments, the collateral management system 802 may enable borrowers to seek loans using collateral tokens. In embodiments, the collateral management system 802 may provide a marketplace (e.g., accessible via a graphical user interface) where borrowers can request a loan amount and provide the collateral tokens as collateral. Lenders (who have accounts with the tokenization platform 100) can then make loan offers to borrowers via the marketplace. In exemplary embodiments, the loan offers may specify the loan amount, interest rate, and loan length. The loan offers may also include additional terms. For example, the loan offers may indicate whether the loan can be sold to another lender, and if so, the payoff amount due to the original lender. The borrower can review the loan offers and ultimately decide which loan offers to accept.

[0175] If the borrower accepts the offer, the collateral management system 802 may instantiate an instance of a loan smart contract commemorating the term of the loan and may escrow the collateral token (e.g., no one can redeem or transfer the collateral token without complying with the smart contract). When escrowing the collateral token, the collateral management system 802 (or loan smart contract) may deposit the collateral token in an escrow account such that no party to the transaction has ownership rights to the collateral token while it is in the escrow account. Such an action locks the collateral token until the loan is paid off in full or the underlying items are liquidated. In embodiments, the loan smart contract may indicate the lender, borrower, locked collateral token (and its address), loan amount, payment schedule, whether the loan is transferable, when the loan is considered defaulted, ownership of the collateral token upon default, etc. The ledger management system 104 may update the distributed ledger to reflect the loan smart contract.

[0176] Once an instance of the smart contract is instantiated, the borrower must begin repaying the loan according to the loan schedule. It is understood that the loan schedule may call for a single lump sum payment by a predetermined time or may call for multiple payments to be made at predetermined intervals. In embodiments, the borrower can make payments to the lender via his or her digital wallet. In these embodiments, the borrower may transfer funds from a bank, credit card, digital wallet holding other currency, etc. The borrower may then transfer those funds to the lender via the digital wallet. In some embodiments, the ledger bridge system 416 facilitates the transfer of funds from the borrower's account to the lender's account.

[0177] In embodiments, the collateral management system 802 may deploy a listening thread corresponding to an instance of a smart contract managing a loan. The listening thread may listen for payments by borrowers defined in the instance of the smart contract. When a payment is made, the listening thread may notify the ledger management system 104, which updates the distributed ledger to reflect the payment. During this update, the instance of the smart contract managing the loan is provided with a notification indicating a payment event, which allows the smart contract to determine whether the loan has been fully repaid. If the loan has been fully repaid, the smart contract releases the collateral token to the borrower and terminates the smart contract. If the loan amount has not been repaid, the terms of the smart contract (e.g., loan amount and next payment) may be updated based on the payment. If the listening thread does not detect receipt of payment before the payment due date, the listening thread may notify the ledger management system 104 of the missed payment. In response to the notification, the ledger management system 104 may update the distributed ledger to reflect the non-payment, which may allow the smart contract to determine whether the loan is in default according to the terms of the contract. If the loan is determined to be in default, the smart contract causes ownership of the collateral token to be transferred to a party designated by the smart contract (e.g., the lender). Once this occurs, the lender becomes the owner of the collateral token and may redeem, sell, gift, or exchange the collateral token.

[0178] In embodiments, the collateral management system 802 may provide a marketplace for loans that can be purchased or transferred. The marketplace may offer the loan's repayment amount, the loan's value (e.g., the amount recovered at full payment), the loan's payment history (e.g., whether the borrower is making payments or has missed payments), the collateral item securing the loan, the price to purchase the loan, etc. In some embodiments, a potential lender can choose to purchase the loan from the current lender. In these embodiments, purchasing the loan causes the collateral management system 802 to terminate the current smart contract and instantiate a new smart contract to reflect the new owner, or adjust the smart contract to direct payments to the new lender's account and to designate the new lender as the destination of the collateral tokens in the event of the borrower defaulting. Additionally, or instead, a borrower can use the marketplace to seek better loan terms. Assuming the loan is transferable, the borrower can list the loan on a marketplace where potential lenders can view the borrower's payment history, remaining loan balance, loan repayments, and collateral. Potential lenders can offer loans to borrowers with respective loan terms. The borrower can accept the loan offer. In response to the borrower accepting the loan offer, the new lender must transfer the loan payoff amount to the previous lender, which causes the collateral management system 802 to terminate the current smart contract and instantiate a new instance of the smart contract according to the newly accepted terms of the loan offer.

[0179] In embodiments, platform 100 includes an authentication system 804. Authentication system 804 may provide authentication and / or appraisal support services on behalf of platform 100. In some embodiments, authentication system 804 may be used to authenticate items offered for sale or offered as pledge. Additionally or alternatively, authentication system 804 may be used to obtain appraisals for items offered for sale or offered as pledge.

[0180] In some embodiments, the authentication system 804 presents a portal that allows a user (e.g., a merchant or an employee of an establishment that holds an item) to upload a virtual representation of an item. The user may provide the item's classification (e.g., baseball card, vintage clothing, jewelry, fine art, etc.) and one or more high-resolution photos of the virtual item, a 3D representation of the item, the item's dimensions, the item's weight, and / or the like. The authentication system 804 may allow domain-specific experts to sign up as authenticators / appraisers so that they can authenticate and / or appraise items categorized in their area of ​​expertise. For example, a sports memorabilia expert may be permitted to authenticate baseball cards and memorabilia, but not jewelry or fine art. In some embodiments, authenticators may be evaluated within their area of ​​expertise and for subareas within that area of ​​expertise (e.g., within the general category of sports memorabilia, an expert may be evaluated for their knowledge of baseball memorabilia, basketball memorabilia, football memorabilia, etc.). When a new item is entered into the portal, domain-specific experts can bid on the appraisal / authentication job, with the bid indicating the terms (e.g., price) under which the expert will perform the appraisal / authentication job. The user can then select one or more experts based on their respective bids and / or their ratings. Alternatively, the authentication system 804 may select one or more experts based on their respective bids and / or their ratings. Once an expert wins the bid, the expert performs the authentication and / or appraisal based on information uploaded by the user (e.g., one or more high-resolution photos of the virtual item, a 3D representation of the item, the item's dimensions, the item's weight, etc.). The expert may provide an appraisal value and / or determination indicating the item's authenticity. The authentication system 804 may include the expert's appraisal value and / or authenticity determination in the virtual representation of the virtual item, and in some embodiments, the authentication system 804 may update the distributed ledger with the expert's appraisal value and / or authenticity determination.As can be appreciated, the appraisal and / or authenticity determination may result in the item being maintained on or removed from the platform, or may affect the ability to use the item to secure a loan.

[0181] In some embodiments, authentication system 804 requests the expert to provide an appraisal / authentication note indicating the reasons for the expert's determination. In providing an appraisal and / or providing a determination of authenticity, the expert provides one or more reasons for their findings. For example, in determining that a particular shoe is a knock-off, the expert may indicate in their notes that the stitching on the shoe indicates a knock-off. Authentication system 804 may include the expert's appraisal / authenticity note in the virtual representation of the virtual item, and in some embodiments, authentication system 804 may update the distributed ledger with the expert's appraisal / authenticity note.

[0182] In embodiments, the expert's authentication decision, as well as the authentication notes, may be used by machine learning system 502 (FIG. 5) to train one or more models that can determine whether an item is likely to be fake. In these embodiments, the models may be trained with images, weights, dimensions, and / or other features of items deemed to be fake. Authentication system 804 (via artificial intelligence system 804) can leverage these models to determine whether a new item is likely to be fake. If the model classifies the item as likely to be fake, authentication system 804 may include that decision in the virtual representation of the virtual item, and in some embodiments, authentication system 804 may update the distributed ledger with a determination that the item is likely to be fake. If the model cannot classify the item as likely to be fake, authentication system 804 may list the item on a portal so that an expert can assess the item's authenticity. Note that in embodiments, while a model may classify an item as likely to be fake, only an expert may authenticate the item, as counterfeiters may adapt and improve the quality of counterfeit items to trick the model into issuing false authentications.

[0183] In some embodiments, the collateral management system 802, the authentication system 804, and the ledger management system 104 may be configured to support a securitized decentralized loan process. An example implementation of a securitized decentralized loan process is described throughout this disclosure, including with reference to Figure XXX.

[0184] In embodiments, the tokenization platform 100 includes a mystery box system 806 that supports a mystery box game. In embodiments, a "mystery box" may refer to a set of tokens that can potentially be won by a player, with each token representing a different item that can be redeemed using the token. In embodiments, each token may have a different probability of being selected. In some embodiments, each token may be assigned a range of numbers, with each token's range of numbers reflecting its probability of being won by a player. For example, if there are three tokens and the first token has a 10% chance of winning, the second token a 20% chance of winning, the third token a 30% chance of winning, and the third token a 40% chance of not winning, the first token may be assigned numbers 1-10, the second token 11-30, and the third token 31-60. In this example, the range of values ​​that can be selected would be 1-100. A player may pay for a chance to win an item in a mystery box. In some embodiments, the winning odds of each token and the items represented by the tokens are depicted in relation to the mystery box, thus informing players about their chances of winning various items.

[0185] In response to receiving a payment from the player, the mystery box system 806 may generate a random number bounded by the entire range of values ​​for the box (e.g., 1 to 100). The mystery box system 806 may then determine which, if any, tokens have been won by the player based on the random number. For example, a mystery box may be jewelry-themed, whereby the mystery box includes a first token representing a diamond ring, a second token representing a cubic zirconia ring, and eight tokens, each representing a $25 gift card to be used at a particular jewelry store (e.g., the jewelry store that provided the ring). In this example, the first token may have a 0.1% chance of winning, the second token a 4.9% chance of winning, and each gift card a 10% chance, whereby the player may have a 15% chance of not winning any prize. In this example, the range of numbers may be 1 to 1000, with the first token corresponding to the number 1, the second token corresponding to the range 2 to 50, and the third through eighth tokens having a set range of 51 to 850. In this example, the price to play may be set by the jewelry store, such that the gift cards are thought of as a mechanism for driving traffic to the jewelry store. Note that in the above example, the ranges of tokens are sequential, but the ranges do not have to be sequential and can be slotted in any suitable manner.

[0186] In embodiments, the mystery box system 806 may transfer tokens to the winning player's account in response to the player winning a prize from a mystery box. In these embodiments, the earned tokens may appear in the player's digital wallet. Alternatively, the mystery box system 806 may deliver the earned tokens to the user via an electronic message (e.g., a text message, a messaging app message, an email, etc.). As described below, in some embodiments, the mystery box system 806 provides services to brick-and-mortar casinos where mystery box games are implemented on physical devices. In these embodiments, the mystery box system 806 may print out a ticket bearing the winning ticket's token identifier (e.g., a QR code).

[0187] In embodiments, the mystery box system 806 may allow a player to select a mystery box to play from multiple available mystery boxes, each of which may have a respective theme. For example, a first mystery box may be art-themed such that the mystery box contains tokens corresponding to art-related items (e.g., art, art-related products, art-related services (e.g., commissioned paintings), etc.), a second box may contain movie and television-related items (e.g., popular movie and / or television program memorabilia, movie and / or television program DVD or download codes, theater gift certificates, etc.), and a third box may be sports-themed such that the third box contains tokens corresponding to sports-related items corresponding to particular teams. For example, a fourth box may be gaming-themed such that the fourth box contains tokens corresponding to gaming-related items (e.g., video game systems, video games, gift items, etc.). A fifth box may be music-themed, and may contain tokens related to items corresponding to a particular band or artist (e.g., autographed concert posters, band or artist memorabilia, concert tickets, album or song download codes, etc.) In this way, players can choose to play for prizes that are attractive to them.

[0188] In embodiments, a mystery box may contain tokens corresponding to replenishable and / or non-replenishable items. Refillable items are items that can be replenished in the mystery box when a player acquires a token representing the item. For example, gift certificates, movie tickets, sports game tickets, DVDs, electronics, video games, replica jerseys, and most clothing items are replenishable, while items such as watches, fine jewelry, game wear, sportswear, autographed memorabilia, limited edition shoes, and original artwork are examples of non-replenishable items. In some embodiments, the party providing the mystery box may specify exchange items of similar value for the non-replenishable items in the mystery box. Thus, when a non-replenishable item is obtained from the mystery box, it can be exchanged for one of the specified exchange items. In some of these embodiments, the mystery box may be arranged according to a "recipe." The recipe specifies two or more tiers of items in the mystery box and, for each tier, the odds for obtaining an item from that tier. In these embodiments, the mystery box provider may provide a list of items belonging to each tier. For example, the highest tier (e.g., the tier with the lowest odds) may contain high-value non-replenishable items, while lower tiers may contain various levels of replenishable items. Each item in the recipe may be tokenized, such that a token is reserved for use in the mystery box. Each time an item from a tier is won by a player, the mystery box system 806 may replace the token representing the item with another token from the same tier as the one won. In this way, the price to play the mystery box and the odds associated with each item in the mystery box do not change when a non-replenishable item is won from the mystery box.

[0189] In embodiments, each mystery box is governed by a smart contract. The smart contract may define different items or tiers of items, and for each item or each tier of items, the odds for winning each item. When a new mystery box is created, the mystery box system 806 may instantiate a new smart contract corresponding to the new mystery box. The smart contract instance may define the items or tiers of items in the new mystery box, the odds for each item (or tier of items), the token identifiers for each of the items in the mystery box (or exchange items that may be included in the mystery box), and the price for playing the mystery box. In embodiments in which items are not exchanged in the mystery box, the smart contract may further define how the odds of an item or the price of the game may be adjusted when a particular item is depleted. For example, if the most valuable item in the mystery box is won, the price to play the game may be lowered and / or the odds of winning the remaining items may be adjusted.

[0190] The mystery box system 806 may offer the mystery box game in a variety of different ways. In embodiments, the mystery box system 806 may offer the mystery box game via the tokenization platform 100, thereby allowing users of the tokenization platform 100 to play the mystery box game on a website or application provided by the tokenization platform 100. Additionally, or alternatively, the mystery box system 806 may offer the mystery box game to users via a third-party website or application. In these embodiments, the third-party website or application may access the mystery box system 806 via the API system 108 of the tokenization platform 100.

[0191] In some embodiments, the mystery box system 806 may support casino-style machines, allowing players to play mystery box games at physical machines located, for example, in a casino or any other suitable brick-and-mortar location. In these embodiments, items may be located at the brick-and-mortar store where the physical device is located, allowing players to exchange tokens at the brick-and-mortar store once they have acquired an item from the mystery box. In these embodiments, the tokenization platform 100 includes a mystery box system 806 that supports mystery box games played at brick-and-mortar stores. In these embodiments, the mystery box system 806 may provide an API that allows networked physical gaming devices to communicate with the tokenization platform 100. The mystery box system 806 may provide the mystery box game to the physical gaming device via the API system 108. In embodiments, the mystery box system 806 may provide a token identifier for an acquired ticket so that the physical gaming device may print a ticket indicating the acquired token. In some embodiments, the ticket may include a QR code indicating the acquired token.

[0192] In embodiments, a player may redeem a ticket representing the won tokens at a brick-and-mortar location. In these embodiments, the brick-and-mortar location may include a scanning device that scans the ticket and communicates the token identifier of the won token to the casino gaming system. In response to receiving the token identifier of the won token, the mystery box system 806 may redeem the won token on the player's behalf and may communicate verification of the redemption of the won token to the scanning device. An employee using the scanning device may then provide the player with the item(s) won by the player. Alternatively, the player may add the won tokens to the player's user account. In these embodiments, the player may scan the ticket (e.g., a QR-code). In response to the player scanning the ticket, the mystery box system 806 may facilitate the transfer of the tokens to the player's account, whereby the ticket may appear in the player's digital wallet. Once this occurs, the player may redeem, sell, gift, pledge, or otherwise trade the tokens.

[0193] In embodiments, the tokenization platform 100 includes a video game integration system 808. The video game integration system 808 enables video game makers to place tokens in video games so that gamers can find, buy, trade, or otherwise interact with the tokens within the video game. In embodiments, the video game makers may access the API of the tokenization platform 100 via the API system 108 so that an instance of the video game may request a particular token or type of token from the tokenization platform 100. In response to the request, the video game integration system 808 may provide the token to the instance of the video game. The token may be fungible or non-fungible. In the latter case, the token may be acquired, purchased, or otherwise traded by multiple video games. In the case of non-fungible tokens, the first user to trade for the token is the owner of the token. In response to the user trading for the token, the video game integration system 808 may update the distributed ledger to reflect the new ownership of the token.

[0194] In some demonstrative embodiments, a video game manufacturer may allow third parties to advertise items for sale within the video game, whereby users can purchase the items by selecting an icon (or other visual indicator) displayed within the video game that represents a token corresponding to the item. For example, an advertiser for a pizza delivery chain may want to provide pizza delivery to users in a particular location. In this example, an instance of the video game may request food-related tokens from the video game integration system 808, whereby each request indicates the location of a device running the respective instance of the video game. The video game integration system 808 may identify tokens that correspond to food items that can be delivered to the location where the respective instance of the video game is running. For example, the video game integration system 808 may identify tokens with associated metadata that indicate a delivery radius that includes the location indicated in the request. In response to the request, the video game integration system 808 provides the identified tokens to the requesting instance of the video game. A visual indicator representing the tokens is then displayed by the instance of the video game, whereby a user (i.e., a video game player) may choose to trade the tokens. When a user trades ownership of a token, the video game integration system 808 updates the token's ownership data to reflect that the token is owned by the user. In scenarios where delivery or other logistical information is required, the video game instance and / or user may provide those details at the time of the transaction, or the user may provide the information needed to complete the transaction. For example, if a user chooses to purchase pizza tokens from a pizza delivery chain, the video game instance and / or user may provide the address where the pizza will be delivered. The user may also provide details such as pizza toppings via the video game instance.

[0195] In some demonstrative embodiments, a video game manufacturer may enable items represented by tokens to be both used in the digital environment of the video game and redeemable in the “real world.” In these embodiments, the video game manufacturer may include certain fungible or non-fungible tokens in the video game, allowing users to find, buy, exchange, or otherwise trade tokens that appear in the video game. When a token that appears in the video game is traded, the video game integration system 808 may update ownership data for the traded token to reflect that the user is the owner of the token. A visual indication of the token may be displayed in the video game instance corresponding to the user and / or in the user's digital wallet. Once a user owns the token, the user can use the token in the video game and then redeem the token to receive the physical item represented by the token. For example, in a role-playing game, the token may represent a pair of earrings that grant the player of the video game special powers (e.g., invisibility). A user can use the earrings in the game to enjoy the special powers or exchange them for the earrings. In the latter scenario, the earrings may be shipped to the user so that they can be physically worn by the user but can no longer be used in the video game. In some of these embodiments, the video game maker may allow users to trade tokens. For example, a token owner may trade or sell the token for a token corresponding to another item. Each time ownership changes, the video game integration system 808 may update the distributed ledger to reflect the change in ownership. Once a user no longer owns the token, the user will no longer be able to use or exchange the item represented by the token.In some embodiments, the video game may allow the user to return the item to an authenticated location (e.g., a storage warehouse), whereby, once the item is authenticated, the user may subsequently use the digital representation of the item again in the video game.

[0196] The video game integration system 808 may enable video game makers to integrate tokens into video games in additional or alternative ways. For example, a video game maker could use tokens as "Easter eggs" or prizes that players can win when they discover tokens. In another example, a video game maker may incorporate one or more mystery boxes into a video game. In another example, a user could create digital items within the context of a video game and tokenize and trade (trade, gift, sell, etc.) the digital items.

[0197] In embodiments, the tokenization platform 100 includes a user acquisition system 810. In embodiments, the user acquisition system 810 provides mechanisms for promoting the tokenization platform, particularly encouraging new users to join. In some embodiments, the user acquisition system 810 provides each existing user with a unique referral code that the user can share with friends, social media followers, contacts, etc. Additionally, the user acquisition system 810 may provide an incentive to each existing user, whereby the incentive represents a reward for each new user or number of users (e.g., three users) that sign up for an account. The incentive may be any form of payment, including currency (e.g., traditional currency or cryptocurrency), gift cards, physical items, digital items, etc. In some embodiments, the reward is provided as a tokenized token, whereby the tokenized token represents a set amount of currency. In embodiments, the user acquisition system 810 may provide different incentives to different users. In some embodiments, the incentive may be determined based on the potential reach of each user. For example, users with a large reach (e.g., social media influencers, celebrities, etc.) may be awarded larger incentives than users with a relatively smaller reach. In some embodiments, incentives may be determined based on the interests of each respective user. For example, a first user interested in golf may be incentivized with golf-related items or gift certificates, while a second user interested in art may be incentivized with art-related items or gift certificates. In some embodiments, the user acquisition system 810 encodes each user's incentives in a respective instance of a smart contract. In some of these embodiments, the instance of the smart contract governing the user's incentives / rewards is associated with the user's referral code and / or the user's public address.When a user's referral code is successfully used to register a new account, the smart contract can facilitate the transfer of tokens representing rewards to the referring user's account.

[0198] Each time a new user enrolls in an account using a referral code, the user acquisition system 810 determines whether the new user is legitimate (e.g., not hot, not a fraudulent account, etc.). Assuming the new user is granted an account (e.g., no fraudulent activity detected), the user acquisition system 810 determines a user account associated with the referral code. In some embodiments, the user acquisition system 810 determines a smart contract associated with the user account and / or referral code. The user acquisition system 810 may provide notification of the new account to a smart contract associated with the user account and / or referral code. The smart contract may then initiate the transfer of tokens representing rewards to the user's account.

[0199] In embodiments, the user acquisition system 810 may perform these services for a third-party customer. In these embodiments, the third-party customer may provide a reward (e.g., cash, cryptocurrency, gift cards, physical items, etc.) to a trusted third-party holder (e.g., a tokenization platform or another trusted holder). The reward may then be tokenized and held in escrow. The third party may further define parameters governing the reward (e.g., amount of incentive to grant, who may be a promoter, etc.). The user acquisition system 810 may generate a smart contract on behalf of the third-party customer. When a user requests a referral code, the user acquisition system 810 may generate an instance of a smart contract on behalf of the customer and may associate the smart contract instance with the user's account. When a user successfully refers a buyer to the customer using the referral code, the user acquisition system 810 (and / or the smart contract instance) may transfer tokens representing the reward to the referring user's account.

[0200] To describe some embodiments in further detail, reference will now be made to example techniques that may be performed by or in association with an electronic commerce system, such as platform 100. The methods include method 900 of Figure 9, method 1000 of Figure 10, method 1100 of Figure 11, method 1200 of Figure 12, method 1300 of Figure 13, method 1400 of Figure 14, method 1500 of Figure 15, method 1600 of Figure 16, method 1700 of Figure 17, method 1800 of Figure 18, and method 1900 of Figure 19. Methods 900, 1000, 1100, 1200, 1300, 1400, 1500, 1600, 1700, 1800, and 1900 can be performed using computing devices such as the systems, hardware, and software described herein. Methods 900, 1000, 1100, 1200, 1300, 1400, 1500, 1600, 1700, 1800, and 1900 may be performed, for example, by executing a machine-readable program or other computer-executable instructions, such as routines, instructions, programs, or other code. The steps or operations of methods 900, 1000, 1100, 1200, 1300, 1400, 1500, 1600, 1700, 1800, and 1900, or another technique, method, process, or algorithm described in connection with the embodiments disclosed herein, may be implemented directly in hardware, firmware, hardware, circuitry, or a combination thereof. For ease of explanation, each of methods 900, 1000, 1100, 1200, 1300, 1400, 1500, 1600, 1700, 1800, and / or 1900 is depicted and described herein as a series of steps or acts. However, steps or acts in accordance with the present disclosure may occur in various orders and / or simultaneously. Moreover, other steps or acts not shown and described herein may be used. Furthermore, not all illustrated steps or acts may be required to implement techniques in accordance with the disclosed subject matter.

[0201] 9 is a flowchart illustrating a method 900 for tokenizing an item according to some embodiments of the present disclosure. At 9002, item information is obtained. The item information may include a unique identifier for a unique unit of the item and a set of item attributes. In an embodiment, a processing system of a tokenization platform obtains the information.

[0202] At 904, one or more digital tokens are generated. In an embodiment, the digital tokens are unique digital tokens. Each unique digital token may include a set of digital attributes corresponding to a set of item attributes. In an embodiment, N digital tokens are generated and linked to the item or a virtual representation thereof. In an embodiment, a token generation system generates the one or more digital tokens.

[0203] At 906, the digital token is bound to the item information. In embodiments, a cryptographic link binds the digital token to the item information such that the digital token provides a representation of the item. For example, the digital token and the item may be unique such that the unique digital token and a unique identifier of a unique unit of the item are cryptographically linked to provide a unique digital representation of the unique unit of the item. In embodiments, a linking system, such as a module of the token generation system 302, binds the digital token to the item information.

[0204] In embodiments, a token may be tokenized (e.g., when generating a token representing an amount of funds). For example, the item information may be funds within platform 100 or funds from a third-party source. The tokenized token may be generated in response to verifying receipt of funds, and the funds may be retained from a transaction by the user. In some embodiments, the funds remain publicly owned by the user, and the ledger is updated with a hold or lien recorded against the funds to prevent the user from trading the tokenized funds without approval by platform 100. In some embodiments, the ledger is updated to reflect the transfer of funds from the user to platform 100. Beneficially, the transferred funds may be tradeable by platform 100 (e.g., for escrow or investment with a third party), and the tokenized token may be redeemable for an equivalent amount of the original funds even if the redeemed funds were not originally tokenized funds, such that the escrowed funds can participate in economic transactions between platform 100 and a third party, while the tokenized token can be used in transactions within platform 100.

[0205] 10 is a flowchart illustrating a technique 1000 for transferring tokens using a digital marketplace, according to some embodiments of the present disclosure. At 1002, a ledger is maintained. The ledger stores a plurality of public addresses, a plurality of virtual representations of a plurality of respective items, and, for each virtual representation, a set of tokens and ownership data for each token. Each set of tokens corresponds to a respective instance of the item represented by the virtual representation. Furthermore, each public address corresponds to a respective account of a respective user of the tokenization platform.

[0206] At 1004, a digital marketplace is provided. In embodiments, the digital marketplace provides a graphical user interface that allows consumers to view visualizations of the virtual representation of the item, including a virtual representation of the item, and trade for instances of the item by purchasing N digital tokens. When a user purchases a token, the ledger may be updated to reflect a change in ownership of the token from the token seller to the user. Once a user owns the token, the user may be permitted to transfer the token to other users, sell the token, use the token as collateral, and / or redeem the token.

[0207] At 1006, the redemption is processed in response to a user requesting token redemption. In embodiments, the redemption may be initiated by associating a specific token corresponding to the virtual representation with the transacting user's account. The association may occur in response to verifying a request to participate in the transaction. A transfer request is received requesting that the specific token be transferred to a transferee. The transfer request includes a digital token identifier identifying the specific token and a public address of a different user. The specific token is then verified. The verification may be based on the digital token identifier and the ledger. The transferee's account on platform 100 may then be verified and / or validated based on the user's public address and the ledger. The ledger is then updated with a block containing ownership data indicating that the specific token corresponding to the virtual representation is owned by the transacting user. In embodiments, the update occurs in response to both verifying the specific token and verifying the transferee. A redemption request to redeem the digital token is then received from the transferee's user device, and a workflow is executed to fulfill the transaction for an instance of the item corresponding to the token. The workflow may be initiated in response to receiving a redemption request.

[0208] 11 is a flowchart illustrating a technique 1100 for transferring tokens between wallets via keyboard interaction, according to some embodiments of the present disclosure. At 1102, one or more wallets are displayed. Displaying the one or more wallets may include, for example, displaying a graphical user interface of the digital wallet via a user device of a user associated with the digital wallet. Additionally, an inventory of tokens owned by the user may be displayed by the graphical user interface of the digital wallet. In embodiments, each token may correspond to a respective item and be redeemable by the user to fulfill transactions for instances of the respective item.

[0209] At 1104, a transfer instruction is received. The transfer instruction may include an indication of one or more digital tokens from an inventory of tokens and a recipient of the digital tokens. The transfer instruction may be received by a graphical user interface of the digital wallet.

[0210] At 1106, the digital token is transferred in response to keyboard interaction. In an embodiment, a digital keyboard is displayed by a graphical user interface of the digital wallet. The digital keyboard includes selectable media content representative of an item corresponding to the digital token in the transfer request. User input is received generating a text-based message including a selection of the selectable media content via the digital keyboard. For example, the user can enter a message surrounding the transfer (e.g., "Enjoy this gift from me") and then select selectable media content representing the token (e.g., an image of the item represented by the token) to create a message with the token embedded therein. The selectable media content includes the digital token / digital token identifier (e.g., a hash value that uniquely identifies the digital token). The digital token (e.g., its identifier) ​​is embedded within the text-based message by the digital keyboard, and the digital wallet sends the text-based message to the recipient's messaging account. Upon receipt, in response to the recipient's selection of the selectable media content, the digital token is accepted into the recipient's respective digital wallet.

[0211] 12 is a flowchart illustrating a method 1200 for redeeming tokens according to some embodiments of the present disclosure. At 1202, ledger data is maintained. The ledger data may include a plurality of public addresses, a plurality of virtual representations, a set of tokens for each of the plurality of virtual representations, and ownership data for each of the sets of tokens. Each public address corresponds to a respective account of a respective user of the tokenization platform. The virtual representations correspond to respective items, and a set of tokens corresponds to a respective instance of each item for each virtual representation.

[0212] At 1204, a redemption request is received. The redemption request seeks to redeem a digital token from a user device of a user, where the digital token corresponds to an instance of the item being redeemed. At 1206, ownership of the digital token by the user is verified. The verification may be based on multiple public addresses, a set of digital tokens, and the redemption request. For example, the redemption request may include a user ID of a user wishing to redeem the token indicated by a token identifier. Platform 100 may verify ownership of the token by verifying that ledger data links the token identifier indicated in the redemption request with the public address of the user indicated in the redemption request. If so, ownership of the digital token is verified.

[0213] At 1208, details for fulfillment and / or delivery are managed by platform 100. In some embodiments, platform 100 may prompt the user to provide delivery details (e.g., via a graphical user interface). In response, platform 100 may receive delivery details from the user via a user device. The delivery details may then be output to a delivery system that initiates delivery of the redeemed token. For example, the user may provide a physical address and other relevant delivery data (e.g., an optimal time slot or phone number for delivery). In this case, the delivery system can use the provided address to initiate delivery of the item represented by the redeemed token. In another example, the token may represent a digital item. In such a case, the user may provide an email address or other account data to which the digital item (or a link to it) may be delivered. In some embodiments, platform 100 may request fulfillment details in response to the user verifying that they are the owner of the token. The fulfillment details include information necessary to fulfill the transaction for the item that was not provided at the time the token was traded. For example, the fulfillment details may include the item's construction materials, size, color, combinations thereof, etc. The fulfillment details may be received from the user's user device and output to a fulfillment system, which may initiate delivery of items that satisfy the fulfillment details.

[0214] 13 is a flowchart illustrating a method 1300 for collateralization and / or securitization according to some embodiments of the present disclosure. At 1302, an item conversion request is received. In embodiments, the item is a tangible object. In other embodiments, the item is some other form of collateral. At 1304, item information is received. The item information may include information needed or helpful in determining the valuation of the item. For example, the item information may include one or more photographs of the item, a description of the item, an appraised value of the item, and / or a holding location of the item.

[0215] At 1306, a virtual representation of the collateral item is generated based on the item information. At 1308, one or more tokens are generated based on the virtual representation. At 1310, ownership of the digital token is assigned. Initially, ownership of the digital token is assigned to the owner of the collateral item represented by the digital token. At 1312, a contract collateralized by the item is memorialized. In an embodiment, the item is an asset used as collateral for a contract to provide a service by a provider for a user. In an embodiment, an instance of a smart contract governing the service is generated. The smart contract indicates an amount the user must provide to the provider and one or more conditions that cause the provider to transfer ownership of the digital token. The instance of the smart contract may then be deployed by a processing system. In an embodiment, the item is a collateralizable item used as loan collateral. An agreement to loan funds to a user in an amount defined by a lender is received by the processing system. An instance of a smart contract governing the loan is generated by the processing system. The smart contract instance indicates the amount the user owes the lender and one or more conditions (e.g., default conditions) that will cause ownership of the tokens to transfer to the lender. The smart contract instance is then deployed by a processing system. In some embodiments, the tokens may be placed in escrow so that the lender cannot redeem or transfer them until the loan is paid. In these embodiments, the smart contract may define the conditions under which the tokens will be returned to the lender (e.g., when payment is completed).

[0216] 14 is a flowchart illustrating a technique 1400 for item authentication according to some embodiments of the present disclosure. At 1402, a tokenization request is received from a user device. At 1404, item information is received. In some embodiments, the item information may be provided by a user or via an automated process. At 1406, a virtual representation of the item is generated.

[0217] At 1408, the authenticity of the item is determined through an appropriate authentication process. In embodiments, authentication of the item may be requested via a portal accessible to the subject matter authentication expert. In these embodiments, the portal may further display a virtual representation of the item. For example, the subject matter expert may be presented with an image of the item, a description of the item (e.g., weight, dimensions, etc.), a video of the item, and / or the like. An authentication report may then be received by the processing system. The authentication report may be provided by the subject matter authentication expert and may include a statement indicating whether the subject matter authentication expert deemed the item authentic or inauthentic, along with one or more reasons for the statement. In some embodiments, the platform may generate a digital token in response to a statement indicating that the item is deemed authentic and assign ownership of the digital token to the item owner. The digital token may be based on the virtual representation of the item.

[0218] FIG. 15 is a flowchart illustrating a technique 1500 for rendering a VR environment. Leger data is maintained at 1502 using a suitable process, such as those described above. At 1504, the environment is rendered. In embodiments, a virtual reality store environment is rendered, providing an interface through which a user can view virtual reality visualizations of available items and conduct transactions for instances of the available items. Available items are items that are available for trade. Additionally, virtual reality visualizations of the items, represented by virtual representations, may also be included within the virtual reality store environment. At 1506, the items in the virtual environment are traded through suitable processing. For example, a request to participate in a trade for an instance of an item is received by platform 100 from a user device of a transacting user. In embodiments, the request to participate in the trade is received in response to the transacting user viewing a virtual reality representation of the item in the virtual reality store environment. Information associated with the request may be verified, and a specific token corresponding to the virtual representation is associated with the transacting user's account in response to verifying the request to participate in the trade.

[0219] FIG. 16 is a flowchart illustrating a technique 1600 for facilitating transactions using a distributed ledger with a sidechain of blocks, according to some embodiments of the present disclosure.

[0220] At 1602, a ledger is maintained. The ledger includes a main chain of blocks and a side chain of blocks. In an embodiment, blocks in the main chain collectively store information related to multiple users, including both item providers and item consumers. The information related to the multiple users includes multiple public addresses, each public address corresponding to a respective account of a respective user on the tokenization platform. Blocks in the side chain collectively store multiple virtual representations of multiple respective items, sets of tokens for each virtual representation, and ownership data for each token. Each virtual representation includes virtual reality content for rendering a virtual reality visualization of the respective item, and each set of tokens corresponds to a respective instance of the item represented by the virtual representation.

[0221] At 1604, a trade request is received through an appropriate process, such as those described above. At 1606, a trade of the item occurs. In embodiments, ownership data for the particular token corresponding to the virtual representation in the first side chain of the block is updated to indicate that the transacting user owns the particular token. In embodiments, the trade of the item includes verifying the particular token based on the digital token identifier and the first blockchain, verifying that a different user has a valid account on the tokenization platform based on the user's public address and the main blockchain, and updating the second blockchain with a new block in response to verifying the particular token and verifying the different user. The new block includes ownership data indicating that the particular token corresponding to the virtual representation is owned by the different user.

[0222] FIG. 17 is a flowchart illustrating a technique 1700 for facilitating user acquisition, according to some embodiments of the present disclosure. At 1702, a referral code corresponding to a user of the tokenization platform is generated. The referral code may be generated by a processing system of the tokenization platform. At 1704, an instance of a smart contract corresponding to the user of the tokenization platform is generated. The instance of the smart contract may be generated by the tokenization platform. The instance of the smart contract indicates an incentive to be provided to the user when the user successfully browses the tokenization platform. At 1706, the instance of the smart contract is deployed by the processing system. At 1708, a request to create a new account is received from a new user by the processing system. The request includes the user's referral code. At 1710, a new account is created for the new user by the processing system. At 1712, the processing system provides a notification of the new account to an instance of a smart contract corresponding to the user. The smart contract then facilitates the transfer of tokens representing the incentive in response to the notification.

[0223] 18 is a flowchart illustrating a technique 1800 for managing a mystery box according to some embodiments of the present disclosure. At 1802, a request to create a mystery box is received by a processing system. At 1804, a set of tokens to be included in the mystery box is received by the processing system. Each token in the set of tokens represents a respective item and has a probability assigned to it. The probabilities indicate the probability of winning the respective item.

[0224] At 1806, a mystery box is generated by the processing system based on the set of tokens and their assigned probabilities. Each token in the set of tokens is assigned a range of values ​​within a value interval such that the range of values ​​for the value interval is proportional to the probability assigned to the token.

[0225] At 1808, an instance of a smart contract is created by the processing system. The smart contract is associated with the mystery box and governs the transfer of tokens from the set of tokens that support the mystery box. At 1810, the instance of the smart contract is deployed by the processing system.

[0226] FIG. 19 is a flowchart illustrating a technique 1900 for video game integration according to some embodiments of the present disclosure. At 1902, an inventory of available tokens is maintained. The available tokens are available for integration into the video game. Each token in the token inventory represents a respective item. At 1904, a token request for a digital token is received by a processing system. The digital token is from an instance of the video game via an API. At 1906, the processing system selects a digital token from the inventory of available tokens based on the token request. At 1908, an indicator of the token is provided to the instance of the video game by the processing system. At 1910, the processing system receives a trade request from the instance of the video game. The trade request is configured to request a transfer of the token provided to the instance of the video game to a user's account for the instance of the video game. At 1912, the ledger is updated to reflect that the user is the owner of the token.

[0227] FIG. 20 illustrates an exemplary ecosystem 2000 for facilitating a securitized decentralized loan process (also referred to as a “decentralized loan process,” “securitized loan process,” or “loan process”). A securitized decentralized loan process may refer to a process that is distributed among a set of participants (e.g., paired computing systems 100, 2014 and devices 2002, 2004, 2006, 2008, 2010) and a set of smart contracts hosted on a set of distributed ledgers 2016, whereby borrowers can collateralize one or more physical items in a trustless or substantially trustless manner, and lenders have the authority to loan money to borrowers in a trustless or substantially trustless manner (e.g., without personally authenticating, appraising, safekeeping, and / or liquidating the collateral items). In particular, the disclosed ecosystem and supporting systems and methods provide mechanisms that enable borrowers to digitize physical items into digital collateral tokens 2042, such that the digital collateral tokens 2042 can be used to secure loans from lenders using smart contracts. In an embodiment, the stages of the decentralized loan process may include one or more of the following: a request stage in which a borrower requests to undergo a loan process; an authentication stage in which a collateral item is authenticated by one or more authenticators; an appraisal stage in which a collateral item is appraised by one or more appraisers; a custody stage in which the collateral item is deposited with a custodian until the loan process instance is terminated; a virtualization stage in which a VIRL corresponding to the collateral item is generated; and a tokenization stage in which the VIRL is tokenized into collateral tokens 2042.a loan request stage in which the borrower requests a loan and / or negotiates the terms of the loan with one or more potential lenders, culminating with the borrower and lender agreeing to the terms of the transaction and locking the collateral token in an escrow account until the loan process is complete; a loan repayment stage in which the loan is repaid or defaulted on by the borrower; and a post-loan stage in which the collateral token 2042 is returned to the borrower if the loan is successfully repaid or liquidated to the buyer if the borrower defaults, the collateral token is exchanged for a collateral item from the vault, and / or any post-loan analysis is performed.

[0228] In some exemplary embodiments, tokenization platform 100 supports a securitized decentralized loan process. In these exemplary embodiments, marketplace system 102, ledger management system 104, collateral management system 802, authentication system 804, and analytics and reporting system 112 may be configured to interface with a set of user devices (e.g., borrower devices 2002, authenticator devices 2004, appraiser devices 2006, custodian devices 2008, and / or lender devices 2010) in facilitating the decentralized loan process against a set of distributed ledgers 2016 hosted by a set of node devices 2014. In embodiments, securitized decentralized loan ecosystem 2000 includes a number of different participants that participate in different stages of the securitized decentralized loan process. In some embodiments, loan participants may include borrowers seeking to obtain loans using physical collateral items, authenticators who authenticate the physical collateral items, appraisers who value the physical collateral items, custodians who securely store the physical collateral items, lenders who lend currency to borrowers, and other suitable participants (e.g., “miners” and / or distributed ledger node devices 2014) that support the distributed ledger ecosystem. As discussed, some types of participants may be organized into guilds, which are groups of entities (e.g., individuals and / or companies) with subject matter expertise related to a particular stage, such as authentication, appraisal, and custody. It will be understood that participants in the securitization distributed ecosystem 2000 may interact with each other and the distributed ledger(s) 2106 via a variety of computing devices, such as laptop computers, desktop computers, tablets, video game consoles, server computers, and / or the like. For ease of explanation, a borrower may join the ecosystem 2000 via a borrower device 2002, a certifier may join the ecosystem 2000 via a certifier device 2004, an appraiser may join the ecosystem 2000 via an appraiser device 2006, a custodian may join the ecosystem 2000 via a custodian device 2008, a lender may join the ecosystem 2000 via a lender device 2010, and so forth.

[0229] In embodiments, the securitized decentralized loan process may be implemented at least in part using a set of distributed ledgers 2016 hosted by a network of node devices 2014, which execute smart contract instances created in connection with the securitized loan process, including one or more smart contracts that govern the authentication, appraisal, and / or securitization of one or more collateral items. In some embodiments, one or more stages in the decentralized loan process are governed by a respective set of smart contracts. Generally, a smart contract may include computer-executable code that executes conditional logic that, when executed, triggers one or more actions. The smart contract may receive data from one or more data sources, whereby the conditional logic analyzes the data to determine whether certain conditions are met and, if so, triggers one or more respective actions. Examples of smart contracts are discussed throughout this disclosure, including examples of conditional logic and trigger actions. In embodiments, the smart contract may be defined according to one or more protocols, such as the Ethereum Protocol, the WAX ​​Protocol, etc. A smart contract may be embodied as computer-executable code and may be written in any suitable programming language, such as Solidity, Golang, Java, JavaScript, C++, etc. Various examples of smart contracts that may be used in connection with various securitized decentralized embodiments are discussed throughout this disclosure. In the exemplary embodiment of FIG. 20 , the distributed ledger 2016 may store, and the node devices 2014 may execute, the following instances: a loan processing smart contract 2022, a stage-level governance smart contract 2024, a guild governance smart contract 2026, an authentication smart contract 2028, an appraisal smart contract 2030, a custody smart contract 2032, a loan smart contract 2034, and / or other suitable smart contracts.Various types of smart contracts are described throughout this disclosure.

[0230] In embodiments, the distributed ledger 2016 may store tokens used in connection with the decentralized loan process, including, but not limited to, collateral tokens 2042 generated in connection with the decentralized loan process and held as collateral to secure loans. These include guild tokens 2044 owned and / or used by guild members performing specific tasks in connection with the decentralized loan process (which may be used for voting by guild members, as described below), currencies / tokens 2046 utilized in connection with the decentralized loan process (e.g., for lending, repayment, rewards, staking, etc.), and other suitable tokens. In embodiments, the collateral tokens 2042 may be digital tokens encapsulating one or more virtual representations (VIRL) of physical items of one or more respective collateral items used to securitize loans in the decentralized loan process. In embodiments, the VIRL corresponds to the physical items and may include a description of the items, a photo of the items, a video of the items, etc. Virtual representations of physical items (VIRL) are discussed throughout this disclosure. In embodiments, the collateral token 2042 may include a smart contract wrapper such that when the holder of the collateral token redeems the token (as determined from the collateral token's ownership record after a loan is repaid and / or after a liquidation event) (as discussed above), the smart contract associated with the collateral token 2042 may provide a notification to the custodian of the collateral item represented by the collateral token 2042 to deliver the collateral item. Once the custodian confirms that the holder of the collateral token 2042 has taken possession of the collateral item, the smart contract of the collateral token 2042 may bump the redeemed collateral token 2042, as described above. A currency token may refer to a digital token used as currency. Examples of currency tokens may include Bitcoin tokens, Ethereum tokens, Ripple tokens, Wax tokens, etc. In some embodiments, a tokenized token refers to a digital token that "wraps" a currency amount (e.g., a currency token and / or fiat currency).When a tokenized token is created, a currency amount is held in escrow, the tokenized token represents ownership of the escrowed currency amount, and when a verified owner of the tokenized token redeems the tokenized token, the owner gains ownership of the escrowed currency amount. Because currency tokens and tokenized tokens are both representative of currency, use of the term "currency / tokenized" token may refer to currency tokens, tokenized tokens, or a combination of both currency tokens and tokenized tokens.

[0231] In embodiments, the distributed ledger 2016 may store additional data, such as event records 2052, ownership data 2054, and / or supporting data 2056. The event records 2052 may include records commemorating any events occurring in connection with the decentralized loan process. The event records 2052 may include records of events such as, but not limited to, a borrower's request to process a loan, an authentication task being assigned, an authentication task being completed, an assessment task being assigned, an assessment task being completed, a custody task being assigned, a custody task being completed, a loan requested by a borrower, a loan being accepted by a lender, a borrower's collateral tokens being locked in escrow corresponding to a loan agreement executed by the borrower, a payment from the borrower to a lender, a borrower's late payment, a transfer of the loan agreement from the current lender to a secondary lender, a borrower being deemed to be in default on the loan, the occurrence of a liquidation event, a borrower fully repaying the loan, rewards awarded to participants in the decentralized process, items deemed counterfeit after a liquidation event, items not meeting their valuation value during a liquidation event, etc. In embodiments, the event record may be generated by any suitable computing device in ecosystem 2000, such as tokenization platform 100, borrower device 2002, authenticator device 2004, appraiser device 2006, custodian device 2008, lender device 2010, node device 2014 (e.g., by a smart contract executed by node device 2014), or other suitable device. In embodiments, event record 2052 may be hashed using a hash function to obtain a hash value. Event record 2052 may be written to a data block and stored in a distributed ledger, and the data block may include the hash value. In this manner, the data in event record 2052 cannot be changed without changing the hash value of event record 2052, thereby making event record 2052 immutable.When a block containing the event record 2052 is stored in the distributed ledger, the event record 2052 can be referenced using the block's address on the distributed ledger 2016.

[0232] In embodiments, supporting data 2056 may be documents and data provided to support tasks or other events performed in connection with the decentralized loan process and / or participants in the decentralized loan process. As discussed, supporting data 2056 may include authentication reports and supporting photographs, videos, scans, etc., appraisal reports and supporting photographs, videos, scans, etc., custody reports and supporting photographs, videos, scans, etc., loan negotiation records indicating negotiation events during loan agreement negotiation, disbursement records corresponding to disbursement events by the lender to the borrower, repayment records indicating payment events by the lender, default records indicating default events, and / or other suitable data.

[0233] In embodiments, the ownership data 2054 may include data associating tokens (e.g., collateral tokens 2042, currency / tokens 2046, and / or guild tokens 2044) with accounts. In embodiments, the ownership data 2054 may be stored in a data block, which may include a link between a token address and an account address. For example, if Bob owns 10 currency tokens (e.g., Bitcoin), the ownership data 2054 for each token may be stored in the distributed ledger and may link the respective token to an account associated with Bob. If Bob uses one of those tokens 2046 to purchase an item from Alice, the token ownership data 2054 may be updated to link the token 2046 used to purchase the item to Alice's account. When ownership changes to a new account, a new block linking the token to the new account may be amended to the distributed ledger 2016. In embodiments, the tokens (e.g., collateral tokens 2042 and / or currency / tokens 2046) may be locked during the loan process. As used herein, “locking” tokens may refer to storing the tokens in an escrow account (e.g., on a distributed ledger that stores escrowed tokens) such that the locked tokens cannot be transferred from the escrow account unless a smart contract associated with the token determines that the tokens are locked. In embodiments, collateral tokens may be “locked,” for example, once the borrower and lender agree to loan terms. In some embodiments, a certain amount of currency / tokens 2046 belonging to a participant (e.g., a certifier, appraiser, and / or custodian) may be locked when the participant performs certain tasks related to securing a loan (e.g., authentication tasks, appraisal tasks, and custodial tasks) to provide an incentive for the participant to participate in the loan process in good faith (e.g., not certifying the collateral item, not overvaluing the collateral item to increase appraisal rewards, and storing the collateral item as property).When a token is “locked,” ownership data 2054 may be added to the distributed ledger that links the token to an escrow account managed by a trusted third party (e.g., tokenization platform 100). Once locked in the escrow account, the token cannot be redeemed or transferred unless it is unlocked. Upon the occurrence of an event that triggers a change in ownership of the token (e.g., repayment of at least a portion of a loan), the token's ownership data 2054 may be updated in the distributed ledger 2016 that stores ownership data 2054 to reflect that the token is owned by its rightful owner (e.g., a borrower, participant, buyer of the token, etc.), thereby unlocking the token. In some embodiments, when a collateral token 2054 is locked, the owner of the physical item may be prevented from using a virtual representation of the item in a virtual environment. For example, if the owner of a physical item tied to a video game via VIRL (e.g., a shoe owner also owns VIRL shoes that, when used in the video game, give the owner special functionality in the video game, such as running faster or jumping higher), pledges the physical item using the technology described herein and locks the resulting pledge token 2042 in an escrow account, locking the pledge token precludes the user from using the VIRL physical item in the video game. In embodiments, an external virtual environment, such as a marketplace, video game, or social media platform, may be configured to query the distributed ledger to obtain VIRL ownership data 2054. If the VIRL is wrapped in an escrowed pledge token 2042, the virtual environment may determine that the corresponding pledge token is held in escrow and prevent the user from using the VIRL within the virtual environment until the VIRL ownership data 2054 indicates that the user owns the VIRL.

[0234] It is noted that in addition to the distributed ledger 2016, the event records 2052, ownership data 2054, and supporting data 2056, as well as other suitable data supporting the decentralized loan process, may be stored in a non-decentralized data store, file system, database, etc. For example, in an embodiment, tokenization platform 100 may maintain a data store that stores the event records 2052, ownership data 2054, and supporting data 2056, as well as other suitable data supporting the decentralized loan process.

[0235] In embodiments, a specific group of participants in a decentralized loan process (e.g., certifiers, appraisers, custodians, etc.) may form or organize into a guild based on their common expertise in a certain area, following a set of governance defined to facilitate the securitized decentralized loan process. Generally, the formation, joining, and operation of the guild, the transactions (and other events) that occur during the loan process, and the mechanisms for facilitating the loan process adhere to the set of governance. Governance may refer to each set of rules and / or regulations that one or more aspects of the loan process and participants adhere to. In embodiments, governance may be defined in a set of files and / or documents (e.g., governance documents) stored on a distributed ledger and / or a centralized computing system (e.g., a tokenization platform). In some embodiments, governance may be implemented through the use of smart contracts and / or software applications executed by the centralized computing system (e.g., tokenization platform 100). In an embodiment, the set of governance may include system-level governance that applies to the entire loan process (e.g., all transactions and participants participating in the loan process), stage-level governance that applies to participants participating in a particular stage (or set of stages) of the loan process and transactions executed during a particular stage (or set of stages), guild-level governance that applies to transactions in which each guild and / or guild member participating in each stage participates, and / or sub-guild governance that applies to transactions in which each sub-guild formed from each guild and sub-guild member participates.In an embodiment, the governance structure is hierarchical, with system-level governance taking precedence over stage-level governance corresponding to each stage of the loan process, which in turn takes precedence over guild-level governance for each guild participating in that stage, and guild-level governance for each guild taking precedence over sub-guild governance for sub-guilds formed within that guild. In other words, the sub-guild governance of a sub-guild can extend or further refine the rules and regulations set out in the guild-level governance of the guild from which the sub-guild was formed, without conflicting with them. Guild-level governance can extend or further refine the rules and regulations set out in the stage-level governance of the stage in which the guild participates, without conflicting with them, and stage-level governance can extend or further refine the rules and regulations set out in the system-level governance, without conflicting with them. It is understood that neither of the different types of governance is required, and that certain stages and guilds may adhere to higher levels of governance (e.g., system-level governance or stage-level governance) without departing from the scope of this disclosure.

[0236] As noted above, the term "guild" may refer to a set of entities (e.g., individuals or businesses) performing a defined type of specialized task (e.g., authenticating watches, authenticating sneakers, storing valuables and / or perishable goods) whereby guild members adhere to a set of governance. For purposes of explanation, guild members are described as individuals, but it is understood that organizations may be comprised of individuals with the same area of ​​expertise and therefore may be included in a guild. In some embodiments, a guild must adhere to system-level governance, stage-level governance corresponding to the stage in which the guild participates, and / or guild-level governance of the guild to which the guild member belongs. Stage-level governance may define the rules and regulations pertaining to all participants who may participate in a stage (e.g., authentication stage, appraisal stage, storage stage, lending stage, etc.). For example, authentication stage-level governance may apply to any authenticator performing authentication tasks in connection with a decentralized loan process, authentication stage governance may apply to any authenticator performing authentication tasks in connection with a decentralized loan process, custody stage governance may apply to any custodian performing custody tasks in connection with a decentralized loan process, lending stage governance may apply to any lender lending money in a decentralized loan process, and so on. Guild-level governance may define rules and regulations for members of a particular guild participating in a particular stage. For example, watch authentication guild governance may pertain only to members of the watch authentication guild, handbag authentication guild governance may pertain only to members of the handbag authentication guild, jewelry authentication guild governance may pertain only to members of the jewelry authentication guild, watch authentication guild governance may pertain only to members of the watch authentication guild, handbag authentication guild governance may pertain only to members of the handbag authentication guild, sneaker authentication guild governance may pertain only to members of the sneaker authentication guild, etc.In embodiments, stage-level guild governance may define one or more of: how guilds may be created, how guild members are added to guilds, how guild members are removed from guilds, how guild members vote on governance modifications; workflows, smart contracts, and / or documentation related to specific tasks performed by each guild (e.g., appraisal, authentication, custody, etc.); voting mechanisms; and the like. As discussed, sets of governance may be hierarchical in nature, such that lower-level governance is required to adhere to and / or not contradict higher-level governance. For example, certification stage-level governance may define a set of rules and regulations that apply to all certifiers, while guild-level governance may define a set of rules, recommendations, and / or regulations that apply to each guild (e.g., a watch authentication guild or a jewelry authentication guild) within a broader group of certifiers (e.g., all certifiers). In this example, guild-level governance may be required to adhere to and not contradict stage-level governance, but may refine rules and / or regulations in the stage-level governance and / or add new rules and / or regulations not defined in the stage-level governance. For example, an example of authentication stage-level governance may require that an authenticator temporarily contribute at least a certain amount of funds (e.g., half of a loan amount) for each authentication task performed by a guild member. In this example, the guild-level governance of an authentication guild (e.g., a watch authentication guild) must require that guild members contribute at least the amount defined in the authentication stage-level governance in connection with authentication tasks performed by that guild member, but the guild-level governance may require a larger amount (e.g., the entire loan amount) than the amount defined in the authentication stage-level governance.In another example, appraisal stage-level governance may require appraisers to provide document support for appraisals, and guild-level appraiser governance associated with a particular guild of appraisers may further refine the document support that must be provided in support of appraisals performed by guild members. Additional examples of governance rules, recommendations, and / or regulations are provided throughout this disclosure.

[0237] In some embodiments, membership in a guild is determined, at least in part, by existing guild members in accordance with the guild's stage-level and / or guild-level governance. For example, in exemplary embodiments, the guild's stage-level governance and / or guild-level governance may provide that guild members may nominate individuals not in the guild to be added to the guild, and that guild members may vote on whether to admit the entity to the guild, and may further include mechanisms for how to nominate, vote, and admit new members to the guild. Thus, to add new members to the guild, existing guild members must go through a nomination and voting process in accordance with the governing government. In some embodiments, voting may be managed using the guild governance smart contract 2026. The guild governance smart contract 2026 may refer to a smart contract configured to manage administrative tasks for a guild, such as voting on amendments to guild-level governance and / or stage-level governance (when the guild governance smart contract 2026 pertains to a guild in the broader sense), voting on adding new members to a guild, voting on removing members from a guild, and issuing guild tokens 2044 to guild members. In some of these embodiments, the guild governance smart contract 2026 used to vote for new members for the guild may include conditional logic that receives nominations of potential guild members and determines whether certain conditions are met (e.g., does the nominator have a high enough reputation to nominate, has the nominator been a guild member long enough to nominate, has the nominator had a minimum number of guild tokens 2044 or other similar status indicator to nominate a new guild member, was the appropriate protocol used, etc.). In response to verifying that the nomination is valid, the guild governance smart contract 2026 may perform the actions of soliciting votes from current guild members and tallying the votes.Once a member has been voted for, the guild governance smart contract 2026 may be configured to determine whether the nominee has received enough votes to be admitted to the guild. If so, the nominee is added to the guild. If not, the nominee is denied membership in the guild. In doing so, the guild governance smart contract 2026 may create one or more event records 2052 identifying the results of the vote and / or whether the new member was added to the guild. In embodiments, the event records 2052 may be written to the distributed ledger 2016. The guild governance contract 2026 may perform additional actions, such as granting the new member guild tokens 2044, creating a profile for the new guild member, adding the new guild member to a roster from which guild members are selected to perform tasks, etc. Guild members may be added to a guild in other manners without departing from the scope of this disclosure.

[0238] In embodiments, an authentication guild may include a collection of individuals or organizations with domain-specific expertise authenticating a particular type or types of items. For example, a watch authentication guild may be composed of individuals with expertise authenticating watches, a shoe authentication guild may be composed of individuals with expertise authenticating shoes, a handbag authentication guild may be composed of individuals with expertise authenticating handbags, an art authentication guild may be composed of individuals with expertise authenticating art, a sporting goods authentication guild may be composed of individuals with expertise authenticating art, a sports memorabilia authentication guild may be composed of individuals with expertise authenticating sports memorabilia, a toy authentication guild may be composed of individuals with expertise authenticating collectible toys, a jewelry authentication guild may be composed of individuals with expertise authenticating jewelry, a musical instrument authentication guild may be composed of individuals skilled in authenticating musical instruments, and a record authentication guild may be composed of individuals skilled in authenticating rare or collectible records. A wine certification guild may be made up of individuals skilled in the certification of wine by the bottle, a whiskey certification guild may be made up of individuals skilled in the certification of whiskey by the bottle, an automobile certification guild may be made up of individuals skilled in the certification of limited edition cars, or any other suitable certification guild is possible.

[0239] In an embodiment, an appraisal guild may include a collection of individuals or organizations with domain-specific expertise appraising a particular type(s) of items. For example, a watch appraiser guild may be composed of individuals with expertise in appraising watches, a shoe appraiser guild may be composed of individuals with expertise in appraising shoes, a handbag appraiser guild may be composed of individuals with expertise in appraising handbags, an art appraiser guild may be composed of individuals with expertise in appraising fine art, a sports memorabilia appraiser guild may be composed of individuals skilled in appraising sports memorabilia, a toy appraiser guild may be composed of individuals skilled in appraising collectible toys, a jewelry appraiser guild may be composed of individuals skilled in appraising jewelry, a musical instrument appraiser guild may be composed of individuals skilled in appraising musical instruments, a wine appraiser guild may be composed of individuals specialising in appraising wine by the bottle, a whiskey appraiser guild may be composed of individuals specialising in appraising whiskey by the bottle, a car appraiser guild may be composed of individuals specialising in appraising limited edition cars, and so on. Other suitable appraisal guilds are possible.

[0240] Within some guilds, there may be different classes of items that are much more popular than others and / or may require additional expertise. For example, within a watch authentication guild, some guilds may have numerous authentication requests to authenticate Rolex® watches, due to both the number of such watches on the market and the number of counterfeit watches intended to pose as Rolex® watches. Thus, in some embodiments, some stage-level governance and / or guild-level governance may provide a mechanism by which one or more sub-guilds may be formed, where the sub-guild is made up of individuals from the guild who have authentication expertise in a particular subdomain of the guild's area of ​​expertise. For example, within a watch guild, there may be sub-guilds that specialize in authenticating different brands of watches, such as Rolex® watches, Omega® watches, Hamilton® watches, etc. As another example, a shoe authentication guild may have sub-guilds that specialize in authenticating different types of shoes, such as sneakers, high-tops, skateboard shoes, heels, and dress shoes, and / or different brands of shoes, such as Nike® shoes, Jordan® shoes, Adidas® shoes, Gucci® shoes, and Louboutin® shoes. As another example, an art authentication guild may have sub-guilds that specialize in authenticating artworks in different mediums, such as paintings, oil paintings, sculptures, lithographs, concert posters, swords, vases, and ceramics; different styles of art, such as impressionist paintings, abstract paintings, postmodern art, pop art, graffiti, Japanese swords, Chinese vases, and Fabergé eggs; and / or artworks by different artists. Thus, different guilds may be divided into sub-guilds in different ways. Furthermore, the existence of sub-guilds for a guild's subdomains does not necessarily mean that all items must be included in the sub-guild.For example, if a Watch Certification Guild has a Rolex Sub-Guild but no other sub-guilds, a Rolex® watch may be certified by one or more certifiers in the Rolex Sub-Guild, but an Omega® watch may be certified by one or more certifiers within the broader Watch Certification Guild that includes members of the Rolex Sub-Guild.

[0241] In embodiments, the ability to form sub-guilds from within each guild may be defined in the guild-level governance and / or stage-level governance of each guild. In some of these embodiments, the formation of new sub-guilds from each guild may be managed and implemented using the guild governance smart contract 2026 corresponding to each guild. In some embodiments, the guild governance smart contract 2026 may define how sub-guilds may be requested and created (e.g., automatically or by a set of guild members). For example, the guild governance smart contract 2026 used by a particular certification guild (e.g., a watch certification guild) may include conditional logic that defines a minimum number and / or percentage of guild members (e.g., watch authenticators) required to request / approve the creation of a new sub-guild (e.g., a Rolex sub-guild). In this example, the guild-level governance of a particular certified guild may require at least 10 guild members and / or at least 50% of the voting power of the guild members (where voting power may be determined using a voting token system where members with more guild tokens 2044 have more voting power or a "one member, one vote" system where all members have one equally weighted vote) to agree to the creation of a sub-guild. Additionally or alternatively, the guild governance smart contract 2026 may include conditional logic requiring a minimum number or percentage of verified successful authentication events (or other tasks, if at another stage) performed by guild members involving items of a particular subclass in order to approve the creation of a new sub-guild.For example, the Shoe Authentication Guild's Guild Governance smart contract 2026 may require proof of at least 1,000 successful authentication events and that at least 5% of the total authentication events involve shoes of a particular class; if the Shoe Authentication Guild collectively performs 10,000 successful authentication events involving a pair of shoes, and more than 1,000 of those authentication events involve Nike® sneakers, the Shoe Authentication Guild may vote to create a Nike® sub-guild (or a "Sneakers" sub-guild). In this example, the Shoe Authentication Guild's Guild Governance smart contract may require analytics to prove more than 1,000 successful authentication events (which may include successful authentication of knock-off sneakers and / or successful authentication of authentic Nike® sneakers). In an embodiment, the analytics to prove that the guild has reached the required number of successful authentications may be obtained based on analysis of a distributed ledger that stores authentication records. Additionally, the Shoe Certification Guild-level governance may subsequently require guild members to vote on the creation of a new NIKE® sub-guild, with the voting scheme defined in the Shoe Guild-level governance and / or the Certification Stage-level governance. Assuming all of the conditions for creating a new sub-guild within the Shoe Guild are met, the Guild Governance smart contract may trigger a "Create New Sub-Guild" action. In embodiments, the action of creating a new sub-guild may include creating new governance corresponding to the sub-guild that defines the rules for the specific sub-guild, including rules for membership in the sub-guild, rewards and fees for the sub-guild, a mechanism for validating items classified in the sub-guild, how the sub-guild secures certification events, the certification form used by the sub-guild, etc. Note that in embodiments, the governance of a sub-guild may initially inherit one or more aspects of the broader guild governance (some of which may be modifiable by the sub-guild and some of which may not be modifiable by the sub-guild).In embodiments, the "create new sub-guild" action may include issuing a notification of the new sub-guild to tokenization platform 100 so that platform 100 may update the assignment of authentication tasks to the new sub-guild, including items that fall under the expertise of the new sub-guild.

[0242] FIG. 21 illustrates example guilds within a decentralized loan ecosystem 2000 and different types of governance that may govern guild members and / or different aspects of the loan system. In the illustrated example, stage-level guilds may include an authentication guild 2102 composed of authenticators performing authentication tasks, an appraisal guild 2104 composed of appraisers performing appraisal tasks, and a custodian guild 2106 composed of custodians performing custodianship tasks. It is understood that additional or alternative types of participants may form guilds in different embodiments. For example, lenders may form a lender guild (not shown). As described above, within an authentication guild, there may be guilds that include members with specific authentication specialties or guilds located in specific geographic regions. In the illustrated example, within the authentication guild, there may be a watch authentication guild 2112-1, a shoe authentication guild 2112-2, and / or any other suitable authentication guilds (e.g., an Nth authentication guild 2112-N). Within some of the authentication guilds, authentication sub-guilds may be formed. For example, within the Watch Guild 2112-1, a Rolex sub-guild may be formed, and members of the Rolex sub-guild 2122 may be Watch Guild members with special expertise in authenticating Rolex® watches. In this manner, members of the Rolex sub-guild 2112-1 are assigned the task of authenticating Rolex® watches (and potentially other types of watches), and members of the Watch Guild 2112-1 who do not belong to sub-guild 2122 cannot authenticate Rolex® watches but can authenticate other types of watches (assuming no other Watch Sub-guilds exist). Similarly, within the Shoe Certification Guild 2112-2, a Sneaker Certification Sub-guild 2124-1 and a Gucci Certification Sub-guild 2124-1 are formed by members of the Shoe Certification Guild 2112-2. In this example, members of sneaker authentication sub-guild 2124-1 can authenticate any type of sneaker, but shoe authenticators who do not belong to sneaker authentication sub-guild 2124-1 cannot authenticate sneakers.Similarly, members of Gucci authentication sub-guild 2124-2 can authenticate Gucci® shoes, but shoe authenticators who do not belong to Gucci authentication sub-guild 2124-2 cannot authenticate Gucci® shoes.

[0243] Within the appraisal guild 2104, there may be guilds aimed at members with particular appraisal expertise or located in particular geographic regions. In the illustrated example, within the appraisal guild 2104, there may be a watch appraisal guild 2114-1, a shoe appraisal guild 2114-2, and / or any other suitable appraisal guilds (e.g., an Nth appraisal guild 2114-3). In the illustrated example, a Rolex appraisal sub-guild 2126 is formed from the watch appraisal guild 2114-1, and a Nike appraisal guild 2128 is formed from the shoe appraisal guild 2114-2. As can be appreciated, the sub-guilds formed from various guilds need not coincide with the sub-guilds formed from guilds participating in different stages. For example, Rolex authenticators and Rolex appraisers form respective sub-guilds 2122 and 2126, but no corresponding Nike authentication sub-guild, sneaker appraisal sub-guild, or Gucci appraisal sub-guild is formed. The manner in which a sub-guild is formed may be defined by the stage-level governance and / or guild governance of the guild in which the sub-guild is formed.

[0244] In this example, no guilds are formed from the custodian guild 2106. While this is the case in this example, in some scenarios there may be guilds that include custodians with particular custodian specialties or that are located in particular geographical areas. In the illustrated example, there are no guilds within the custodian guild, but custodians may be organized according to region (e.g., state, city, etc.), ability to store particular types of items (e.g., vehicles, perishable goods, and / or the like), or other suitable common characteristics.

[0245] In embodiments, the overall ecosystem 2100 (including the overall loan process workflow) may be governed by system-level governance 2130. In this example, one or more stages may be governed by stage-level governance associated with the participants of the stage and / or the workflow executed in association with the stage. For example, authentication stage-level governance 2132 may involve all authenticators 2102 and the authentication stage, appraisal stage-level governance 2134 may involve all appraisers 2104 and the appraisal stage, custody stage-level governance 2136 may involve all custodians 2106 and the custody stage, loan stage-level governance 2138 may involve lenders (not shown) and the loan negotiation and repayment stages, etc. As discussed above, stage-level governance 2132, 2134, 2136, 2138 may refine system-level governance 2130 and add rules and regulations consistent with system-level governance 2130. Similarly, watch guild-level governance 2142 pertains to the watch certification guild 2112-1, but not to the other certification guilds 2112-2...2112-N. Watch guild-level governance 2142 may include rules that further refine the system-level governance 2130 and / or add rules and regulations to the certification stage-level governance 2132. In an embodiment, Rolex sub-guild governance 2144 may be created by members of the Rolex certification sub-guild 2122. Rolex sub-guild governance 2144 defines additional rules and regulations that apply to members of the Rolex sub-guild 2122 when certifying Rolex® watches, but that do not apply to other members of the watch certification guild 2112-1. Note that sub-guilds do not require sub-guild governance and can use the guild-level governance of the guild from which the sub-guild was formed. A more detailed description of guilds and governance is provided below.

[0246] Returning to FIG. 20, governance may define rules and regulations related to different aspects of the securitized decentralized loan process. In embodiments, system-level governance defines rules and regulations related to the entire loan process. Examples of system-level governance include defining the loan process workflow (e.g., which stages must be performed in what order), types of collateral items allowed, rules regarding guild formation and membership (e.g., whether guilds can be formed, whether guilds can change the rules, how guilds can change the rules, and / or the like), rules for managing the loan process workflow between stages (e.g., whether an authenticator who authenticates a collateral item can authenticate the same collateral item and / or keep the collateral item, when the loan process can progress to the next stage, etc.); rules requiring guild members to stake currency (e.g., For example, in connection with authentication tasks, appraisal tasks, and / or custody tasks involving collateral items, providing rules for having Guild members contribute currency (e.g., cryptocurrency and / or fiat currency wrapped in tokenized tokens), rules for performing tasks (e.g., the types of supporting documentation required to demonstrate agreement), rules for changing governance (e.g., who can vote to change governance, how votes to change governance are conducted, etc.), rules for rewarding participants (e.g., requirements and / or limitations regarding the amount or percentage of payments that may be made when performing certain tasks, regulatory requirements of different jurisdictions), and / or other appropriate rules and regulations.

[0247] In embodiments, the system-level governance may include a reference to one or more respective loan process smart contracts 2022 stored on the distributed ledger 2016. The loan process smart contracts 2022 may implement one or more aspects of system-level governance for a distributed loan process instance, including, for example, initiating each stage of the loan process upon completion of the previous stage according to the loan process workflow defined in the system-level governance. In embodiments, the loan process smart contracts 2022, once instantiated, include conditional logic that listens (e.g., using an event listener thread) for notifications from stage-level smart contracts indicating successful completion of a stage. In response to completion of a stage, the loan process smart contracts 2022 may then initiate the next stage in the loan process workflow. For example, an exemplary loan process workflow may be defined to include a request stage in which a borrower requests to pledge one or more items, an authentication stage in which one or more authenticators authenticate the one or more items, and an authentication stage in which the authenticated items are authenticated. The process includes a custody stage in which the authenticated items are stored with a trusted custodian, a ledger management system 104 (or another suitable component) generates VIRL for one or more deposited items, tokenizes the VIRL for the deposited items to generate collateral tokens, and locks the collateral tokens (e.g., in an escrow account on the distributed ledger 2016), a lending stage in which the loan is negotiated and accepted by the borrower and lender, a repayment stage in which the loan is repaid by the borrower, and a post-loan stage in which the collateral tokens are unlocked and returned to the borrower or liquidated if the borrower defaults on the loan. In facilitating this example loan process workflow, the loan process smart contract 2022 may be configured with conditional logic that determines whether the current stage is successfully completed and, if so, initiates the next stage in the loan process workflow.In embodiments, initiating the next stage of the loan process workflow may include instantiating a stage-level smart contract (e.g., authentication smart contract 2028, valuation smart contract 2030, custody smart contract 2032, or loan smart contract 2034), whereby the instance of the stage-level smart contract performs a stage-specific workflow and issues notifications that the loan process workflow receives upon successful or unsuccessful completion of the stage-specific workflow. In embodiments, the loan process smart contract 2022 may perform one or more tasks described as being performed by other types of smart contracts. For example, the loan process smart contract 2022 may be configured to facilitate loan negotiation and signing, monitoring loan repayments, determining default events, triggering liquidation events, awarding rewards to participants, and / or the like.

[0248] System-level process governance may include additional rules and requirements, examples of which are provided throughout this disclosure. For example, system-level process governance may include rules that prevent a single entity from acting as both the certifier and the appraiser, rules that require the certifier, appraiser, and / or custodian to contribute at least a percent of the loan value (e.g., to prevent manipulation of the system), and / or other rules related to decentralizing the loan process, reducing the likelihood of fraud, promoting trust, maximizing value for participants, minting tokens, etc. In an embodiment, at least a portion of the system-level process governance is implemented by the loan process smart contract 2022. In an embodiment, the loan process governance smart contract may include conditional logic that determines whether each stage is successfully completed and, if so, triggers the next action in the loan process.

[0249] In embodiments, stage-level governance defines rules and regulations associated with each stage of the loan process, such that each stage of the loan process may be executed in accordance with one or more respective stage-level governances. It is understood that in some embodiments, stage-level governance may apply to two stages. For example, an authentication stage may comply with stage-level authentication governance that defines rules for any authentication tasks performed in connection with the decentralized loan process, an appraisal stage may comply with stage-level appraisal governance that defines rules for any appraisal tasks performed in connection with the decentralized loan process, and a custody stage may comply with stage-level custody governance that defines rules for any custody tasks performed in connection with the decentralized loan process. Stage-level governance may include VIRL stage-level governance that defines rules for generating VIRL tokens for the collateral items (in some embodiments, the VIRL stage and tokenization stage may be treated as a single stage), loan governance that defines rules for requesting and negotiating a loan, and / or any other suitable stage-level governance.

[0250] In embodiments, stage-level governance may further refine the rules set forth in system-level governance and / or include additional rules related to a stage. For example, stage-level governance may further refine the rules and / or regulations of system-level governance, such as further refinement of adding and / or removing guild members, further refinement of how guild members stake currency in connection with guild-specific tasks (e.g., authentication tasks, appraisal tasks, or custody tasks), further refinement of the types of evidence required to support authentication tasks, etc. For example, system-level governance may state that new members must be voted into any guild and may be removed with at least a 60% majority vote, but may not define other specifics. In this example, the authentication stage-level governance rules may define a first voting scheme for voting for the authentication guild and removing members, while the appraisal stage-level governance may define a second scheme for voting for the appraisal guild and removing members. For example, a certifier may have a one-member-one-vote voting scheme where new members can be added to the guild with a simple majority vote and removed with a 60% majority vote, while an appraiser may have a token barter scheme where each guild member has a fixed amount of guild tokens 2044, whereby each guild member's voting power is proportional to the amount of guild tokens 2044 the guild member possesses, in which case the appraiser may remove a guild member 2044, thereby reducing the guild member's voting power to remove a guild member. In the second scheme, more senior or active members have more voting power than more senior or less active guild members. In an embodiment, stage-level governance may further define the types of documentation and supporting data required by the guild for that stage. In this example, the certification stage-level governance may further refine this rule to require certifiers to fill out a certification report and provide photographic evidence to support the report.Similarly, appraisal stage-level governance may further refine this rule to require the appraiser to submit an appraisal report indicating the appraised value and to provide documentary evidence of past sales of similar items to support the appraised value. In this example, custodian stage-level governance may further refine this rule to require the custodian to provide photographic evidence of the item being safely stored and to complete a custodian report showing any damage visible when the item was deposited by the owner (e.g., borrower) and the item's owner's verification of this visible damage. Furthermore, appraisal stage-level governance may further define that the appraisal report includes the liquidation value of the collateral item in addition to the appraised value of the collateral item, where the liquidation value indicates the low-end price at which the collateral item is expected to sell (e.g., in a short-notice liquidation event or at a set-price sale to achieve a quick liquidation sale).

[0251] As previously mentioned, stage-level governance may also define new rules and regulations to the extent that those new rules and regulations do not contradict or otherwise override system-level governance. For example, assuming no such rules are defined in system-level governance, stage-level governance may define rules for how stage-specific tasks are performed. For example, with respect to an authentication stage, authentication stage-level governance may require that a primary authenticator make a determination of the authenticity of a collateral item and that at least one other authenticator (functioning as a "secondary authenticator") verify the primary authenticator's determination regarding the item's authenticity. In this example, stage-level governance may further define that the primary authenticator gets a percentage (e.g., 60% or 70%) of the authentication fee / reward, with the remaining amount split among one or more secondary authenticators. Further, in this example, the attestation stage-level governance may refine the system-level requirements for attestors to stake currency tokens by defining the allocation of risk to the primary attestor and other secondary attestors (e.g., the primary attestor stakes 60% or 70% of the loan amount (assuming the loan is agreed upon), with the secondary attestors splitting the remaining portion of the loan amount equally). In another example, the appraisal stage-level governance may define the mechanics and workflow of appraisal. For example, governance may define how appraisal tasks are assigned to attestors and that any appraisal must be verified by one or more additional attestors. In this example, the appraisal stage-level governance could further refine how primary and secondary attestors are compensated and / or the amount of currency they must stake to secure that appraisal. In another example, the custodian stage-level governance may define additional rules for the custody of certain collateral items. For example, if an item requires temperature-controlled storage, the custodian stage-level governance may define rules requiring the custodian to provide proof of such temperature-controlled storage.In another example, if the collateral item is a vehicle, storage stage-level governance may define rules requiring the storage provider to provide evidence of the vehicle's mileage as of the date the vehicle was first received and the date it is repossessed by the rightful owner (e.g., a borrower or buyer in liquidation). Stage-level governance may include additional or alternative refinements of system-level rules and regulations and / or additional or alternative definitions of rules and / or requirements not addressed in system-level governance.

[0252] In embodiments, some stage-level governance may include a form template or a reference thereto (e.g., an address where the form template can be obtained) to be used in association with the stage. In some exemplary embodiments, authentication stage-level governance may include a reference to an authentication form template that can be used by an authenticator when performing an authentication task. The form template may include a set of fields to be filled in by an authenticator whose task is to authenticate a collateral item, such that the authenticator fills out the form and submits it to the authentication system 804, the authenticator smart contract 2028, and / or the loan processing smart contract 2022. In filling out the form, the authenticator can provide an opinion regarding the authenticity of the item and can provide analysis to support that opinion. The form may include instructions to provide supporting evidence, such as photographs, serial numbers, videos, etc. In some exemplary embodiments, appraisal stage-level governance may include a reference to an appraisal report template that the appraiser can use when performing an appraiser task. Assuming authentication is performed before appraisal, the appraiser can trust that the item is authentic, but may require inspection of either the item itself or photographs and / or videos of the item to provide an appropriate valuation. The appraiser form may include a set of fields that an appraiser tasked with appraising a collateral item may complete and submit the completed form to the authentication system 804 and / or an appraisal smart contract. In completing the form, the appraiser may provide an appraisal value and may provide analysis supporting the appraisal value. The form may include instructions to provide supporting evidence, such as evidence of past sales of similar items, blue book values, auction data, etc. In some exemplary embodiments, custody stage-level governance may include a reference to a custody form template that may be used by the custodian in performing custody tasks. In some embodiments, the form may require the appraiser to provide a liquidation value of the collateral item in addition to the appraisal price.The liquidation value may be a low-end valuation of the collateral item, such as when the collateral item needs to be liquidated quickly. The liquidation value combined with the valuation may provide potential lenders with an opportunity to assess the risk associated with lending money, taking into account the valuation and liquidation value of the collateral. The form may include a set of fields to be completed by a custodian tasked with custody of the collateral item, such that the certifier completes the form and submits it (e.g., to the collateral management system 802 and / or a custody smart contract). When completing the form, the custodian may provide the condition of the collateral item when received and verify that the collateral item is stored in a physical location with appropriate precautions to protect the collateral item. The form may also include instructions to provide evidence, such as photographs of the collateral item (including visible damage). The form template is provided as an example, and it is understood that additional or alternative form templates may be used during various stages of the decentralized loan process. Additionally, some guilds may further refine form templates for specific types of collateral items. In these scenarios, guild-refined form templates relevant to each task may be used instead of the form templates defined in the stage-level governance. It should be noted that other stage-level governances may include other form templates. Additionally, it should be understood that some guild-level governances and / or sub-guild-level governances may include or reference form templates to be used by members of the guild or sub-guild in place of a form template defined in the stage-level governance, or when the stage-level governance does not include or reference a broader form template.

[0253] In some embodiments, stage-level governance may include references to one or more smart contracts used in connection with managing stage-level tasks and / or guilds participating in a stage. These smart contracts may include a stage-level governance smart contract 2024 that corresponds to managing the participants in each stage, enforcing the stage-level governance of the respective stage and any associated rules and regulations defined in the system-level governance. In embodiments, the stage-level governance smart contract 2024 may be configured to implement the mechanics of a particular stage. For example, the stage-level governance of a particular stage may require that any changes to governance be voted on by all participants in the stage, and may use the stage-level governance smart contract 2024 to implement the voting process. In this example, authenticators (across all guilds) may want to modify the governance of the authentication stage to require that the borrower pay the authenticator a verification fee (in addition to the reward paid to the authenticator upon successful completion of the loan process) so that the authenticator can receive payment even if the item is determined to be fake or if the borrower decides not to enter into the loan agreement (which would prevent the authenticator from receiving a reward for participating in the loan transaction). Stage-level governance 2024 may require certifiers to have a supermajority (e.g., a two-thirds majority) vote to amend the stage-level governance, which must further receive approval from a decision maker affiliated with a central authority to make such an amendment. In this example, stage-level governance smart contract 2024 may include a listening thread that receives votes from certifiers and determines whether a supermajority has voted to amend the certified stage-level governance. If so, the smart contract may perform an action to amend the certified stage-level governance and may generate a block indicating the result of the vote to be written to the corresponding distributed ledger 2014.Although this example has been described with respect to authentication stages and with respect to voting, the stage-level governance smart contract 2024 may be configured to implement various other aspects of stage-level governance.

[0254] Additionally, in exemplary embodiments, stage-level governance may include references to respective smart contracts used to manage stage-level events and transactions. For example, authentication stage-level governance may include a reference to authentication smart contract 2028 used to facilitate authentication tasks performed in connection with the loan process, and valuation stage-level governance may include a reference to valuation smart contract 2030 used to facilitate valuation tasks performed in connection with the loan process. custody stage-level governance may include a reference to custody smart contract 2032 used to facilitate appraisal tasks performed in connection with the loan process, and loan stage-level governance may include a reference to loan smart contract 2034 used to manage loan agreements and loan repayment stages. In some embodiments, a loan workflow may include a loan pre-liquidation stage (described below) that is managed by loan pre-liquidation stage-level governance. In these embodiments, loan pre-liquidation stage-level governance may include a reference to a loan pre-liquidation smart contract, described in more detail below.

[0255] In example embodiments, the authentication stage-level governance may include a reference (e.g., an address) of the authentication smart contract 2028 that may be used for the authentication task. The reference may define an address that may be used to retrieve the authentication smart contract 2028 (e.g., from the distributed ledger 2016). In these embodiments, the loan process smart contract 2022, the authenticator device 2004, and / or the tokenization platform 100 may instantiate an instance of the authentication smart contract 2028 in response to the authenticator being assigned a new authentication task and / or the authenticator accepting a new authentication task via the authenticator device 2004. Once instantiated, the instance of the authentication smart contract 2028 is written to the distributed ledger 2016, and the authentication smart contract instance may be executed to manage the authentication task. In embodiments, the authentication smart contract 2028 may be configured to receive input from the authenticator device 2004, the borrower device 2002, and / or the collateral management system 804, and may include conditional logic that determines whether all necessary steps have been performed in connection with the authentication task based on the received input.

[0256] 22 illustrates a series of operations of an example method 2200 that may be performed to perform an authentication workflow. Method 2200 may be performed by a smart contract, such as authentication smart contract 2028 or loan process smart contract 2022. For ease of explanation, method 2200 is described as being performed by an authentication smart contract.

[0257] At 2202, the instance of the authentication smart contract 2028 may receive confirmation of the recipient of the collateral item from the authenticator device. In some scenarios, the collateral item is physically sent to the primary authenticator to perform the task. In such scenarios, the primary authenticator may confirm receipt of the collateral item using the authenticator device 2004. In these embodiments, the authenticator can provide an image of the collateral item and note any visible damage to the item. Alternatively, the primary authenticator may be sent a VIRL of the collateral item. In these embodiments, the VIRL can include an ultra-high resolution image of the collateral item and / or other media that can help the authenticator perform the authentication task.

[0258] At 2204, the authentication smart contract instance may receive an authentication report and supporting documents from the primary authenticator. In these embodiments, the primary authenticator may be required to generate the authentication report in accordance with the authentication stage-level governance and / or guild-level governance of the authentication guild to which the authenticator belongs. In some embodiments, the primary authenticator may generate the report using a form template included in the authentication stage-level governance and / or guild-level governance. The report may indicate the primary authenticator's conclusion (e.g., whether the item is authentic or fake) and the reasons for it. Supporting documents may include photographs, serial numbers, test results, etc., that support the authenticator's conclusion. Once the authenticator provides the authentication report, the report and supporting documents may be provided to one or more secondary authenticators (if required by the stage-level governance).

[0259] At 2206, the authentication smart contract instance receives verification from one or more secondary authenticators. In some embodiments, the authentication smart contract 2028 may include conditional logic that requests the opinions of secondary authenticators in response to receiving the primary authenticator's report. In some embodiments, the smart contract instance (or the primary authenticator) may provide the primary authenticator's report and supporting evidence to the secondary authenticator (after being assigned to the task) and may listen for responses from the secondary authenticators. Once received, the authentication smart contract 2028 may determine whether the requisite number of secondary authenticators have provided supporting opinions, and if so, the authentication smart contract instance executes logic to determine whether the secondary authenticators have verified the primary authenticator's opinion regarding the authenticity of the collateral item.

[0260] At 2208, a data block based on the authentication report, supporting documentation, and the secondary authenticator's opinion may be generated, and the data block may be written to the distributed ledger 2016. In some embodiments, the authentication smart contract may generate the data block and write the data block to the distributed ledger. Alternatively, the authentication smart contract may send the authentication report, supporting documentation, and the secondary authenticator's opinion to the ledger management system 202 (or another suitable system), which may in turn generate the data block and write the data block to the distributed ledger.

[0261] At 2210, the authentication smart contract instance may provide a notification to the loan processing smart contract 2022 indicating the outcome of the authentication task. In particular, the authentication smart contract may provide a notification to the loan processing smart contract 2022 indicating whether the item was deemed authentic by the primary authenticator and secondary authenticator(s). If so, the authentication smart contract instance may continue to proceed with the authentication workflow until the authenticator(s) who participated in the authentication process are rewarded (e.g., from repayment funds and / or proceeds of a liquidation event). If not, the authentication smart contract instance may terminate the authentication task.

[0262] At 2212, the authentication smart contract instance may lock an amount of currency from the authenticator to ensure authentication if the item is deemed unauthenticated. In some embodiments, the authentication smart contract instance may enforce requirements set forth in the authenticator's authentication stage-level governance and / or guild-level governance to lock a certain amount of currency (e.g., currency / tokens) when the authenticator(s) deem an item authentic, providing a greater amount of security to the lender. In this way, authenticators may have less incentive to authenticate items that may be counterfeit. In embodiments, the locked amount may be equal to or a percentage of the loan amount, total repayment amount, appraisal amount, or another suitable value, where the locked amount is defined according to the appraisal stage governance. In some embodiments, the locked currency tokens are returned to the authenticator during the repayment process, with the amount of locked currency from the authenticator not exceeding the remaining balance of the loan, providing a contingency if the locked currency is later discovered to be counterfeit.

[0263] At 2214, the authentication smart contract instance may transfer a reward amount to the authenticator who participated in the authentication task upon loan repayment. Once the loan process is completed (e.g., after the loan is repaid and the collateral item is returned to the borrower, after a liquidation event in which the buyer of the collateral item has a predetermined time after the sale to inspect the collateral item, and / or if the buyer decides not to participate in the loan and wishes to regain possession of the collateral item), rewards may be issued to the first authenticator and any second authenticators who participated in the authentication task. For example, authenticators may be rewarded with a percentage of the loan or repayment amount, a predetermined fee, and / or the like. Once the loan process is completed, the authentication smart contract instance may be torn down.

[0264] The example in Figure 22 is provided as an example of an authentication workflow. Other authentication workflows may be performed in connection with an authentication task. Additionally, within each authentication guild, members of each authentication guild may refine the authentication workflow and / or authentication smart contract to improve authentication for a particular task, provided that such refinements are subject to authentication stage-level governance.

[0265] Referring back to FIG. 20 , the appraisal stage-level governance may include a reference (e.g., an address) of the appraisal smart contract 2030 that may be used for an appraisal task. The reference may define an address that may be used to retrieve the appraisal smart contract 2030 (e.g., from the distributed ledger 2016). In these embodiments, the loan process smart contract 2022, the appraiser device 2006, and / or the tokenization platform 100 may instantiate an instance of the appraisal smart contract 2030 in response to the appraiser being assigned a new appraisal task and / or the appraiser accepting a new appraisal task via the appraiser device 2006. Once instantiated, the instance of the appraiser smart contract 2030 is written to the distributed ledger 2016, where the appraisal smart contract instance can be executed to manage the appraisal task. In embodiments, the appraisal smart contract 2030 may be configured to receive input from the appraiser device 2006, the borrower device 2002, and / or the tokenization platform 100, and may include conditional logic that determines whether all necessary steps have been performed in connection with the appraisal task based on the received input.

[0266] 23 is an illustration of the operations of a method 2300 that may be performed to execute an appraisal workflow. Method 2300 may be performed by a smart contract, such as appraisal smart contract 2030 or loan process smart contract 2022. For ease of explanation, method 2300 is described as being performed by an appraisal smart contract.

[0267] At 2302, the instance of the authentication smart contract 2030 may receive confirmation of receipt of the collateral item from the authenticator device 2006. In some scenarios, the collateral item is physically sent to a primary authenticator to perform the task. In such scenarios, the primary authenticator may confirm receipt of the collateral item using the authenticator device 2006. In these embodiments, the authenticator may provide images of the collateral item and note any visible damage to the item. Alternatively, the primary authenticator may be sent a VIRL of the collateral item. In these embodiments, the VIRL may include ultra-high resolution images of the collateral item and / or other media that can assist the authenticator in performing the authentication work. In some embodiments, the authenticator may receive additional information, such as confirmation that a set of authenticators have authenticated the collateral item.

[0268] At 2304, the appraisal smart contract instance may receive the appraisal report and supporting documents from the appraiser device 2006 of the primary appraiser. In these embodiments, the primary appraiser may be required to generate the appraisal report in accordance with the appraisal stage-level governance and / or guild-level governance of the appraisal guild to which the appraiser belongs. In some embodiments, the primary appraiser may generate the report using a form template included in the appraisal stage-level governance and / or guild-level governance of the appraiser's appraisal guild. The report may show the appraisal price determined by the appraiser and supporting documentation for the appraisal price. The supporting documentation may include links to blue book values ​​of similar items, screenshots of sales of similar items, historical data regarding sales of similar items, and / or other appropriate information supporting the appraiser's appraisal value. Once the appraiser provides the appraisal report, the report and supporting documentation may be provided to one or more secondary appraisers (if required by appraisal stage-level governance). In some embodiments, the appraisal stage-level governance or the appraiser's guild-level governance may require the appraiser to submit a liquidation value in the appraisal report in addition to the appraisal price.

[0269] At 2306, the appraisal smart contract instance receives validation from one or more secondary appraisers. In some embodiments, the appraisal smart contract 2030 may include conditional logic that requests the opinions of secondary appraisers in response to receiving the primary appraiser's report. In some embodiments, the appraisal smart contract 2030 (or the primary appraiser) may provide the primary appraiser's appraisal report and supporting evidence to the secondary appraiser (after being assigned to the task) and may listen for responses from the secondary appraisers. Once received, the appraisal smart contract 2030 may determine whether the requisite number of secondary appraisers have confirmed the primary appraiser's valuation.

[0270] At 2308, a data block based on the appraisal report, supporting documentation, and the opinion of the secondary appraiser may be generated, and the data block may be written to the distributed ledger 2016. In some embodiments, the appraisal smart contract may generate the data block and write the data block to the distributed ledger 206. Alternatively, the appraisal smart contract may send the appraisal report, supporting documentation, and the opinion of the secondary appraiser to the ledger management system 202 (or another suitable system), which may in turn generate a data block and write the data block to the distributed ledger 2016. In some embodiments, the data block may further include the liquidation value of the collateral item as determined by the appraiser.

[0271] At 2310, the appraisal smart contract may provide a notification to the loan process smart contract 2022 indicating the outcome of the appraisal task. In particular, the appraisal smart contract may provide a notification to the loan process smart contract 2022 indicating the appraised value. Assuming the borrower agrees to the loan agreement, the appraisal smart contract may continue to progress the appraisal workflow until one or more appraisers who participated in the appraisal process are rewarded (e.g., from repayment funds and / or proceeds of a liquidation event). If the borrower decides not to form a loan agreement and terminate the loan process, the appraisal smart contract may terminate the appraisal task.

[0272] At 2312, the appraisal smart contract may lock an amount of currency from the appraiser to secure the appraisal if the item does not liquidate for at least the appraisal value provided by the appraiser. In some embodiments, the appraisal smart contract 2030 may enforce requirements set forth in the appraisal stage-level governance of the appraiser's guild and / or guild-level governance to lock a certain amount of currency (e.g., currency / tokens) when one or more appraisers provide appraisal values, providing greater security for lenders. In this way, appraisers may have less incentive to appraise items at higher prices to improve the likelihood of a loan agreement being concluded. In embodiments, the locked amount may be equal to or a percentage of the loan amount, total repayment amount, appraisal price, or another suitable value, where the locked amount is defined according to the appraisal stage governance. In some embodiments, the locked currency tokens are returned to the appraiser during the repayment process, providing a contingency if the appraised item is sold in a liquidation event for a value lower than the appraised value, such that the amount of locked currency from the appraiser does not exceed the remaining balance of the loan.

[0273] At 2314, the appraisal smart contract may transfer the reward amount to the appraiser who participated in the appraisal task upon loan repayment. Once the loan process is complete (e.g., after the loan is repaid and the collateral item is returned to the borrower, or after a liquidation event), rewards may be issued to the primary appraiser and any secondary appraisers who participated in the appraisal task. For example, appraisers may be rewarded with a percentage of the loan or repayment amount, a predetermined fee, and / or the like. Once the loan process is complete, the appraisal smart contract instance may be torn down.

[0274] The example in Figure 23 is provided as an example of an appraisal workflow. Other appraisal workflows may be implemented in connection with an appraisal task. Additionally, within each appraisal guild, members of each appraisal guild may refine the appraisal workflow and / or appraisal smart contract to improve the appraisal for a particular task, provided that such refinements are in accordance with appraisal stage-level governance.

[0275] Referring back to FIG. 20 , custody stage level governance may include a reference (e.g., an address) of the custody smart contract 2032 that may be used for the appraisal task. The reference may define an address that may be used to retrieve the custody smart contract 2032 (e.g., from the distributed ledger 2016). In these embodiments, the loan process smart contract 2022, the appraiser device 2006, and / or the tokenization platform 100 may instantiate an instance of the custodian smart contract 2030 in response to the custodian being assigned a new appraisal task and / or the custodian accepting a new custodian task via the custodian device 2008. Once instantiated, the instance of the appraiser smart contract 2030 is written to the distributed ledger 2016, where the custodian smart contract instance can be executed to manage the custodian task. In embodiments, the custody smart contract 2032 may be configured to receive inputs from the custody device 2008, the borrower device 2002, and / or the tokenization platform 100, and may include conditional logic that determines whether all necessary steps have been performed in connection with the custody task based on the received inputs.

[0276] 24 illustrates an example of a method 2400 of operations that may be performed to execute a custody workflow. Method 2400 may be performed by a smart contract, such as custody smart contract 2032 or loan process smart contract 2022. For ease of explanation, method 2400 is described as being performed by an instance of a custody smart contract.

[0277] At 2402, the instance of the custodian smart contract 2032 may receive confirmation of the recipient of the collateral item from the custodian device 2008. In some scenarios, the collateral item is sent to the custodian for safekeeping during the pendency of the loan. Alternatively, the collateral may be deposited with the custodian by another party, such as the borrower. In either scenario, the custodian can confirm receipt of the collateral item using the appraiser device 2006. In these embodiments, the custodian can document the collateral item upon receipt, such as by taking a picture of the collateral item and noting any visible damage to the item.

[0278] At 2404, the custodian smart contract instance may receive a custodian report and supporting documentation from the custodian device 2008 of the custodian. In these embodiments, the custodian may be required to generate the custodian report in accordance with the custodian stage-level governance and / or guild-level governance (to the extent such a guild exists) of the custodian guild to which the custodian belongs. In some embodiments, the custodian may use a form template included in the custodian's stage-level governance and / or the custodian guild's guild-level governance to generate the report. In the report, the custodian may indicate that the item was received, the condition in which it was received, any damage observed on the collateral item, where the item is being stored, whether the item is in secure storage, and / or other relevant information. In embodiments, the custodian may provide supporting documentation, such as images of the collateral item, including any documentation of noticeable damage, images of the item in storage, etc. Once the custodian provides the secure storage report, the custodian report and supporting documentation may be written to the distributed ledger 2016.

[0279] At 2406, a data block based on the custody report and supporting documentation, and the opinion of the secondary appraiser may be generated, and the data block may be written to the distributed ledger 2016. In some embodiments, the custody smart contract may generate the data block and write the data block to the distributed ledger 206. Alternatively, the custody smart contract may send the custody report, supporting documentation, and the opinion of the secondary appraiser to the ledger management system 202 (or another suitable system), which may in turn generate a data block and write the data block to the distributed ledger 2016.

[0280] At 2408, the custody smart contract instance may lock an amount of currency from the vault to mitigate risks associated with property loss or damage during custody. In some embodiments, the custody smart contract 2030 may enforce requirements set forth in custody stage-level governance and / or guild-level governance to lock an amount of currency (e.g., currency / tokens) when an item is safe-kept, to provide greater security to the lender. In embodiments, the locked amount may be equal to or a percentage of the loan amount, total repayment amount, valuation value, or another suitable value, where the locked amount is defined according to the governance of the vault custody stage. In some embodiments, the locked currency tokens are returned to the vault during the course of repayment, such that the amount of locked currency from the vault does not exceed the remaining loan amount, to provide a contingency if the stored collateral item is damaged or lost. At 2410, the custodian smart contract instance may provide a notification to the loan processing smart contract 2022 indicating that the collateral item has been secured and that an event record 2052 related to the custodian task has been written to the distributed ledger 2016.

[0281] At 2412, the custodial smart contract instance may facilitate the transfer of ownership of the collateral item to the owner of the collateral token 2042 corresponding to the collateral item upon a redemption event. In embodiments, the redemption of the collateral token 2042 may be performed according to a collateral redemption workflow, which may be performed off-chain (e.g., by a trusted third-party computing system such as tokenization platform 100) and / or on-chain (e.g., by one or more smart contract instances). In embodiments, the collateral redemption workflow may include, but is not limited to, the following operations: These include receiving a request from a user device to redeem the collateral item represented by the collateral token 2042; verifying that the user attempting to redeem the collateral token 2042 is the legitimate owner of the collateral token 2042 based on ownership data 2052 stored in the distributed ledger 2016; identifying a custodian of the collateral item represented by the collateral token 2042 from the distributed ledger 2016 and / or the loan process smart contract 2022; sending a redemption notice to the custodian device 2008 of the identified custodian indicating that the claimant has redeemed the collateral token 2042; receiving a confirmation notice from the custodian device 2008 of the identified custodian indicating that the claimant of the collateral token has taken ownership of the collateral item; and burning the collateral token in response to receiving the notice from the custodian (as described above). In embodiments, the redemption workflow may include additional or alternative steps, such as receiving feedback from the redeeming owner of the collateral item indicating that the collateral item has been returned in satisfactory condition, and / or updating the distributed ledger 2016 to indicate the occurrence and content of such feedback event (which may be used for analysis and / or updating the custodian's rating).

[0282] At 2414, the custodian smart contract may transfer a reward amount to the custodian upon repayment of the loan and / or redemption of the collateral item. For example, the custodian may be rewarded as a percentage of the loan or repayment amount, a predefined fee, and / or the like. Once the loan process is complete, the instance of the custodian smart contract may be torn down.

[0283] The example in Figure 24 is provided as an exemplary custodial workflow. Other custodial workflows may be implemented in connection with a custodial task. Additionally, within a custodian guild, individual guild members may refine the custodian workflow and / or the custodian smart contract to improve custody of a particular item, provided that such refinements comply with custodian stage-level governance.

[0284] Referring back to FIG. 20 , loan stage-level governance may include a reference (e.g., an address) of the loan smart contract 2034 that may be used to monitor loan repayment. The reference may define an address that can be used to retrieve the loan smart contract 2034 (e.g., from the distributed ledger 2016). In these embodiments, the loan process smart contract 2022, the borrower device 2002, the lender device 2010, and / or the tokenization platform 100 may instantiate an instance of the loan smart contract 2034 in response to a loan agreement being concluded. In embodiments, loan negotiation is performed off-chain by the borrower and lender (e.g., via the tokenization platform 100). In these embodiments, the loan smart contract instance may be instantiated in response to the parties' agreement to the terms of the loan agreement. Once instantiated, the loan smart contract instance is written to the distributed ledger 2016, and the loan smart contract instance may be executed to manage the loan repayment stages. In embodiments, the loan smart contract 2034 may be configured to receive input from the borrower device 2002, the lender device 2010, and / or the tokenization platform 100.

[0285] 25 illustrates an example of the operations of a method 2500 that may be performed to execute a loan repayment workflow. Method 2500 may be performed by a smart contract, such as loan smart contract 2034 or loan process smart contract 2022. For ease of explanation, method 2500 is described as being performed by an instance of a loan smart contract. In the depicted example, loan smart contract 2034 may be instantiated at the time the borrower and lender agree to the loan agreement off-chain. However, in some embodiments, loan contract 2032 may be configured to facilitate loan negotiations as well.

[0286] At 2502, the loan smart contract 2034 instance may receive loan terms and establish a repayment schedule according to the loan terms. In some scenarios, the loan smart contract 2034 may receive the loan terms from a computing system (e.g., a tokenization platform) that facilitated the negotiation of the loan agreement. The loan terms may include the loan amount, loan term, loan repayment amount, interest rate, late fee penalties, default condition definitions, etc. In embodiments, the loan smart contract instance may determine the repayment schedule based on the repayment amount and loan term. The loan smart contract instance may determine the repayment schedule such that payments are distributed evenly over the loan term. The loan smart contract instance may determine the repayment schedule in any other suitable manner.

[0287] At 2504, the loan smart contract instance locks the collateral token in an escrow account, facilitating the transfer of funds from the lender's account to the borrower. In embodiments, once a loan agreement is established, the loan smart contract instance may lock the collateral token in an escrow account for the duration of the loan repayment period. Once the collateral token is locked, thereby preventing the borrower from redeeming the collateral token, the loan smart contract instance may facilitate the transfer of funds equal to the loan amount from the lender's account to the buyer's account. In some embodiments, the loan smart contract instance may transfer funds by updating the ownership data 2054 of the set of currencies / tokens 2044 owned by the lender to reflect the borrower's account.

[0288] At 2506, the loan smart contract instance listens for a payment event notification. In embodiments, the loan smart contract 2034 may be configured with an event listener that listens for a payment event notification. In some embodiments, the payment event notification may be received from the borrower device 2002, the lender device 2004, or a trusted third-party computing system (e.g., tokenization platform 100) that is facilitating the repayment of the loan. In embodiments, the payment event notification may indicate the amount paid and the date and / or time the payment was received.

[0289] At 2508, the loan smart contract instance may determine whether the scheduled payment has been received. If the payment has not been received, the loan smart contract instance may determine whether the loan is in default according to the loan contract. A loan can go into default if the borrower misses one or more payments, and the loan contract may define how many payments can be missed before the loan goes into default. If the loan is not in default, the loan smart contract instance may apply any penalties and / or fees to the principal balance and may continue to listen for payment event notifications.

[0290] If the loan is in default, the loan smart contract instance may initiate the liquidation of the collateral item, as shown at 2512. In some embodiments, the loan smart contract instance may provide a liquidation request to a marketplace (e.g., the marketplace system 102) indicating the collateral token 2042 and / or the VIRL wrapped therein. The liquidation request may include additional data such as the appraisal value, appraisal records, authentication records, custody records, and / or the remaining loan amortization amount. In response, the marketplace may conduct a liquidation sale. In embodiments, the liquidation sale may be a fixed-price sale (e.g., set at the appraisal value) or an auction (e.g., opening with the remaining loan amortization amount). Once the item is liquidated and the buyer pays for the collateral item, the loan smart contract instance may receive a liquidation notification indicating the item has been liquidated. In response, the loan smart contract instance may initiate the transfer of the collateral token 2042 used to secure the defaulted loan from the escrow account in which it was held to the account of the buyer of the collateral item. Once the collateral token ownership data 2054 is updated to indicate that the collateral token 2042 is owned by the buyer, the buyer may then redeem the collateral token 2042 (e.g., as described throughout this disclosure). In embodiments, the remaining amount of the loan is paid to the lender from the proceeds of the sale, as well as compensation for participants in the loan process (e.g., the certifier, appraiser, and / or custodian). At 2514, the loan smart contract instance may generate a data block indicating the default event and may write the data block to the distributed ledger, thereby creating a record of the default event.

[0291] If payment is received at 2508, the loan smart contract instance may determine whether the loan is paid in full, as shown at 2516. If the loan is not paid in full, the loan smart contract instance may determine the remaining amount of the loan repayment. In some embodiments, the loan smart contract instance may unlock currency / tokens 2044 for guild members who staked tokens in connection with performing their respective authentication, appraisal, and custody tasks. In embodiments, the loan smart contract instance may unlock an amount of tokens proportional to the payment received, as shown at 2518. In these embodiments, any guild member's remaining locked tokens do not exceed the remaining amount of the loan repayment.

[0292] If the loan smart contract instance determines that the loan has been paid in full at 2516, the loan smart contract instance may generate a data block indicating the repayment event and may write the data block to the distributed ledger, as shown at 1520. In this manner, the loan smart contract instance creates a record of the repayment event indicating that the loan has been paid in full. Once the loan has been repaid in full, the loan smart contract instance may issue a repayment notice to the loan process smart contract instance governing the loan and / or to tokenization platform 100, which may initiate the awarding of rewards to participants in the loan process (e.g., the certifier, appraiser, and / or custodian).

[0293] At 2522, the loan smart contract instance may unlock the collateral token 2042 from the escrow account and restore ownership to the borrower. In embodiments, the loan smart contract instance may update the ownership data 2054 of the collateral token 2042 to once again reflect that the borrower is the owner of the collateral token. Once the loan process is complete, the custody smart contract instance may be torn down.

[0294] The example of Figure 25 is provided as an exemplary loan repayment workflow. Other loan repayment workflows may be implemented in connection with lending and loan repayment without departing from the scope of this disclosure.

[0295] Referring back to FIG. 20 , in some embodiments, different variations of the decentralized loan process may include a pre-loan liquidation event. The pre-loan liquidation event may be a conditional liquidation sale that occurs before the loan is negotiated. Note that the sale may be a set-price sale, where the price is set prior to the sale, or an auction sale, where the collateral item is auctioned. In some embodiments, an exemplary loan process workflow may include a request stage, followed by an authentication stage, a safekeeping stage, and a tokenization stage (in any suitable order), followed by a pre-loan liquidation stage, followed by a loan stage and a repayment stage. In these exemplary embodiments, once the collateral item is authenticated, escrowed, and tokenized, an auction or set-price sale is conducted for the collateral item (e.g., via the marketplace system 102), whereby a buyer of the collateral item obtains ownership, triggered upon borrower default (or when the borrower decides to forgo the loan and relinquish ownership of the item). In this way, the borrower and lender know the true value of the collateral item before the loan is negotiated, whic...

Claims

1. receiving, by one or more processing devices, a request to initiate a loan process from a user device, the request indicating a borrower's collateral item; generating, with one or more processing devices, a virtual representation of the collateral item, the virtual representation including at least one of a description of the collateral item and one or more media content each depicting at least a portion of the collateral item; one or more processing devices generating a collateral token corresponding to the collateral item, the collateral token being a digital token stored on a distributed ledger distributed across a set of node devices; and instantiating, by one or more processing devices, a loan process smart contract instance comprising computer readable instructions configured to manage the loan process according to a loan process workflow, the loan process smart contract instance being at least partially executed by a set of node devices that store the distributed ledger, the loan process smart contract instance comprising: receiving a loan agreement notice indicating one or more loan term parameters of the loan agreed to by the lender and borrower, instantiating a loan smart contract comprising computer readable instructions configured to manage repayment of the loan based on the one or more loan term parameters, and locking the collateral token in an escrow account stored on the distributed ledger until the loan smart contract instance determines a change in a state of the loan related to a parameter of the loan that applies to the escrow of the collateral.

2. 2. The method of claim 1, wherein the computer readable instructions of the loan process smart contract instance further comprise instantiating an authentication smart contract instance including computer readable instructions configured to manage authentication tasks performed by an authenticator to authenticate the collateral item, and to issue an authentication notification upon confirming that the appraisal tasks are completed.

3. 3. The method of claim 2, wherein the loan process smart contract instance instantiates the authentication smart contract instance according to a loan process workflow.

4. 4. The method of claim 3, wherein the loan process workflow is defined in a system-level governance document stored in the distributed ledger, the system-level governance defining the conditions for initiating an authentication task.

5. 3. The method of claim 2, wherein the loan process smart contract instance instantiates the authentication smart contract instance in response to receiving a request notification indicating that a borrower has requested to initiate a loan process.

6. 3. The method of claim 2, wherein the computer readable instructions of the loan process smart contract instance are further configured to receive an authentication report from the authenticator's authentication device, the authentication report including an authentication opinion of the authenticator indicating an authentication status including whether the authenticator deemed the collateral item authentic.

7. 7. The method of claim 6, wherein the authentication report further includes supporting documentation provided by the certifier to support the authentication opinion.

8. 8. The method of claim 7, wherein the authentication report further includes one or more attestations issued by one or more respective secondary certifiers, each attestation indicating that a respective secondary certifier confirmed the authentication opinion.

9. The method of claim 6 , wherein the authentication report is generated from a form template defined according to an authentication stage level governance that defines a set of rules and regulations related to the performance of an authentication task.

10. 10. The method of claim 9, wherein the authentication stage level governance defines an authentication task workflow, the authentication task workflow including one or more conditions that must be satisfied to complete the authentication task and trigger the next stage of the loan process workflow to which the loan process conforms.

11. The method of claim 10 , wherein certification stage level governance is defined at least in part by a certification guild of which the certifier is a guild member.

12. The method of claim 11 , wherein the authentication guild includes a plurality of different specialized authentication guilds, each specialized authentication guild specializing in authenticating a respective type of collateral item.

13. 13. The method of claim 12, wherein the plurality of different specialty authentication guilds comprises at least a subset of the group including: a watch authentication guild specializing in authenticating watches, a shoe authentication guild specializing in authenticating shoes, a handbag authentication guild specializing in authenticating handbags, an art authentication guild specializing in authenticating art, a sports memorabilia authentication guild specializing in authenticating sports memorabilia, a toy authentication guild specializing in authenticating collectible toys, a jewelry authentication guild specializing in authenticating jewelry, a clothing authentication guild specializing in authenticating designer clothing, a musical instrument authentication guild specializing in authenticating musical instruments, a record authentication guild that authenticates rare or collectible records, a wine authentication guild specializing in authenticating wines in certain quantities, a whiskey authentication guild specializing in authenticating whiskeys in certain quantities, and an automobile authentication guild specializing in authenticating limited edition cars.

14. The method of claim 13 , wherein the certifier belongs to one of different professional certification guilds.

15. The method of claim 14 , wherein an authenticator is assigned an authentication task based on a professional authentication guild to which the authenticator belongs and the item type of the collateral item.

16. 10. The method of claim 9, wherein the authentication stage level governance defines an authentication smart contract from which an authentication smart contract instance is instantiated.

17. 10. The method of claim 9, wherein the authentication smart contract instance initiates a deposit of the currency tokens and / or the tokenization tokens from the authenticator's account to the escrow account in response to an authentication report indicating that the authenticator deems the collateral item to be authentic.

18. 20. The method of claim 17, wherein at least a portion of the deposited amount is held in escrow until the loan process is completed.

19. 7. The method of claim 6, wherein in response to receiving the authentication report from the authenticator device, the authentication smart contract instance outputs an authentication notification to the loan process smart contract instance, the authentication notification causing the loan process smart contract instance to initiate an appraisal stage of loan processing.

20. 7. The method of claim 6, wherein the authentication smart contract instance is further configured to generate a data block including the authentication report and a cryptographic hash value generated based at least in part on the authentication report, and write the data block to the distributed ledger.

21. The method of claim 2 , wherein a rating of a verifier is updated based on results related to a verification task.

22. 2. The method of claim 1 , wherein the computer readable instructions of the loan process smart contract instance are further configured to instantiate an appraisal smart contract instance including computer readable instructions configured to manage an appraisal task performed by an appraiser to determine an appraisal value of the collateral item, and to issue an appraisal notice upon confirming that the appraisal task is completed.

23. 23. The method of claim 22, wherein the loan process smart contract instance instantiates the appraisal smart contract instance according to a loan process workflow.

24. 24. The method of claim 23, wherein the loan process workflow is defined in a system-level governance document stored on the distributed ledger, the system-level governance defining the conditions for initiating an appraisal task.

25. 23. The method of claim 22, wherein the loan process smart contract instance instantiates the appraisal smart contract instance in response to receiving an authentication notification indicating that the authenticator has authenticated the collateral item and deemed the collateral item authentic.

26. 23. The method of claim 22, wherein the computer readable instructions of the loan process smart contract instance are further configured to: receive an appraisal report from the appraisal device of the appraiser, the appraisal report including a valuation of the collateral item including at least one of an appraisal value of the collateral item and a liquidation value of the collateral item.

27. 27. The method of claim 26, wherein the appraisal report further includes one or more of the physical condition of the collateral item, the new or used condition of the collateral item, the working condition of the collateral item, previous sales prices of similar items, and blue book valuations of similar items.

28. 30. The method of claim 27, wherein the appraisal report further includes one or more verifications issued by one or more respective secondary appraisers, each verification indicating that a respective secondary appraiser confirmed the appraisal value.

29. 27. The method of claim 26, wherein the appraisal report is generated from a form template defined according to an appraisal stage level governance that defines a set of rules and regulations related to the performance of an appraisal task.

30. 30. The method of claim 29, wherein the appraisal stage level governance defines an appraisal task workflow, the appraisal task workflow including one or more conditions that must be satisfied to complete the appraisal task and trigger the next stage of the loan process workflow.

31. 31. The method of claim 30, wherein appraisal stage level governance is defined at least in part by appraisal guilds of which the appraiser is a guild member.

32. 32. The method of claim 31, wherein the appraisal guild includes a plurality of different specialized appraisal guilds, each specialized appraisal guild specializing in appraising a respective type of collateral item.

33. 33. The method of claim 32, wherein the plurality of different specialized appraisers guilds comprises at least a subset of the group including: a watch appraiser guild specializing in appraising watches, a shoe appraiser guild specializing in appraising shoes, a handbag appraiser guild specializing in appraising handbags, an art appraiser guild specializing in appraising art, a sports memorabilia appraiser guild specializing in appraising sports memorabilia, a toy appraiser guild specializing in appraising collectible toys, a jewelry appraiser guild specializing in appraising jewelry, a clothing appraiser guild specializing in appraising designer clothing, a musical instrument appraiser guild specializing in appraising musical instruments, a record appraiser guild specializing in appraising rare or collectible records, a wine appraiser guild specializing in appraising a unit of wine, a whiskey appraiser guild specializing in appraising a unit of whiskey, and an automobile appraiser guild specializing in appraising limited edition cars.

34. 34. The method of claim 33, wherein the appraiser belongs to one of the different professional appraisal guilds.

35. 35. The method of claim 34, further comprising assigning appraisal tasks to appraisers based on the professional appraisal guild to which the appraiser belongs and the item type of the collateral item.

36. 36. The method of claim 35, wherein the appraisal stage level governance defines an appraisal smart contract from which an appraisal smart contract instance is instantiated.

37. 37. The method of claim 36, wherein the appraisal smart contract instance, in response to receiving the appraisal report, initiates a deposit of the currency tokens and / or the tokenization tokens from the appraiser's account to the escrow account, wherein an amount of the currency tokens and / or the tokenization tokens is less than or equal to the appraisal value.

38. 40. The method of claim 37, wherein at least a portion of the deposited amount is locked in an escrow account until the loan process is completed.

39. 27. The method of claim 26, wherein the appraisal smart contract instance outputs an appraisal notification to the loan process smart contract in response to receiving the appraisal report from the appraiser device, the appraisal notification causing the loan process smart contract instance to initiate a deposit stage of the loan process.

40. 27. The method of claim 26, wherein the authentication smart contract instance is further configured to generate a data block including the authentication report and a cryptographic hash value generated based at least in part on the authentication report, and write the data block to the distributed ledger.

41. The method of claim 22, wherein the ratings of the appraisers are updated based on results associated with the appraisal task.

42. 2. The method of claim 1 , wherein the computer readable instructions of the loan process smart contract instance are further configured to instantiate a custody smart contract instance including computer readable instructions configured to manage custody tasks performed by a custodian to safely store collateral items during at least a portion of the loan process, and to issue a custody notification upon confirmation that the custody tasks are completed.

43. 43. The method of claim 42, wherein the loan process smart contract instance instantiates the custodial smart contract instance according to a loan process workflow.

44. 43. The method of claim 42, wherein the loan process workflow is defined in a system-level governance document stored in the distributed ledger, the system-level governance defining the conditions for initiating a custodial task.

45. 43. The method of claim 42, wherein the loan process smart contract instance instantiates the custody smart contract instance in response to receiving an appraisal notification indicating that an appraiser has appraised the collateral item.

46. 43. The method of claim 42, wherein the computer readable instructions of the loan process smart contract instance are further configured to receive a custody report from a custodian device of the custodian, the custody report including verification that the collateral item is stored at a facility associated with the custodian and including an indication of any visible damage observed by the custodian when the collateral item was received.

47. 47. The method of claim 46, wherein the archival report further includes supporting documentation provided by the archival as proof of completion of the archival task.

48. 48. The method of claim 47, wherein the custody report further includes photographic documentation of any visible damage observed by the custodian when the secured item was received by the custodian.

49. 47. The method of claim 46, wherein the custody report is generated from an custody form template defined according to custody stage level governance that defines a set of rules and regulations related to the performance of custody tasks.

50. 50. The method of claim 49, wherein the custody stage level governance defines a custody task workflow, the custody task workflow including one or more conditions that must be satisfied to complete the custody task and trigger the next stage of the loan process workflow.

51. 51. The method of claim 50, wherein governance of the custodian stage level is defined, at least in part, by a custodian guild of which the custodian is a guild member.

52. 50. The method of claim 49, wherein the custody stage level governance defines a custody smart contract from which a custody smart contract instance is instantiated.

53. 53. The method of claim 52, wherein in response to receiving the custody report, the custody smart contract instance initiates a deposit of the currency tokens and / or the tokenization tokens from the custody account to the escrow account, wherein an amount of the currency tokens and / or the tokenization tokens is less than or equal to an appraised value as determined by the appraiser of the collateral item.

54. 54. The method of claim 53, wherein at least a portion of the deposited amount is locked in an escrow account until the loan process is completed.

55. 47. The method of claim 46, wherein in response to receiving the storage report from the storage device, the storage smart contract instance outputs a storage notification to the loan process smart contract, the storage notification causing the loan process smart contract instance to initiate generation of the collateral token.

56. 47. The method of claim 46, wherein the custody smart contract instance is further configured to generate a data block including the custody report and a cryptographic hash value generated based at least in part on the custody report, and write the data block to the distributed ledger.

57. 43. The method of claim 42, wherein the rating of the storage is updated based on a result associated with the storage task.

58. 43. The method of claim 42, wherein the custodian device provides one or more images of the collateral item that are used to generate the virtual representation of the collateral item.

59. 43. The method of claim 42, wherein the custodial smart contract instance is configured to execute a redemption workflow after the collateral tokens are unlocked from the escrow account.

60. 60. The method of claim 59, wherein the redemption workflow results in a redeemer of the collateral token taking possession of the collateral item from the custodian.

61. 10. The method of claim 1 , wherein the loan smart contract instance is configured to initiate a liquidation process in response to determining that the loan is in default.

62. 62. The method of claim 61, wherein the collateral token is transferred to a buyer who purchases the collateral token during a liquidation event, and the buyer redeems the collateral token to own the collateral item from a custodian who holds the collateral item.

63. 2. The method of claim 1 , wherein the loan smart contract instance is configured to initiate a transfer of the collateral tokens from the escrow account to the borrower's account upon determining that the loan has been fully repaid.

64. 64. The method of claim 63, wherein the collateral token is transferred from the escrow account to the borrower's account by updating ownership data defining a current owner of the collateral token such that the ownership data includes an address of the borrower's account on the distributed ledger.

65. The method of claim 1 , wherein the collateral token encapsulates a virtual representation of the collateral item.

66. 2. The method of claim 1, wherein the loan smart contract is configured to determine a loan repayment schedule based on a loan term and a loan amount of the loan defined in the loan term parameters, and the loan is considered to be in a default stage if a predefined amount of payments are not made according to the payment schedule.

67. 2. The method of claim 1, wherein the workflow of the loan process includes an authentication stage defining authentication tasks to be performed by an authenticator, an appraisal stage defining authentication tasks to be performed by an appraiser, and a custody stage defining custody tasks to be performed by a custodian, and the authentication stage, appraisal stage, and custody stage are performed before the collateral token is generated.

68. 64. The method of claim 63, wherein the loan instance smart contract instance facilitates allocating rewards to the certifier, appraiser, and custodian in response to completion of the loan process.

69. The method of claim 1 , wherein the collateral item is a tangible object.

70. 2. The method of claim 1, wherein the change in the state of the loan is at least one of the loan becoming fully repaid, the loan going into default and the collateral items being successfully liquidated, and a repayment state where collateral is no longer required as defined in the loan agreement.

Images