Method and system for providing token identity - Patents.com

Abstract

A method for facilitating permission-based cryptographic transactions between service providers includes: receiving an onboarding request from a first computing system, the onboarding request including permission data and an identification value, the identification value being associated with a first blockchain wallet; generating a permission token and an alias based on the permission data, the permission token including a verified identity data point; sending the generated alias to the first computing system in response to the onboarding request; receiving a token request from a second computing system, the token request including the alias; and sending the generated permission token and the identification value to the second computing system in response to the token request.

Description

[Technical Field]

[0001] The present disclosure relates to providing token identities, and in particular to the use of permission tokens, to facilitate cryptographic transactions between service providers that comply with identity verification requirements without the need for the transmission or exchange of personally identifiable information.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of and priority to U.S. Provisional Patent Application No. 63 / 406,521, filed September 14, 2022, the entire disclosure of which is incorporated herein by reference. [Background technology]

[0003] Blockchain was originally created to provide a platform for trading cryptocurrencies. Two key principles on which it was created were that the blockchain itself be fully distributed, stored and managed across a vast collection of computing systems, and that cryptocurrency transactions be conducted with complete anonymity, with participants not being required to provide identifying information and all transactions between blockchain wallets being independent of ownership. These two principles led to the widespread adoption of blockchain, which has led to its use in creating and managing a vast number and variety of cryptocurrencies.

[0004] However, the popularity of blockchain, combined with its decentralized and anonymous nature, has led to a significant amount of fraud in cryptocurrency transactions, costing consumers over $1 billion in 2021 in the United States alone. The lack of a central authority to regulate transactions puts users at a disadvantage, and anonymity leaves victims with little redress, making it difficult to police and stop fraudulent actors. To combat fraudulent activity, many countries have established policies, regulations, and requirements regarding the identity of blockchain participants and rules for participants in blockchain transactions.

[0005] To comply with these new policies and regulations, virtual asset service providers (VASPs), which operate cryptocurrency exchanges or blockchain wallets on behalf of participants, perform identity verification processes for their participants. However, because a large portion of cryptocurrency transactions occur between participants using different VASPs, each VASP is required to verify the identities of other users transacting with its participants, a process that can be difficult and exposes participants' and other users' personally identifiable information (PII) to other VASPs. Furthermore, a significant number of cryptocurrency transactions occur between participants in different countries, each with its own applicable policies and regulations. Therefore, VASPs are not only forced to verify the identities of other users of their participants' transactions, but also to verify that both their participants and other users comply with applicable regulations in other countries, a process with which VASPs may not be familiar.

[0006] As a result, current systems require all VASPs to be familiar with the regulations that may apply to every country in which their participants are located in order to ensure compliance with applicable regulations, and require all VASPs to easily exchange users' PII, which can be a fairly difficult, time-consuming, and costly task and can significantly increase the opportunities for users' PII to be compromised. Therefore, there is a need for a technological solution to ensure compliance of cryptographic transactions without the exchange of PII and without requiring VASPs to be familiar with applicable regulations in every potential trading country. Summary of the Invention

[0007] This disclosure provides a description of a system and method for facilitating permission-based cryptographic transactions between service providers. A new user of a blockchain can verify their identity through their virtual asset service provider (VASP) and interact with the blockchain through the virtual asset service provider. The VASP can verify the user's identity and any aspects of it that may be applicable under regulations regarding cryptographic transactions. The VASP can register a user with a token identity service by providing data points related to verified user identity attributes. The token identity service can generate a permission token for the user based on those verified user identity attributes and return to the VASP an alias that the user can use when engaging in cryptographic transactions. When conducting a transaction, the user can provide their alias to the other party. The other party can provide the alias to their VASP when requesting to receive or send cryptocurrency from the user. The other party VASP can provide the alias to the token identity service, which can return a permission token for the user containing all the information the other party VASP needs to ensure that the user has been properly verified to meet any applicable regulations known to the other party VASP. The other party VASP can then submit the new cryptocurrency transaction to the blockchain, indicating full compliance, and no PII about any of the participants has been exchanged; each VASP only needs to verify the identity of its own user.

[0008] A method for facilitating permission-based cryptographic transactions between service providers includes: receiving, by a receiver of a processing server, an onboarding request from a first computing system, the onboarding request including at least permission data and an identification value, the identification value being associated with a first blockchain wallet for a blockchain associated with a blockchain network; generating, by a processor of the processing server, a permission token and an alias based at least on the permission data, the permission token including one or more verified identity data points; transmitting, by a transmitter of the processing server, the generated alias to the first computing system in response to the received onboarding request; receiving, by the receiver of the processing server, a token request from a second computing system, the token request including the alias; and transmitting, by the transmitter of the processing server, at least the generated permission token and the identification value to the second computing system in response to the received token request.

[0009] A system for facilitating permission-based cryptographic transactions between service providers includes: a blockchain network; a first computing system; a second computing system; and a processing server; the processing server comprising: a receiver that receives an onboarding request from the first computing system, the onboarding request including at least permission data and an identification value, the identification value being associated with a first blockchain wallet for a blockchain associated with the blockchain network; a processor that generates a permission token and an alias based on at least the permission data, the permission token including one or more verified identity data points; and a transmitter that transmits the generated alias to the first computing system in response to the received onboarding request, wherein the receiver of the processing server receives a token request from the second computing system, the token request including the alias, and the transmitter of the processing server transmits at least the generated permission token and the identification value to the second computing system in response to the received token request. [Brief explanation of the drawings]

[0010] The scope of the present disclosure is best understood from the following detailed description of exemplary embodiments when taken in conjunction with the accompanying drawings, in which:

[0011] [Figure 1] FIG. 1 is a block diagram illustrating a high-level system architecture for facilitating permission-based cryptographic transactions, according to an example embodiment. [Figure 2] 2 is a block diagram illustrating a processing server in the system of FIG. 1 that facilitates permission-based cryptographic transactions, according to an example embodiment. [Figure 3A]2 is a flow diagram illustrating a process for facilitating permission-based cryptographic transactions between service providers within the system of FIG. 1 according to an example embodiment. [Figure 3B] 2 is a flow diagram illustrating a process for facilitating permission-based cryptographic transactions between service providers within the system of FIG. 1 according to an example embodiment. [Figure 4] 1 is a flow diagram illustrating an example method for facilitating permission-based cryptographic transactions between service providers, according to an example embodiment. [Figure 5] FIG. 1 is a block diagram illustrating a computer system architecture, according to an exemplary embodiment.

[0012] Further areas of applicability of the present disclosure will become apparent from the following detailed description. The detailed description of exemplary embodiments is intended for purposes of illustration only and is not intended to necessarily limit the scope of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0013] System for Permission-Based Cryptographic Transactions FIG. 1 illustrates a system 100 for facilitating permission-based cryptographic transactions on a blockchain in a manner that satisfies compliance with any applicable regulations and without the exchange of personally identifiable information (PII). System 100 may include a processing server 102, described in more detail below, which may operate a token identity service to facilitate permission-based transactions. System 100 may also include a blockchain network 104. Blockchain network 104 may include multiple blockchain nodes 106. Each blockchain node 106 may be a computing system, such as that shown in FIG. 2 or FIG. 5, described in more detail below, configured to perform functions related to blockchain processing and management, including, for example, generating blockchain data values, verifying proposed blockchain transactions, verifying digital signatures, generating new blocks, validating new blocks, and maintaining copies of the blockchain. In some embodiments, processing server 102 may be a blockchain node 106 in blockchain network 104.

[0014] A blockchain may be a distributed ledger comprising at least a plurality of blocks. Each block may include at least a block header and one or more data values. Each block header may include at least a timestamp, a block reference value, and a data reference value. The timestamp may be the time when the block header was generated and may be expressed using any suitable method (e.g., a UNIX timestamp, DateTime notation, etc.). The block reference value may be a value that references a preceding block in the blockchain (e.g., based on the timestamp). In some embodiments, the block reference value in the block header may be a reference to the block header of the most recently added block preceding the respective block. In an exemplary embodiment, the block reference value may be a hash value generated by hashing the block header of the most recently added block. Similarly, the data reference value may be a reference to one or more data values ​​stored in the block containing the block header. In an exemplary embodiment, the data reference value may be a hash value generated by hashing one or more data values. For example, the block reference value may be the root of a Merkle tree generated using one or more data values.

[0015] The use of a block reference value and a data reference value in each block header results in immutability for the blockchain. Any attempted change to the data value requires the generation of a new data reference value for that block, which in turn requires the generation of a new block reference value for the subsequent block, which in turn requires the generation of a new block reference value for each subsequent block. For the change to be permanent, this must be performed and updated for every single blockchain node 106 in the blockchain network 104 before a new block is created and added to the blockchain. Computational and communication limitations can make such changes extremely difficult or impossible, thus achieving the blockchain's immutability.

[0016] In some embodiments, a blockchain can be used to store information about blockchain transactions made between two different blockchain wallets. A blockchain wallet can contain a private key of a cryptographic key pair, which can be used to generate a digital signature that can serve as a payer's authorization for the blockchain transaction, and the digital signature can be verified by each blockchain network 104 using the public key of the cryptographic key pair. In some cases, the term "blockchain wallet" can specifically refer to a private key. In other cases, the term "blockchain wallet" can refer to a computing device (e.g., user device 108a, service provider 110a, etc.) that stores a private key for use in blockchain transactions. For example, each computing device can have its own private key for each cryptographic key pair and can be a blockchain wallet for use in transactions with a blockchain associated with the blockchain network. The computing device can be any type of device suitable for storing and utilizing a blockchain wallet, such as a desktop computer, laptop computer, notebook computer, tablet computer, mobile phone, smartphone, smartwatch, smart TV, wearable computing device, embedded computing device, etc.

[0017] Each blockchain data value stored in the blockchain may correspond to a blockchain transaction or other data storage, as appropriate. A blockchain transaction may include at least the following: a digital signature of the sender (e.g., user device 10b, service provider 110b, etc.) generated using the sender's private key, the recipient's blockchain address of the currency generated using the recipient's public key, and the amount of blockchain currency to be transferred or other stored data. In some blockchain transactions, the transaction may also include: one or more sender blockchain addresses where the blockchain currency is currently stored (e.g., if a digital signature validates access to such currency); and an address for any changes to be maintained by the sender, generated using the sender's public key. Addresses to which cryptocurrency that can be used in future transactions is sent are referred to as "output" addresses because they were previously used to capture the output of a previous blockchain transaction, and are also referred to as "unspent transactions" because there is currency sent to the address in a previous transaction where that currency has not yet been spent. In some cases, a blockchain transaction may also include a sender public key for use by an entity in validating the transaction. For traditional processing of blockchain transactions, such data may be provided by either the sender or the recipient to a blockchain node 106 in the blockchain network 104. The node can use the public key in the sender's wallet's cryptographic key pair to verify the digital signature and verify access to the sender's funds (e.g., if the unspent transaction has not yet been spent and was sent to an address associated with the sender's wallet), a process known as "confirming" the transaction, and then including the blockchain transaction in a new block.In traditional blockchain implementations, new blocks may be validated by other blockchain nodes 106 in the blockchain network 104 before being added to the blockchain and distributed to all blockchain nodes 106 in the blockchain network 104. If the blockchain data value does not relate to a blockchain transaction but instead relates to the storage of other types of data, the blockchain data value may still include or involve digital signature validation.

[0018] The system 100 may include the user devices 108 shown in FIG. 1 as a first user device 108a and a second user device 108b. Each user device 108 may be a device utilized by a participant in a blockchain associated with the blockchain network 104 and may perform functions associated with the blockchain. In the system 100, participants in the blockchain may interact with the blockchain through a service provider 110. The service provider 110 may interact directly with the blockchain nodes 106 on behalf of the participant to provide convenience, value-added services, security, etc. to the participant. In some cases, the service provider 110 may store keys for blockchain wallets associated with the participant (e.g., similar to how a bank maintains accounts used by customers). In other cases, the user device 108 may hold private keys for its blockchain wallet, and communications may be routed to the blockchain network 104 through the service provider 110. In the industry, the service provider 110 may also be referred to as a “virtual asset service provider” or “VASP.” In some cases, each participant in a transaction may utilize a different service provider 110. In other cases, both participants in a transaction may utilize the same service provider 110 .

[0019] In the system 100, cryptographic transactions conducted using blockchain may be subject to one or more policies, regulations, requirements, constraints, etc., collectively referred to herein as regulations. Regulations may be set by the blockchain network 104, the service provider 110, a government agency, a financial institution, a standards body, or other appropriate entity. Regulations may apply to any aspect of a transaction or to any aspect of the individuals involved in a transaction. For example, a country may require that the identity of anyone conducting a cryptographic transaction within that country be verified. For another example, transactions involving certain types of goods (e.g., alcohol) may require that both parties to the transaction be of a certain age. In some cases, regulations may apply to one participant in a transaction (e.g., location-specific regulations that apply only to participants within a location). In other cases, regulations may apply to both participants in a transaction, and rules may be applied to both parties in a transaction to satisfy applicable regulations, such as when a country requires both participants in a transaction even if one participant is located within its country.

[0020] To ensure compliance with applicable regulations, traditionally, each service provider 110 identifies all applicable regulations and performs all necessary verifications for each participant to verify compliance. To accomplish this task, service providers 110 may exchange PII with participants, allowing service provider 110b to verify the identity of the participant behind user device 108a, for example. Each time a participant transacts with another participant using a different service provider 110, that participant's PII is provided to the new service provider 110, resulting in that participant's PII being spread across multiple systems and through multiple transfers, significantly increasing the likelihood that that person's data will be compromised.

[0021] To address these challenges and allow the service provider 110 to focus solely on its participants, the processing server 102 can provide a token identity service using permission tokens to quickly and accurately provide regulatory compliance information. In the system 100, when a new blockchain participant registers with the service provider 110, the service provider 110 verifies the participant's identity and collects any other appropriate information that may be required for compliance with any potential regulations. The service provider 110 can verify the identity and other data using any appropriate method. The verified data (also referred to as verified identity data points or verified identity attributes) can be obtained and stored by the service provider 110 in any appropriate manner, such as in compliance with any regulations applicable to the storage of PII or other identity data. The identity attributes can include any attributes relevant to applicable regulations regarding cryptographic transactions, such as level of identity verification (e.g., identification via name, identification via photograph, multiple types of identity verification, etc.), age, geographic location, income, compliance with regulatory authorities, etc. For example, service provider 110 may verify a participant's identity and age via a driver's license and store an attribute indicating the participant's age and that the identity was successfully verified by their state government. In another example, service provider 110 may verify a participant's identity and age through their national government (e.g., via a passport) and also verify their geographic location through a state government and store an attribute indicating that the identity and age are verified at the central level and the location is verified at the state level.

[0022] Once the service provider 110 verifies the participant's identity attributes, the participant can be registered with the token identity service via the processing server 102. In some cases, communication with the processing server 102 can be performed by the service provider 110 on the participant's behalf. In other cases, the participant can communicate directly with the processing server 102 using their user device 108. In such cases, the participant can provide information identifying the service provider 110 whose identity has been verified. Registering the participant with the processing server 102 can include transmitting not only the permission data in the verified identity attributes, but also identifying information regarding the blockchain wallet with which the identity attributes are associated. In some cases, the identifying information can be the public key of the blockchain wallet. In other cases, the identifying information can be a unique value suitable for use by the service provider 110 in identifying the participant and its stored data.

[0023] The processing server 102 can receive verified identity attributes and identification information about the participants. When the processing server receives registration data from the user device 108, the processing server 102 can use the provided information to identify the service provider 110 to verify or request verified user identity attributes. In an exemplary embodiment, the processing server 102 can receive only attributes about the participants without any PII. For example, the attributes can include that the participant's identity has been double-verified at a central level (without any information about that identity).

[0024] After receiving the attributes, the processing server 102 can generate a permission token for the participant. The permission token can be a digital token containing the attributes in a standardized format and can include fields for any identity attributes necessary to ensure compliance with applicable regulations. For example, the permission token can include separate data fields for identity verification for multiple levels and countries, as well as data fields for income, age, state, city, country, education level, etc. If attribute data for such a field is not provided to the processing server 102, the field can be left empty or null. In some cases, the permission token can include a field indicating compliance with identity requirements in each country that includes participants in the blockchain. For example, in a case involving participants from 20 countries, the permission token can include fields indicating compliance or non-compliance with regulations for each of those 20 countries. The processing server 102 can be configured to determine compliance based on each country's regulations and the supplied identity attributes. In some cases, the processing server 102 can be configured to determine compliance with any regulations that may be imposed or submitted by any appropriate entity, such as a financial institution, a standards organization, etc. For example, the service provider 110 may verify a participant's identity at a level appropriate for United States (US) regulations but not for European Union (EU) regulations, in which case the participant's permission token may indicate compliance with the US and non-compliance with the EU.

[0025] In addition to the permission token, the processing server 102 can generate an alias for the participant. The alias can be a value that is unique to the participant and directly associated with the participant's permission token, and can be used to identify the participant and its permission token among service providers 110. The processing server 102 can return the alias to the user device 108 (e.g., directly or via the service provider 110). The participant can then send its alias to another participant via its user device 108 and the other participant's user device 108 when a new transaction is desired. In some cases, a participant can request a specific alias during the registration process. In some embodiments, a participant can link its alias across multiple service providers 110. For example, a participant can have three different blockchain wallets managed by three different service providers 110 and can register with the processing server 102 (e.g., via its user device 108) to associate its alias with all three blockchain wallets. In such embodiments, participants can select which blockchain wallet to use to send and receive currency for a particular transaction. In some cases, an alias can include a subsection or component that indicates a service provider. For example, participant Jane can request an alias of "jane," and the service provider to use for the transaction can be indicated as part of the full alias, such as jane.vaspone.tokenservice for a first service provider 110 and jane.vasptwo.tokenservice for a second service provider 110. In these embodiments, participants can deactivate one or more blockchain wallets for use in future cryptographic transactions and / or remove them entirely from their account.

[0026] If the processing server 102 can provide a single participant with multiple blockchain wallets linked via their aliases, such data can be stored in the following example format: - accountAlias:ACC55059970032193496 status:ACTIVE crypto-addresses: - cryptoAddressId:52c3837d-cf45-4830-b1cf-60f2616bfa04 status:ACTIVE asset:BTC blockchainAddress:mu692DY2GwYXbWdv3wUsQRr6nXsYW8QRsm - cryptoAddressId:52c3837d-cf45-4830-b1cf-60f2616bfa05 status:ACTIVE asset:ETH blockchainAddress:'0x46Be1B5b35708e369b943CE6094c6f0484d480A7' createdDate:'2022-03-20T09:12:28-05:00' updatedDate:'2022-03-20T12:18:36-05:00'

[0027] In this example, for a participant with an alias of ACC55059970032193496 (which may be a hash of the participant's issued alias or may be mapped to an issued alias), two blockchain wallets have been registered for use with the alias on the processing server 102, one using BTC and the other using ETC. Both are active as shown in the profile, and therefore both can be used to send and receive currency using the provided addresses.

[0028] In an exemplary transaction, a first participant, Alice, located in the United States, can use a first user device 108a to have her identity verified by a first service provider 110a, register with a token identity service, and be issued an alias, alias.usa.tokenservice. A second participant, Bob, located in Canada, uses a second service provider 110b to interact with the blockchain and wishes to purchase an item listed by Alice for 10 units of cryptocurrency via a cryptographic transaction on the blockchain. To receive payment, Alice can provide her alias to Bob by sending it from her first user device 108a to Bob's second user device 108b. Bob can then submit a request via the second user device 108b to the second service provider 110b to send 10 units of cryptocurrency to the alias, alice.tokenservice. The second service provider 110b can send a request for Alice's permission token to the processing server 102 via an appropriate communication network and method by including the alias alice.usa.tokenservice.

[0029] The processing server 102 can receive the alias and identify the associated permission token. The processing server 102 can then electronically transmit the permission token back to the service provider 110b. The service provider 110b can then view the verified identity attribute in the permission token to determine whether Alice has verified her identity in an appropriate manner with respect to any regulations applicable to the cryptographic transaction involving Bob's payment of 10 units of cryptocurrency. Once the service provider 110b is satisfied that all matters are in compliance, the service provider 110b can submit a request for the new cryptographic transaction to the blockchain node 106 for inclusion in the blockchain using traditional methods. The request can include a destination address for Alice's blockchain wallet, as well as a digital signature from Bob's blockchain wallet (e.g., provided by the second service provider 110b or by Bob's second user device 108b when requesting the transaction). In some cases, the destination address can be provided by the processing server 102 along with the permission token, can be generated using a public key provided by the processing server 102 along with the permission token, can be provided by the first user device 108a when providing the alias, or can be requested from the first service provider 110a after compliance has been verified by the second service provider 110b.

[0030] The result is a successful cryptographic transaction between the two participants on the blockchain that ensures compliance with applicable regulations. In traditional systems, service provider 110a and service provider 110b would need to exchange Alice's and Bob's PII and verify their respective identities in a manner appropriate to all applicable regulations, including those of both the United States and Canada, which requires each service provider 110a and 110b to be familiar with all regulations and the rules governing the receipt and storage of PII in both countries. In system 100, first service provider 110a is solely responsible for verifying its participant, Alice's, identity and is required to understand the identity requirements for transactions in Alice's country, the United States. Second service provider 110b is solely responsible for verifying Bob's identity and is required to understand the identity requirements for transactions in Bob's country, Canada. By utilizing the permission token from the token identity service, the second service provider 110b can verify that Alice's identity has been verified and complies with U.S. regulations, and can also identify whether the identity verification is appropriate for transactions with Canadian citizens based on the attributes contained therein. The transaction is successfully completed without any exchange of PII, and in some cases, the data represented in the permission token does not require the service provider 110 to independently understand the regulations of every possible jurisdiction. This results in significant improvements in processing speed, user security, and resource consumption for cryptographic transactions. Also, in some embodiments, service providers 110 do not need to communicate directly with other service providers 110, allowing for significantly increased reach and participation rates for all participants and service providers 110 compared to traditional systems.

[0031] In another exemplary transaction, the service provider 110 may itself perform identity verification. In such a case, the permission token may include an attestation by the service provider 110 in place of verified identity attributes. In this example, Alice may provide her alias to Bob, using their user devices 108a and 108b. As part of the process, the first service provider 110a may authenticate that Alice is authorized to participate in the transaction with Bob. Such an attestation may be a digital signature generated by the first service provider 110a or another format suitable for the second service provider 110b to verify as authentic from the first service provider 110a and indicating Alice's authorization to participate in the transaction. Bob may submit a transaction request with Alice's alias to the second service provider 110b, which may request a permission token from the processing server 102 associated with the alias. The processing server 102 can identify the permission token, which can include the attestation from the first service provider 110a, and provide the permission token to the second service provider 110b, which can verify the attestation and permission for Alice to participate in the cryptographic transaction and proceed with the cryptographic transaction.In some cases, the second service provider 110b may provide attestation regarding Bob's permission to participate in the transaction, which may be provided to the processing server 102 when requesting a permission token, which may be provided to the first service provider 110a, and / or may be verified by the first service provider 110a and / or the processing server 102 before providing the permission token to the second service provider 110b.

[0032] In some embodiments, one or more of the functions described in this disclosure can be performed by a smart contract stored on a blockchain. The smart contract can be stored on a blockchain and configured to self-execute when one or more conditions are met. In system 100, the smart contract can be configured to receive a permission token and transaction data as input, resulting in self-execution, where the smart contract verifies that compliance with applicable regulations has been met based on the input permission token. If the verification is successful, the smart contract can generate a new blockchain transaction, which can be submitted to the blockchain node 106 for inclusion in the blockchain. As another example, a smart contract can be used to provide a permission token or a destination address when an alias is provided.

[0033] A smart contract can be used to effectuate the transfer after identity verification is performed by the service provider 110. In such an example, using the methods described above, the first service provider 110a and the second service provider 110b can each verify that their respective users comply with applicable identity regulations. In some cases, the first service provider 110a and the second service provider 110b can exchange notifications indicating successful verification. The first service provider 110a, on behalf of the first user, can indicate to a smart contract stored on the blockchain that cryptocurrency is approved for transfer to the second user. The smart contract then executes adding a new cryptographic transaction to the blockchain for the transfer of currency to the second user's blockchain wallet (e.g., second user device 108b). In a second example, the first service provider 110a can indicate to a smart contract stored on the blockchain that the cryptocurrency transfer is approved, and the smart contract can verify compliance with identity requirements for both users before executing the transfer. Using the above-described methods, the smart contract can perform the verification, for example, by receiving permission tokens for each participant from the processing server 102, receiving attestations, and verifying them with the processing server 102. In a third example, the first service provider 110a can indicate approval of the transfer to a first smart contract, which can invoke a second smart contract to perform a compliance check with respect to identity verification requirements. In such an example, the first smart contract or the second smart contract can be configured to add a new cryptographic transaction to the blockchain upon successful verification. In some embodiments, the processing server 102 generates the above-described smart contract and provides it to the blockchain node 106 for addition to the blockchain, which can occur, for example, upon participant registration or when a new transaction is requested.

[0034] In some cases, compliance with requirements may require service providers 110 to directly exchange data about participants. For example, some transactions, such as those to which movement rules are applicable, may require reporting on one or more identity attributes instead of simply verifying compliance with identity attribute requirements. In such cases, service providers 110 may communicate directly or through processing server 102 using appropriate communication networks and methods, and processing server 102 may route communications directly to the appropriate service provider 110, thereby enabling any service provider 110 to transact with any other service provider 110 without having to obtain detailed communication information about all other service providers 110. In cases where identity attributes are exchanged, service provider 110 may ensure compliance with any regulations regarding the transmission and reception of such data.

[0035] If the processing server 102 participates in the exchange, the transfer can utilize encryption, hashing, and other techniques to ensure that the processing server 102 does not obtain any personally identifiable information (PII). For example, a first service provider 110a can encrypt the identity attributes of a first participant using the public key of a second service provider 110b's encryption key pair, and the second service provider 110b can encrypt the identity attributes of a second participant using the public key of the first service provider 110a's encryption key pair. The encrypted data can be provided by each service provider 110 to the processing server 102, which can provide the encrypted data to other service providers 110. Each service provider 110 can then decrypt the identity attributes using its private key, resulting in the exchange of PII between the service providers 110 without any PII being exposed to the processing server 102. In some cases, the processing servers 102 may exchange public keys, which allows data to be exchanged without any direct communication between the service providers 110 .

[0036] Processing Server 2 illustrates an embodiment of a processing server 102 in the system 100 of FIG. 1. Those skilled in the art will appreciate that the embodiment of the processing server 102 illustrated in FIG. 2 is provided for illustrative purposes only and is not an exhaustive list of all possible configurations of a processing server 102 suitable for performing the functions of the present disclosure. For example, computer system 500 illustrated in FIG. 5 and described in more detail below may be a suitable configuration of a processing server 102. In some cases, other components of the system 100, such as the blockchain nodes 106, user devices 108, and service providers 110, may include components shown in FIG. 2 and described below.

[0037] The processing server 102 may include a receiving device 202. The receiving device 202 may be configured to receive data over one or more networks via one or more network protocols. In some examples, the receiving device 202 may be configured to receive data from blockchain nodes 106, user devices 108, service providers 110, and other systems and entities via one or more communication methods, such as radio frequency, a local area network, a wireless area network, a cellular communication network, Bluetooth, the Internet, etc. In some embodiments, the receiving device 202 may include multiple devices (e.g., different receiving devices receiving data over different networks (e.g., a first receiving device receiving data over a local area network and a second receiving device receiving data over the Internet)). The receiving device 202 may receive a transmitted electronic data signal. Upon receipt of the data signal by the receiving device 202, data may be superimposed on the data signal and may be decoded, parsed, read, or otherwise obtained. In some embodiments, the receiving device 202 may include an analysis module for analyzing the received data signal to obtain the data superimposed thereon. For example, the receiving device 202 may include an analysis program configured to receive and convert received data signals into usable input for functions performed by the processing device to implement the methods and systems of the present disclosure.

[0038] The receiving device 202 can be configured to receive data signals electronically transmitted by a blockchain node 106, which can be superimposed or encoded with a blockchain data entry, a request for blockchain data, a confirmation message, a cryptographic key, a smart contract, etc. The receiving device 202 can also be configured to receive data signals electronically transmitted by a user device 108, which can be superimposed or encoded with an alias request, a verified identity attribute, an identification value, service provider information, a public key, a destination address, etc. The receiving device 202 can be configured to receive data signals electronically transmitted by a service provider 110, which can be superimposed or encoded with an alias request, a permission token request, an identification value, a verified identity attribute, an update to a verified identity attribute, a public key, a destination address, etc.

[0039] The processing server 102 may also include a communications module 204. The communications module 204 may be configured to transfer data between modules, engines, databases, memory, and other components of the processing server 102 for use in performing the functions of the present disclosure. The communications module 204 may include one or more communication types and may use various communication methods for communication within a computing device. For example, the communications module 204 may include a bus, a contact pin connector, wires, etc. In some embodiments, the communications module 204 may also be configured to communicate between internal components of the processing server 102 and external components of the processing server 102 (e.g., an externally connected database, display device, input device, etc.). The processing server 102 may also include a processing unit. The processing unit may be configured to perform the functions of the processing server 102 of the present disclosure, as would be apparent to one skilled in the art. In some embodiments, the processing unit may include multiple engines and / or modules (e.g., query module 216, generation module 218, validation module 220, etc.) specifically configured to perform one or more functions of the processing unit. As used herein, the term "module" may refer to software or hardware that is specifically programmed to receive input, perform one or more operations using the input, and provide an output. The inputs, outputs, and operations performed by the various modules will be apparent to one of ordinary skill in the art based on this disclosure.

[0040] The processing server 102 may also include an account database 206. The account database 206 may be configured to store one or more account profiles 208 using a suitable data storage format and schema. The account database 206 may be a relational database using SQL (Structured Query Language) to store, identify, modify, update, access, etc., stored structured data sets. Each account profile 208 may be a structured data set configured to store data related to a permission account. For example, the account profile 208 may include a permission token, identification information, service provider information, alias, verified user identity attributes, registered blockchain wallets, blockchain addresses, currency balances, wallet status, etc.

[0041] The processing server 102 may also include memory 214. The memory 214 may be configured to store data (e.g., public keys, private keys, symmetric keys, etc.) for use by the processing server 102 in performing the functions of the present disclosure. The memory 214 may be configured to store data using appropriate data formatting methods and schemas and may be any appropriate type of memory (e.g., read-only memory, random-access memory, etc.). The memory 214 may include, for example, cryptographic keys and algorithms, communication protocols and standards, data formatting standards and protocols, program code for modules and processing device application programs, and other appropriate data used by the processing server 102 in performing the functions of the present disclosure. This will be apparent to those skilled in the art upon reading this disclosure. In some embodiments, the memory 214 may include a relational database using Structured Query Language (SQL) to store, identify, modify, update, access, etc., stored structured data sets. The memory 214 may be configured to store, identify, modify, update, access, etc., stored structured data sets, for example, regulations, location data, permission data, cryptographic keys, algorithms, etc.

[0042] The processing server 102 may also include a query module 216. The query module 216 may be configured to perform queries on a database to identify information. The query module 216 may receive one or more data values ​​or query strings, and based thereon, may perform the query string on an indicated database (e.g., the memory 214 of the processing server 102) to identify information stored therein. The query module 216 may then output the identified information to an appropriate engine or module of the processing server 102 as needed. The query module 216 may, for example, perform a query on the account database 206 to identify the account profile 208 for which the permission token is being requested via the alias.

[0043] The processing server 102 may also include a generation module 218. The generation module 218 may be configured to generate data for use by the processing server 102 when performing the functions of the present disclosure. The generation module 218 may receive instructions as input, generate data based on the instructions, and output the generated data to one or more modules of the processing server 102. For example, the generation module 218 may be configured to generate smart contracts, blockchain data entries, blocks, confirmation messages, permission tokens, aliases, destination addresses, etc.

[0044] The processing server 102 may also include a validation module 220. The validation module 220 may be configured to perform data validation and verification for the processing server 102 as part of the functionality described in this disclosure. The validation module 220 may receive instructions as input, perform data validation or verification as instructed, and output results of the data validation or verification to one or more modules of the processing server 102. In some cases, the input may include data to be validated or verified and / or data used in the validation or verification. In other cases, the validation module 220 may be configured to identify such data (e.g., in the account database 206 and / or in memory). The validation module 220 may be configured, for example, to verify regulatory compliance, to confirm new blockchain data entries and / or blocks, to verify digital signatures, etc.

[0045] The processing server 102 may also include a transmitting device 222. The transmitting device 222 may be configured to transmit data over one or more networks via one or more network protocols. In some examples, the transmitting device 222 may be configured to transmit data to the blockchain node 106, the user device 108, the service provider 110, and other entities via one or more communication methods, such as a local area network, a wireless area network, a cellular communication network, Bluetooth, radio frequency, the Internet, etc. In some embodiments, the transmitting device 222 may include multiple devices (e.g., different transmitting devices for transmitting data over different networks (e.g., a first transmitting device transmitting data over a local area network and a second transmitting device transmitting data over the Internet)). The transmitting device 222 may electronically transmit a data signal having superimposed data, the data being analyzed by a receiving computing device. In some embodiments, the transmitting device 222 may include one or more modules for superimposing, encoding, or formatting data into a data signal suitable for transmission.

[0046] The transmitting device 222 may also be configured to electronically transmit a data signal to a blockchain node 106, which may be superimposed or encoded with a blockchain data entry, a blockchain data request, a block, a confirmation message, a response message, etc. The transmitting device 222 may also be configured to electronically transmit a data signal to a user device 108, which may be superimposed or encoded with an alias, a confirmation message, a destination address, a data request, etc. The transmitting device 222 may also be configured to electronically transmit a data signal to a service provider 110, which may be superimposed or encoded with an alias, a permission token, an identification information, a destination address, a data request, a verified identity attribute request, etc.

[0047] Processing for permission-based cryptographic transactions 3A and 3B illustrate processing within the system 100 of FIG. 1 for facilitating permission-based cryptographic transactions on a blockchain associated with the blockchain network 104. At S302, the first service provider 110a may verify the identity of a participant on the blockchain registered at the first service provider 110a using an appropriate method. As part of verifying the participant's identity, the first service provider 110a may collect verified user identity attributes, which may include a verification level and other verified user data (e.g., age, income, geographic location, etc.). At S304, the first service provider 110a may electronically transmit an onboarding request to the processing server 102 via an appropriate communication network and method. The onboarding request may include at least identifying information and verified user identity attributes about the participant.

[0048] At S306, the receiving device 202 of the processing server 102 may receive an onboarding request from the first service provider 110a. At S308, the generation module 218 of the processing server 102 may generate a permission token and an alias for the participant. The permission token may include multiple data fields for identity attributes used for regulatory compliance, and the data values ​​for the data fields are based on the verified user identity attributes received in the onboarding request. In some cases, the alias may include a reference to the first service provider 110a and / or the verified user identity attributes. At S310, the sending device 222 of the processing server 102 may electronically send the alias to the first service provider 110a in response to the onboarding request.

[0049] At S312, the first service provider 110a may receive an alias for the participant. At S314, the first service provider 110a may issue the received alias to the participant, such as via the first user device 108a. The participant may then transmit the alias via the first user device 108a to another participant registered with the second service provider 110b. The other participant may then use their user device 108b to submit a transaction request to the second service provider 110b, the transaction request including at least the alias, the transaction amount, and any other data suitable for use in a cryptographic transaction, such as an unspent transaction output, a digital signature, etc. At S316, the second service provider 110b may receive the transaction request.

[0050] At S318, the second service provider 110b can electronically send a request for a permission token to the processing server 102 using an appropriate communication network and method. The request can include at least the alias received in the transaction request. At S320, the receiving device 202 of the processing server 102 can receive the permission token request. At S322, the query module 216 of the processing server 102 can identify a permission token for the first participant in the account profile 208 associated therewith via the received alias. At S324, the sending device 222 of the processing server 102 can electronically send the identified permission token for the first participant to the second service provider 110b in response to the permission token request.

[0051] At S326, the second service provider 110b can receive the permission token. At S328, the second service provider 110b can verify that the first participant's identity complies with any applicable regulations based on the data values ​​in the data fields in the permission token. As part of the verification, the second service provider 110b can verify, or may have already verified, the second participant's compliance in terms of identity verification via the registration process. Once the second service provider 110b verifies that the transaction complies with all applicable regulations, at S330, the second service provider 110b can generate a new blockchain transaction. The new blockchain transaction can include at least the transaction amount, the destination address, the unspent transaction output, a digital signature, and any other data required for a blockchain transaction.

[0052] At S332, the second service provider 110b can submit the new blockchain transaction to a blockchain node 106 in the blockchain network 104 using an appropriate communication method and can notify the first service provider 110a when the transaction has been added to the blockchain. The blockchain node 106 can then confirm the transaction, which can be included in a new block that is created, confirmed, and added to the blockchain. At S334, the first service provider 110a can notify the first participant that the transaction involving the first participant has been successfully added to the blockchain. As a result of this process, the first and second participants, each using different service providers, participate in a cryptographic transaction on the blockchain that complies with all applicable regulations, without the need for an exchange of PII and for each participant to be individually verified by each service provider 110.

[0053] Exemplary Method for Permission-Based Cryptographic Transactions FIG. 4 illustrates a method 400 for facilitating permission-based cryptographic transactions through the use of permission tokens.

[0054] At S402, an onboarding request including at least permission data and an identification value is received from a first computing system (e.g., first service provider 110a) by a receiver (e.g., receiving device 202) of a processing server (e.g., processing server 102), where the identification value is associated with a first blockchain wallet with respect to a blockchain associated with a blockchain network (e.g., blockchain network 104). At S404, a permission token and an alias based at least on the permission data are generated by a processor (e.g., generation module 218) of the processing server, where the permission token includes one or more verified identity data points.

[0055] At S406, the generated alias is transmitted by a transmitter of the processing server (e.g., sending device 222) to the first computing system in response to the received onboarding request. At S408, a token request is received from the second computing system (e.g., second service provider 110b), where the token request includes the alias. At S410, at least the generated permission token and the identification value can be transmitted by a transmitter of the processing server to the second computing system in response to the received token request.

[0056] In one embodiment, the identification value can be a public key associated with the first blockchain wallet. In some embodiments, the one or more verified identity data points can include at least one of the following: geographic location, age, income, identity verification status, compliance status, etc. In one embodiment, the generated permission token does not include any personally identifiable information. In some embodiments, the onboarding request does not include any personally identifiable information. In one embodiment, method 400 can further include: generating, by the second computing system, a new blockchain transaction including at least a transaction amount, one or more unspent transaction outputs, and one of the identification value or a destination address generated using the identification value; and transmitting, by the second computing system, the generated new blockchain transaction to a blockchain node in the blockchain network (e.g., blockchain node 106) for inclusion in the blockchain. In a further embodiment, method 400 can further include: verifying, by the second computing system, compliance of the first blockchain wallet with one or more applicable regulations based on the one or more verified identity data points included in the received permission token prior to generating the new blockchain transaction.

[0057] Computer System Architecture 5 illustrates a computer system 500 in which embodiments of the present disclosure, or portions thereof, may be implemented as computer-readable code. For example, the processing server 102, the blockchain node 106, the user device 108, and the service provider 110 may be implemented in the computer system 500 using hardware, a non-transitory computer-readable medium having instructions stored thereon, a combination thereof, or may be implemented in one or more computer systems or other processing systems. The hardware may embody modules and components used to implement the methods of FIGS. 3A, 3B, and 4.

[0058] Where programmable logic is used, such logic may be executed on commercially available processing platforms configured with executable software code, resulting in special-purpose or dedicated devices (e.g., programmable logic arrays, application-specific integrated circuits (ASICs), etc.). Those skilled in the art will appreciate that embodiments of the disclosed subject matter may be implemented in a variety of computer system configurations, including multi-core, multi-processor systems, minicomputers, mainframe computers, distributed functionality linked or clustered computers, and general-purpose or miniature computers that may be implemented in virtually any device. For example, at least one processor unit and memory may be used to implement the embodiments.

[0059] A processor unit or device of the present disclosure may be a single processor, multiple processors, or a combination thereof. A processor device may have one or more processor “cores.” The terms “computer program medium,” “non-transitory computer-readable medium,” and “computer-usable medium” of the present disclosure are used generally to refer to tangible media (e.g., removable storage unit 518, removable storage unit 522, and a hard disk installed in hard disk drive 512, etc.).

[0060] Various embodiments of the present disclosure are described with respect to this exemplary computer system 500. After reading this disclosure, it will be apparent to one skilled in the art how to implement the present disclosure using other computer systems and / or computer architectures. While operations are disclosed as sequential processes, some operations may in fact be performed in parallel, concurrently, and / or in distributed environments, where program code is stored locally or remotely for access by uniprocessor or multiprocessor machines. Furthermore, in some embodiments, the order of operations may be rearranged without departing from the spirit of the disclosed subject matter.

[0061] The processor unit 504 may be a special-purpose or general-purpose processor unit specially configured to perform the functions of the present disclosure. The processor unit 504 may be connected to a communications infrastructure 506 (e.g., a bus, a message queue, a network, a multi-core message passing scheme, etc.). The network may be any network suitable for performing the functions of the present disclosure and may include a local area network (LAN), a wide area network (WAN), a wireless network (e.g., Wi-Fi), a mobile communications network, a satellite network, the Internet, fiber optics, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to those skilled in the art. The computer system 500 may also include a main memory 508 (e.g., random access memory, read-only memory, etc.) and may also include a secondary memory 510. The secondary memory 510 may include a hard disk drive 512 and a removable storage drive 514 (e.g., a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, etc.).

[0062] Removable storage drive 514 may read from and / or write to removable storage unit 518 in a well-known manner. Removable storage unit 518 may include a removable storage medium that can be read from and written to by removable storage drive 514. For example, if removable storage drive 514 is a floppy disk drive or a USB port, removable storage unit 518 may be a floppy disk or a portable flash drive, respectively. In one embodiment, removable storage unit 518 may be a non-transitory readable recording medium.

[0063] In some embodiments, secondary memory 510 may include alternative means for allowing computer programs or other instructions to be loaded into computer system 500 (e.g., removable storage unit 522 and interface 520). Examples of such means may include program cartridges and cartridge interfaces (e.g., found in video game systems), removable memory chips (e.g., EEPROM, PROM, etc.) and associated sockets, other removable storage units 522 and interfaces 520, as will be apparent to those skilled in the art.

[0064] Data stored in computer system 500 (e.g., in main memory 508 and / or secondary memory 510) may be stored on any type of suitable computer-readable medium, such as optical storage (compact disc, digital versatile disc, Blu-ray disc, etc.) or magnetic tape storage (e.g., hard disk drive). The data may be organized in any type of suitable database structure (e.g., a relational database, a Structured Query Language (SQL) database, a distributed database, an object database, etc.). Suitable structures and storage types will be apparent to those skilled in the art.

[0065] Computer system 500 may also include a communications interface 524. Communications interface 524 may allow software and data to be sent and received between computer system 500 and external devices. Exemplary communications interface 524 may include a modem, a network interface (e.g., an Ethernet card), a communications port, a PCMCIA slot and card, etc. The software and data transferred via communications interface 524 may be in the form of signals. The signals may be electronic, electromagnetic, optical, or other signals apparent to those skilled in the art. The signals propagate over communications path 526. The paths are configured to carry the signals and may be implemented using wire, cable, fiber optics, a telephone line, a cellular phone link, a radio frequency link, etc.

[0066] Computer system 500 may further include a display interface 502. Display interface 502 may be configured to allow data to be transferred between computer system 500 and an external display 530. Exemplary display interfaces 502 may include a high-definition multimedia interface (HDMI), a digital visual interface (DVI), a video graphics array (VGA), etc. Display 530 may be any suitable type of display that displays data transferred via display interface 502 of computer system 500, including a cathode ray tube (CRT) display, a liquid crystal display (LCD), a light-emitting diode (LED) display, a capacitive touch display, a thin-film transistor (TFT) display, etc.

[0067] The computer program medium and computer usable medium may refer to memory (e.g., main memory 508 and secondary memory 510), which may be semiconductor memory (such as DRAM). These computer program products may be means for providing software to computer system 500. Computer programs (e.g., computer control logic) may be stored in main memory 508 and / or secondary memory 510. Computer programs may also be received via communications interface 524. Such computer programs, when executed, may enable computer system 500 to perform methods of the present disclosure. In particular, computer programs, when executed, may enable processor unit 504 to implement the methods shown in FIGS. 3A, 3B, and 4 as described herein. Such computer programs therefore represent the controller of computer system 500. The present disclosure is implemented using software. The software may be stored in a computer program product and loaded into computer system 500 using removable storage drive 514, interface 520, and hard disk drive 512 or communications interface 524.

[0068] The processor unit 504 may include one or more modules or engines configured to perform the functions of the computer system 500. Each module or engine may be implemented using hardware, or in some embodiments, software (e.g., corresponding to program code or programs stored in the main memory 508 or the secondary memory 510). In such embodiments, the program code may be compiled by the processor unit 504 (e.g., by a compilation module or engine) before execution by the hardware of the computer system 500. For example, the program code may be source code written in a programming language (e.g., assembly language or machine code) that is translated into a lower-level language for execution by the processor unit 504 and / or any additional hardware components of the computer system 500. The compilation process may include the use of lexical analysis, preprocessing, syntactic analysis, semantic analysis, syntax-driven translation, code generation, code optimization, or any other techniques suitable for translating program code into a lower-level language for control of the computer system 500 to perform the functions of the present disclosure. Those skilled in the art will appreciate that such processing results in computer system 500 being a specially configured computer system 500 that is uniquely programmed to perform the functions described above.

[0069] Technology consistent with the present disclosure provides, among other features, systems and methods for facilitating permission-based cryptographic transactions between service providers. While various exemplary embodiments of the systems and methods of the present disclosure have been described above, it should be understood that they are presented by way of example only, and not by way of limitation. They are not exhaustive and do not limit the disclosure to the precise form disclosed. Modifications and variations are possible in light of the above teachings. Modifications and variations may be made from implementations of the present disclosure without departing from the scope or spirit of the disclosure.

Claims

1. 1. A method for facilitating permission-based cryptographic transactions between service providers, comprising: receiving, by a receiver of a processing server, from a first computing system an onboarding request including at least permission data and an identification value, the identification value being associated with a first blockchain wallet with respect to a blockchain associated with the blockchain network; generating, by a processor of the processing server, a permission token and an alias based on at least the permission data, the permission token including one or more verified identity data points; transmitting, by a transmitter of the processing server, the generated alias to the first computing system in response to the received onboarding request; receiving, by the receiver of the processing server, a token request from a second computing system, the token request including the alias; and transmitting, by the transmitter of the processing server, at least the generated permission token and the identification value to the second computing system in response to the received token request.

2. 2. The method of claim 1, wherein the identification value is a public key associated with the first blockchain wallet.

3. 10. The method of claim 1, wherein the one or more verified identity data points include at least one of: geographic location, age, income, identity verification status, compliance status, and the like.

4. 10. The method of claim 1, wherein the generated permission token does not include any personally identifiable information.

5. 10. The method of claim 1, wherein the onboarding request does not include any personally identifiable information.

6. The method of claim 1 further comprising: generating, by the second computing system, a new blockchain transaction including at least a transaction amount, one or more unspent transaction outputs, and one of the identification value or a destination address generated using the identification value; and transmitting, by the second computing system, the generated new blockchain transaction to a blockchain node in the blockchain network for addition to the blockchain.

7. The method of claim 6 further comprising: prior to generating the new blockchain transaction, verifying, by the second computing system, compliance of the first blockchain wallet with one or more applicable regulations based on the one or more verified identity data points included in the received permission token.

8. 10. The method of claim 1, the first computing system is associated with a first virtual asset service provider; The method, wherein the second computing system is associated with a second virtual asset service provider.

9. 1. A system for facilitating permission-based cryptographic transactions between service providers, comprising: Blockchain network and a first computing system; a second computing system; and a processing server, the processing server comprising: a receiver that receives an onboarding request from the first computing system, the onboarding request including at least permission data and an identification value, the identification value being associated with a first blockchain wallet with respect to a blockchain associated with a blockchain network; and a processor that generates a permission token and an alias based on at least the permission data, the permission token including one or more verified identity data points; a transmitter that transmits the generated alias to the first computing system in response to the received onboarding request; the receiver of the processing server receives a token request from the second computing system, the token request including the alias; The system, wherein the transmitter of the processing server transmits at least the generated permission token and the identification value to the second computing system in response to the received token request.

10. 10. The system of claim 9, wherein the identification value is a public key associated with the first blockchain wallet.

11. 10. The system of claim 9, wherein the one or more verified identity data points include at least one of: geographic location, age, income, identity verification status, compliance status, and the like.

12. 10. The system of claim 9, wherein the generated permission token does not include any personally identifiable information.

13. 10. The system of claim 9, wherein the onboarding request does not include any personally identifiable information.

14. 10. The system of claim 9, wherein the second computing system comprises: creating a new blockchain transaction that includes at least a transaction amount, one or more unspent transaction outputs, and one of the identification value or a destination address generated using the identification value; The system transmits the generated new blockchain transaction to a blockchain node in the blockchain network for addition to the blockchain.

15. 15. The system of claim 14, wherein the second computing system verifies compliance of the first blockchain wallet with one or more applicable regulations based on the one or more verified identity data points included in the received permission token prior to generating the new blockchain transaction.

16. 10. The system of claim 9, the first computing system is associated with a first virtual asset service provider; The second computing system is associated with a second virtual asset service provider.

Images