US12327242B2 - Multi-signature verification network - Google Patents

Abstract

Systems and methods for authorizing a blockchain transaction. A verification network receives a transaction request for the blockchain transaction from a payer device including a first signature generated by a first private key associated with a payer. The verification network broadcasts a verification request to verification system(s) which assess pre-agreed threshold parameters. If the parameter(s) are satisfied, at least one verification system perfects the transaction by generating a second signature using a second private key, and broadcasts the transaction to the blockchain network. If the parameter(s) are not satisfied, verification offer(s) from among the verification system(s) including the second signature(s) are used to prompt the payer device to confirm the blockchain transaction by selecting at least one of the offer(s). The verification network receives selected offer(s) from the payer device and broadcasts the transaction to the blockchain network, in accordance with the selected offer(s) and the transaction request.

Description

FIELD OF THE DISCLOSURE

The present disclosure generally relates to systems and methods for authorizing blockchain-based transactions of digital assets, and more specifically, to a multi-signature authorization system including a multi-signature verification network that leverages a pool of trusted verification institutions to generate at least one signature and at least one verification offer together with a payer signature, in order to authorize blockchain-based transactions.

BACKGROUND

The use of blockchain technology for transactions involving digital assets such as cryptocurrencies has become increasingly popular due to the decentralized nature of transactions, the use of a mathematically verifiable ledger, near-immediate settlement, and isolation from operational, technical, or geo-political concentration risks. Although blockchain technology presents these advantages, managing cryptographic keys is burdensome and dangerous, exposing users to the dual threats of electronic theft and accidental loss of assets. Further, with near-immediate settlement comes a lack of “claw-back” reversibility of transactions, increasing the impact of fraud. Accordingly, there is a need to provide the security, safety, and reversibility of traditional centralized payment systems without reinstating concentration risks posed by relying on any single service provider.

SUMMARY

Aspects of the present disclosure relate to systems, methods and non-transitory computer readable media for authorizing a blockchain transaction. In some examples, system may include a verification network in communication with at least a payer computing device associated with a payer, a verification pool that includes one or more independent third-party verification computing systems (e.g., verification providers or verification institutions), and a blockchain network. In some examples, the verification network includes a computing system having a processor and a memory having programming instructions stored thereon, where the programming instructions, when executed by the processor, cause the system to perform an operation for authorizing the blockchain transaction. The operation of the verification network includes receiving, from the payer computing device, a partially-signed blockchain transaction (e.g., a transaction request). The transaction may include a first signature, where the first signature may be generated by a first private key created and managed by the payer (e.g., a first private key associated with the payer). In one example, the first signature may be the only signature included in the (partially-signed) transaction. In some examples, the partially-signed transaction may be enriched by the verification network with situational details such as (without being limited to) time, value, geolocation, merchant statistics and/or any suitable information that may be useful to a verification provider in analyzing the likelihood of attempted fraud. Since, in an exemplary embodiment, the payer private key must be protected by the payer, the nature of the present disclosure significantly mitigates the impact of unauthorized access to this payer private key, thereby significantly increasing the attractiveness of existing backup solutions.

The operation of the verification network further includes broadcasting the partially-signed transaction and details relating to one or more pre-agreed threshold parameters (e.g., risk assessment details) to the one or more verification providers. The operation may further include assessing, by at least one verification provider from among the verification pool, the one or more pre-agreed threshold parameters associated with the partially-signed transaction. The assessing may be a part of a broader risk analysis procedure and the threshold parameters may comprise one or more pre-agreed risk parameters. If the pre-agreed threshold parameters are satisfied, the (at least one) verification provider may immediately perfect (e.g., “bless”) the transaction request and broadcast the now-perfected blockchain transaction to the blockchain network. Perfecting the transaction request may include generating a second signature using a second private key (e.g., created and maintained by the verification provider) and optionally imposing a pre-agreed surcharge.

In the absence of pre-agreed threshold parameters, or if the pre-agreed threshold parameters are not satisfied during the assessment, the operation may further include generating, by at least one of the one or more verification providers, one or more verification offers including a respective one or more second signatures and, optionally, in some examples, one or more risk-related surcharges. Each of the one or more second signatures may be generated by a respective one of the one or more verification providers using a second private key (e.g., created and maintained by the verification provider). In some embodiments, the one or more verification providers may transmit one or more denials, rather than verification offers.

In an example operation of the present disclosure, the first verification provider to assess the risk and perfect the transaction may prevail and capture a previously-agreed fee. In the event that the risk analysis performed by the verification provider determines that a risk surcharge is needed to offset risk, the operation may include transmitting the one or more verification offers to the payer client device and prompting the payer computing device to confirm the blockchain transaction by selecting at least one of the one or more verification offers and receiving, from the payer client device, a selection of at least one offer of the one or more verification offers (thereby providing a perfected blockchain transaction). The operation may conclude with broadcasting the perfected blockchain transaction to the blockchain network.

In some examples, systems and methods of the present disclosure may leverage the breakthroughs in real-time risk assessment that have been created via high-frequency trading to allow verification providers to compete for individual transaction fees, while isolating the payer from reliance on any single provider.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG.1A is a block diagram illustrating a computing environment for authorizing blockchain transactions, according to an exemplary embodiment.

FIG.1B is a block diagram visually depicting one or more parties to a blockchain transaction, according to an exemplary embodiment.

FIG.2 is a block diagram illustrating a computing environment for authorizing blockchain transactions including a verification network, according to an exemplary embodiment.

FIG.3 is a flow diagram illustrating a method of authorizing a blockchain transaction using a verification network, according to one or more exemplary embodiments.

FIG.4 is a flow diagram illustrating communication among one or more computing components for authorizing a blockchain transaction using a verification network, according to one or more exemplary embodiments.

FIG.5A is a block diagram illustrating one or more screenshots of a client computing device, according to one or more exemplary embodiments.

FIG.5B is a block diagram illustrating one or more screenshots of a client computing device, according to one or more exemplary embodiments.

FIG.6 is a block diagram illustrating a computing environment, according to one or more exemplary embodiments.

DETAILED DESCRIPTION

Aspects of the present disclosure relate to systems, methods and non-transitory computer readable media for authorizing a blockchain transaction. In some examples, system may include a verification network in communication with at least a payer computing device associated with a payer, a verification pool that includes one or more independent third-party verification computing systems (e.g., verification providers or verification institutions), and a blockchain network. In some examples, the verification network includes a computing system having a processor and a memory having programming instructions stored thereon, where the programming instructions, when executed by the processor, cause the system to perform an operation for authorizing the blockchain transaction. The operation includes receiving, from the payer computing device, a partially-signed blockchain transaction (e.g., a transaction request). The transaction may include a first signature, where the first signature may be generated by a first private key created and managed by the payer (e.g., a first private key associated with the payer). In one example, the first signature may be the only signature included in the (partially-signed) transaction. In some examples, the partially-signed transaction may be enriched by the verification network with situational details such as (without being limited to) time, value, geolocation, merchant statistics and/or any suitable information that may be useful to a verification provider in analyzing the likelihood of attempted fraud. Since, in an exemplary embodiment of the present disclosure, the payer private key must be protected by the payer, the nature of the present disclosure significantly mitigates the impact of unauthorized access to this payer private key, thereby significantly increasing the attractiveness of existing backup solutions.

The operation of the verification network further includes broadcasting the partially-signed transaction and details relating to one or more pre-agreed threshold parameters (e.g., risk assessment details) to the one or more verification providers. The operation may further include assessing, by at least one verification provider from among the verification pool, the one or more pre-agreed threshold parameters associated with the partially-signed transaction. The assessing may be a part of a broader risk analysis procedure and the threshold parameters may comprise one or more pre-agreed risk parameters. If the pre-agreed threshold parameters are satisfied, the (at least one) verification provider may immediately perfect (e.g., “bless”) the transaction request and broadcast the now-perfected blockchain transaction to the blockchain network. Perfecting the transaction request may include generating a second signature using a second private key (e.g., created and maintained by the verification provider) and optionally imposing a pre-agreed surcharge.

In the absence of pre-agreed threshold parameters, or if the pre-agreed threshold parameters are not satisfied during the assessment, the operation may further include generating, by at least one of the one or more verification providers, one or more verification offers including a respective one or more second signatures and, optionally, in some examples, one or more risk-related surcharges. Each of the one or more second signatures may be generated by a respective one of the one or more verification providers using a second private key (e.g., created and maintained by the verification provider). In some embodiments, the one or more verification providers may transmit one or more denials, rather than verification offers.

In an example operation of the present disclosure, the first verification provider to assess the risk and perfect the transaction may prevail and capture a previously-agreed fec. In the event that the risk analysis performed by the verification provider determines that a risk surcharge is needed to offset risk, the operation may include transmitting the one or more verification offers to the payer client device and prompting the payer computing device to confirm the blockchain transaction by selecting at least one of the one or more verification offers and receiving, from the payer client device, a selection of at least one offer of the one or more verification offers (thereby providing a perfected blockchain transaction). The operation may conclude with broadcasting the perfected blockchain transaction to the blockchain network.

In some examples, systems and methods of the present disclosure may leverage the breakthroughs in real-time risk assessment that have been created via high-frequency trading to allow verification providers to compete for individual transaction fees, while isolating the payer from reliance on any single provider.

In conventional blockchain transaction systems, two parties may directly transact with one another. For example, a payee may share a public address (e.g., public key) to which a payer is to transmit an amount of cryptocurrency. The payer may then initiate a transaction that has one or more inputs and one or more outputs. The one or more inputs may correspond to a public key of the payer (e.g., an address from which the cryptocurrency originates) and a signature that was generated using a private key of the payer. The one or more outputs may correspond to the public address of the payee. The transaction may be transmitted to a blockchain network for verification (e.g., to verify that the payer actually has the amount of digital assets, e.g., cryptocurrency, that the payer alleges to have, and that the payer has not transmitted these digital assets).

Such conventional systems, however, suffer from one or more limitations. For example, should a user's private key become compromised (e.g., stolen), the fraudulent party that obtained the user's private key has necessarily stolen all cryptocurrency associated therewith. Further, should a user lose their private key, all cryptocurrency associated therewith is effectively lost.

One or more systems currently exist to combat the limitations of a single signature transaction. For example, one or more systems may provide a multi-signature service. A multi-signature transaction requires that two or more signatures be generated for each transaction. With conventional multi-signature systems, each system functions to provide the additional signature that may be necessary to perfect a transaction. In other words, in a conventional multi-signature service, a signature from the payer and a signature from the multi-signature service is needed for any given transaction.

The one or more techniques disclosed herein provide a verification network that improves upon conventional multi-signature services. For example, the verification network described herein acts as a middleman between parties to a transaction and one or more trusted verification institutions. Upon receiving a transaction request from a payer, the verification network may broadcast a verification request to a pool of pre-defined verification institutions. Each verification institution may be a trusted entity that can “bless” or verify the transaction. At least one signature is needed from the pool of verification institutions to perfect (i.e., “bless”) the respective transaction. Accordingly, the system of the present disclosure eliminates dependency on a single entity, as currently required by conventional multi-signature services, and instead relies on a pool, or network, of verification institutions that may verify the transaction. Moreover, the system of the present disclosure also eliminates control over a payer's digital assets that may result from two or more parties colluding to release or take control of the digital assets.

The term “user” as used herein includes, for example, a person or entity that owns a computing device (which may include a wireless device); a person or entity that operates or utilizes a computing device; or a person or entity that is otherwise associated with a computing device (which may include a wireless device). It is contemplated that the term “user” is not intended to be limiting and may include various examples beyond those described.

Moreover, examples of the present disclosure described below refer to blockchain-based transactions involving digital assets such as, for example (but not limited to), cryptocurrency. In general, systems and methods of the present disclosure may be configured to authorize transactions involving any suitable digital asset that may be tokenized, including security tokens, tokenized real estate, and one or more cryptocurrencies (e.g., digital or virtual currency that may use cryptography for security). In general, cryptocurrency may include, without being limited to, Bitcoin, Litecoin, Ether, etc. In fact, for purposes of this disclosure, the term cryptocurrency should be understood to include any digital or virtual assert or currency.

In some examples, transactions with respect to the present disclosure are referred to as blockchain transactions. In other examples, transactions are referred to as cryptocurrency transactions. As used herein, both blockchain transactions and cryptocurrency transactions refer to transactions of cryptocurrency (or any suitable digital asset) that uses a blockchain network.

FIG.1A is a block diagram illustrating acomputing environment100 for authorizing blockchain transactions, according to an example embodiment.Computing environment100 may include atleast client device102,client device104,verification pool106,verification network105 andblockchain network108. Communication amongclient device102,client device104,verification pool106 andblockchain network108 may be performed viaverification network105. Although oneclient device102 and oneclient device104 are shown inFIG.1A, it is understood thatenvironment100 may include any number ofclient devices102 and/or any number ofclient devices104.

In the examples described herein,client device102 may be operated by a user representing a payer. For example,client device102 may be a mobile device, a tablet, a desktop computer, or any computing system having the capabilities described herein.

In the examples described herein,client device104 may be operated by a user representing a payee. For example,client device104 may be a mobile device, a tablet, a desktop computer, or any computing system having the capabilities described herein.

Client device102 andclient device104 may communicate withverification network105.Verification network105 may be representative of a service that supports multi-signature functionality. In general, multi-signature functionality is a service that requires two or more signatures (e.g., two or more private keys) to authorize a cryptocurrency transaction.Verification network105 may be configured to store one or more private keys associated with each user or subscriber. For example,verification network105 may be configured to store one or more private keys associated with at least the payer to a transaction (e.g., client device102).

Unlike conventional multi-signature services,verification network105 does not perform the verification of cryptocurrency transactions between parties to a transaction. Rather,verification network105 may be configured to facilitate the verification thereof by broadcasting a proposed transaction toverification pool106.

Verification pool106 may be representative of one or more trusted financial institutions (e.g., verification providers) that may verify a cryptocurrency transaction. In other words,verification pool106 may include one or more financial institutions that are required to act as a second party to a multi-signature transaction.Verification pool106 may include one ormore verification institutions110₁,110₂, . . . ,110_n(generally “verification institution110”, where n is an integer greater than or equal to 1). In some embodiments, eachverification institution110 may be pre-approved withverification network105. When a transaction request is received fromclient device102 atverification network105,verification network105 may broadcast a verification request to eachverification institution110. Eachverification institution110 may then assess a risk associated with verifying the transaction. Based on this assessment, eachverification institution110 may generate a verification offer (described further below) to be transmitted toclient device102. In some embodiments, one ormore verification institutions110 may promptclient device102 to authenticate withverification institution110. For example, averification institution110 may requestverification network105 to transmit an identification request to the payer (e.g., client device102) to confirm the identity of the payer for risk analysis purposes. Because eachverification institution110 is competing with one or moreother verification institutions110, eachverification institution110 may race to assess the risk associated with a transaction and generate an offer that competes with other offers. Accordingly, those skilled in the art may readily understand thatverification institutions110 may balance the trade-off between quickly generating a verification offer and accurately assessing a risk associated with the verification offer.

When eachverification institution110 generates a verification offer,verification institution110 may access a private key associated with the payer (e.g., created and/or managed by the payer) viaverification network105. Eachverification institution110 may then generate a second signature for the transaction, using the private key hosted byverification network105. The second signature for the transaction may be transmitted byverification institution110 toverification network105 with the verification offer. In some examples, the second signature may represent a private key created and/or maintained by verification institution110 (a verification provider) and/or provided viaverification network105. Accordingly,verification network105 receives at least two signatures (e.g., a first signature fromclient device102 and a second signature from each verification institution110) which are required for the transaction.

In some embodiments, eachverification institution110 may have a pre-established relationship with a user (or subscriber) ofverification network105. For example, eachverification institution110 may prompt the user to submit a verification application, such that eachverification institution110 may vet the user similar to a credit card application process. Accordingly, for each user, eachverification institution110 may set one or more pre-arranged limits, parameters, or contractual duties for each transaction. For example, for a given user,verification institution110 may set a transaction limit of Bitcoin, Litecoin, Ether, etc. to a transaction. In another example, averification institution110 may attempt to limit its liability to a transaction, by contractually agreeing with each user thatverification institution110 is only liable for up to 50% of the transaction amount. Accordingly, when selecting a verification offer, a user may base the decision on, for example, whichverification institution110 offers the best refund policy.

Verification network105 may receive the one or more verification offers from the one or more verification institutions110 (i.e.,verification instate110₁,110₂, . . . ,110_n).Verification network105 may transmit the one or more verification offers toclient device102 andprompt client device102 to select an offer among the verification offer(s).Verification network105 may receive fromclient device102 an indication of a selection of a particular verification offer.Verification network105 may then broadcast the transaction to blockchain network108 (responsive to the selected offer) for posting.Blockchain network108 may include one or more computing devices for processing a blockchain transaction, by generating a block that is added to a blockchain that includes a record for the transaction. The blockchain represents a decentralized, public ledger of all transactions of a blockchain-based currency.

The role played byverification institution110 is similar to a verifier of a transaction. For example,verification institution110 may be responsible for verifying that the payer (e.g., client device102) is indeed the payer and that the payer has the alleged amount of cryptocurrency for the transaction.

In conventional blockchain systems, transactions between a payer and payee are irreversible, because once a payer relinquishes control of the amount of cryptocurrency, the payer can only be made whole if the payee agrees to refund the payer. The present system addresses this limitation by providing anintermediary verification network105 andverification pool106. When one ormore verification institutions110 assess a risk associated with a particular transaction, proposes a verification offer, and receives an acceptance of that verification offer, therespective verification institution110 has taken responsibility for the transaction. In other words, if a fraudulent third party gained access to the payer's account,verification institution110 is responsible for making the payer whole (i.e., refunding the payer the amount transferred to the payee). In this manner, verification institution110 (e.g., a verification provider) may “eat the charges” for any risk miscalculations, thereby reducing the impact of fraud on the payer. Moreover, because various verification institutions110 (e.g., verification providers) ofverification pool106 may compete to perfect a transaction through one or more verification offers,environment100 may spread out any risk miscalculations among the verification providers ofverification pool106, thereby reducing any concentration risk that is conventionally posed by relying on a single verification service provider.

Further, becauseverification network105 supports multi-signature functionality, for each transaction, two or more signatures are necessary to perfect the transaction. In conventional multi-signature systems (e.g., two-signature system), any individual party that has access to at least two of the payer's private keys may take control of the payer's cryptocurrency. Similarly, in conventional systems, any two actors may collude to release or take control of an individual's cryptocurrency by gaining access to at least two private keys of the individual. The present disclosure addresses these limitations of conventional systems by anticipating the possibility that, when the proposed transaction is broadcast toverification pool106, two ormore verification institutions110 may collude to release the payer's funds. To address this, the computing device associated with the payer (e.g., client device102) is a mandatory party to the transaction. In other words, even though one ormore verification institutions110 inverification pool106 may collude and provide the necessary number of signatures required for a specific multi-signature transaction,verification network105 will not perfect the transaction without receiving a signature from the payer.

Examples ofclient device102,verification network105 andverification institution110_nare described further below with respect toFIG.2.

FIG.1B is a block diagram150 visually depicting one or more parties to a cryptocurrency transaction, according to example embodiments. As shown, block diagram150 includesverification institution110₁,verification institution110₂, andverification institution110_nas the one ormore verification institutions110. For this transaction, at least two signatures are needed to perfect the transaction from payer to payee.

As illustrated, the verification offers122-1 and122-2 submitted byinstitution110₁andinstitution110₂, respectively, have been selected by payer (e.g., client device102). In conventional systems, because a minimum of two signature are required, the signature (2/2) generated byverification institution110₁and the signature (2/2) generated byverification institution110₂would be sufficient to perfect the transaction. Those skilled in the art may readily understand that, ifverification network105 were compromised, and two or more private keys associated withclient device102 were accessed,verification institution110₁andverification institution110₂could collude to release or gain access to the payer's cryptocurrency. However, such signatures would not be sufficient to perfect the transaction incomputing environment100 because client device102 (includingsignature120 generated by client device102) is a mandatory party to the transaction. Accordingly, at least one of the at least two required signatures must be generated by client device102 (or more generally, the payer). Thus, in the example shown inFIG.1B,signatures124 to perfect the transaction (e.g., for payment) includes signatures (2/3) (i.e.,signature120 ofclient device102 and signatures (2/2) ofrespective verification institutions110₁.110₂).

FIG.2 is a block diagram illustratingcomputing environment200 for authorizing blockchain transactions, according to one or more exemplary embodiments. As illustrated,computing environment200 includes atleast client device102, at least oneverification institution110, andverification network105.Client device102,verification institution110 andverification network105 may communicate via at least onenetwork205.

Network205 may be of any suitable type, including individual connections via the Internet, such as cellular or Wi-Fi networks. In some embodiments,network205 may connect terminals, services, and mobile devices using direct connections, such as, without being limited to, radio frequency identification (RFID), near-field communication (NFC), Bluetooth™, low-energy Bluetooth™ (BLE), Wi-Fi™, ZigBee™, ambient backscatter communication (ABC) protocols, universal serial bus (USB), wide area network (WAN), or local area network (LAN). Because the information transmitted may be personal or confidential, security concerns may dictate one or more of these types of connections be encrypted or otherwise secured. In some embodiments, however, the information being transmitted may be less personal, and therefore, the network connections may be selected for convenience over security.

Network205 may include any type of computer networking arrangement used to exchange data. For example,network205 may be the Internet, a private data network, a virtual private network using a public network and/or other suitable connection(s) that enables components incomputing environment200 to send and receive information therebetween.

Client device102 may includeapplication252 andwallet254.Application252 may be representative of a web browser that allows access to a website or a stand-alone application.Client device102 may accessapplication252 to access functionality ofverification network105.Client device102 may communicate overnetwork205 to request a webpage, for example, from webclient application server206 ofverification network105. For example,client device102 may be configured to executeapplication252 to access one or more functionalities ofverification network105. The content that is displayed toclient device102 may be transmitted from webclient application server206 toclient device102, and subsequently processed byapplication252 for display through an interactive graphical user interface (GUI) rendered byclient device102.

Wallet254 may be representative of a digital storage location onclient device102.Wallet254 may be configured to store one or morekey pairs255 associated with a user's blockchain account (e.g., account212). As illustrated, eachkey pair255 may include a private key256 and a correspondingpublic key258.

Each private key256 may be an alphanumeric string that allows a user ofclient device102 to transmit (e.g., spend) one or more cryptocurrencies to another individual or entity (i.e., another cryptocurrency address). Private key256 may be used to sign each cryptocurrency transaction. For example, a user may input private key256 into a signature algorithm which outputs a signature that may be verified byverification network105. Any individual or entity that has access to private key256 may be able to access the one or more cryptocurrencies corresponding to private key256.

Eachpublic key258 may correspond to a respective private key256. In some embodiments,public key258 may be derived from its respective private key256.Public key258 may be an alphanumeric string that corresponds to a public address of an individual or entity. For example, when a payer or transmitter attempts to transmit an amount of cryptocurrency to a user ofclient device102, the payer or transmitter directs the transmittal to the address defined bypublic key258.Public key258 may be public because, although derived from a respective private key256, it is near impossible to reverse engineer private key256.

Verification network105 may includemanagement system202 anddatabase204.Management system202 may be representative of a computing system.Management system202 may include webclient application server206,account handler208,transaction agent209, andverification agent210.

Each ofaccount handler208,transaction agent209, andverification agent210 may be comprised of one or more software modules. The one or more software modules may be collections of code or instructions stored on a media (e.g., memory of management system202) that represent a series of machine instructions (e.g., program code) that implements one or more algorithmic steps. Such machine instructions may be the actual computer code that a processor ofmanagement system202 interprets to implement the instructions or, alternatively, may be a higher level of coding of the instructions that is interpreted to obtain the actual computer code. The one or more software modules may also include one or more hardware components. One or more aspects of the algorithm may be performed by the hardware components (e.g., circuitry) itself, rather than as a result of an instruction.

Account handler208 may be configured to manage one ormore accounts212 associated with one or more users. For example,account handler208 may communicate withdatabase204. As illustrated,database204 may include one or more accounts212. Eachaccount212 may include one or morekey pairs215 and one ormore transactions218. Eachkey pair215 may include aprivate key214 and a correspondingpublic key216.Account handler208 may generate one or morekey pairs215 upon a user registering withverification network105. In some embodiments,account handler208 may generate one or morekey pairs255 stored onclient device102.

Eachprivate key214 may be an alphanumeric string that allows one ormore verification institutions110 to verify a particular transaction request.Private key214 may be used to sign each cryptocurrency transaction. For example, averification institution110 may access aprivate key214 fromverification network105, and inputprivate key214 into a signature algorithm which outputs a signature that may be verified byverification network105. Any individual or entity that has access toprivate key214 may be able to access the one or more cryptocurrencies corresponding theprivate key214.

Eachpublic key216 may correspond to a respectiveprivate key214. In some embodiments,public key216 may be derived from its respectiveprivate key214.Public key216 may be an alphanumeric string that corresponds to a public address associated with an individual or entity. For example, when averification institution110 assesses a risk associated with a transaction request,verification institution110 may identify a payer usingpublic key216.Public key216 may be public because, although derived from a respectiveprivate key214, it is near impossible to reverse engineerprivate key214.

Transaction agent209 may be configured to manage one ormore transactions218 associated with eachaccount212. For example,transaction agent209 may act as a “middle-man” betweenclient device102 and one ormore verification institutions110. In operation, for example,transaction agent209 may transmit a transaction request to one ormore verification institutions110. Each of the one ormore verification institutions110 may race to assess the risk associated with verifying the transaction, and provide an offer to the payer for verifying the transaction. For example, each of the one ormore verification institutions110 may transmit to verification network105 a willingness to verify the transaction along with a fee for their verification (e.g., a verification offer). The verification offer may, in turn, be transmitted fromverification network105 toclient device102 for display. Upon receiving input fromclient device102 that corresponds to a selection of a verification offer,verification network105 may transmit the offer acceptance to therespective verification institution110.

After a transaction is finalized between a payer (e.g., client device102) and a payee (e.g., client device104),transaction agent209 may record the transaction indatabase204. For example,transaction agent209 may record the payer to the transaction and the payee to the transaction, along with the transaction amount, in one ormore transactions218. Accordingly, if, for example, the transaction was later deemed fraudulent,transaction agent209 may notify theverification institution110 that verified the transaction, such thatverification institution110 can reimburse the payer to the transaction.

Verification agent210 may be configured to verify one or more transactions between a payer (e.g., client device102) and a payee (e.g., client device104).Verification agent210 may, for example, verify a first signature transmitted fromclient device102 toverification network105 that signals the initiation of the transaction. The first signature may correspond to a first signature needed for a multi-signature transaction.Verification agent210 may further be configured to verify a second signature transmitted from averification institution110, in response to generation of a verification offer fromverification institution110. The second signature may correspond to a second signature (or additional signature) needed for a multi-signature transaction.

Upon receiving the necessary number of signatures required for the multi-signature transaction (e.g., two or more signatures),verification institution110 may communicate withtransaction agent209 to complete the transaction.Transaction agent209 may broadcast the completed transaction toblockchain network108, such that the transaction may be posted thereto.

Verification institution110 may be representative of a computing system associated with any suitable entity such as, for example, a particular financial institution or other trusted entity.Verification institution110 may includecomputing device260.Computing device260 may be a mobile device, a tablet, a desktop computer, or any computing system having the capabilities described herein.Computing device260 may includeapplication262 andrisk analyzer264.

Application262 may be representative of a web browser that allows access to a website or a stand-alone application.Computing device260 may accessapplication262 to access functionality ofverification network105.Computing device260 may communicate overnetwork205 to request a webpage, for example, from webclient application server206 ofverification network105. For example,computing system260 may be configured to executeapplication262 to access one or more functionalities ofverification network105. The content that is displayed tocomputing device260 may be transmitted from webclient application server206 tocomputing device260, and subsequently processed byapplication262 and, in some examples, may be displayed through a GUI rendered by computingsystem260.

Risk analyzer264 may be comprised of one or more software modules. The one or more software modules may be collections of code or instructions stored on a media (e.g., memory of computing device260) that represent a series of machine instructions (e.g., program code) that implements one or more algorithmic steps. Such machine instructions may be the actual computer code a processor ofcomputing device260 interprets to implement the instructions or, alternatively, may be a higher level of coding of the instructions that is interpreted to obtain the actual computer code. The one or more software modules may also include one or more hardware components. One or more aspects of the algorithm may be performed by the hardware components (e.g., circuitry) itself, rather than as a result of an instruction.

Risk analyzer264 may be configured to assess a risk associated with verifying a cryptocurrency transaction between the payer (e.g., client device102) and the payee (e.g., client device104). In some embodiments,risk analyzer264 may assess the risk associated with verifying the cryptocurrency transaction by taking in account one or more parameters that include, but are not limited to, a current location of client device102 (e.g., at a location associated with the user), an amount of cryptocurrency to be transmitted, a frequency of transactions between the payer (e.g., client device102) and the payee (e.g., client device104), the identity of the payee (e.g., a merchant), the time of day of the transaction, a purchase history of the payer, and the like. In some examples, risk analysis byrisk analyzer264 may include contacting the payer (e.g., via a call or text) to confirm the transaction. Based on the risk assessment performed byrisk analyzer264,verification institution110 may generate a verification offer to be transmitted toclient device102.

Because, however, verifying the transaction may subjectverification institution110 to financial risk (e.g., if the transfer fromclient device102 toclient device104 was fraudulent),verification institution110 may charge the payer a fee for their verification service. For example, whenrisk analyzer264 determines that there is minimal risk associated with verifying the transaction,verification institution110 may propose a minimal fee toclient device102 in the verification offer. In another example, whenrisk analyzer264 determines that there is a higher risk associated with verifying the transaction,verification institution110 may propose a higher fee toclient device102 in the verification offer. Further, in some embodiments,verification institution110 may propose a surge fee to a transaction. For example, in those embodiments in whichverification network105 broadcasts a higher volume of verification requests,verification institution110 may propose a surge fee for its services.

FIG.3 is a flow diagram illustrating amethod300 of authorizing a blockchain transaction usingverification network105, according to one or more exemplary embodiments.Method300 may begin atstep302.

Atstep302,verification network105 may receive a transaction request from client device102 (e.g., via a payment card, an application, a mobile phone, online, etc.). The transaction request may include at least a designation of the payer (e.g., client device102), the payee (e.g., client device104), and the amount of cryptocurrency specified in the transaction. For example, the transaction request may include a public address (e.g., public key258) corresponding toclient device102, a signature generated byclient device102 using private key256), a public address corresponding toclient device104, and the amount specified in the transaction. Further, in some embodiments, the transaction request may also specify a number of signatures required for the multi-signature authorization. For example, in some embodiments, the transaction request may specify that at least oneverification institution110 is necessary for verification. In another example, the transaction request may specify that at least two of theverification institutions110 are necessary for verification. In some examples, the transaction request may represent a partially-signed blockchain transaction, that may include a first signature generated by theclient device102 using private key256, but may not include any second signatures needed to perfect the blockchain transaction.

Atstep304,verification network105 may broadcast a verification request toverification pool106. The verification request may include one or more parameters associated with the transaction request. Such parameters may include, but are not limited to, the public address (e.g., public key258) corresponding toclient device102, a public address associated withclient device104, and the amount specified in the transaction. In some examples,verification network105 may determine and include situational details associated with the partially-signed transaction that may be useful (to verification pool106) in analyzing a likelihood of attempted fraud. Non-limiting examples of situational details may include a time of the transaction, a value of the transaction, a geolocation ofclient device102, any merchant statistics, etc. In some examples, the verification request broadcast byverification network105 may include the partially-signed transaction (from client device102) and any additional information and/or risk assessment details (e.g., parameters, situational details, etc.) provided byverification network105. Thus, in some examples, the partially-signed transaction may be enriched by the information provided byverification network105. In some embodiments, the one or more parameters may further include a number of additional signatures needed fromverification pool106 to complete the multi-signature transaction.

Atstep306,verification network105 may receive one or more verification offers based on a risk analysis of the transaction request. For example,verification network105 may receive one or more verification offers from one ormore verification institutions110 to be transmitted toclient device102. Each verification offer may be generated by averification institution110 based on a determined risk with verifying the transaction. Each verification offer may include a verification charge associated therewith.

Atstep308,verification network105 may prompt the payer to select a verification offer from arespective verification institution110.Verification network105 may transmit the one or more verification offers toclient device102 for display.Client device102 may, in turn, push the one or more verification offers toclient device102, prompting the payer to select from among the one or more verification offers.

Atstep310,verification network105 may receive, fromclient device102, an indication of a selection of at least one verification offer. For example,client device102 may receive input via a GUI displayed thereon, which corresponds to a selection of a verification offer from aparticular verification institution110.Client device102 may translate the input to a message that is transmitted toverification network105. The message may indicate the verification offer selected by the payer.

Atstep312,verification network105 may broadcast the transaction betweenclient device102 andclient device104 toblockchain network108. For example, upon determining that the necessary number of signatures required by the transaction request is met,verification network105 may transmit the transaction between payer and payee toblockchain network108 for posting to the blockchain. In some examples, the transaction may also take into account any surcharge fee associated with the selected verification offer(s).

In some examples, the verification request (step304) may include the partially-signed transaction (e.g., the transaction request) and details relating to one or more pre-agreed threshold parameters (e.g., risk assessment details). Responsive to the broadcasted verification request (step304), at least one verification institution110 (e.g., verification institution110₂) amongverification pool106 may assess the pre-agreed threshold parameter(s) associated with the partially-signed transaction. The assessing may be a part of a broader risk analysis procedure and the threshold parameter(s) may comprise one or more pre-agreed risk parameters. If the pre-agreed threshold parameter(s) are satisfied, the (at least one) verification institution110 (e.g., verification institution110₂) may immediately perfect (e.g., “bless”) the transaction request and broadcast the now-perfected blockchain transaction to blockchain network108 (e.g., bypassing steps306-310). Perfecting the transaction request may include generating a second signature using a second private key (e.g., created and maintained by the verification provider) and optionally imposing a pre-agreed surcharge. In some examples, verification institution110 (e.g., verification institution110₂) may broadcast the perfected transaction directly toblockchain network108 and/or viaverification network105. In some examples, a first verification institution110 (e.g., verification institution110₂) to assess the risk, perfect the transaction (according to the previously-agreed upon fee) and broadcast the perfected transaction (e.g., the now fully-signed transaction including the first signature fromclient device102 and the second signature from verification institution110₂) may prevail and capture the previously-agreed fee.

In the absence of pre-agreed threshold parameter(s), or if the pre-agreed threshold parameter(s) are not satisfied during the assessment, the operation may further include generating, by at least one ofverification institutions110, a respective one or more verification offer(s) including a respective one or more second signatures and, optionally, in some examples, one or more risk-related surcharges. Each of the second signature(s) may be generated by a respective one ofverification institutions110 using a respective second private key (e.g., created and maintained by a respective verification institution110). The verification offer(s) may be transmitted to and received by verification network105 (step306) and step306 may proceed to steps308-310 (as discussed above). In some embodiments, verification institution(s)110 may transmit one or more denials, rather than verification offers. Thus, in some examples, when verification institution(s)110 determine, from the risk analysis, that a risk surcharge is needed to offset risk, the verification offer(s) may include the requested surcharge and an indication to promptclient device102 to select a verification offer. Based on the indication to prompt the payer,verification network105 may promptclient device102 to select a verification offer and may receive a selection from client device102 (as described above at steps308-310). Responsive to the selection fromclient device102,verification network105 may then broadcast the now perfected transaction (e.g., including the first signature fromclient device102 and the second signature in the selected verification offer) to blockchain network108 (step312). In this manner,verification network105 may cause the payer (via client device102) to confirm the blockchain transaction.

FIG.4 is a flow diagram illustrating amethod400 of communication among one or more computing components for authorizing a blockchain transaction usingverification network105, according to one or more exemplary embodiments.Method400 may begin atstep402.

Atstep402,client device102 may transmit a transaction request toverification network105. The transaction request may include at least a designation of the payer (e.g., client device102), the payee (e.g., client device104), and the amount of cryptocurrency specified in the transaction. For example, the transaction request may include a public address (e.g., public key258) corresponding toclient device102, a signature generated byclient device102 using private key256), a public address corresponding toclient device104, and the amount specified in the transaction. Further, in some embodiments, the transaction request may also specify a number of signatures required for the multi-signature authorization. For example, in some embodiments, the transaction request may specify that at least oneverification institution110 is necessary for verification. In another example, the transaction request may specify that at least two of theverification institutions110 is necessary for verification.

Atstep404,verification network105 may receive the transaction request fromclient device102. In some embodiments, upon receiving the transaction request fromclient device102,verification network105 may verify that the payer has indeed signed the transaction. For example,verification network105 may verify thatclient device102 transmitted the signature for the transaction.

Atstep406,verification network105 may broadcast a verification request toverification pool106. The verification request may include one or more parameters associated with the transaction request. Such parameters may include, but are not limited to, the public address (e.g., public key258) corresponding toclient device102, a public address associated withclient device104, and the amount specified in the transaction. In some embodiments, the one or more parameters may further include a number of additional signatures needed fromverification pool106 to complete the multi-signature transaction.

Atstep408,verification institution110 may receive the broadcasted verification request fromverification network105. Although the below operations are discussed generally with respect to one ormore verification institutions110, those skilled in the art may readily understand that it is not required for allverification institutions110 inverification pool106 to perform all of the operations described below.

Atstep410,verification institution110 may assess a risk associated with verifying the transaction request. For example,risk analyzer264 may be configured to assess a risk associated with verifying the cryptocurrency transaction between the payer (e.g., client device102) and the payee (e.g., client device104). In some embodiments,risk analyzer264 may assess the risk associated with verifying the cryptocurrency transaction by taking in account one or more parameters that include, but are not limited to, a current location of client device102 (e.g., at a location associated with the user), an amount of cryptocurrency to be transmitted, a frequency of transactions between the payer (e.g., client device102) and the payee (e.g., client device104), and the like. Based on the risk assessment performed byrisk analyzer264,verification institution110 may generate a verification offer to be transmitted toclient device102.

Atstep412,verification institution110 may assign a verification fee to the verification offer based on the risk assessment analysis. For example,verification institution110 may assign a fee to their verification service based on the risk associated with verifying a particular transaction. For example, ifrisk analyzer264 determines that there is minimal risk associated with verifying the transaction,verification institution110 may propose a minimal fee toclient device102 in the verification offer. In another example, ifrisk analyzer264 determines that there is a higher risk associated with verifying the transaction,verification institution110 may propose a higher fee toclient device102 in the verification offer.

Atstep414,verification institution110 may access a private key associated with the payer. For example, upon generating a verification offer,verification institution110 may request from verification network105 a private key (e.g., private key214) that is hosted byverification network105 and associated with the payer (e.g., client device102).

Atstep416,verification institution110 may generate a signature using the accessed private key. For example,verification institution110 may generate a second (or third, fourth, etc.) signature for the transaction usingprivate key214. By generating a second signature prior to transmitting the verification offer toclient device102, the transaction may be completed as soon as the payer selects a verification offer.

Atstep418,verification institution110 may transmit the verification offer and the second (or additional) signature toverification network105. Atstep420,verification network105 may receive the verification offer and the second signature fromverification institution110.

At step422,verification network105 may prompt the payer to select a verification offer from arespective verification institution110.Verification network105 may transmit the one or more verification offers toclient device102 for display. The verification offer may include the verification fee associated therewith.

Atstep424,client device102 may receive the prompt fromverification network105. For example,client device102 may receive the one or more verification offers fromverification network105 viaapplication252 executing thereon.

Atstep426,client device102 may generate a GUI displaying the one or more verification offers. The GUI generated byclient device102 may be displayed to the payer via a display associated withclient device102. For example, the GUI may be displayed via an external display device (e.g., a monitor) associated withclient device102. In another embodiment, the GUI may be displayed via a touchscreen associated withclient device102. The GUI may include the one or more verification offers and the one or more verification fees associated therewith.

Atstep428,client device102 may receive an input that corresponds to a selection among the verification offer(s). For example,client device102 may receive an input, via the GUI, a selection of a verification offer. Atstep430,client device102 may transmit a verification offer acceptance toverification network105.

Atstep430,verification network105 may receive the selection of the verification offer acceptance fromclient device102. Atstep432,verification network105 may notify arespective verification institution110 of the verification offer acceptance. For example,verification network105 may transmit a message to arespective verification institution110 associated with the verification offer.

At step434,verification network105 may record the transaction details indatabase204. for example,verification network105 may record the transaction date, the transaction amount, the payer public address, the payee public address, any verification fees and one ormore verification institutions110 associated with one or more accepted verification offers indatabase204. By recording the transaction details indatabase204, should the transaction later be deemed fraudulent (e.g., a fraudulent third party obtained the payer's private key (e.g., private key256), the transaction may be reversible. For example, the one ormore verification institutions110 whose verification offers were accepted are now liable for refunding the payer the transaction amount.

Atstep436,verification network105 may broadcast/post the transaction betweenclient device102 andclient device104 toblockchain network108. For example, upon determining that the necessary number of signatures required by the transaction request is met,verification network105 may transmit the transaction between payer and payee toblockchain network108 for posting to the blockchain. In some examples, the transaction may also reflect any verification fees.

Although not shown inFIG.4, as discussed above, in some examples, after step408 (e.g., at step410), verification institution(s)110 may assess pre-agreed threshold parameter(s) associated with the transaction request and determine whether the pre-agreed threshold parameter(s) have been satisfied. If at least one ofverification institutions110 determine that the pre-agreed threshold parameter(s) are satisfied, the at least oneverification institution110 may perfect the blockchain transaction (as discussed above) and broadcast the perfected blockchain transaction to blockchain network108 (thereby bypassing, for example, steps412-434). If the pre-agreed threshold parameter(s) are not satisfied, the process may proceed according to steps412-436.

FIG.5A is a block diagram500 illustrating one or more screenshots ofclient computing device502, according to one or more exemplary embodiments. As illustrated,client device502 may be a mobile device associated with a payer. For example,client device502 may be associated with client device102 (explained in detail above).Client device502 may includedisplay504.Display504 may be currently displayingscreenshot505.Screenshot505 may illustrate an example GUI that may be generated and displayed to the payer upon receiving one or more verification offers fromverification network105.

As shown,screenshot505 includes one or more verification offers503₁,503₂, and503₃(generally “verification offer503”). Verification offer503₁may include a graphic508₁associated with averification institution110₁and verification fee506₁associated therewith. Verification offer503₂may include a graphic508₂associated with averification institution110₂and verification fee506₂associated therewith. Verification offer503₃may include a graphic508₃associated with averification institution110₃and verification fee506₃associated therewith. Each verification offer503 may be selectable by the payer.

FIG.5B is a block diagram550 illustrating one or more screenshots ofclient computing device502, according to one or more exemplary embodiments. As illustrated,display504 ofclient device502 may be currently displayingscreenshot555.Screenshot555 may illustrate an example GUI that may be generated and displayed to the payer upon the payer providing input accepting or rejection a verification offer.

As shown, when a payer provides a select and drag input (e.g., swipe right) the display may update to revealscreenshot555. The payer may be prompted with one or more options for each verification offer503. For example, verification offer503₁may include a graphic552₁associated with a rejection of the verification offer (e.g. “deny”) and graphic554₁associated with an approval of the verification offer (e.g. “approve”). Verification offer503₂may include a graphic552₂associated with a rejection of the verification offer (e.g. “deny”) and graphic554₂associated with an approval of the verification offer (e.g. “approve”). Verification offer503₃may include a graphic552₃associated with a rejection of the verification offer (e.g. “deny”) and graphic554₃associated with an approval of the verification offer (e.g. “approve”).

Upon receiving an input via graphic552 or graphic554,client device102 may transmit to verification network105 a rejection or approval of each verification offer.

It is understood thatFIGS.5A and5B illustrate an example arrangement, presentation and selection operations of verification offers503 ondisplay504 ofclient device502. It is understood that verification offers503 may be arranged and presented in any suitable manner ondisplay504, and that verification offers503 may be selected by one or more suitable input operations including operations other than a select and drag input (e.g., swipe right).

FIG.6 is a block diagram illustrating anexemplary computing environment600, according to one or more embodiments.Computing environment600 may includecomputing system602 andcomputing system652.Computing system602 may be representative ofclient device102.Computing system652 may be representative ofmanagement system202 orverification network105.

Computing system602 may includeprocessor604,memory606,storage608, andnetwork interface610. In some embodiments,computing system602 may be coupled to one or more I/O device(s)612 (e.g., keyboard, mouse, etc.).

Processor604 may retrieve and execute program code618 (i.e., programming instructions) stored inmemory606, as well as store and retrieve application data.Processor604 may be included to be representative of a single processor, multiple processors, a single processor having multiple processing cores, and the like.Network interface610 may be any type of network communications allowingcomputing system602 to communicate externally viacomputing network605. For example,network interface610 may be configured to enable external communication withcomputing system652.

Storage608 may be, for example, a disk storage device. Although shown as a single unit,storage608 may be a combination of fixed and/or removable storage devices, such as fixed disk drives, removable memory cards, optical storage, network attached storage (NAS), storage area network (SAN), and the like.Storage608 may includewallet620.Wallet620 may be configured to store one or more key pairs associated with a user's blockchain account. Each key pair may include a private key and a corresponding public key.

Memory606 may includeapplication614,operating system616 andprogram code618. In some examples,memory606 may include a geolocation agent (not shown).Program code618 may be accessed byprocessor604 for processing (i.e., executing program instructions).Program code618 may include, for example, executable instructions for communicating withcomputing system652 to display one or more pages ofwebsite662.Application614 may enable a user ofcomputing system602 to access a functionality ofcomputing system652. For example,application614 may access content managed by computingsystem652, such aswebsite662. The content that is displayed to a user ofcomputing system602 may be transmitted fromcomputing system652 tocomputing system602, and subsequently processed byapplication614 for display through a GUI ofcomputing system602.

Computing system652 may includeprocessor654,memory656,storage658, andnetwork interface660. In some embodiments,computing system652 may be coupled to one or more I/O device(s)674. In some embodiments,computing system652 may be in communication withdatabase204.

Processor654 may retrieve and execute program code666 (i.e., programming instructions) stored inmemory656, as well as store and retrieve application data.Processor654 is included to be representative of a single processor, multiple processors, a single processor having multiple processing cores, and the like.Network interface660 may be any type of network communications enablingcomputing system652 to communicate externally viacomputing network605. For example,network interface660 may allowcomputing system652 to communicate withcomputer system602.

Storage658 may be, for example, a disk storage device. Although shown as a single unit,storage658 may be a combination of fixed and/or removable storage devices, such as fixed disk drives, removable memory cards, optical storage, network attached storage (NAS), storage area network (SAN), and the like.

Memory656 may includewebsite662,operating system664,program code666,account handler668,verification agent670, andtransaction agent672.Program code666 may be accessed byprocessor654 for processing (i.e., executing program instructions).Program code666 may include, for example, executable instructions configured to perform steps discussed above in conjunction withFIGS.3-4. As an example,processor654 may accessprogram code666 to perform operations for verifying a cryptocurrency transaction.Website662 may be accessed by computingsystem602. For example,website662 may include content accessed by computingsystem602 via a web browser or application.

Account handler668 may be configured to manage one or more accounts associated with one or more users. For example,account handler668 may communicate withdatabase204 that stores one or more key pairs215 (FIG.2).Account handler668 may generate one or more key pairs upon a user registering withverification network105. In some embodiments,account handler668 may generate one or more key pairs stored oncomputing system602.

Transaction agent672 may be configured to manage one or more transactions associated with each account. For example,transaction agent672 may act as a “middle-man” betweencomputing system602 and one ormore verification institutions110. In operation, for example,transaction agent672 may transmit the transaction request to one ormore verification institutions110. Upon receiving input fromcomputing system602 that corresponds to a selection of a verification offer,transaction agent672 may transmit the offer acceptance to therespective verification institution110.

Verification agent670 may be configured to verify one or more transactions between a payer and a payee.Verification agent670 may, for example, verify a first signature transmitted fromclient device602 toverification network105 that signals the initiation of the transaction. The first signature may correspond to a first signature needed for a multi-signature transaction.Verification agent670 may further be configured to verify a second signature transmitted from a verification institution, in response to generation of a verification offer fromverification institution110. The second signature may correspond to a second signature (or additional signature) needed for a multi-signature transaction.

Although not shown inFIG.6, eachverification institution110 may also include one or more of the components shown incomputing system652. For example,verification institution110 may include a processor similar toprocessor654, memory similar tomemory656, storage similar tostorage658, a network interface similar tonetwork interface660 and, in some examples, one or more I/O devices similar to I/O device(s)674. Similar tomemory656 ofcomputing system652, the memory ofverification institution110 may also include an operating system similar tooperating system664 and program code similar toprogram code666. In contrast tomemory656 ofcomputing system652, the memory ofverification institution110 may store application262 (FIG.2) and risk analyzer264 (FIG.2), and the program code ofverification institution110 may include program instructions relating toapplication260 andrisk analyzer264.

It is understood that aspects of the present disclosure may be implemented in hardware or software or a combination of hardware and software. In one example, aspects of the present disclosure may be implemented as a program product for use with a computer system. The program(s) of the program product define functions of the embodiments (including the methods described herein) and can be contained on a variety of computer-readable storage media. Illustrative computer-readable storage media include, but are not limited to: (i) non-writable storage media (e.g., read-only memory (ROM) devices within a computer, such as compact disk-ROM (CD-ROM) disks readable by a CD-ROM drive, flash memory, ROM chips, or any type of solid-state non-volatile memory) on which information is permanently stored; and (ii) writable storage media (e.g., floppy disks within a diskette drive or hard-disk drive or any type of solid state random-access memory (RAM)) on which alterable information is stored. Such computer-readable storage media, when carrying computer-readable instructions that direct the functions of the present disclosure, are embodiments of the present disclosure.

While the present disclosure has been discussed in terms of certain embodiments, it should be appreciated that the present disclosure is not so limited. The embodiments are explained herein by way of example, and there are numerous modifications, variations and other embodiments that may be employed that would still be within the scope of the present disclosure.

Claims (30)

The invention claimed is:

1. A system comprising:

one or more verification computing systems; and

a verification network comprising a computing system having a processor and a memory storing programming instructions, the verification network configured to:

receive a proposed blockchain transaction generated by at least one payer device, and

broadcast a verification request for the proposed blockchain transaction to the one or more verification computing systems,

the one or more verification computing systems configured to determine whether the proposed blockchain transaction includes one or more pre-agreed threshold parameters, responsive to the verification request,

when the proposed blockchain transaction includes and satisfies the one or more pre-agreed threshold parameters, the one or more verification computing systems are configured to:

directly perfect the proposed blockchain transaction to create a perfected blockchain transaction, and

broadcast the perfected blockchain transaction directly to a blockchain network, and

when the proposed blockchain transaction fails to include the one or more pre-agreed threshold parameters or fails to satisfy the one or more pre-agreed threshold parameters:

the one or more verification computing systems are configured to perfect the proposed blockchain transaction via prompting authorization from the at least one payer device, and

the verification network is configured to broadcast the perfected blockchain transaction to the blockchain network, responsive to receiving said authorization from the at least one payer device.

2. The system ofclaim 1, wherein the proposed blockchain transaction comprises a first signature that is generated using a first private key.

3. The system ofclaim 2, wherein the first private key is generated and maintained by the at least one payer device.

4. The system ofclaim 3, wherein the perfecting of the proposed blockchain transaction comprises generating one or more additional signatures using a second private key.

5. The system ofclaim 4, wherein the second private key is generated and maintained by the one or more verification computing systems.

6. The system ofclaim 1, wherein when the proposed blockchain transaction fails to include the one or more pre-agreed threshold parameters or fails to satisfy the one or more pre-agreed threshold parameters:

the one or more verification computing systems are configured to perfect the proposed blockchain transaction by generating and transmitting one or more verification offers to the at least one payer device,

responsive to receiving the one or more verification offers, the at least one payer device is configured to transmit a selection of at least one offer from among the one or more verification offers to the verification network, the selection indicating the authorization of the proposed blockchain transaction, and

upon receiving said selection, the verification network is configured to broadcast the perfected blockchain transaction to the blockchain network.

7. The system ofclaim 6, wherein the at least one payer device is configured to display the one or more verification offers via a graphical user interface of the at least one payer device.

8. The system ofclaim 6, wherein the one or more verification computing systems are configured to generate the one or more verification offers based on a risk analysis of the proposed blockchain transaction.

9. The system ofclaim 8, wherein the one or more verification offers comprise one or more of an indication of a transaction risk based on the risk analysis, a verification charge based on the risk analysis, and a surge charge based on a volume of verifications requests received by the one or more verification computing systems.

10. The system ofclaim 8, wherein the one or more verification computing systems are configured to assess a risk associated with verifying the proposed blockchain transaction.

11. The system ofclaim 10, wherein the risk is based on one or more of a location of the at least one payer device, a transaction amount, a frequency of transactions between a payer associated with the at least one payer device and a payee, an identity of the payee, a time of the proposed blockchain transaction, and a purchase history of the payer.

12. The system ofclaim 6, wherein the verification network further comprises an account handler, a transaction agent, a verification agent, and a database, wherein:

the account handler is configured to generate one or more key pairs, each key pair comprising a public key and a private key, and each key pair associated with a particular user, and to store said one or more key pairs in the database,

the transaction agent is configured to perform one or more of:

broadcasting the verification request to the one or more verification computing systems,

recording the perfected blockchain transaction in the database, and

broadcasting the perfected blockchain transaction to the blockchain network, and

the verification agent is configured to verify at least one of a first signature and one or more additional signatures.

13. The system ofclaim 12, wherein:

the account handler is configured to grant access to at least one private key among the one or more key pairs to the one or more verification computing systems, and

the one or more verification computing systems are configured to generate one or more additional signatures using said at least one private key.

14. The system ofclaim 1, wherein the proposed blockchain transaction comprises one or more of a public key associated with the at least one payer device, payee address information associated with a payee, a public key associated with the payee, a transaction amount and a specification of two or more additional signatures to perfect the proposed blockchain transaction.

15. The system ofclaim 1, wherein the one or more verification computing systems are configured to:

prompt the at least one payer device to authenticate with the one or more verification computing systems,

confirm an identity of a payer associated with the at least one payer device, and

verify that an account associated with the payer includes a transaction amount.

16. The system ofclaim 1, wherein the verification network is configured to incorporate situational detail data to the proposed blockchain transaction, the situational detail data comprising one or more of transaction information, geolocation data, and merchant data, the verification request including the situational detail data.

17. The system ofclaim 16, wherein the transaction information comprises one or more of a time and a value, and the merchant data comprises merchant statistics data.

18. The system ofclaim 16, wherein the one or more verification computing systems are configured to analyze the situational detail data in the verification request to determine a likelihood of fraud associated with the proposed blockchain transaction.

19. The system ofclaim 18, wherein the one or more verification computing systems are configured to perfect the proposed blockchain transaction responsive to said analyzing of the situational detail data and said determining of whether the proposed blockchain transaction includes the one or more pre-agreed threshold parameters.

20. The system ofclaim 18, wherein the one or more verification computing systems are configured to reverse the perfected blockchain transaction responsive to determining that the proposed blockchain transaction is fraudulent.

21. A non-transitory computer-readable storage media carrying computer-readable instructions that, when executed by one or more processors, direct the one or more processors to perform the functions of:

receiving a proposed blockchain transaction generated by at least one payer device; and

broadcasting a verification request for the proposed blockchain transaction to one or more verification computing systems,

wherein, upon receiving the verification request, the one or more verification computing systems being caused to perform the functions of:

determining whether the proposed blockchain transaction includes one or more pre-agreed threshold parameters, responsive to the verification request;

when the proposed blockchain transaction includes and satisfies the one or more pre-agreed threshold parameters:

directly perfecting the proposed blockchain transaction to create a perfected blockchain transaction, and

broadcasting the perfected blockchain transaction directly to a blockchain network; and

when the proposed blockchain transaction fails to include the one or more pre-agreed threshold parameters or fails to satisfy the one or more pre-agreed threshold parameters:

perfecting the proposed blockchain transaction via prompting authorization from the at least one payer device, and

broadcasting, via the one or more processors, the perfected blockchain transaction to the blockchain network, responsive to receiving said authorization from the at least one payer device.

22. The non-transitory computer-readable storage media ofclaim 21, wherein the proposed blockchain transaction comprises a first signature that is generated using a first private key, the first private key being generated and maintained by the at least one payer device.

23. The non-transitory computer-readable storage media ofclaim 22, wherein the perfecting of the proposed blockchain transaction comprises generating one or more additional signatures using a second private key, the second private key being generated and maintained by the one or more verification computing systems.

24. The non-transitory computer-readable storage media ofclaim 21, wherein when the proposed blockchain transaction fails to include the one or more pre-agreed threshold parameters or fails to satisfy the one or more pre-agreed threshold parameters:

the perfecting of the proposed blockchain transaction comprises generating and transmitting, by the one or more verification computing systems, one or more verification offers to the at least one payer device;

transmitting, responsive to receiving the one or more verification offers, by the at least one payer device, a selection of at least one offer from among the one or more verification offers to the one or more processors, the selection indicating the authorization of the proposed blockchain transaction; and

broadcasting, upon receiving said selection the perfected blockchain transaction to the blockchain network.

25. The non-transitory computer-readable storage media ofclaim 24, wherein the functions further comprise:

generating one or more key pairs, each key pair comprising a public key and a private key, and each key pair associated with a particular user, and storing said one or more key pairs in a database;

performing one or more of:

broadcasting the verification request to the one or more verification computing systems,

recording the perfected blockchain transaction in the database, and

broadcasting the perfected blockchain transaction to the blockchain network; and

verifying at least one of a first signature and one or more additional signatures.

26. The non-transitory computer-readable storage media ofclaim 21, wherein the proposed blockchain transaction comprises one or more of a public key associated with the at least one payer device, payee address information associated with a payee, a public key associated with the payee, a transaction amount and a specification of two or more additional signatures to perfect the proposed blockchain transaction.

27. The non-transitory computer-readable storage media ofclaim 21, wherein the functions further comprise:

incorporating situational detail data to the proposed blockchain transaction, the situational detail data comprising one or more of transaction information, geolocation data, and merchant data, the verification request including the situational detail data.

28. The non-transitory computer-readable storage media ofclaim 27, wherein the functions further comprise:

analyzing, by the one or more verification computing systems, the situational detail data in the verification request to determine a likelihood of fraud associated with the proposed blockchain transaction.

29. The non-transitory computer-readable storage media ofclaim 28, wherein the functions further comprise:

perfecting, by the one or more verification computing systems, the proposed blockchain transaction responsive to said analyzing of the situational detail data and said determining of whether the proposed blockchain transaction includes the one or more pre-agreed threshold parameters.

30. The non-transitory computer-readable storage media ofclaim 28, wherein the functions further comprise:

reversing, by the one or more verification computing systems, the perfected blockchain transaction responsive to determining that the proposed blockchain transaction is fraudulent.

Images