WO2024054665A1

WO2024054665A1 - Targeted blockchain transactions based on specialized non-fungible token tracking, minting, and transaction system

Info

Publication number: WO2024054665A1
Application number: PCT/US2023/032350
Authority: WO
Inventors: Victor W. TANG
Original assignee: Object Layer Technology Corporation
Priority date: 2022-09-09
Filing date: 2023-09-08
Publication date: 2024-03-14

Abstract

A system for minting a specialized non-fungible token (NFT), i.e., a project token, may mint the project token in a configuration to track a project type, ownership, future blockchain transaction, execution, and/or transaction schedules associated with the project token. The project token may further comprise one or more files. The system may be used to determine a group of current project token holders (regardless of whether they were the original owners of a project token) associated with a same type of project token and may facilitate future transaction(s) to that group of owners. The type of future transaction may be specified by the project token and may include cryptocurrcncy, a follow-on token that comprises one or more files, or the like. In some examples, the system may additionally or alternatively be configured to determine a subset of the group of holders that are trusted before conducting executing a future transaction.

Description

TARGETED BLOCKCHAIN TRANSACTIONS BASED ON SPECIALIZED NON-FUNGIBLE TOKEN TRACKING, MINTING, AND TRANSACTION SYSTEM

RELATED APPLICATION

[0001] This application is a non-provisional application that claims the benefit of priority from U.S. Provisional Patent Application No. 63/405,290, filed September 8, 2022, which is incorporated by reference herein for all purposes.

BACKGROUND

[0002] Blockchain technology is developing a mature industry around the minting and selling of non- fungible tokens (NFTs) across a variety of blockchains. Generating an NFT may entail the minting of a unique token representing a single file, such as an image, document, song, or video, which, once minted, publishes that file, accessible to all via a blockchain. These tokens have limited functionality — typically they can only be sold, transferred, or burned (i.e., destroyed) once created. However, toolsets and multiple marketplaces have been created to help with the minting and trading of these tokens. For example, these toolsets may include methods for executing a blockchain payment to a seller’s wallet for the purchase of an NFT and/or a minter’s wallet for the royalties from sale of an NFT.

[0003] However, existing blockchain technologies provide no technical means to ensure that NFT transfers comport with various regulations. Efforts to comport with these regulations may accordingly occur off the blockchain since there isn’t a technical means for comporting with such regulations, but this undermines a blockchain’s usefulness as a canonical source of relevant information for the minting or transfer of a token.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identify the figure in which the reference number first appears. The same reference numbers in different figures indicate similar or identical items.

[0005] FIG. 1 illustrates a block diagram of an example environment comprising a plurality of blockchain networks, a distributed file storage network, and a number of systems forming part thereof or connected thereto. [0006] FIG. 2 illustrates a block diagram of a host computing system and user device(s) connected thereto, along with components of the host computing system.

[0007] FIG. 3 illustrates a web user interface that may be used by an authenticated user accessing the web user interface via a user device to create, edit, and/or publish a project and/or to mint a project token. This data may be used as at least part of the project token and/or a metadata file associated therewith.

[0008] FIGS. 4A-4C illustrate a sequence diagram of an example process including operations of a first user to create and/or update a new proj ect, publish the proj ect for one or more other users to view and/or register for, and/or to mint one or more tokens for the project so that other user(s) can purchase or otherwise receive project token(s) minted for the project. [0009] FIGS. 5A-5C illustrate a sequence diagram illustrating operations that a user (e.g., a project originator, project candidate recipient, project recipient) may complete to become a trusted user and provide qualified and trusted wallet(s) that can be transferred a project token and/or follow-up blockchain transaction. [0010] FIGS. 6A and 6B illustrate a sequence diagram illustrating operations executed to process a followup blockchain transaction that may comprise payment to project token holders that meets regulatory requirements and/or a blockchain transaction comprising minting of a follow-on token, transmission of a message over a blockchain, and/or the like.

DETAILED DESCRIPTION

[0011] The techniques (e.g., hardware and/or software) discussed herein may include a system and/or processes for minting a token (e.g., an NFT or similar) with enhanced privacy controls and that facilitates or automates repayment by the originator of the token to a recipient of the token or a party to which the recipient transferred the token. The techniques may include tracking ownership of the token and/or ensuring that the entities receiving repayment are legally authorized to receive the payment despite the identity obfuscating nature of blockchain networks. The techniques may additionally or alternatively transmit a follow-up/futurc blockchain transaction to a subset of blockchain wallet addresses based at least in part on determining the blockchain wallet addresses ’ past or present token ownership, participation in a blockchain transaction, recency of ownership of a token, geographic location, a number of project tokens held by or a number of project-related blockchain transactions conducted with a blockchain wallet, and/or other criteria as may be specified by user input.

[0012] To achieve these ends, the techniques may comprise a host computing sendee that causes creation of the tokens, tracks their use, manages key(s) for encrypting/decrypting attachment(s) (e.g., file(s)) that may be the subject of or related to operation of the token(s), and facilitates or automates repayment to token holders and a particular configuration of an NFT schema, NFT enumeration, and/or metadata extension file that may be part of the minted token. This unique token schema is called a project token herein. In some examples, the techniques may be carried out on any blockchain network that supports NFT or similar protocols. In some examples, the project token may be minted into an ERC 721, ERC 1155, or other NFT compliant token, allowing the project token to be sold and traded on established marketplaces. However, unlike a typical NFT, the project token discussed herein may comprise links to two or more files (although in some instances a project token may include a singular file) and may comprise the metadata extension to contain project and/or payment details such as repayment execution, and/or repayment schedules as well as references to one or more project documents, just as registered securities documents, which may be encrypted. Extending existing NFT logic enables the tracking of token ownership which may then be used for the determination of recipients for future blockchain transactions.

[0013] Repayment, as discussed herein, may comprise determining, as a group of token holders, one or more blockchain wallets that currently hold a project token, as may be determined via the project token tracking discussed herein, facilitated by a minting processing that may comprise a joint computation by both blockchain network node(s) and the host computing service. In some examples, a wallet may be proactively created on behalf of a user for the purpose of minting a project token to be held by that wallet. In such an instance, the new wallet may be added to the group of token holders once the wallet address has been created. Once the group of token holders have been identified, repayment may comprise determining, via an extension file of the project token (e g., a metadata extension file and/or enumeration extension file) and/or file(s) referenced by the project token, a repayment type, which may define terms of the repayment, such as a period over which repayment will be made, a periodicity of the payment, a substance of the repayment (e.g., fiat, cryptocurrcncy, a file, another newly minted project token), and/or the like. In some examples, before repayment is executed the host computing system may additionally or alternatively determine whether a wallet in the group of wallets to which repayment is to be made: (1) is determined by the host computing system to be a trusted wallet by virtue of being associated with a digital identity account comprising personal information sufficient to verify the user’s identity using a know your customer (KYC) database and/or determine that the user passes anti- moncy laundering (AML) and/or Office of Foreign Assets Control (OFAC) checks, (2) is associated with a wallet score that meets or exceeds a threshold wallet score determined by a third-party service that scores wallets for involvement in potentially fraudulent activity, and/or (3) is indicated in a database, a blockchain transaction or other means as having previously given authorization for a first user to communicate with the user associated with the wallet in compliance with the privacy regulations, such as CAN-SPAM, GDPR, CCPA, or the like.

[0014] The forms of future transactions to wallets associated with the original transaction may transmit the same content as the original transaction, another token, or involve other types of data. For example, the original transaction may have comprised a fiat, project token, or cryptocurrency transfer from the project recipient to the project originator; a purchase of the project originator’s product or service (e.g., via a blockchain network or via traditional sales channels, in which case a wallet may be set up for the entity and a notification thereof transmitted to the project recipient): an onboarding process for an employee (the project recipient in such a case) including a submission of an employee’s personal details, etc. The repayment executed or caused to be executed by the host computing service may be the same or different. For example, the repayment may be a transfer of fiat, a new follow-on token, and/or cryptocurrency. In some examples, a follow-on minted as part of repayment may include and/or link to file(s) that may be the same or different than file(s) of an original project token.

[0015] To give a few practical examples, a first user (e.g., a borrower, the project originator in this case) may raise funds by minting a project token in exchange for remuneration provided by a second user (e.g., the project lender in this case). The project originator may use the system discussed herein to mint a project token for each project lender (the token recipient), such as the second user, in exchange for some consideration provided by the project lender. The project token may specify, via a metadata file, project terms such as a repayment schedule and/or type (e.g., repayment in kind, cryptocurrency repayment, fiat repayment, file repayment, follow-on token repayment), and/or the like, and document(s) which may be via DRM-protected or otherwise encrypted, such as regulation conforming funding documents (e.g., a project proposal, prospectus, funding terms, revenue projections, first user profile, financial regulator (e.g., the U.S. Securities and Exchange Commission) filing(s), and/or lender requirements). The smart contract(s) associated with the project token may identify the project originator’s wallet address, and the project recipients wallet addresses. Such a project token may be transferred to and held by the second user’s blockchain wallet and may be sold to another party by the original owner of the project token. Regardless, the project token may be used identify and/or automate repayment to and/or communication with a current holder of the project token. In some examples, any holder of a project token may access the files associated with the project token and the system discussed herein may allow the first user to define and/or encrypt those files. In some examples, the repayment portion of the project token may automate payment from the first user to a holder of the proj ect token, which may be the second user or a third user that purchased the project token from the second user.

[0016] In some examples, project types may vary, as may repayment types. In an additional or alternate example, the first user may mint a project token and transfer the project token to a wallet associated with a second user that purchased a product from the first user. That product may comprise the project token, a file associated with the project token, or may comprise a product sold outside a blockchain transaction. Moreover, the wallet may be created on behalf of the second user by the first user or the wallet may be a pre-existing wallet associated with second user. For example, where the second user is a customer or employee of the first user and may have transacted with the first user outside of a blockchain network, a wallet may be created on behalf of the second user. The repayment portion of the project token may cryptographically authorize the second user to access a file or repository of files, the minted project token may include such file(s), and/or the repayment may include a newly minted project token that contains the file(s). For example, the second user may access file(s) and/or content attached to the project token using a private key generated as part of minting the project token that can only be accessed by a wallet that is a current token owner.

[0017] To give a more concrete example, the first user may be an author and the second user may be an individual that purchased a book from the author, either by purchasing the book via a proj ect token, as described herein, or via a traditional purchase of a digital or hardcopy book. The system discussed herein may mint a project token for the second user and may track ownership of the project token. The first user may then use the repayment feature of the project token to generate a follow-on token comprising one or more files to owners and/or former owners of the first project tokens. For example, an author may mint follow-on tokens that include a chapter from a new book, an advanced reading copy of a new book, an audio clip or video of an interview of the author, or the like. In some examples, a follow-on token may be minted in a same or different protocol as the project token. A follow-on token is not considered a project token. Any of these files may be encrypted using a private key generated by a wallet of a recipient cryptographically signing the follow-on token as part of minting the follow-on token. A smart contract that is part of the minting process for the project token may control the decryption process, enabling authorized wallets, such as past or current token owners to decrypt the token documents.

[0018] In another example, project tokens may be minted and transmitted to wallet(s) associated with a subgroup of users for repayment of other kinds. For example, a project token may be minted for an employee of a company to identify wallets to which future repayments may be made as part of payroll, a project token may be minted for a wallet held by a device (e.g., an Intemet-of-things (loT) device) that may receive fde(s) as part of the repayment or the newly minted project token to conduct various operations (e g., change a display of the device, control operations of the device such as temperature control, security control, or the like using a file that is part of the repayment or a newly minted project token), a proj ect token may be minted for a subscriber or ticket/season ticket holder for that subscriber to receive tokens containing digital tickets or other file(s) as part of a subscription or ticket disbursement, and/or the like.

[0019] In some examples, the host computing device may comprise a messaging service, newsletter service, email service , or utilize other channels associated with wallets that currently and/or previously owned a project token, such as via an on-chain message to a wallet or directly to a digital identity associated with a user and displayed on a mobile wallet application of the wallet owner’s user device. In other words, sending a message via this messaging service may comprise sending a message to a wallet holder that the wallet associated therewith has been blacklisted and/or has a wallet score below a threshold score and is accordingly unable to receive payment. An example of a token sent directly to his wallet would be one with a title "Project Name Action Required for Payment" with a document listing the problem and how to resolve. In some examples, this messaging service may send messages using a message template or manually entered subject, body, and/or attachments, which may be the file(s) to be included in a project token. A repayment method may utilize a network that is not a blockchain network if that network has been registered as being owned by the recipient wallet. For example, this may include email, text messaging, voice, a bank account, and/or the like.

[0020] The techniques discussed herein may additionally or alternatively comprise a system for validating a user as a tmsted user by creating a digital identity associated with the user that has been verified via AML, KY C, and/or OFAC checks, and/or wallet scoring to uniquely identify a user and establish a system of trust for wallets. Thus, the system discussed herein may track current and/or previous owners and, for project tokens entitling current owners to repayment, determine a subgroup of current owners that are validated via AML/KY C/OFAC and/or wallet scoring or that have a currently valid digital identity account stored at the host computing system (or as a token held by the wallet). In some examples, a currently valid digital identity may be one where the host computing system detennined that payment to the user is authorized as determined based on AML, KYC, and/or OFAC check(s) that were conducted less than a length of time in the past, such as 1- month, 6-months, or 1 year, without limitation and for example. For current owner(s) of a project token that pass the AML/KY C/OFAC check and/or that have a wallet score that meets or exceeds a threshold wallet score, repayment may occur according to the repayment specified by the project token. Current owner(s) of a project token that aren’t in this subgroup — i.e., owner(s) that have not completed an AML/KYC/OFAC check or that own a wallet that has a wallet score that is less than a threshold or whose digital identity is not current by virtue of the AML/KY C/OFAC check having occurred at a time longer than the timer period — may have repayment withheld and may be notified of the AML/KYC/OFAC, wallet score, and/or non-current digital identity failure. Accordingly, the techniques ensure that all current owners entitled to repayment are in good standing with the relevant authorities and meet the requirements to participate in the funding process and are eligible to receive funds, payments, and/or distributions. In examples where repayment includes a file, message or other data instead of funds, this AML/KYC/OFAC check and/or wallet scoring may be skipped, although in some examples, the techniques may include repayment to current owners associated with wallets having wallet scores that meet or exceed a threshold wallet score.

[0021] The techniques discussed herein provide the transparency and accountability that the blockchain affords, while layering in additional trust through compliance checks of recipients of payments and/or wallet vetting to ensure that a recipient stays fully complaint with regulatory bodies. Additionally or alternatively, the techniques add regulatory compliant banking and payment functionality never before associated with NFTs, providing a project token originator a reliable and instantaneous means to provide payment to all project token recipients as well as to communicate with same. Moreover, the techniques use the metadata file generated as part of minting a project token to identify candidate wallets for subsequent (“follow-up”) blockchain transactions. Current NFT protocols currently require separately minting each file in a unique NFT and does not provide any specification or mechanism for controlling access to the document once minted. Minted NFTs contain documents that are fully accessible by the public. The techniques discussed herein address these shortcomings and defines a system and methods to provide access-controlled, private, multi -document project tokens, not just for ERC protocol tokens, but any blockchain.

EXAMPLE ENVIRONMENT

[0022] FIG. 1 illustrates a block diagram of an example environment 100 in which the techniques for minting a project token, tracking project token(s), determining analytics associated with project token(s) and/or their holding wallets, and/or managing and executing repayments to project token(s) herein may be implemented. The example environment 100 may comprise a first blockchain network 102 and/or a second blockchain network 104, such as Ethereum, Solana, Bitcoin (e.g., including use of the Ordinals protocol), Flow, Tezos, Cardano, and/or the like. In some examples, the techniques discussed herein may be conducted via a single blockchain network although in additional or alternate examples, tire techniques discussed herein enable the host computing system 106 discussed herein to mint project tokens on multiple blockchain networks. A blockchain network 102 may comprise various nodes, depicted as computing device(s) in the figures. In some examples, the nodes that participate in a blockchain network may individually store a copy of that particular blockchain’s ledger. Nodes that participate in the blockchain may comprise node(s) that transact on a blockchain node by operating on the blockchain ledger by requesting a follow-on token to be minted, transacting token(s), destroying token(s), etc.

[0023] Requests from these transacting nodes to mint/transact/destroy/etc., are transmitted to one or more mining nodes of the blockchain network. In some examples, such requests are transmitted to all mining nodes participating in the blockchain network and the first mining node to verify conformance of the request to protocols associated with the blockchain and to solve a proof of work problem or determine a proof of stake. Upon determining that the request comports with the protocols of the blockchain orthc type of token requested, a mining node may attempt to be the first to solve a proof of work problem and/or determine a proof of stake for the request. If the mining node solves the proof of work and/or determines the proof of stake before receiving a notification that another mining node has done so, the mining node may transmit a notification to the other mining nodes that includes the proof of work or proof of stake along with the requested operation on the blockchain ledger. So long as 51% or more of the miners affirm that this notification from the mining node is valid, the operation is then concatenated to the blockchain ledger, which may include concatenating a notification that a follow-on token has been minted along with what wallet holds the token, a transaction between wallets, a destruction of a token, and/or the like.

[0024] The host computing system 106 may comprise one or more computing devices and may be a node of one or more blockchain networks by virtue of sending requests, via network(s) 108, to a blockchain network (i.e., to create transactions on that specific blockchain), reading from the blockchain ledger, and/or potentially storing a copy of a blockchain ledger or salient portion(s) of the blockchain ledger. Each node in the blockchain network is interconnected to several other nodes, forming a fault-tolerant peer-to-peer network. Should a host node become unavailable, the host computing system 106 would connect to an alternate node within the blockchain network. For example, the host computing system 106 may determine a salient portion of the blockchain ledger by determining that such a portion of the blockchain ledger is the result of request(s) sent by the host computing system 106 to the blockchain network and/or the result of subsequent transaction(s) regarding a token that the host computing system 106 requested to be minted.

[0025] In some examples, the salient portion of the blockchain ledger may further comprise a portion that host computing system 106 predicts will be added to the blockchain ledger as a result of a request sent by the host computing system 106 to mining node(s) of a blockchain network in anticipation of the mining node(s) executing the request. In some examples, this predicted portion of the blockchain ledger that the host computing system 106 stores may comprise an indication that such a portion is merely predicted until a confirmation of execution of the request is received from the blockchain network (e.g., by receiving notification of a newly added block that includes execution of a request transmitted by the host computing system 106). The host computing system 106 may reduce the latency associated with mining by storing this predicted portion of project data instead of waiting for the block to be added by a mining node. [0026] In some examples, the host computing system 106 may receive a request, via network(s) 108, from a user device 110 associated with a user 112 to mint a new project token having the configuration discussed herein. In some examples, the user device 110 may have a mobile wallet application stored thereon or a browser that accesses a webpage hosted by the host computing system 106. For example, the host computing system 106 may store and/or execute a user component that may provided hosted services for the user device 110 to communicate with and/or access, such as via an API. The host computing system 106 may receive project data discussed herein from the user device 110, such as via a user interface of the user device. In some examples, a first portion of the project data may be used to populate a data structure that is compliant with an NFT creation protocol, such as ERC 721, ERC 1155, Solana NFT, Solana Cardinal, MANA token, Origin protocol, or the like . For example, the first portion of the proj ect token may comprise a link to a metadata file which additionally includes links to project files, all stored in a distributed storage system 114 that are to be part of a newly minted project token, an address of a wallet associated with a recipient of a project token, and/or the like. In some examples, the wallet associated with the recipient may be accessed via a mobile wallet application stored and executed on a second device 116.

[0027] Encryption keys associated to the project data may be stored at the host computing system 106 or within a Smart contract stored on a blockchain network 102. Project files are typically stored in a distributed storage system 114 as part of a metadata extension and/or enumeration extension file (i.e., collectively and separately “a metadata file,” herein) that may be stored separately from the blockchain ledger, but may be referred to via a network address in the project token. In some examples, the metadata file may store various data discussed herein associated with a project token that may be used to define project characteristics (e.g., identifier, project type, description, prospectus), repayment data and/or rules, automate repayment, determine metric(s) associated with a project token, determine a portion of a blockchain ledger that is relevant to a project token. In some examples, the repayment data and/or rules may comprise repayment terms, repayment schedule, and/or a repayment method, such as a real or digital product, such as one or more files (which may be transmitted as part of a subsequent project token); share issuance; principal and/or interest payments; a percentage of revenue; and/or the like.

[0028] In examples where repayment includes a payment of fiat or cryptocurrency to a project token holder, instead of file(s), the metadata file may additionally or alternatively include network address links to verification document(s) for an asset, a funding type (e.g., equity, revenue-based financing, annuity, etc.), requirement(s) for repayment eligibility (e.g., such as creating or having a blockchain wallet and/or establishing a digital identity/account with the service provided by the host computing device), computer-readable configuration data defining the loan tenns repayment details, and/or other sensitive loan data in encrypted format, such as an account or blockchain wallet address to transfer cryptocurrency from to make the repayments. [0029] In some examples, all or portion of the metadata file or a copy thereof may be stored at the host computing system 106 and/or at the distributed storage system 114.

[0030] As noted above, the host computing system 106 may also be connected, via network(s) 108, to a distributed storage system 114. In some examples, the host computing system 106 may store file(s) for a project token and a metadata file associated with the project token at the distributed storage system 114. The distributed storage system 114 may be a cloud storage system, peer-to-peer network (e g., interplanetary file system (IPFS)), or the like and may store file(s) that may be linked to by the project token(s). In some examples, each storage node in the distributed storage system 114 may be interconnected with other storage nodes, such as via network(s) 108, providing redundancy and fault tolerance as a peer-to-peer or cloud storage network. Other computing device(s), such as user device 110 and/or second device 116 may connect to the distributed storage system 114 via service(s) hosted by component(s) of host computing system 106 to directly store and/or retrieve files in the distributed storage system 114.

[0031] For example, the host computing system 106 may host a web page with authentication and networking protocols for facilitating these connections. In some examples, a mobile wallet application stored and executed by the second device 116 may access a webpage hosted by host computing system 106 and/or token(s) stored on blockchain network 102 and/or blockchain network 104 and in so doing may upload to and/or download content from the distributed storage system 114 as part of the mobile wallet applications interactions with the webpage and/or the token(s). In some examples, the mobile wallet application stored on the second device 116 may establish an independent connection to any blockchain network and the blockchain wallet(s) contained therein.

[0032] In order to include multiple files within a single project token, the project token may include or link to a metadata file permissible in many NFT protocols, which may be implemented as a metadata.] son discussed further herein. This metadata file may at least one of be stored in the distributed storage system 114. In some examples, the file(s) stored in the distributed storage system 114 may be part of repayment triggered by terms set in the project token, independently from or as part ofnewly minting a project token. The file(s) may include, for example, text, document file(s), audio file(s), video file(s), image(s), executable (s), data structure(s), and/or the like.

[0033] The NFT protocols used to mint the project token discussed herein may provide a link to any of the file(s) discussed herein, whether they are part of a fiat or cryptocurrency repayment or whether the repayment is a file or set of files. Traditionally, these file(s) would be viewable by anyone with access to the blockchain network. However, the host computing system 106 and/or the distributed storage system 114 may encrypt the file(s) using a private key generated by a host computing system as part of minting the project token or as part of a transfer of the project token from one wallet to another or may prevent network or memory access to the files without the accessing wallet having ownership of the tokens and able to demonstrate ownership of the wallet’s private key to a Smart contract or Host computing system controlling access to the key. For example, the host computing system 106 and/or distributed storage system may be configured to deny access to the files unless a wallet presents a blockchain wallet address currently associated with ownership of the project token and executes a cryptographic signature demonstrating possession of the private key for wallet owning the project token (e.g., using asymmetrical keys, hashing, and digital signatures to prove possession of the private key). In either case, anyone with access to the blockchain ledger may be able to see the link to the files or a preview of the files, but may be unable to access them.

[0034] In an example where ownership of the project token has changed, the host computing system 106 or security smart contract may track ownership of the project based at least in part on transactions recorded in the blockchain ledger that identify that the first wallet address transferred the project token (identified by its token and collection id) to a second wallet address and may utilize a smart contract that encrypts the private key and is configured to verify ownership of the project token before providing access to the private key to a requestor. For example, if a first wallet address transfers the project token to a second wallet address via a blockchain transaction, the security smart contract may authenticate the requesting wallet and verify that the request signature is signed by the private key associated with the wallet address. Once authenticated, the security smart contract (or host computing system) may query the token Smart contract to confirm that the calling wallet is the token owner. Having confirmed ownership, the security smart contract would return the decrypted document, or return the project token encryption key to the host computing system to decrypt and return the project documents for the calling document

[0035] The host computing system 106 may use the project data received from a user device to transmit a request to a blockchain system in the form of a data structure for the mining node(s) of the blockchain network. As discussed above, this request may include a request to mint a new token (that, together with the remainder of the project data stored at the host computing system 106 and/or the distributed storage system 114 composes the project token), transfer a project token, destroy (bum) a project token, and/or the like. In some examples, the project data may specify which blockchain system to which to transmit a request. Accordingly, the particular data structure, file type, and/or formatting for the request may depend on the blockchain indicated in the project data to comport with a protocol associated with the particular blockchain network.

[0036] In some examples, the request to mint a new token may identify a wallet associated with a second user 118, who may be a project token recipient or purchaser, depending on the use case. The project token recipient may be, for example, a lender, subscriber, customer, employee, loT device, or the like. In an example where the project recipient is an loT device, the file(s) stored in the distributed storage system 114 may comprise an executable and/or data structure (e.g., a configuration and/or settings file) usable by the loT device as part of its execution. In some examples, the second user 118 may be required to set up a digital identity/account hosted by the host computing system 106, e.g., via a web or mobile application at the second device, such in examples where repayment includes transfer of funds. In such an example, setting up the digital identity/account may comprise requesting the user to provide credential(s) signed (e.g., physically, digitally, or cryptographically) by a third-party AML/KYC/OFAC verifier, providing personal information, and/or authorization to conduct AML, KYC, and/or OFAC checks and/or obtain AML/KYC/OFAC credential(s) on behalf of the user. The personal information may include, for example, one or more of a first name, middle name, last name, address, social security number, occupation, credit card number and/or other payment instrument identifier(s), phone number, tax identification number, driver’s license number, birthdate, biometric data, etc

[0037] According to the techniques discussed herein, a user may use the host computing system 106 to issue a first set of project tokens to a first set of blockchain wallet addresses via a first blockchain transaction, which may include a single or multiple sub-transactions on the blockchain network. In some examples, issuance of the first set of project tokens may comprise transferring one project token to one blockchain wallet, but in additional or alternate examples, multiple project tokens may be issued to a single blockchain, such as when the project tokens include disparate files, have a fixed price, or the like, wallet, or one project token may be issued to multiple blockchain wallets.

[0038] After the user has issued the first set of first project tokens via the host computing system 106 and the operations discussed herein, the user may initiate, by sending a request to the host computing system 106, via user device 110, to initiate a second blockchain transaction with a second set of blockchain wallet addresses that may be determined based at least in part on querying a Token Smart contract and/or transactions on a blockchain ledger, possibly via an indexing database, determine to include a first blockchain wallet address in the second set of blockchain wallet addresses based at least in part on various criteria including:

• the first blockchain wallet address being a present or past proj ect token holder of one of the first proj ect tokens,

• determining the first blockchain wallet address held one of the first project tokens within a within a last time period (e g., the last month, year, any other time period),

• the first blockchain wallet participating in a blockchain transaction (e.g., with a previous holder of a first project token, with a wallet associated with a user that created the first set of first project tokens using the techniques discussed herein),

• determining that the metadata file, digital id verification data, user browser ip data, or other data indicates that the first blockchain wallet address is associated with a geographic location or region, and/or

• other criteria that may be selected or submitted by the user, such as determining blockchain wallet address(es) owning a specified number of or specific token ids.

[0039] In some examples, if the second blockchain transaction will include a payment, the host computing system 106 may further determine a subset of the second set of wallet addresses that are associated with a currently valid digital identity; have passed AML, KYC, and/or OFAC check(s); and/or have a wallet score that meets or exceeds a threshold wallet score. Blockchain wallet addresses not included in this subset may be excluded from the second blockchain transaction and a message blockchain transaction may be sent to this subset instead of a payment transaction, informing the owners of this wallet subset that action is needed on their part to receive payment. In some examples, regardless of whether the second blockchain transaction includes a payment, the user may optionally select or the host computing system 106 may enforce one or more of these wallet safety determinations to determine a subset of the second set of blockchain wallet addresses. In some examples, a user may provide input to forgo these safety determinations so long as the project type and/or second blockchain transaction does not include a payment.

EXAMPLE HOST COMPUTING SYSTEM COMPONENTS AND OPERATIONS

[0040] FIG. 2 illustrates a block diagram of an example architecture 200 comprising a host computing system 106 and user device(s) connected thereto via network(s) 108. FIG. 2 also depicts particular components of the host computing system 106. In some examples, the host computing system 106 may be a single computer, server(s), and/or a distributed computing device(s), such as cloud computing device(s). In some examples, at least one of the host computing system 106 dcvicc(s) may be a member or host node of a blockchain network, such as blockchain network 102, although, in some examples, the host computing system device(s) may be a member or host node for multiple blockchain networks.

[0041] In some examples, the host computing system 106 may comprise processors) 202, memory 204, and/or network interface(s) 206. Processor(s) 202 may comprise any suitable processing unit, such as central processing unit(s) (CPU(s)), graphics processing unit(s) (GPU(s)), tensor processing unit(s) (TPU(s)), integrated circuits (e.g., application-specific integrated circuits (ASICs)), field-programmable gate arrays (FPGAs), microcontroller(s), digital signal processor(s), and/or the like. In some examples, the processor( s) 202 may include one or more hardware processors configured and/or specifically programmed to execute software operations described herein. The processor(s) 202 may be configured to fetch and execute computer-readable processor-executable instructions stored in the memory 204 to conduct any of the operations discussed herein.

[0042] In some examples, the memory 204 may comprise one or more tangible non-transitory computer- readable media and can include volatile and/or nonvolatile memory and/or removable and/or non-removable media implemented for storage of information such as computer-readable processor-executable instructions, data structures, program modules or other data. In various implementations, the memory may be implemented using any suitable memory technology, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic RAM (SDRAM), non volatile/Flash -type memory, or any other type of memory capable of storing information. Tire architectures, systems, and individual elements described herein may include many other logical, programmatic, and physical components, of which those shown in the accompanying figures are merely examples that are related to the discussion herein. Further, in some examples, the host computing system 106 may access external storage, such as RAID storage systems, storage arrays, network-attached storage, storage area networks, peer-to-peer storage, cloud storage, or any other medium that can be used to store information and that can be accessed by the processor(s) 202 directly or through another computing device or network.

[0043] In some examples, the host computing system 106 may include network interface(s) 206 that include one or more interfaces and hardware components for enabling communication with various other devices, such as over the network(s) 108 or directly, and/or facilitating communication between devices, such as between any one or more of user device 110, second device 116, distributed storage system 114, and/or blockchain network 102 (or other blockchain nctwork(s)). For example , the network intcrfacc(s) 206 may facilitate communication with other local computing device(s) in a local network with host computing system 106 such as individual computing devices of the host computing system 106 and/or other device(s) such as those mentioned above. The network interface(s) 206 may enable Wi-Fi-based communication such as via frequencies defined by the IEEE 802.11 standards, short range wireless frequencies such as ultra-high frequency (UHF) (e.g., Bluetooth®, satellite), cellular communication (e.g., 2G, 3G, 4G LTE, 5G, etc.), and/or any suitable wired or wireless communications protocol that enables the respective computing device to interface with other computing device(s). In

[0044] Memory 204 may store a login component 208, project component 210, user component 212, messaging component 214, originator administration component 216, recipient administration component 218, and/or administrator component 220, any of which may be implemented in hardware and/or software. Software component(s) thereof may be implemented as processor-executable instructions that, when executed by the processor(s) 202, perform the operations discussed herein.

[0045] In some examples, the component(s) of the host computing system 106 may execute operations to deploy smart contracts on one or more blockchain networks, mint project tokens on one or more blockchain networks, and query, transfer, and/or bum said tokens. In some examples, the components discussed herein may comprise various software that accomplishes the operations discussed herein and provides access to these components and outputs therefrom via an application programming interface (API) or individual APIs. In some examples, a website may make calls via the APIs to respective ones of the components and/or may provide inputs and/or receive outputs from one or more of the components directly. In some examples, the user device 110 and/or second device 116 may connect to this website to interface with the components) stored in memory 204.

[0046] In some examples, the login component 208 may establish a connection between the user device 110 and a mobile wallet application 222, between the second device 116 and the mobile wallet application 222, and/or between the mobile wallet application 222 and a user account associated with the user stored in memory 204. For example, the second device 116 may establish a connection to the mobile wallet application or run an instantiation of the mobile wallet application for a user to sign transactions to be performed on a blockchain with the blockchain wallet configured within the mobile wallet application for that user. In some examples, the mobile wallet application 222 may comprise services hosted by servers separate from the architecture depicted or, in additional or alternate examples, may be hosted by the host computing system 106 and/or distributed storage system 114. In additional or alternate examples, the mobile wallet application 222 may comprise an executable installed on the user device 110 and/or the second device 116 and may operate independently (without any sendees hosted elsewhere) or may call to such services. In some examples, the mobile blockchain application may comprise a mobile blockchain wallet for signing blockchain transactions initiated by another computing device. For example, the second device 116 may store the mobile wallet application 222 and a user may use the mobile wallet application to sign a project token as part of minting the project token. In some examples, the login component 208 may implement password, biometric, two-factor authentication, and/or the like.

[0047] In some examples, the login component 208 may additionally or alternatively interface with the user component 212 to execute account management operations and verify that a user accessing the host computing system 106 and/or operations provided by the component(s) thereof has completed AML, KYC, and/or OFAC checks. For example, the user or a service authorized on the part of the user may submit a credential signed by a third-party AML, KYC, and/or OFAC verifier, such as via the OpenlD 4 verifiable credential issuance standard, verifiable credentials data model, or the like. In some examples, this credential may be appended to their digital identification or stored in association with the digital identification. In some examples, the completed verification may be represented by a blockchain token that is issued to the verified user’s wallet. In some examples, the blockchain token indicating the completed verification may indicate an expiration date associated with the completed verification. In some examples, the user component 212 may receive personal information from the userto conduct such checks and/or receive such credentials on auser’s behalf. Regardless, the user component 212 may save these credentials and/or the results of these checks in association with a user’s unique decentralized digital identity that may be bound to an account identifier associated with the user that may be stored in memory 204. In some examples, the login component 208 and/or user component 212 may identify the user as a project originator, a project recipient, or both by associating the user’s digital identity and/or account identifier with an indication thereof. This indication may be used to control which webpages, API(s) or portions thereof, and/or component(s) the user has access to.

[0048] The login component 208 may additionally or alternatively comprise an interface for creating a blockchain wallet or connecting an existing wallet to a user’s account. Either way, the login component 208 may track whether the user has proven ownership of a blockchain wallet. In some examples, the login component 208 may execute a verification that a connected wallet is active and/or contain tokens indicating that user compliance verification has been completed and is in good standing. In some examples, the login component may interface (e.g., by transmitting request(s) and/or receiving response(s)) from third party servers that determine regulatory compliance of a user account associated with a wallet and/or wallet vetting, such as by AML, KY C, OFAC, and/or wallet scoring services running on remote servers. In some examples, the wallet scoring may comprise determining a fraud risk and/or safety score associated with the wallet based at least in part on a history of transactions in one or more blockchain ledgers associated with the wallet. The login component 208 (and/or user component 212) may thereby indicate whether an account is in good standing and/or may notify a user of items to be rectified, such as updating AML/KYC/OFAC credential(s), submitting new regulatory documents such as proof of investor accreditation, and/or the like.

[0049] In some examples, project component 210 may manage project webpage(s) for a project created by a user and/or project data related to the project. In some examples, the project component 210 may cause rendering of the project data and/or webpage details via a browser. A project may include a blockchain transaction that includes or is based on the metadata file discussed herein. The blockchain transaction may include minting a project token or may include a follow up blockchain transaction including other blockchain transaction operations, such as transferring cryptocurrency, recording bank account debit/deposit, instantiating or executing a smart contract, transmitting a message via the blockchain, and/or the like. The project data may include data for minting a project token and/or project properties for creating at least part of a metadata file to be associated with the project token. Remaining portions of the project properties in the metadata file may include data specific to a recipient and/or recipient wallet of the project token. In some examples, the project component 210 may further retrieve from the metadata file the file names, file types, content addresses (CIDs), part of a distributed hash table (DHT) for file storage, network addresses linking to a file stored in the distributed storage system 114, and/or the like to facilitate attaching and/or linking file(s) to a project token and/or blockchain transaction The project component 210 may additionally or alternatively manage a database caching or “indexing” this information and other project token information. In some examples, the project component 210 may administrate access to such files, such as by instantiating and/or administrating smart contracts to transfer key(s) for decrypting files and/or using OAuth

[0050] In some examples, the project component 210 may additionally or alternatively comprise a database fortracking a stage of a project, which may be controlled by user input provided via instructions received from the user device 110, although in additional or alternate examples, the stage may be defined by a set of rules based on a state of the proj ect, such as whether full or partial proj ect data has been received; whether the proj ect has been published, broadcasted, or otherwise submitted to a candidate project recipient; whether a project token has been submitted for recipient cryptographic signature; whether a recipient wallet has cryptographically signed a project token for minting; whether a project token has been minted or a blockchain transaction has been conducted; whether a blockchain network has verified addition of the blockchain transaction to the blockchain ledger; a funding status of the project; and/or the like. In an example where the project comprises raising funds for a project, for example, the project stages may include, without limitation:

• “Proposed,” e .g . , a proj ect originator may have created a new proj ect on the host computing system 106 and can review and update project data related to the new project until it is published to candidate recipients for their review; • “Pending : ” a proj ect may be indicated as ready for publishing based at least in part on determining that a set of criteria have been satisfied, such as but not limited to the indication of the funding type, funding amount, required project recipient experience and/or qualifications, whether any documents required by regulation have been uploaded and/or referenced in the metadata file, whether attributes such as subject matter and/or geolocational tags have been associated with the project type (e.g., “book,” “music subscription,” “season tickets,” “newsletter,” “loan,” “esg,” “usa”), whether an administrator of the host computing system 106 has reviewed and/or approved the project for publishing;

• “Published,” e.g., a project may have been published, such as to a token marketplace website, via an email, and/or the like in a manner that enables candidate recipients to find and review the project. In some examples, the host computing system 106 may provide functionality to allow a candidate recipient to register their email and/or connect the project to their account/digital identification stored with the host computing system 106 and may indicate how many units they may be interested in purchasing. In some examples, project(s) in this phase do not yet have a minted project token and/or have not cause a blockchain transaction to occur;

• “Funding,” e.g., a project that has been deployed and minted as aproject token. Accounts that indicated interest in purchasing project token(s) may be notified and the project token(s) may be available to be purchased;

• “Funded,” e.g., the minimum number of units defined in the project funding documents have been purchased prior to a funding deadline.

[0051] Note that all of these are given as mere examples and are particular to the singular example of raising funds, although it is contemplated that the techniques discussed herein may be used for a variety of other projects, the project statuses and rulesets of which may vary.

[0052] In some examples, the user component 212 may store and/or manage accounts, digital identification associated with a user account, user account roles and pennissions (e.g., which component(s), API(s), portion(s) of API(s) to which a user has access, whether a user can publish a project without administrative review), wallet score(s) and/or date(s) associated therewith, AML/KYC/OFAC credentials and/or dates of certification, etc.

[0053] The messaging component 214 may facilitate communication between a project originator and one or more project recipients determined, in accordance with the ownership information tracked by the Smart contract that minted the project token, blockchain transaction records and/or other data associated with a user wallet, to be associated with a same project identifier, to be current or previous holders of a same set of project tokens, to be a recent holder of a project token (e.g., held the project token within a threshold amount of time from the present), to have participated in a blockchain transaction, to be associated with a geographic location or region, or other criteria. In some examples, the messaging component may transmit a message via email or via an on-blockchain communication, such as via a blockchain transaction that comprises a message or a proj ect token that comprises the message. In some examples, such a message may include attachments, such as one or more files that may be linked to the project token or transaction using the metadata file discussed herein.

[0054] The originator administration component 216 may store and manage a database and/or cause rendering of a dashboard related to the database formanaging aprojectoriginator’sprojects. In some examples, this dashboard may be used to access a specific project webpage and/or project data associated with a project, create a new project, and/or track metrics associated with project (e.g., metrics determined based at least in part on a metadata file associated with a project or project token, smart contract token data, blockchain transaction history, and/or project database records), analytics and/or reports related to a status and/or progress of the project, and/or the like. In some examples, user may use this dashboard to initiate a blockchain transaction. The blockchain transaction may comprise repayment for a project token that was purchased as part of a funding project, a blockchain payment, minting of a follow-on token (e.g., which may comprise one or more files), a message, and/or the like. In some examples, the dashboard may provide an option to allow the blockchain transaction to occur automatically upon satisfaction of one or more conditions, such as terms of a funding project (c.g., repayment at certain intervals or on certain dates), determining that a file having a file name was uploaded to the distributed storage system 114 (e.g., a newsletter, music file, book, ticket QR code image) and/or was identified in a metadata file, determining that a metadata file indicates authorization to automatically cause the blockchain transaction to on a date or a certain amount of time after the project token was minted, transferred, and/or the like.

[0055] In some examples, the dashboard may provide tools for determining a set of blockchain wallet addresses to which to direct the blockchain transaction. For example, the dashboard may allow a user to select various options for determining the set of blockchain wallet addresses based at least in part on metadata file property(ies), metrics associated with the metadata file and/or blockchain transactions associated with a previous project token, and/or the like. For example, the user may determine the set of blockchain wallet addresses to be blockchain wallet addresses that currently hold the previous project token, previously held the previous project token, both current and previous holders of the previous project token, held the previous project token within a threshold amount of time ago, participated in a blockchain transaction, received a separate project token from the same originator that generated the previous project token, and/or any of the properties identified in the metadata file (e.g., geolocation, annotations associated with a project such as a project identifier and/or tags). In some examples, such a set of blockchain wallet addresses may be reduced to a subset of blockchain wallet addresses for any blockchain wallet addresses determined to not be associated with a verified account (e.g., a digital identification with AML/KYC/OFAC credential(s) associated therewith) or that are associated with a wallet score that is below a threshold wallet score.

[0056] In some examples, the recipient administration component 218 may store and manage a database and/or cause rendering of a dashboard related to the database for managing projects the project recipient is interested in and/or projects that resulted in transferring a project token to a wallet associated with the project recipient. In examples where a user is both an originator and a recipient or candidate recipient, the dashboard may be the same and/or may include delineations or identifiers of those projects the user is originating, potentially receiving a blockchain transaction from, and/or has or will receive a blockchain transaction from. In some examples, the project recipient dashboard may further comprise suggestions of other projects generated by a same originator or same attribute(s) (e.g., as specified in a metadata file) as a project that the project recipient is interested in or that the recipient has received a blockchain transaction from, and/or the like. In some examples, the dashboard may further indicate terms, states, and/or the like of a proj ect, and may indicate an anticipated future blockchain transaction related to the project and/or a preview thereof. The recipient dashboard may additionally or alternatively enable a recipient to purchase a project token, put a project token up for sale in a marketplace, identify a different wallet blockchain address for a future blockchain transaction to be directed to (e.g., that may or may not be associated with the recipient), receive market data related to a project token, and/or verify and/or monitor the status of credential(s) and/or wallet scores associated with the recipient and/or the wallet(s) associated with that user.

[0057] Note that a recipient of a project token may sell such a token at any existing NFT marketplace that supports the blockchain network on which the project token was minted. Upon opening a project token, a user, such a prospective buyer of the token or any other user accessing the blockchain, may see an image or file representing the project token and a brief description and/or a preview representation of any encrypted files associated with the proj ect token, all of which may be supplied by the metadata file, along with an external link taking the prospect to a project page associated with the project token. Any files that are not private/encrypted would be viewable by a user accessing the project token.

[0058] In examples where the project token was minted for a funding project, the public file(s) associated with the project token may comprise document file(s), image(s), and/or message(s) indicating the repayment/funding terms, any document(s) required by regulation(s) (e.g., a prospectus, disclosure(s), SEC filing(s)), an indication that any blockchain transactions that comprise payment or repayment of the project token to a buyer requires registering for or possessing a verified digital identity with the host computing system 106 (e.g., which may comprise completing AML/KYC/OFAC verification and/or supplying private information to the host computing system 106 for the host computing system to complete the verification and obtain the credential(s) on the buyer’s behalf), and an indication that the buyer must have a wallet on the blockchain that the project token was minted on with a minimum wallet score in order to be eligible to receive repayments. If the buyer fails to satisfy any of these, the project token may successfully be transferred to the buyer, potentially, but the host computing system may prevent payment to a blockchain wallet associated with the buyer. A buyer and/or transferee wallet that satisfies these criterion would have tire proj ect token transferred thereto in a blockchain transaction on the blockchain network the project token was minted on — the seller would receive the proceeds from the sale, and the new project token holder’s wallet address would be recorded by the project token’s smart contract, so that it would be included in future repayments. Any unpaid funds may be paid, as specified by the project token documents and metadata file settings, to the new holder of the project token, provided the holder can provide satisfy the criteria for demonstrating the wallet is a trusted wallet to receive the payment.

[0059] For a user that buys or is transferred a project token that does not include more than a minimum payment or a minimum total payment paid to the buyer across all project tokens purchased by the buyer, these requirements may be reduced, both in the file(s) stored with the project token and as reflected in the metadata file associated therewith. For example, the buyer may merely need a blockchain wallet on a same blockchain network the project token was minted on or a bridge smart contract to hold the project token from a wallet in a separate blockchain network. Although, in some examples, a project originator may specify, in the metadata file, that a blockchain wallet must have a wallet score that meets or exceeds a minimum wallet score requirement. If this isn’t the case, a future blockchain transaction from the originator to that blockchain wallet may be withheld.

[0060] The administrator component 220 may enable a user with an administrator role to perform administrative and reporting functions including but not limited to review and approval of projects, credential(s), wallet score(s), analytics, and/or the like associated with user(s) and/or projects. In some examples, the administrator component 220 may notify an administrator account when a project status changes and administrator involvement may be required, such as projects that change in status to “pending” for administrator approval, in which case the proj ect may be temporarily locked or prevented from moving forward in status to publishing or minting a token until administrator approval is received, or the like.

[0061] In some examples, the memory 204 may further store and/or execute website data, account data, user account data, credential(s), project data, etc.

[0062] In some examples, the administrator component 220 may comprise an auditing component that may record blockchain transactions related to any of the projects created and/or stored via the host computing system 106 to create an audit trail for at least projects that include payment and/or repayment. In some examples, recording a blockchain transaction may include saving the outbound and/or inbound wallet address(es), wallet score(s) associated with the transaction, the digital identity(ies) associated with the transaction and/or an identifier of their credentials, and/or blockchain transactions detected via blockchain ledger broadcasts that are associated with a previously recorded blockchain wallet address, a project token, or a blockchain transaction initiated by the host computing system 106. In some examples, the auditing component may facilitate audit and/or reporting of the blockchain transactions by:

• storing and facilitating display of each current holder of a token, as well as any transfers or deletions that may have occurred (as detected from subsequent blockchain transactions recorded in an updated blockchain ledger);

• storing and facilitating display of each batch of transactions (in this case payments) made to holders of a token; • identifying (e.g., by storing in a database) past holders of a token who resold a token; and/or

• creating subgroups of token holders to receive future transactions (e.g., current project token holders whose wallets are still associated with a verified digital identity) or messages (e g., current holders whose wallets have been flagged and no longer trusted in order to receive alerts of wallet issues).

EXAMPLE USER INTERFACE, PROJECT DATA, AND TOKEN MINTING

[0063] FIG. 3 illustrates an example user interface 300 that may be used by an authenticated user accessing the user interface via a connection between a user device and the host computing system 106 to create, edit, review, and/or publish a project. The user interface may be presented via a browser as part of a webpage or as part of an application running on a user’s device. The example user interface 300 may additionally or alternatively be used to mint a project token or initiate a blockchain transaction that follows transfer of a project token. For example, a follow-up blockchain transaction may include a blockchain transaction with a set of blockchain wallets determined based at least in part on the project token smart contract ownership data associated with a previously issued project token and/or previous blockchain transactions noted in a blockchain ledger. In some examples, the depicted example user interface 300 comprises at least some of the project data that may be used to mint a project token and/or generate a metadata file for the project token.

[0064] Although the depicted example pertains to a funding type project, a user interface for other project types may be the same or similar. The user interface is merely presented as a manner of better understanding the project and token creation phases. The depicted example project presented by the user interface may be in a published state and may be ready to transition to a funding state where upon receiving an indication from the user, the host computing system 106 will request the selected blockchain to mint proj ect token(s) for the proj ect and/or metadata file(s) will be generated in association therewith, if such file (s) have yet to be created.

[0065] The example user interface includes various project data properties that may ultimately end up being stored as part of a metadata file, such as a name (i.e., “Community Center Expansion”), project status (i.e., “Published”), and Description. In some examples, an arrangement of the example user interface 300, fields available via the example user interface 300, options selectable via the example user interface 300, and/or webhooks, API calls, and/or HTTP requests that are permitted to be made via interacting with the example user interface 300 may change based on a project type 302 selected by a user. In the depicted example, the project type is “Revenue Based Finance,” which may cause the user interface to present the fund date 304, amount 306, period 308 , terms 310, and/or unit size 312 fields. In some examples, each of these fields may correspond with a portion of the metadata file.

[0066] In an additional or alternate example, the project type may comprise a general project type and/or specific project types, each of which may be associated with different user interface and/or API configurations. For example, the general project type associated with the depicted project type 302 may be a finance project and the specific project type may be a revenue based finance project. In some examples, specific project types may be hierarchically organized in association with one or more general project types. General project types may additionally or alternatively include project types for subscriptions, payroll, royalty payments and/or royalty financing, content creators, promotional campaigns, and/or the like. Specific project types may specify a sub-class of the general project type, such as different financing repayment methods (e.g., revenue percentage, annuity, equity), different content creators (e.g., author, musician, video creator), etc., different subscription types (e.g., season ticket, newsletter, audio and/or video subscription, podcast), and/or particular subject matter (e.g., file type(s), payment type) of the project token or anticipated subsequent blockchain transactions (e.g., payment, minting subsequent tokcn(s) such as follow-on tokcn(s), e.g., NFT tokens representing payments in the form of new subscription drops, such new podcast, new book chapter, new song, new ticket, and the like). [0067] In some examples, selection of a funding project type may trigger requirements that the project data include file(s) comprising a regulatory filing(s), registration requirement(s) (e.g., a securities registration, an accreditation), or the like as part of the project data submitted by the project originator and/or, in additional or alternate examples, regulatory filing(s) and/or compliance document(s) may be required to be submitted by a project token recipient. Such requirements may also then require the user owns a trusted wallet in order to receive payments. Without such requirements, a non-trusted wallet may be sufficient to receive payments.

[0068] Some of the fields and/or respective metadata file properties that may be used for other project types and that may be presented by the example user interface 300 to facilitate population of at least part of the metadata file may include:

• a term (e.g., a length of time), day/time of a month/year, and/or frequency of future payroll-related blockchain transactions, subscription blockchain transactions, royalty payment blockchain transactions, etc.;

• a classification of recipient that may be associated with a unique token id (e.g., a standard subscriber that receives a minimum number of file(s) as part of a subsequent project token issuance, a premium subscriber that receives an increased number of files as part of a subsequent project token issuance, a first investor classification that is entitled to a first level of consideration (e.g., payment(s) and/or file(s)), a second investor classification that is entitled to a different level of consideration, a first job role entitled to first compensation or a second job role entitled to second compensation and/or compensation frequencies, vesting schedules, or bonus structure);

• options to differentiate future blockchain transactions associated with different classifications of recipient (e.g., a project token holder may be distinguished by location, venue, or the classifications discussed above, which may entitle the project token holder to different future blockchain transaction(s));

• an option to automate a future blockchain transaction or indicate that a future blockchain transaction must be manually created or manually authorized before executing the blockchain transaction;

• identification of a claimable token, credential, credit, coupon, or unit(s) of cryptocurrency; • an identification of file(s) unique to a project type (e.g., tax document(s), pay stubs, share awards, vesting schedules and/or progress, bonus notification(s) associated with a payroll project type; an identification that a subsequent blockchain transaction is anticipated to include a particular file type (e.g., audio, video, text, document, image; shipping certification(s));

• an identification of one or more wallet addresses to which a project token recipient would like to receive future blockchain transactions (e.g, messages, announcements, NFT token drops of promotional material but not payment transactions which arc issued only to the registered proj cct token owner);

• a release schedule or date for a product, an identification of the product, a preview, or a portion of the product that may be transmitted to a holder of a project token;

• an indication of whether the project token holder previously gave authorization to be contacted with promotional materials;

• an indication of whether the project token holder has requested the deletion or retention of data related to the project token holder; and/or the like.

[0069] Returning to the particular user interface components and related data depicted in FIG. 3 for a funding project type, the fund date 304 may be optional and may specify (e.g., in conjunction with loan document(s) that may be linked to the project token) a funding deadline by which, if the project is not fully funded or has not reached a minimum amount/percentage to proceed 316, for example, if a minimum percentage of units was not purchased. In such an instance, the host computing system 106 would transmit an instruction to the blockchain to bum (destroy) all project tokens units associated with the project (if already minted) and wallets that were transferred a project token would be refunded along with a message detailing the reason for refund. In the depicted example, the minimum percentage is 100%.

[0070] In some examples, a funding project type may specify an amount 306 to be raised for the project, which is $500,000 in the depicted example, although it is contemplated that the amount 306 may be indicated in any currency or other consideration. A funding project type may additionally or alternatively comprise a period 308 for which repayment may be made and although the period depicted in the example is 20 years may be for any other duration up to and including an unlimited duration. In some examples, the period 308 may indicate a lifetime of a loan instrument from the date a project transitions to a funded status, which may dictate a date at which any project tokens related to the project may be burned.

[0071] In some examples, additional fields may depend on a funding type selected by the user, such as the terms 310. In some examples, the depicted terms 310 pertain to revenue-based financing, such as by including terms specifying apercentage of revenue, frequency (e.g., annually, quarterly, monthly), and/or a date at which payments will be made. In some examples, the terms 310 may further indicate a percentage and/or split of the repayment that may be based at least in part on a number of project tokens minted. Other funding types may be associated with different terms. 1 [0072] In some examples, a unit size 312 may indicate a price, value, or principal associated with a project token. In the depicted example, the unit size is $5,000. If overfunding is not desired or permitted forthis project, with the example amount 306 being $500,000 that means that 100 project tokens may be issued for this project. Moreover, according to the depicted example, the metadata file generated based at least in part on the depicted project data may cause a follow-up blockchain transaction on January 15^th of every year until expiration of the period 308 to any project token holders (whether they were the original holders or subsequent holders) with a verified wallet. That blockchain transaction may include one hundredth of 10% of the previous year’s revenue for every project token held by a verified wallet for the depicted example where 100 tokens would be issued (where overfunding is not desired or permitted).

[0073] Any of the project types discussed herein may include project data selected and/or submitted by the project originator that may include any one or more of:

• an indication 318 of a blockchain on which a proj ect token is to be minted and/or follow-up blockchain transactions are to be executed (e.g., Solana is the selected blockchain in the depicted example) — the indication 318 may additionally or alternatively indicate a blockchain protocol for minting the project token and/or a blockchain protocol for a follow-up blockchain transaction;

• a unit size 312 indicating a price, value, or principal associated with a project token — although the price depicted in example user interface 300 is $5,000, the price may be smaller (e.g., a Satoshi, a cent) or larger, may additionally or alternatively specify fee(s) associated with the project token (e.g., gas, in some examples, the price may exclusively be the project token fees), and/or the price may be positive (i.e., to be paid by a project token recipient) or negative (i.e., to be paid from wallet(s) associated with the originator of the project);

• a group of candidate recipients 320 indicated as the total number 255 and individually or collectively viewable via selection of the view button — the group of candidate recipients 320 may comprise verified accounts that have indicated interest in the project after its publication and/or may be a group of candidate recipients for a follow-up blockchain transaction;

• a total interest amount 314, which may indicate a total amount of funds that would be conveyed if all of the group of candidate recipients 320 were to receive a project token and/or a follow-up blockchain transaction — although the total interest amount depicted in the example is the result of multiplying the number of candidate recipients (i.e., 255) by the unit size (i.e., $5,000), resulting in an indicated interest in purchasing $1,355 million in project tokens, in some examples, the total amount may be determined by subtracting any fees (e.g., gas) and/or payments to be made by the originator of the project to accomplish the minting and/or transference of project token(s) and/or follow-up blockchain transaction(s) to the group of candidate recipients 320;

• a preview image 322 or file associated with the project — in some examples, this image 322 or file may be a preview or representation of the project and may be the image that is held by the minted token as a traditional part of an NFT, as opposed to the file(s) 324, which are unique to the project token techniques discussed herein;

• file(s) 324 to be stored in the distributed storage system 114 associated with and/or accessible by a URL stored in the metadata file associated with the project token or transmitted as part of a follow-up blockchain transaction;

• an indication of whether a file is private or public — private file(s) may be encrypted and only viewable by a project token holder, whereas public filc(s) may be accessible to anyone with access to the distributed storage system 114 and/or blockchain on which the project token was minted;

• an originator wallet address or addresses for funding payment(s), fees, and/or the like for minting and/or transferring a project token and/or follow-up blockchain transaction;

• a number of project tokens that are to be minted (e.g., which, for funding projects may depend on the amount 306 and the unit size 312, although in some examples, more project tokens may be minted to allow for overfunding a project) and/or a number of follow-up blockchain transactions that are guaranteed or expected to occur;

• a project name, a project description, a project status, a unique project identifier, attribute(s) associated with the project or a group of projects (e.g., tags identifying the project type, subject matter, geolocation(s), venues, or the like); and/or the like.

[0074] In some examples, the host computing system 106 may automatically transition to minting project token(s) once the total interest amount 314 exceeds the amount, after receiving originator and/or administrator verification to proceed, and/or upon receiving a request from an originator’s user device to mint the project token(s) (e g., via selection of the “Mint” user interface element). Tn some examples, the example user interface 300 may additionally or alternatively comprise options to add file(s) to the project, view a group of candidate recipients 320 for a project token and/or follow-up blockchain transaction once project tokcn(s) have been minted and transferred, view a status of minting and transference of project token(s) and/or a follow-up blockchain transaction (e.g., that may be determined based at least in part on an updated blockchain ledger broadcast by a blockchain network), save a project, and/or the like. Once minted, candidate recipients may be sent a message via a blockchain transaction to their wallet, inviting them to purchase one or more of the project tokens. In some examples, the originator may define a maximum number of project tokens that may be purchased by a user or may include no such maximum number. In some examples, the announcement could also be staged and sent to smallergroups of candidate recipients at a time. In another example , an original may create a marketplace for a project token and may mint the project token(s) immediately. These NFTs would be then be available immediately for candidate recipients to review and/or purchase.

[0075] In other project examples where the candidate recipient may not have a wallet yet, such as an employee, subscriber, or the like, the host computing system 106 may transmit an email with a link to download a mobile wallet application and/or otherwise create a wallet. Upon creation of the wallet, the wallet address may be transmited by such a user’s device back to the host system 106 and the project token may be transferred to the user’s wallet once payment has been executed by the originator and/or the purchaser, depending on the implementation.

[0076] In some examples, saving the project and/or determining to mint a project token may cause creation of at least part of the metadata file discussed herein based at least in part on the project data provided by the originator as discussed above. In some embodiments, the host computing system may store or cache in a database at least in part on an updated blockchain ledger received from a blockchain (e g., indicating a status of minting, a transaction that includes the project token or a wallet to which/from which a project token was transferred), and/or based at least in part on data received from a recipient, such as identification of a digital identity and/or blockchain wallet address(es) associated with the recipient.

[0077] In some examples, the metadata file may comprise an external URL associated with the project token that may allow a user of a third party marketplace to open a project webpage associated with the project token to view the token file(s). In addition to the file(s) listed in the example, the project token may additionally be minted with the metadata file, which may be a computer readable and/or executable file, such as the example metadata.json document depicted below and representing the project data properties entered for this project.

{

"name": "Community Center Expansion",

"description": "Add a new 40' x 50' lap and recreational pool to the current community center and mens and womens change & locker room",

"originator": "Newcastle Community Center",

"funding_amount" : 500000,

“pending blockchain confirmation” : 0,

"date minted": "2021-09-03T22:45: 06. 597+00: 00",

"unit_size": 5000,

“period" : {"value”: 20, “unit” : "year"},

"docroot": "QnQp2k37mJBND8xZNM8eywEsJAS48F4DNCuZF4hDqrtTYF",

"atributes" : [

{

"value" : " Project Token"

},

{

"trait_type" : "project_ type",

"value": "Community Improvement"

},

"trait type" : "funding type",

"value": "revenue- based financing"

}, {

"trait type": "funding currency" ,

"value": "USD"

},

"portfolio": [

{

"name" : "Community Center Expansion Powerpoint",

"document" :

"ipfs://QnQp2k37mJBND8xZNM8eywEsJAS4BF4DNCuZF4hDqrtTYF/Community%20Center%20 Expansion.ppt,

"mimeType" : "application/vnd.ms -powerpoint ",

"encrypt" : 0

},

{

"name": "New Pool Rendering",

"document:

"ipfs://nQp2k37mJBND8xZNM8eywEsJAS4BF4DNCuZF4hDqrtTYF/New%20Pool%20rendering. jpg",

"encrypt": 0

},

{

"name": "Proposal Video",

"document" : " ipfs://QnQp2k37mJBND8xZNM8eywEsJAS4BF4DNCuZF4hDqrtTYF/New%20Pool%20 video .m3u8", "encrypt" : 0

},

{

"name" : "Project Prospectus",

"document" • :

"ipfs://QnQp2k37mJBND8xZNM8eywEsJA54BF4DNCuZF4hDqrtTYF/Project%20Prospectus.pdf' !!

"encrypt"- : 1

},

]

}

[0078] Note that, although the Project Prospectus is indicated in the metadata file as being encrypted, this may not be the case for similar documents in practice. In some examples, the metadata file depicted above may be an example of a metadata.json file that may be uploaded to IPFS or another distributed storage system 1 14 and may be pointed to by the project token tokenURI field. In some examples, the metadata file may be a permanent immutable record that contains the metadata such as the project name and description for the project token, project data properties that may provide additional details about the project token, attributes that may provide searchable attributes enabling this token to be easily found on a third party NFT marketplace. Any of this data may be used as at least part of determining a set or subset of blockchain wallet addresses to which to transmit a follow-up blockchain transaction. In some examples, the docroot may comprise the IPFS location where the token fde(s) have been uploaded. In some examples, portfolio may detail the file(s) that have also been uploaded to IPFS along with their locations, multipurpose internet mail extension (MIME) type, and/or encryption status, as may be determined by the project data including an indication to indicate a file as being public or private.

[0079] In some examples, follow-up blockchain transaction logic can be incorporated into a project token smart contract that would take the project token contract address, wallet addresses of a set or subset of wallet addresses determined according to any of the techniques discussed herein, and/or any other inputs to execute the follow-up blockchain transaction. The benefit of this would be that this process can then be reviewed and audited by an originator and/or may automate the process in additional or alternate examples.

EXAMPLE PROCESS FOR CREATING, UPDATING, PUBLISHING, AND/OR MINTING PROJECT TOKEN(S) FOR A PROJECT

[0080] FIGS. 4A-4C illustrate a sequence diagram of an example process 400 including operations of a first user to create and/or update a new project, publish the project for one or more other users to view and/or register for, and/or to mint one or more tokens for the project so that other user(s) can purchase or otherwise receive project token(s) minted for the project. In some examples, example process 400 may be carried out by respective different device(s), system(s), and/or component(s) illustrated in FIGS. 4A-4C, such as a user device 110, login component 208 (and/or user component 212 or any of the other components of host computing system 106), originator administration component 216, memory 204, distributed storage system 114, and/or blockchain network 102.

[0081] Turning to FIG. 4A, at operation 402, example process 400 may a user logging into the host computing system 106 via a user device and the login component 208, according to any of the techniques discussed herein. In some examples, the login component 208 may authenticate the user via the user’s mobile wallet application.

[0082] At operation 404, example process 400 may comprise rendering an originator console page via the originator administration component 216 once the user is authenticated, according to any of the techniques discussed herein. In some examples, the console page may comprise a user interface for making API call(s) to one or more component(s) of the host computing system 106, distributed storage system 114, blockchain network 102, and/or other device(s).

[0083] At operation 406, example process 400 may comprise requesting to create a project and/or uploading details and/or file(s) associated with the project request (e.g., project data), according to any of the techniques discussed herein. In some examples, operation 406 may be facilitated by selection of a “create” user interface element in the console. In some examples, the originator administration component 216 may render a project page similar to the example user interface 300 of FIG. 3, enabling the originator to enter details for this project, and upload file(s) supporting this project, such as a project proposal, prospectus, funding terms, revenue projections, originator profde, lender requirements, image, audio file, video file, executable, etc. The originator may elect to make any or all of these file(s) public or private such that only the originator or a future token holder may view such files. In examples including a project token that may include future follow-up blockchain transactions that may include a payment in coin(s) or token(s), the originator may select the type of funding he wishes to use for this project, including but not limited to a revenue-based stream, an annuity, or an equity distribution. The originator may additionally or alternatively select a different project type, as discussed above, which will affect other options available to the originator.

[0084] At operation 408, example process 400 may comprise generating a new symmetric key (if any documents are identified as private) and encrypting those file(s) marked as private with the symmetric key, according to any of the techniques discussed herein.

[0085] At operation 410, example process 400 may comprise uploading file(s) for the project to distributed storage system 114, according to any of the techniques discussed herein. In some examples, uploaded filc(s) may be stored on IPFS and may be uploaded there directly from the user device 110 or uploaded via the originator administration component 216.

[0086] At operation 412, example process 400 may comprise receiving a list of file link(s) referencing networked addresses of the file(s) uploaded to the distributed storage system 114, according to any of the techniques discussed herein. In some examples, this list of file link(s) may be integrated in the metadata file discussed herein.

[0087] At operation 414, example process 400 may comprise transmitting a request to save the project if the user isn’t ready to publish the project or if the project needs administrative approval before publishing, according to any of the techniques discussed herein.

[0088] Turning to FIG. 4B, at operation 416, responsive to receiving the request to save the project, the example process 400 may comprise creating and storing a metadata file and/or storing project data in memory 204, according to any of the techniques discussed herein. For example, operation 416 may comprise creating the metadata file based at least in part on project data received from the user device 110. Storing project data associated with the project may comprise storing a default image link, array of file links, project name/description/etc, a symmetric key encrypted by the user’s public key, and/or the like.

[0089] At operation 418, example process 400 may comprise requesting to edit the project, according to any of the techniques discussed herein. In some examples, this operation may occur when a user returns to edit a previously saved project.

[0090] At operation 420, example process 400 may comprise retrieving and/or loading a metadata file and/or file(s) from the memory 204 or, if the project has published, additionally or alternatively from the distributed storage system 114, according to any of the techniques discussed herein. In some examples, projects may not be edited after publication since they may be published to system(s), such as IPFS and/or a blockchain that is immutable.

[0091] At operation 422, example process 400 may comprise generating a project editing page responsive to operation 418 and operation 420, according to any of the techniques discussed herein. The project edit page may be a same or different version of the project page discussed herein.

[0092] At operation 424, example process 400 may comprise requesting to publish the project, according to any of the techniques discussed herein. In some examples, the originator may access the project page via the originator administration component 216 and may select a “publish” user interface element to trigger this request. In some examples, the “publish” user interface element may be replaced by a “mint” user interface element at a later stage, such as after publication and before minting.

[0093] At operation 426, example process 400 may comprise saving the project and/or pausing the project from advancing to a next status for an administrator to review and/or approve the project before the project advances to a next status, such as publishing or funding, according to any of the techniques discussed herein. For example, if certain criteria arc met, such as the funding type requiring regulatory approval, or the funding amount being over a certain threshold, the project may be put into a pending status, requiring administrator(s) of the host computing system to review the project prior to publishing and/or prior to minting. Once approved, an administrator component 220 may update the project status in the memory 204 to published, enabling this project to be visible via the project component 210. Candidate recipients can then view this project and register for further updates, such as by providing a blockchain wallet address to send a message or project token to or by providing an email, as well as indicate a number of units they would be interested in purchasing. In some examples, the messaging component 214 may enable the originator to import candidate recipients and/or select from past recipients of a project token to invite them to view this new project. For project types other than funding project type(s), this operation may be omitted.

[0094] At operation 428, example process 400 may comprise requesting to mint one or more project tokens for the project, according to any of the techniques discussed herein. For a funding type project, once the project has received a sufficient number of registered candidate recipients and/or the total interest amount (i.e., the number of units candidate recipients have expressed interest in purchasing multiplied by the unit size) exceeds a defined threshold, the originator may access the project page and select the “mint” user interface element to trigger the process for minting the one or more project tokens. In an example where the project type is not a funding type, the total interest amount may be used or may be dispensed with by the user, which may, in some examples, require administrator authorization. In an example where the total interest amount isn’t used and the project doesn’t require administrative approval before publishing, the originator may freely mint the project token(s) at anytime or may cause the project token(s) to be minted in batches at intervals of additional candidate recipients or when the total number of candidate recipients meets or exceeds a threshold number. [0095] At operation 430, example process 400 may comprise generating or updating a metadata fde with project data and uploading the metadata file to the distributed storage system 114, according to any of the techniques discussed herein. The metadata file may thereby be made publicly accessible (even if files referred thereto may be encrypted) and immutable.

[0096] Turning to FIG. 4C, at operation 432, example process 400 may comprise requesting a signature from a wallet associated with a project token recipient, according to any of the techniques discussed herein. For example, the originator administration component 216 may request the originator to sign the blockchain transaction(s) for minting the NFT portion(s) of the project tokcn(s) that may deploy an ERC 721 or ERC 1155 NFT contract or a similar contract or a proxy thereof, such that this project may be minted and assigned its own NFT token ID. In some examples, the originator may sign the blockchain transaction(s) using a wallet associated with the originator, such as by using a mobile wallet application to cryptographically sign the blockchain transaction(s).

[0097] At operation 434, example process 400 may comprise receiving the signed transactions from a wallet associated with the originator, according to any of the techniques discussed herein.

[0098] In some examples, before the host computing system transmits a request to mint the project token(s), the example process 400 may return to operation 426 before proceeding to operation 436.

[0099] At operation 436, example process 400 may comprise requesting the project token be minted to the originator’s wallet, according to any of the techniques discussed herein. For example, the originator administration component 216 may batch mint the requisite number of project tokens needed to meet the project token amount, if one is defined as discussed above. These project tokens would be minted to a wallet designated by the originator on the selected blockchain. Alternately, the originator may elect to mint to an ERC 1155 contract, requiring a slightly different procedure to mint and issue future blockchain transactions. Operation 436 may further include storing a metadata file link in the tokenURL field (or its analog in other protocols) of the project token so that the metadata file may be read from the distributed storage system 114 after the metadata file has been uploaded to the distributed storage system 114. In some examples, operation 436, operation 432, and/or operation 434 may be responsive to the request to mint the project tokens and may be part of the host computing system preparing the project tokens to be minted.

[0100] At operation 438, example process 400 may comprise storing a project token token id and/or smart contract address in the memory 204 and/or updating a project status associated with the project, according to any of the techniques discussed herein. For example, at this point the project status may be updated to “funding” or “active.”

[0101] At operation 440, example process 400 may comprise displaying an updated project page, a list of candidate recipients for the newly minted tokens, and/or an option to send a message via the messaging component 214 and/or transmit a blockchain transaction to a candidate recipient, according to any of the techniques discussed herein. Operation 440 may comprise initiating a blockchain transaction with a wallet associated with a candidate recipient to transmit a message transaction or notification token containing promotional or informational file(s) to the candidate recipient(s). Note that this is not necessarily used for the transfer of the actual project tokens. Additionally or alternatively, the originator may use the originator administration component 216 to select from a list of registered candidate recipients and to send an invite informing them that the project token(s) are now available for purchase.

EXAMPLE PROCESS FOR VALIDATING A USER ACCOUNT AS A VERIFIED USER ACCOUNT [0102] FIGS. 5A-5C illustrate a sequence diagram illustrating an example process 500 for validating a user account (e.g., a project originator, project candidate recipient, project recipient) as a verified user account and/or providing qualified and verified wallet(s) that can be transferred a project token and/or follow-up blockchain transaction(s). In some examples, example process 500 may be carried out by respective different device(s), system(s), and/or component(s) illustrated in FIGS. 5A-5C, such as a user device 502 (which may represent a user device associated with a project originator, candidate project recipient, and/or project recipient), login component 208 (and/or user component 212 or any of the other components of host computing system 106), an administration component 528 (which may be or include the originator administration component 216, recipient administration component 218, and/or administrator component 220), a KYC/AML/OFAC verifier 512, and/or a wallet score provider 538. In some examples, example process 500 may further be executed to allow a user account to access an administration component of the host computing system.

[0103] Turning to FIG. 5A, at operation 504, example process 500 may comprise determining that a user device and/or user account is logging into a digital identity account for the first time, that the user account has not configured the user device 502 with a mobile wallet application, and/or that a credentials associated with a digital identity have expired, according to any of the techniques discussed herein. In an example where the user attempts to log in by accessing the login component 208, if the mobile wallet application is not installed on the device or configured with the host computing system, the user may directed to download and install the mobile wallet application, as part of an openlD for Verifiable Credential Issuance (OIDC4VC), OAUTH2, or a similar authentication protocol. Once the verification process described below has been completed, the now trusted user can complete the login process.

[0104] At operation 506, example process 500 may comprise transmitting a link or QR code for a mobile wallet application to be installed on the user device 502, according to any of the techniques discussed herein. In some examples, the mobile wallet application may be used as a first wallet for holding a digital identity and/or credentials associated with the user account and as a second wallet for holding a blockchain wallet.

[0105] At operation 508, example process 500 may comprise installing the mobile wallet application on the user device 502, creating a unique digital identifier for the user/user account, and/or prompting the user to complete a wallet, KY C, AML, and/or OFAC verification, according to any of the techniques discussed herein. As an identity Wallet, the mobile wallet application may implement a standard for a decentralized identity wallet, such as a Self-Issued OpenlD Provider v2 (SIOPv2) wallet. Using a SIOPv2 wallet, the user may create a unique digital identity (DID)

[0106] At operation 510, example process 500 may comprise transmitting responses to and/or receiving queries from a KYC, AML, and/or OFAC verifier 512, according to any of the techniques discussed herein. For example, once the mobile wallet application has created the DID it may then verify that DID by connecting with a credential issuer that provides the AML/KYC/OFAC checks to ensure that the user represented by the DID is not a bad actor and legally able to participant in funding transactions. To complete this process, the user may uploads to the credential issuer the requested documents such as the driver’s license, a face scan, and/or the like.

[0107] At operation 514, example process 500 may comprise receiving a signed verified credential for the user, according to any of the techniques discussed herein. In some examples, the issuer may create a verified credential (VC) attesting that the user has been verified to be who the user claims to be and has passed the regulatory AML/KYC/OFAC tests and is not a bad actor. This VC may be signed by the issuer and encrypted and stored by the mobile wallet application on the user device 502. A VC may be issued per verifier (e.g., one each for each of or one for multiple of AML, KYC, and/or OFAC checks) and may take a variety of forms. In at least one example, the VC may comprises a JSON file and may comprise an indication of an issuer, issue timestamp, expiration data, type, subject, cryptographic proof, and/or the like.

[0108] At operation 516, example process 500 may comprise completing registration as a trusted user based at least in part on the mobile wallet application encrypting and/or storing the VC in secured memory on the user device 502, according to any of the techniques discussed herein. In some examples, operation 516 may comprise re-attempting to log in via the login component 208. For example, operations 518-526 may be part of this re-attempt to login and configuring the user account as a verified/trusted user account for the host computing system 106.

[0109] Turning to FIG. 5B, at operation 518, example process 500 may comprise requesting a user digital identity and proof of the AML/KYC/OFAC verification, according to any of the techniques discussed herein. For example, operation 518 may request submission of the VC.

[0110] At operation 520, example process 500 may comprise displaying, at the user device 110, the request generated at operation 518 and prompting the user for user authorization to transmit the DID and/or (encrypted or decrypted) VC, according to any of the techniques discussed herein.

[OHl] At operation 522, example process 500 may comprise transmitting the DID and/or VC to the login component 208 responsive receiving user authorization to do so, according to any of the techniques discussed herein.

[0112] At operation 524, example process 500 may comprise verifying the VC(s) associated with the user account, such as by validating a cryptographic proof associated with the VC and generated by the issuer of the VC, according to any of the techniques discussed herein. So long as the VC is validate, example process may continue to operation 526, otherwise the login component 208 may transmit an error notification to the user device 110 and/or may prevent login by the user account until valid credentials are proffered.

[0113] At operation 526, example process 500 may comprise transmitting an authentication token to the user device 110, thereby permitting access by the user device 110 to one or more component(s) of the host computing system, as defined by a role and/or permissions associated with the user account, according to any of the techniques discussed herein. In some examples, operation 526 may additionally or alternatively redirect a user device browser to a request component, webpage, or API of the host computing system.

[0114] In some examples, the remaining operations of example process 500 include operations related to a blockchain wallet component of the mobile wallet application, such as allowing the trusted user to add wallets to their digital identity, which can then take part in project transactions initiated by the administration component 528 (such as the originator and/or recipient administration components) of the host computing system.

[0115] In an additional or alternative example, a KYC/AML/OFAC verifier 512 may issue a token representing completion of the verification steps, with identification data and/or an expiration date to the user’s wallet. The login component 208 may then query the wallet or Verifier Smart Contract for the existence of a recent verification token in order to validate the user.

[0116] In some examples, the verification of a wallet’s trusted status, may additionally or alternatively comprise confirming that the expiration date associated with a credential has not expired and/or querying a blockchain indexer to ascertain whether the wallet owns a token indicating a credential.

[0117] Turning to FIG. 5C, at operation 530, example process 500 may comprise requesting a user wallet, according to any of the techniques discussed herein. In some examples, operation 530 may be part of setting up a user account, part of setting up a wallet to which to mint project tokens for an originator’s project, and/or responsive to receiving a request from the user account to conduct a blockchain transaction by the host computing system 106.

[0118] At operation 532, example process 500 may comprise transmitting a wallet address to the administration component 528, according to any of the techniques discussed herein. If the user does not already have a wallet, the user may create a wallet using the mobile wallet application. Additionally or alternatively, the user may import a wallet to the mobile wallet application or select an existing wallet.

[0119] At operation 534, example process 500 may comprise requesting a blockchain transaction via an administration component with a selected wallet, such as may have been transmitted to the administration component 528 as part of operation 532, according to any of the techniques discussed herein. Because wallets are dynamic — a wallet may be trusted at one point (i.e., by having a first wallet score that meets or exceeds a threshold score), but later on may be involved in a suspicious transaction — the administration component 528 may verify each wallet that takes part in a blockchain transaction via the host computing system 106. For example, such a blockchain transaction may comprise minting a follow-on token or receiving a project token or follow-on blockchain transaction. A follow-on token may be defined in the metadata file as the form of payment to be issued to the owners of the project token. This may take the form of an ERC20 token representing currency, or an NFT containing a book chapter as payment for funding a book project, or an NFT containing instructions to create a new trusted wallet, sent to holders of untrusted wallets that were rejected for payment. A follow-on token may be sent to an untrusted wallet if that follow-on token is not regulated by government authorities — for instance, a token comprising a book chapter may be transmitted to a wallet regardless of a trust state of the wallet.

[0120] At operation 536, example process 500 may comprise requesting a wallet score from a wallet score provider 538, according to any of the techniques discussed herein. For example, the administration component 528 may call the wallet score provider 538 for each wallet in a transaction prior to executing that transaction.

[0121] At operation 540, example process 500 may comprise receiving a wallet score from the wallet score provider 538, according to any of the techniques discussed herein. In some examples, the wallet score provider 538 may look up the wallet address in a database and/or blockchain ledger and determine score based at least in part on a level of involvement of the wallet address in any suspicious activity.

[0122] So long as the wallet score received from the wallet score provider 538 meets or exceeds a threshold score, at operation 542, example process 500 may comprise inclusion of the wallet in the blockchain transaction, according to any of the techniques discussed herein. If the wallet score is below the threshold score, the administration component 528 may omit the wallet from the blockchain transaction and notify the user. For funding type project where multiple wallets may be paid, only trusted wallets (e.g., wallets that received a score above a minimum threshold) may be paid. The remaining, low-score wallets do not receive payment — these payments are withheld, the wallet owner is notified by way of a different blockchain transaction containing a message or token containing informational file(s) for rectifying the trust state, and the held payment is only released once a new trusted wallet has been provided by that user. The low-score wallet holders may additionally or alternatively be notified via pre-registered channel(s), such as via email and/or text messaging (e.g., short message/messaging service (SMS)).

EXAMPLE PROCESS FOR PROCESSING A FOLLOW-UP BLOCKCHAIN TRANSACTOIN BASED ON PREVIOUSLY-ISSUED PROJECT TOKEN(S)

[0123] FIGS. 6A and 6B illustrate a sequence diagram of an example process 600 executed to process a follow-up blockchain transaction that may comprise payment to project token holders that meets regulatory requirements and/or a blockchain transaction to current and/or former holders of a project token or other project token(s). In some examples, the follow-up blockchain transaction may comprise minting of a new payment token comprising one or more files, transmission of a message over a blockchain, a blockchain transaction comprising a payment, and/or the like. In some examples, example process 600 may be carried out by respective different device(s), system(s), and/or component(s) illustrated in FIGS. 6A and 6B, such as a user device 110, originator administration component 216, a wallet/KYC/AML/OFAC verifier 616, distributed storage system 114, and/or blockchain network 102.

[0124] At operation 602, example process 600 may comprise transmitting a notification of due payment or a due follow-up blockchain transaction, according to any of the techniques discussed herein. In some examples, the notification may be triggered based at least in part on terms associated with a project token with which the due payment or follow-up blockchain transaction is associated. For example, terms of a funding project type may specify payment terms according to a schedule or milestones to holder(s) of a project token and/or terms of a subscription project type may specify terms regarding issuance of a product or file(s) to holder(s) of a project token, either of which could trigger this notification. In some examples, a mobile wallet application on the user device may receive and present the notification.

[0125] At operation 604, example process 600 may comprise transmitting a request to initiate a follow-up blockchain transaction, according to any of the techniques discussed herein. In some examples, the follow-up blockchain transaction may comprise a due payment, minting of a follow-on token comprising one or more files, transmission of a message over a blockchain, a blockchain transaction comprising a payment, and/or the like.

[0126] At operation 606, example process 600 may comprise querying a project token smart contract to retrieve a token metadata file location, ownership chain, and/or other properties, according to any of the techniques discussed herein. Operation 606 may be used as part of determining the set or subset of wallets to which to transmit the follow-up blockchain transaction. For example, any one or more parts of the metadata file, ownership chain, verification data, host system and public service provider database records, blockchain ledger data, and/or project data property(ies) may be used to determine the set.

[0127] At operation 608, example process 600 may comprise retrieving the metadata file from the distributed storage system 114, according to any of the techniques discussed herein. For example, the metadata file location may be indicated as an IPFS link that may be used to retrieve the metadata file and/or data retrieved from the project token smart contract, such as the ownership chain.

[0128] At operation 610, example process 600 may comprise determining a set of wallets to conduct a blockchain transaction with based at least in part on the metadata file, ownership chain, connected data store(s), and/or project data property(ies), according to any of the techniques discussed herein. Determining the set of wallets to which to transmit a blockchain transaction may be based at least in part on the project type associated with the project token, tenns specified by the project token, properties specified by the metadata file, or the like, according to any of the techniques discussed herein. For example, determining to include a blockchain wallet address in the set may comprise: • determining that the blockchain wallet address holds the project token and/or one or more tokens specified by the user or that the one or more tokens held by the blockchain wallet address are associated with a project identification indicated in the metadata file;

• determining that the blockchain wallet address is a current holder of the project token or a previous holder of the project token, either or both of which may be selected by the user as a criterion for inclusion in the set, although for funding project types previous holders may be excluded from the set;

• determining to include the blockchain wallet address based on length of time of token ownership or recency of project token ownership;

• determining to include the blockchain wallet address based on one or more factors such as a required minimum age, state/province of residence, professional accreditation, or the like;

• determining based on last user login details such as recency, geographic location, or the like; etc.

[0129] At operation 612, example process 600 may comprise verifying that the originator wallet and/or the set of wallets are trusted wallets and reducing the set to a subset of wallets to exclude wallet(s) that are not trusted, according to any of the techniques discussed herein. For example, operation 612 may comprise retrieving a wallet score, confirming a recent (e g., non-expired) KYC/AML/OFAC check by a wallet/KYC/AML/OFAC verifier 616, and/or requesting presentation of a VC to validate a wallet as a trusted wallet. Wallet(s) that don’t meet any of the requirements discussed herein may be excluded from the set and the remaining wallet(s) after any exclusions have been made are the subset of wallet(s) to which a follow-up blockchain transaction may be directed. In some examples, operation 612 may be conducted only for payment or funding project type follow-up blockchain transactions, although it is understood that this validation or a portion thereof may optionally be executed for any blockchain transaction.

[0130] Turning to FIG. 6B, at operation 614, example process 600 may comprise notifying the user of any untrusted wallct(s) and/or indicating a total or partial repayment amount (for payment transactions), according to any of the techniques discussed herein. For example, a partial payment amount may be paid to a subset of the wallets that are trusted, but if all the wallets are trusted the total payment amount may be paid. Operation 614 may additionally or alternatively comprise notifying an excluded wallet that the wallet is untrusted and prompting a user to provide a trusted wallet to receive the blockchain transaction. For example, the prompt may provide a webpage URL to provide a trusted wallet. In some examples, notifying such a user may occur after operation 624. In some examples, payment may be contingent on a project token be transferred from an untrusted wallet to a trusted wallet.

[0131] At operation 618, example process 600 may comprise transmitting an affirmation to execute the blockchain transaction with the set or subset of wallets, according to any of the techniques discussed herein. For example, operation 618 may comprise affirming execution of the blockchain transaction with the entire set of wallets if no operation 612 did not occur/did not need to occur for the project type and/or if all the wallets in the set are trusted. [0132] At operation 620, example process 600 may comprise verifying that an originator wallet is sufficiently funded in currency specified by the metadata file associated with a project token, according to any of the techniques discussed herein. Operation 620 may occur for at least blockchain transactions comprising a payment or it may be skipped for blockchain transactions that do not include a payment. However, in some examples, various fees (e.g., gas) for the blockchain transaction may be due and operation 620 may check to ensure the originator wallet holds sufficient funds to cover the fees.

[0133] At operation 622, example process 600 may comprise creating a first batch of candidate blockchain transactions for transmission to the set or subset of wallets and/or creating a second batch of candidate blockchain transactions to holding wallet(s) and/or smart contract(s) that may function as escrow wallets that may hold fiind(s) and/or file(s) for any untrusted wallets, according to any of the techniques discussed herein. In some examples, once a user provides a trusted wallet in place of an untrusted wallet, the holding wallet) s) and/or smart contract(s) may release the fund(s) and/or file(s) to the trusted wallet, such as via another blockchain transaction.

[0134] At operation 624, example process 600 may comprise displaying blockchain transaction details via a mobile wallet application at the user device 110 and receiving a user wallet’s cryptographic signature of the blockchain transaction(s), according to any of the techniques discussed herein.

[0135] At operation 626, example process 600 may comprise transmitting a request to a blockchain network to execute the blockchain transaction(s) with the set/subset of wallets and/or the holding wallet(s), according to any of the techniques discussed herein. In some examples, operation 626 may additionally or alternatively comprise storing a confirmation received from the blockchain network that the blockchain transaction(s) were executed and recorded in the blockchain ledger.

EXAMPLE CLAUSES

[0136] A. A system comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: receiving a first request to create a first project token from a first device associated with a first user, wherein the first request indicates a blockchain network on which to mint the first project token, a first blockchain wallet address to which to transfer the first project token, and includes a link to a metadata file indicating project data including a project identification and a link to a first file; transmitting a set of project tokens comprising the first project token to a first set of blockchain wallet addresses by a first set of blockchain transactions over the blockchain network, wherein the first set of blockchain wallet addresses comprises the first blockchain wallet address; receiving, from the blockchain network, a portion of an updated blockchain ledger indicating at least one of minting the first project token, transmission of the first project token to the first blockchain wallet address, or a transfer of the first project token from the first blockchain wallet address to a second blockchain wallet address; receiving a second request to create a second blockchain transaction, the second blockchain transaction comprising transmitting at least one of a follow-on token, cry ptocurrency, message, or one or more files to a second set of blockchain wallet addresses and wherein the second request is received at a time subsequent to the first blockchain transaction; determining, based at least in part on the portion of the updated blockchain ledger and a token ownership chain, the second set of blockchain wallet addresses based at least in part on determining that the second set of blockchain wallet addresses at least one of currently holds or previously held the first project token; and transmitting, to the blockchain network, a third request to execute the second blockchain transaction with the set of blockchain wallet addresses.

[0137] B. The system of paragraph A, wherein: the metadata file further includes repayment data indicating a future blockchain transaction comprising the follow-on token or cryptocurrency transfer to a wallet that holds the first project token at a future time; and receiving the second request is based at least in part on a host computing device determining, based at least in part on the repayment data that a time period has passed, that a file was uploaded, or that a blockchain transaction initiated by the first device occurred on the first blockchain network or a second blockchain network.

[0138] C. The system of cither paragraph A or B, wherein the metadata file indicates that a future blockchain transaction will comprise a payment and the operations further comprise: creating a digital identity associated with a second user based at least in part on a credential associated with the second user, wherein the first blockchain wallet address or the second blockchain wallet address is associated with the digital identity; and determining to authenticate the digital identity as a trusted entity based at least in part on the credential and wherein the credential indicates at least one of: that a second wallet score associated with the first blockchain wallet address or the second blockchain wallet address meets or exceeds a threshold wallet score; or that a second authorization to transact with the second user was received from at least one of an anti-money laundering service, know your customer sendee, or an office of foreign assets control service.

[0139] D. The system of any one of paragraphs A-C, wherein determining the second set of blockchain wallet addresses is further based at least in part on determining to include or exclude ablockchain wallet address in the second set of blockchain wallet addresses based at least in part on at least one of: determining, based at least in part on the updated blockchain ledger, that the blockchain wallet address last held the first project token at a period of time from a current time that is less than a threshold period or held the first project token for a duration of time that meets or exceeds a threshold duration of time; determining that a number of at least one of first project tokens or other tokens held by the blockchain wallet address meets or exceeds a first threshold number; determining that the blockchain wallet address holds one or more tokens specified by the first user or that the one or more tokens held by the blockchain wallet address are associated with the project identification; determining, based at least in part on the updated blockchain ledger, that a number of blockchain transactions associated with the blockchain wallet meets or exceeds a second threshold number; determining that the blockchain wallet is associated with a geographical location or region; determining that a digital identity associated with the blockchain wallet indicates an age greater than a minimum age, a state or province of residence, or a professional accreditation; determining that a last user login associated with the blockchain wallet indicates that the user login occurred within a time period or within a geographic location; determining that a user-specified criterion is met by at least one of the blockchain wallet address or an account associated with the blockchain wallet address; determining that the blockchain wallet address has conducted a blockchain transaction with a wallet associated with the first user; or determining that a third project token held by the blockchain wallet address is associated with a first property that is the same as a property indicated by the metadata file.

[0140] E. The system of paragraph D, wherein the operations further comprise determining to include the blockchain wallet in a subset of the second set of blockchain wallet addresses based at least in part on at least one of: determining that a blockchain wallet address of the subset is associated with a first wallet score that meets or exceeds a threshold wallet score; determining that the blockchain wallet address is associated with a credential indicating authorization to receive payment from at least one of an anti -money laundering database, know your customer database, or an office of foreign assets control database; determining the subset of the second set ofblockchain wallet addresses to include only current holders of the first project token, only previous holders of the first project token, or both current holders and previous holders of the first project token; and wherein the operations further comprise determining to withhold the second blockchain transaction from a remainder of the second set ofblockchain wallet addresses that does not include the subset of the second set of blockchain wallet addresses, or sending an alternate blockchain transaction to the remainder.

[0141] F. The system of any one of paragraphs A-E, wherein: the first file comprises at least one of text, a document file, an audio file, a video file, or an image; the metadata file further indicates that the first file is either private or public; and the operations further comprise: storing the first file in a network-accessible memory; if the metadata file indicates that the first file is private, encrypting the first files based at least in part on a private key that is part of a cryptographic signature of the first project token executed by a wallet that holds the first project token; and storing the metadata file in network-accessible memory'.

[0142] G. The system of paragraph F, wherein: the cryptographic signature was executed by a first wallet associated with the first blockchain wallet address; the second blockchain wallet address is a current holder of the first project token; and the operations further comprise: determining, based at least in part on the portion of the updated blockchain ledger, that the first project token was transferred from the first blockchain wallet address to the second blockchain wallet address; creating a smart contract on the blockchain network or a second blockchain network, wherein the smart contract encrypts the private key and is configured to verify ownership of the first project token; receiving, from a second wallet associated with the second blockchain wallet address, a request to access the private key and a cryptographic proof of ownership of a second private key having ownership of the first project token; and permitting access, by the smart contract, to the private key based at least in part on determining, based at least in part on the updated blockchain ledger, that the second wallet is the current holder of the first project token and the cryptographic proof. [0143] H. One or more non-transitory computer-readable media storing processor-executable instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising: receiving a first request to create a first project token from a first device associated with a first user, wherein the first request indicates a blockchain network on which to mint the first project token, a first blockchain wallet address to which to transfer the first project token, and includes a link to a metadata file indicating project data including a project identification and a link to a first file; transmitting a set of project tokens comprising the first project token to a first set of blockchain wallet addresses by a first set of blockchain transactions over the blockchain network, wherein the first set of blockchain wallet addresses comprises the first blockchain wallet address; receiving, from the blockchain network, a portion of an updated blockchain ledger indicating at least one of minting the first project token, transmission of the first project token to the first blockchain wallet address, or a transfer of the first project token from the first blockchain wallet address to a second blockchain wallet address; receiving a second request to create a second blockchain transaction, the second blockchain transaction comprising transmitting at least one of a follow-on token, cryptocurrency, message, or one or more files to a second set of blockchain wallet addresses and wherein the second request is received at a time subsequent to the first blockchain transaction, determining, based at least in part on the portion of the updated blockchain ledger and a token ownership chain, the second set of blockchain wallet addresses based at least in part on determining that the second set of blockchain wallet addresses at least one of currently holds or previously held the first proj ect token; and transmitting, to the blockchain network, a third request to execute the second blockchain transaction with the set of blockchain wallet addresses.

[0144] I. The one or more non-transitory computer-readable media of paragraph H, wherein: the metadata file further includes repayment data indicating a future blockchain transaction comprising the follow-on token or cryptocurrency transfer to a wallet that holds the first project token at a future time; and receiving the second request is based at least in part on a host computing device determining, based at least in part on the repayment data that a time period has passed, that a file was uploaded, or that a blockchain transaction initiated by the first device occurred on the first blockchain network or a second blockchain network.

[0145] J. The one or more non-transitory computer-readable media of either paragraph H or I, wherein the metadata file indicates that a future blockchain transaction will comprise a payment and the operations further comprise : creating a digital identity associated with a second user based at least in part on a credential associated with the second user, wherein the first blockchain wallet address or the second blockchain wallet address is associated with the digital identity; and determining to authenticate the digital identity as a trusted entity based at least in part on the credential and wherein the credential indicates at least one of: that a second wallet score associated with the first blockchain wallet address or the second blockchain wallet address meets or exceeds a threshold wallet score; or that a second authorization to transact with the second user was received from at least one of an anti-money laundering service, know your customer service, or an office of foreign assets control service. [0146] K. The one or more non-transitory computer-readable media of any one of paragraphs H-J, wherein determining the second set of blockchain wallet addresses is further based at least in part on determining to include or exclude a blockchain wallet address in the second set of blockchain wallet addresses based at least in part on at least one of: determining, based at least in part on the updated blockchain ledger, that the blockchain wallet address last held the first project token at a period of time from a current time that is less than a threshold period or held the first project token for a duration of time that meets or exceeds a threshold duration of time; determining that a number of at least one of first project tokens or other tokens held by the blockchain wallet address meets or exceeds a first threshold number; determining that the blockchain wallet address holds one or more tokens specified by the first user or that the one or more tokens held by the blockchain wallet address are associated with the project identification; determining, based at least in part on the updated blockchain ledger, that a number of blockchain transactions associated with the blockchain wallet meets or exceeds a second threshold number; determining that the blockchain wallet is associated with a geographical location or region; determining that a digital identity associated with the blockchain wallet indicates an age greater than a minimum age, a state or province of residence, or a professional accreditation; determining that a last user login associated with the blockchain wallet indicates that the user login occurred within a time period or within a geographic location; determining that a user-specified criterion is met by at least one of the blockchain wallet address or an account associated with the blockchain wallet address; determining that the blockchain wallet address has conducted a blockchain transaction with a wallet associated with the first user; or determining that a third proj ect token held by the blockchain wallet address is associated with a first property that is the same as a property indicated by the metadata file.

[0147] L. The one or more non-transitory computer-readable media of paragraph K, wherein the operations further comprise determining to include the blockchain wallet in a subset of the second set of blockchain wallet addresses based at least in part on at least one of: determining that a blockchain wallet address of the subset is associated with a first wallet score that meets or exceeds a threshold wallet score; determining that the blockchain wallet address is associated with a credential indicating authorization to receive payment from at least one of an anti-money laundering database, know your customer database, or an office of foreign assets control database; determining the subset of the second set of blockchain wallet addresses to include only current holders of the first project token, only previous holders of the first project token, or both current holders and previous holders of the first project token; and wherein the operations further comprise determining to withhold the second blockchain transaction from a remainder of the second set of blockchain wallet addresses that does not include the subset of the second set of blockchain wallet addresses, or sending an alternate blockchain transaction to the remainder.

[0148] M. The one or more non-transitory computer-readable media of any one of paragraphs H-L, wherein: the first file comprises at least one of text, a document file, an audio file, a video file, or an image; the metadata file further indicates that the first file is either private or public; and the operations further comprise: storing the first file in a network-accessible memory ; if the metadata file indicates that the first file is private, encrypting the first files based at least in part on a private key that is part of a cryptographic signature of the first project token executed by a wallet that holds the first project token; and storing the metadata file in network-accessible memory.

[0149] N. The one or more non-transitory computer-readable media of paragraph M, wherein: the cryptographic signature was executed by a first wallet associated with the first blockchain wallet address; the second blockchain wallet address is a current holder of the first project token; and the operations further comprise: determining, based at least in part on the portion of the updated blockchain ledger, that the first project token was transferred from the first blockchain wallet address to the second blockchain wallet address; creating a smart contract on the blockchain network or a second blockchain network, wherein the smart contract encrypts the private key and is configured to verify ownership of the first project token; receiving, from a second wallet associated with the second blockchain wallet address, a request to access the private key and a cryptographic proof of ownership of a second private key having ownership of the first project token; and permitting access, by the smart contract, to the private key based at least in part on determining, based at least in part on the updated blockchain ledger, that the second wallet is the current holder of the first project token and the cryptographic proof.

[0150] 0. A method comprising: receiving a first request to create a first project token from a first device associated with a first user, wherein the first request indicates a blockchain netw ork on which to mint the first project token, a first blockchain wallet address to which to transfer the first project token, and includes a link to a metadata file indicating project data including a project identification and a link to a first file; transmitting a set of project tokens comprising the first project token to a first set of blockchain wallet addresses by a first set of blockchain transactions over the blockchain network, wherein the first set of blockchain wallet addresses comprises the first blockchain wallet address; receiving, from the blockchain network, a portion of an updated blockchain ledger indicating at least one of minting the first project token, transmission of the first project token to the first blockchain wallet address, or a transfer of the first project token from the first blockchain wallet address to a second blockchain wallet address; receiving a second request to create a second blockchain transaction, the second blockchain transaction comprising transmitting at least one of a follow-on token, crvpiociirrcncv. message, or one or more files to a second set of blockchain w allet addresses and wherein the second request is received at a time subsequent to the first blockchain transaction; determining, based at least in part on the portion of the updated blockchain ledger and a token ownership chain, the second set of blockchain wallet addresses based at least in part on determining that the second set of blockchain wallet addresses at least one of currently holds or previously held the first project token; and transmitting, to the blockchain network, a third request to execute the second blockchain transaction with the set of blockchain wallet addresses. [0151] P. The method of paragraph 0, wherein: the metadata file further includes repayment data indicating a future blockchain transaction comprising the follow-on token or cryptocurrency transfer to a wallet that holds the first project token at a future time; and receiving the second request is based at least in part on a host computing device determining, based at least in part on the repayment data that a time period has passed, that a file was uploaded, or that a blockchain transaction initiated by the first device occurred on the first blockchain network or a second blockchain network.

[0152] Q. The method of either paragraph 0 or P, wherein the metadata file indicates that a future blockchain transaction will comprise a payment and the method further comprises: creating a digital identity associated with a second user based at least in part on a credential associated with the second user, wherein the first blockchain wallet address or the second blockchain wallet address is associated with the digital identity; and determining to authenticate the digital identity as a trusted entity based at least in part on the credential and wherein the credential indicates at least one of: that a second wallet score associated with the first blockchain wallet address or the second blockchain wallet address meets or exceeds a threshold wallet score; or that a second authorization to transact with the second user was received from at least one of an anti-money laundering service, know your customer service, or an office of foreign assets control service.

[0153] R. The method of any one of paragraphs O-Q, wherein determining the second set of blockchain wallet addresses is further based at least in part on determining to include or exclude a blockchain wallet address in the second set of blockchain wallet addresses based at least in part on at least one of: determining, based at least in part on the updated blockchain ledger, that the blockchain wallet address last held the first project token at a period of time from a current time that is less than a threshold period or held the first project token for a duration of time that meets or exceeds a threshold duration of time; determining that a number of at least one of first project tokens or other tokens held by the blockchain wallet address meets or exceeds a first threshold number; determining that the blockchain wallet address holds one or more tokens specified by the first user or that the one or more tokens held by the blockchain wallet address are associated with the proj ect identification; determining, based at least in part on the updated blockchain ledger, that a number of blockchain transactions associated with the blockchain wallet meets or exceeds a second threshold number; determining that the blockchain wallet is associated with a geographical location or region; determining that a digital identity associated with the blockchain wallet indicates an age greater than a minimum age, a state or province of residence, or a professional accreditation; determining that a last user login associated with the blockchain wallet indicates that the user login occurred within a time period or within a geographic location; determining that a user-specified criterion is met by at least one of the blockchain wallet address or an account associated with the blockchain wallet address; determining that the blockchain wallet address has conducted a blockchain transaction with a wallet associated with the first user; or determining that a third project token held by the blockchain wallet address is associated with a first property that is the same as a property indicated by the metadata file. [0151] S. The method of paragraph R, wherein the method further comprises determining to include the blockchain wallet in a subset of the second set of blockchain wallet addresses based at least in part on at least one of: determining that a blockchain wallet address of the subset is associated with a first wallet score that meets or exceeds a threshold wallet score; determining that the blockchain wallet address is associated with a credential indicating authorization to receive payment from at least one of an anti -money laundering database, know your customer database, or an office of foreign assets control database; determining the subset of the second set ofblockchain wallet addresses to include only current holders of the first project token, only previous holders of the first project token, or both current holders and previous holders of the first project token; and wherein the method further comprises determining to withhold the second blockchain transaction from a remainder of the second set ofblockchain wallet addresses that does not include the subset of the second set of blockchain wallet addresses, or sending an alternate blockchain transaction to the remainder.

[0155] T. The method of any one of paragraphs O-S, wherein: the first file comprises at least one of text, a document file, an audio file, a video file, or an image; the metadata file further indicates that the first file is cither private or public; and the method further comprises: storing the first file in a network-accessible memory; if the metadata file indicates that the first file is private, encrypting the first files based at least in part on a private key that is part of a cryptographic signature of the first project token executed by a wallet that holds the first project token; and storing the metadata file in network-accessible memory.

[0156] While the example clauses described above are described with respect to one particular implementation, it should be understood that, in the context of this document, the content of the example clauses can also be implemented via a method, device, system, computer-readable medium, and/or another implementation. Additionally, any of examples A-T may be implemented alone or in combination with any other one or more of the examples A-T.

CONCLUSION

[0157] Various instructions, methods and techniques described herein may be considered in the general context of computer-executable instructions, such as program modules stored on computer-readable media, and executed by the processor(s) herein. Generally, program modules include routines, programs, objects, components, data structures, etc., for performing particular tasks or implementing particular abstract datatypes. These program modules, and the like, may be executed as native code or can be downloaded and executed, such as in a virtual machine or other just-in-time compilation execution environment. Typically, the functionality of the program modules may be combined or distributed as desired in various implementations. An implementation of these modules and techniques may be stored on computer storage media or transmitted across some form of communication media.

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

[0159] The modules and/or components described herein represent instructions that can be stored in any type of computer-readable medium and can be implemented in software and/or hardware. All of the methods and processes described above can be embodied in, and fully automated via, software code modules and/or computer-executable instructions executed by one or more computers or processors, hardware, or some combination thereof. Some or all of the methods can alternatively be embodied in specialized computer hardware.

[0160] Conditional language such as, among others, “can,” “could,” “may” or “might,” unless specifically stated otherwise, are understood within the context to present that certain examples include, while other examples do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that certain features, elements and/or steps are in any way required for one or more examples or that one or more examples necessarily include logic for deciding, with or without user input or prompting, whether certain features, elements and/or steps arc included or arc to be performed in any particular example.

[0161] Conjunctive language such as the phrase “at least one of X, Y or Z,” unless specifically stated otherwise, is to be understood to present that an item, term, etc. can be either X, Y, or Z, or any combination thereof, including multiples of each element. Unless explicitly described as singular, “a” means singular and plural.

[0162] While one or more examples of the techniques have been described, various alterations, additions, permutations and equivalents thereof are included within the scope of the techniques.

[0163] In the description of embodiments, reference is made to the accompanying drawings that form a part hereof, which show by way of illustration specific embodiments of the claimed subject matter. It is to be understood that other embodiments may be used and that changes or alterations, such as structural changes, may be made. Such embodiments, changes or alterations are not necessarily departures from the scope with respect to the intended claimed subject matter. While the steps herein may be presented in a certain order, in some cases the ordering may be changed so that certain inputs are provided at different times or in a different order without changing the function of the systems and methods described. The disclosed procedures could also be executed in different orders. Additionally, various computations that are herein need not be performed in the order disclosed, and other embodiments using alternative orderings of the computations could be readily implemented. In addition to being reordered, the computations could also be decomposed into subcomputations with the same results.

[0164] Any routine descriptions, elements or blocks in the flow diagrams described herein and/or depicted in the attached figures should be understood as potentially representing modules, segments, or portions of code that include one or more computer-executable instructions for implementing specific logical functions or elements in the routine. Alternate implementations are included within the scope of the examples described herein in which elements or functions can be deleted, or executed out of order from that shown or discussed, including substantially synchronously or in reverse order, depending on the functionality involved as would be understood by those skilled in the art.

[0165] It should be emphasized that many variations and modifications can be made to the above-described examples, the elements of which are to be understood as being among other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims.

Claims

CLAIMS WHAT IS CLAIMED IS:

1. A system comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: receiving a first request to create a first project token from a first device associated with a first user, wherein the first request indicates a blockchain network on which to mint the first project token, a first blockchain wallet address to which to transfer the first project token, and includes a link to a metadata file indicating project data including a project identification and a link to a first file; transmitting a set of project tokens comprising the first project token to a first set of blockchain wallet addresses by a first set of blockchain transactions over the blockchain network, wherein the first set of blockchain wallet addresses comprises the first blockchain wallet address; receiving, from the blockchain network, a portion of an updated blockchain ledger indicating at least one of minting the first project token, transmission of the first project token to the first blockchain wallet address, or a transfer of the first project token from the first blockchain wallet address to a second blockchain wallet address; receiving a second request to create a second blockchain transaction, the second blockchain transaction comprising transmitting at least one of a follow-on token, cryptocurrency, message, or one or more files to a second set of blockchain wallet addresses and wherein the second request is received at a time subsequent to the first blockchain transaction; determining, based at least in part on the portion of the updated blockchain ledger and a token ownership chain, the second set of blockchain wallet addresses based at least in part on determining that the second set of blockchain wallet addresses at least one of currently holds or previously held the first project token; and transmitting, to the blockchain network, a third request to execute the second blockchain transaction with the set of blockchain wallet addresses.

2. The system of claim 1, wherein: the metadata file further includes repayment data indicating a future blockchain transaction comprising the follow-on token or cryptocurrency transfer to a wallet that holds the first project token at a future time; and receiving the second request is based at least in part on a host computing device determining, based at least in part on the repayment data that a time period has passed, that a file was uploaded, or that a blockchain transaction initiated by the first device occurred on the first blockchain network or a second blockchain network.

3. The system of claim 1, wherein the metadata file indicates that a future blockchain transaction will comprise a payment and the operations further comprise: creating a digital identity associated with a second user based at least in part on a credential associated with the second user, wherein the first blockchain wallet address or the second blockchain wallet address is associated with the digital identity; and determining to authenticate the digital identity as a trusted entity based at least in part on the credential and wherein the credential indicates at least one of: that a second wallet score associated with the first blockchain wallet address or the second blockchain wallet address meets or exceeds a threshold wallet score; or that a second authorization to transact with the second user was received from at least one of an anti-money laundering sendee, know your customer service, or an office of foreign assets control service.

4. The system of claim 1, wherein determining the second set of blockchain wallet addresses is further based at least in part on determining to include or exclude a blockchain wallet address in the second set of blockchain wallet addresses based at least in part on at least one of: determining, based at least in part on the updated blockchain ledger, that the blockchain wallet address last held the first proj ect token at a period of time from a current time that is less than a threshold period or held the first project token for a duration of time that meets or exceeds a threshold duration of time; determining that a number of at least one of first project tokens or other tokens held by the blockchain wallet address meets or exceeds a first threshold number; determining that the blockchain wallet address holds one or more tokens specified by the first user or that the one or more tokens held by the blockchain wallet address are associated with the project identification; determining, based at least in part on the updated blockchain ledger, that a number of blockchain transactions associated with the blockchain wallet meets or exceeds a second threshold number; determining that the blockchain wallet is associated with a geographical location or region; determining that a digital identity associated with the blockchain wallet indicates an age greater than a minimum age, a state or province of residence, or a professional accreditation; determining that a last user login associated with the blockchain wallet indicates that tire user login occurred within a time period or within a geographic location; determining that a user-specified criterion is met by at least one of the blockchain wallet address or an account associated with the blockchain wallet address; determining that the blockchain wallet address has conducted a blockchain transaction with a wallet associated with the first user; or determining that a third project token held by the blockchain wallet address is associated with a first property that is the same as a property indicated by the metadata file.

5. The system of claim 4. wherein the operations further comprise determining to include the blockchain wallet in a subset of the second set of blockchain wallet addresses based at least in part on at least one of: determining that a blockchain wallet address of the subset is associated with a first wallet score that meets or exceeds a threshold wallet score; determining that the blockchain wallet address is associated with a credential indicating authorization to receive payment from at least one of an anti-money laundering database, know your customer database, or an office of foreign assets control database; determining the subset of the second set of blockchain wallet addresses to include only current holders of the first project token, only previous holders of the first project token, or both current holders and previous holders of the first project token; and wherein the operations further comprise determining to withhold the second blockchain transaction from a remainder of the second set of blockchain wallet addresses that does not include the subset of the second set of blockchain wallet addresses, or sending an alternate blockchain transaction to the remainder.

6. The system of claim 1, wherein: the first file comprises at least one of text, a document file, an audio file, a video file, or an image; the metadata file further indicates that the first file is either private or public; and the operations further comprise: storing the first file in a network-accessible memory; if the metadata file indicates that the first file is private, encrypting the first files based at least in part on a private key that is part of a cryptographic signature of the first project token executed by a wallet that holds the first project token; and storing the metadata file in network-accessible memory.

7. Tire system of claim 6, wherein: the cryptographic signature was executed by a first wallet associated with the first blockchain wallet address; the second blockchain wallet address is a current holder of the first project token; and the operations further comprise: determining, based at least in part on the portion of the updated blockchain ledger, that the first project token was transferred from the first blockchain wallet address to the second blockchain wallet address; creating a smart contract on the blockchain network or a second blockchain network, wherein the smart contract encrypts the private key and is configured to verify ownership of the first project token; receiving, from a second wallet associated with the second blockchain wallet address, a request to access the private key and a cryptographic proof of ownership of a second private key having ownership of the first project token; and permitting access, by the smart contract, to the private key based at least in part on determining, based at least in part on the updated blockchain ledger, that the second wallet is the current holder of the first project token and the cryptographic proof.

8. One or more non-transitory computer-readable media storing processor-executable instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising: receiving a first request to create a first project token from a first device associated with a first user, wherein the first request indicates a blockchain network on which to mint the first project token, a first blockchain wallet address to which to transfer the first project token, and includes a link to a metadata file indicating project data including a project identification and a link to a first file; transmitting a set of project tokens comprising the first project token to a first set of blockchain wallet addresses by a first set of blockchain transactions over the blockchain network, wherein the first set of blockchain wallet addresses comprises the first blockchain wallet address; receiving, from the blockchain network, a portion of an updated blockchain ledger indicating at least one of minting the first project token, transmission of the first project token to the first blockchain wallet address, or a transfer of the first project token from the first blockchain wallet address to a second blockchain wallet address; receiving a second request to create a second blockchain transaction, the second blockchain transaction comprising transmitting at least one of a follow-on token, cryptocurrency, message, or one or more files to a second set of blockchain wallet addresses and wherein the second request is received at a time subsequent to the first blockchain transaction; determining, based at least in part on the portion of the updated blockchain ledger and a token ownership chain, the second set of blockchain wallet addresses based at least in part on determining that the second set of blockchain wallet addresses at least one of currently holds or previously held the first project token; and transmitting, to the blockchain network, a third request to execute the second blockchain transaction with the set of blockchain wallet addresses.

9. The one or more non-transitory computer-readable media of claim 8, wherein: the metadata file further includes repayment data indicating a future blockchain transaction comprising the follow-on token or cryptocurrency transfer to a wallet that holds the first project token at a future time; and receiving the second request is based at least in part on a host computing device determining, based at least in part on the repayment data that a time period has passed, that a file was uploaded, or that a blockchain transaction initiated by the first device occurred on the first blockchain network or a second blockchain network.

10. The one or more non-transitory computer-readable media of claim 8, wherein the metadata file indicates that a future blockchain transaction will comprise a payment and the operations further comprise: creating a digital identity associated with a second user based at least in part on a credential associated with the second user, wherein the first blockchain wallet address or the second blockchain wallet address is associated with the digital identity; and determining to authenticate the digital identity as a trusted entity based at least in part on the credential and wherein the credential indicates at least one of: that a second wallet score associated with the first blockchain wallet address or the second blockchain wallet address meets or exceeds a threshold wallet score; or that a second authorization to transact with the second user was received from at least one of an anti-money laundering sendee, know your customer service, or an office of foreign assets control service.

11. The one or more non-transitory computer-readable media of claim 8, wherein determining the second set of blockchain wallet addresses is further based at least in part on determining to include or exclude a blockchain wallet address in the second set of blockchain wallet addresses based at least in part on at least one of: determining, based at least in part on the updated blockchain ledger, that the blockchain wallet address last held the first proj ect token at a period of time from a current time that is less than a threshold period or held the first project token for a duration of time that meets or exceeds a threshold duration of time; determining that a number of at least one of first project tokens or other tokens held by the blockchain wallet address meets or exceeds a first threshold number; determining that the blockchain wallet address holds one or more tokens specified by the first user or that the one or more tokens held by the blockchain wallet address are associated with the project identification; determining, based at least in part on the updated blockchain ledger, that a number of blockchain transactions associated with the blockchain wallet meets or exceeds a second threshold number; determining that the blockchain wallet is associated with a geographical location or region; determining that a digital identity associated with the blockchain wallet indicates an age greater than a minimum age, a state or province of residence, or a professional accreditation; determining that a last user login associated with the blockchain wallet indicates that the user login occurred within a time period or within a geographic location; determining that a user-specified criterion is met by at least one of the blockchain wallet address or an account associated with the blockchain wallet address; determining that the blockchain wallet address has conducted a blockchain transaction with a wallet associated with the first user; or determining that a third project token held by the blockchain wallet address is associated with a first property that is the same as a property indicated by the metadata file.

12. The one or more non-transitory computer-readable media of claim 11, wherein the operations further comprise determining to include the blockchain wallet in a subset of the second set of blockchain wallet addresses based at least in part on at least one of: determining that a blockchain wallet address of the subset is associated with a first wallet score that meets or exceeds a threshold wallet score; determining that the blockchain wallet address is associated with a credential indicating authorization to receive payment from at least one of an anti-money laundering database, know your customer database, or an office of foreign assets control database; determining the subset of the second set of blockchain wallet addresses to include only current holders of the first project token, only previous holders of the first project token, or both current holders and previous holders of the first project token; and wherein the operations further comprise determining to withhold the second blockchain transaction from a remainder of the second set of blockchain wallet addresses that does not include the subset of the second set of blockchain wallet addresses, or sending an alternate blockchain transaction to the remainder.

13. The one or more non-transitory computer-readable media of claim 8, wherein: the first file comprises at least one of text, a document file, an audio file, a video file, or an image; the metadata file further indicates that the first file is either private or public; and the operations further comprise: storing the first file in a network-accessible memory; if the metadata file indicates that the first file is private, encrypting the first files based at least in part on a private key that is part of a cryptographic signature of the first project token executed by a wallet that holds the first project token; and storing the metadata file in network-accessible memory.

14. The one or more non-transitory computer-readable media of claim 13, wherein: the cryptographic signature was executed by a first wallet associated with the first blockchain wallet address; the second blockchain wallet address is a current holder of the first project token; and the operations further comprise: determining, based at least in part on the portion of the updated blockchain ledger, that the first project token was transferred from the first blockchain wallet address to the second blockchain wallet address, creating a smart contract on the blockchain network or a second blockchain network, wherein the smart contract encrypts the private key and is configured to verify ownership of the first project token; receiving, from a second wallet associated with the second blockchain wallet address, a request to access the private key and a cryptographic proof of ownership of a second private key having ownership of the first project token; and permitting access, by the smart contract, to the private key based at least in part on determining, based at least in part on the updated blockchain ledger, that the second wallet is the current holder of the first project token and the cryptographic proof.

15. A method comprising: receiving a first request to create a first project token from a first device associated with a first user, wherein the first request indicates a blockchain network on which to mint the first project token, a first blockchain wallet address to which to transfer the first project token, and includes a link to a metadata file indicating project data including a project identification and a link to a first file; transmitting a set of project tokens comprising the first project token to a first set of blockchain wallet addresses by a first set of blockchain transactions over the blockchain network, wherein the first set of blockchain wallet addresses comprises the first blockchain wallet address; receiving, from the blockchain network, a portion of an updated blockchain ledger indicating at least one of minting the first project token, transmission of the first project token to the first blockchain wallet address, or a transfer of the first project token from the first blockchain wallet address to a second blockchain wallet address; receiving a second request to create a second blockchain transaction, the second blockchain transaction comprising transmitting at least one of a follow-on token, cryptocurrency, message, or one or more files to a second set of blockchain wallet addresses and wherein the second request is received at a time subsequent to the first blockchain transaction; determining, based at least in part on the portion of the updated blockchain ledger and a token ownership chain, the second set of blockchain wallet addresses based at least in part on determining that the second set of blockchain wallet addresses at least one of currently holds or previously held the first project token; and transmitting, to the blockchain network, a third request to execute the second blockchain transaction with the set of blockchain wallet addresses.

16. The method of claim 15, wherein: the metadata file further includes repayment data indicating a future blockchain transaction comprising the follow-on token or cryptocurrency transfer to a wallet that holds the first project token at a future time; and receiving the second request is based at least in part on a host computing device determining, based at least in part on the repayment data that a time period has passed, that a file was uploaded, or that a blockchain transaction initiated by the first device occurred on the first blockchain network or a second blockchain network.

17. The method of claim 15, wherein the metadata file indicates that a future blockchain transaction will comprise a payment and the method further comprises: creating a digital identity associated with a second user based at least in part on a credential associated with the second user, wherein the first blockchain wallet address or the second blockchain wallet address is associated with the digital identity; and determining to authenticate the digital identity as a trusted entity based at least in part on the credential and wherein the credential indicates at least one of: that a second wallet score associated with the first blockchain wallet address or the second blockchain wallet address meets or exceeds a threshold wallet score; or that a second authorization to transact with the second user was received from at least one of an anti-money laundering sendee, know your customer service, or an office of foreign assets control service.

18. The method of claim 15, wherein determining the second set of blockchain wallet addresses is further based at least in part on determining to include or exclude a blockchain wallet address in the second set of blockchain wallet addresses based at least in part on at least one of: determining, based at least in part on the updated blockchain ledger, that the blockchain wallet address last held the first proj ect token at a period of time from a current time that is less than a threshold period or held the first project token for a duration of time that meets or exceeds a threshold duration of time; determining that a number of at least one of first project tokens or other tokens held by the blockchain wallet address meets or exceeds a first threshold number; determining that the blockchain wallet address holds one or more tokens specified by the first user or that the one or more tokens held by the blockchain wallet address are associated with the project identification; determining, based at least in part on the updated blockcham ledger, that a number of blockchain transactions associated with the blockchain wallet meets or exceeds a second threshold number; determining that the blockchain wallet is associated with a geographical location or region; determining that a digital identity associated with the blockchain wallet indicates an age greater than a minimum age, a state or province of residence, or a professional accreditation; determining that a last user login associated with the blockchain wallet indicates that the user login occurred within a time period or within a geographic location; determining that a user-specified criterion is met by at least one of the blockchain wallet address or an account associated with the blockchain wallet address; determining that the blockchain wallet address has conducted a blockchain transaction with a wallet associated with the first user; or determining that a third project token held by the blockchain wallet address is associated with a first property that is the same as a property indicated by the metadata file.

19. The method of claim 18, wherein the method further comprises determining to include the blockchain wallet in a subset of the second set of blockchain wallet addresses based at least in part on at least one of: determining that a blockchain wallet address of the subset is associated with a first wallet score that meets or exceeds a threshold wallet score; determining that the blockchain wallet address is associated with a credential indicating authorization to receive payment from at least one of an anti-money laundering database, know your customer database, or an office of foreign assets control database; determining the subset of the second set of blockchain wallet addresses to include only current holders of the first project token, only previous holders of the first project token, or both current holders and previous holders of the first project token; and wherein the method further comprises determining to withhold the second blockchain transaction from a remainder of the second set of blockchain wallet addresses that does not include the subset of the second set of blockchain wallet addresses, or sending an alternate blockchain transaction to the remainder.

20. The method of claim 15, wherein: the first file comprises at least one of text, a document file, an audio file, a video file, or an image; the metadata file further indicates that the first file is cither private or public; and the method further comprises: storing the first file in a network-accessible memory; if the metadata file indicates that the first file is private, encrypting the first files based at least in part on a private key that is part of a cryptographic signature of the first project token executed by a wallet that holds the first project token; and storing the metadata file in nctwork-acccssiblc memory.