Recoverable transactions in a blockchain system via wrapped recoverable tokens

Abstract

Several aspects of this disclosure provide techniques and apparatus for processing recoverable transactions on a blockchain. An exemplary method generally involves receiving a request to execute a transaction on the blockchain to transfer an amount of wrapped tokens that encapsulate the base tokens to be exchanged in the transaction on the blockchain. The sequential cumulative amount of tokens in the recipient wallet that are in a recoverable state is increased by the amount of tokens identified in the request. After a threshold time period from the timestamp associated with the received request, it is determined whether the transaction is frozen. Based on the determination that the transaction is not frozen, the sequential cumulative amount of tokens in the recipient wallet that are in a recoverable state is decreased and the sequential cumulative amount of tokens in the recipient wallet that are in an unrecoverable state is increased.

Description

Technical Field

[0001] Aspects of the present disclosure relate to security in blockchain systems, and more particularly, to recoverable transactions in blockchain systems.

Background Art

[0002] A blockchain can be used to provide a ledger of transactions that occur within these distributed systems in various distributed systems. Generally, a blockchain may include a chain of blocks, where the latest block includes some information regarding the transactions that have occurred and a reference to the immediately preceding block, which can be the hash value of the previous block. Since the reference to the immediately preceding block can be a value derived from the immediately preceding block, the verification of a transaction within the blockchain can be performed by confirming that the hash of a block is determined to be the same value as that stored as the reference to the immediately preceding block within a subsequent block within the blockchain. If there is a mismatch between the calculated hash of a block and the hash value of the block within a subsequent block within the blockchain, the verification of the blockchain can fail.

[0003] Generally, once a transaction is recorded and verified on a blockchain, it is immutable and irreversible. Since the transactions recorded on a blockchain are immutable and irreversible, the blockchain may be regarded as the true source of the transactions recorded on it. Thus, executing a transaction on a blockchain can enable trust to be established between potentially unknown parties executing the transaction on the blockchain. For example, the source of tokens transferred between parties on a blockchain can be trusted by users participating in such transactions by recording such transactions on the blockchain.

[0004] However, the immutability and irreversibility of transactions on the blockchain can also create various security risks. For example, in a 51% attack, if a majority of the nodes participating in processing a transaction on the blockchain include false records, the transaction records stored on the blockchain may be modified. In another example, due to the immutability and irreversibility of transactions on the blockchain, a transaction resulting from a malicious attack (for example, the transfer of tokens to an attacker demanding a cryptocurrency payment to undo the effects of a ransomware attack) may not be reversible, and victims of such attacks may not be able to recover tokens lost as a result of such attacks.

[0005] Therefore, technologies are needed to improve the security of transactions that occur on the blockchain. [Overview of the project]

[0006] Several embodiments provide computer implementations for processing recoverable transactions on a blockchain. An exemplary method generally involves receiving a request to execute a transaction on the blockchain. This request generally involves transferring an amount of tokens on the blockchain from a sender wallet to a recipient wallet identified in the request, where the tokens are generally wrapped tokens that encapsulate the base tokens exchanged in the transaction on the blockchain. The cumulative total of tokens in the recipient wallet in a recoverable state is increased by the amount of tokens identified in the request. After a threshold time period from the timestamp associated with the received request, it is determined whether the transaction is frozen. Based on the determination that the transaction is not frozen, the cumulative total of tokens in the recipient wallet in a recoverable state is decreased by the amount of tokens, and the cumulative total of tokens in the recipient wallet in an unrecoverable state is increased by the amount of tokens.

[0007] Other embodiments provide a processing system configured to perform the methods described above and the methods described herein; a non-temporary computer-readable medium containing instructions that, when executed by one or more processors of the processing system, cause the processing system to perform the methods described above and the methods described herein; a computer program product embodied on a computer-readable storage medium containing code for performing the methods described above and the methods described herein; and a processing system comprising means for performing the methods described above and the methods described herein.

[0008] The following description and related drawings detail some exemplary features of one or more embodiments.

[0009] The attached figures illustrate some aspects of one or more embodiments and should therefore not be considered to limit the scope of this disclosure. [Brief explanation of the drawing]

[0010] [Figure 1] This figure shows an exemplary computing system according to an embodiment of the present disclosure in which recoverable transactions are executed on a blockchain using wrapped tokens. [Figure 2] This figure shows a timeline for executing a recoverable transaction on the blockchain using a wrapped token, according to an embodiment of the disclosure. [Figure 3] This figure shows exemplary operation for executing a recoverable transaction on a blockchain using a wrapped token, according to an embodiment of the present disclosure. [Figure 4] This figure shows an exemplary system that can carry out the embodiments of this disclosure. [Modes for carrying out the invention]

[0011] For ease of understanding, the same reference numerals are used to indicate identical elements common to the drawings, where possible. Elements and features of one embodiment are intended to be usefully incorporated into other embodiments without further detail.

[0012] In a cryptocurrency system, a transaction can be represented as a block within a blockchain that tracks the collection of transactions performed using the cryptocurrency system. In these cryptocurrency systems, processed transactions cannot be modified later, thus providing an immutable ledger of transactions performed using the cryptocurrency system.

[0013] Using a blockchain system to execute and record transactions generally allows transactions to be recorded immutably, which can enable the blockchain to provide a consistent, unalterable record of transactions that occur on the blockchain, and thus a consistent, unalterable transaction history for each user performing an action on the blockchain. However, the immutability and irreversibility of transactions on the blockchain can enable a malicious party to execute malicious transactions that cannot be undone. For example, transactions resulting from hacking a wallet, fraud carried out against a wallet owner, theft of tokens from a wallet, and other attacks against wallets can occur from time to time, and the immutability and irreversibility of transactions executed on the blockchain may prevent victims from recovering tokens lost in such attacks. Thus, transaction security and trust in a blockchain system can be negatively affected by the immutability of the blockchain system and the irreversibility of transactions executed on the blockchain system.

[0014] Aspects of this disclosure provide techniques for executing recoverable transactions on a blockchain using wrapped tokens. As described in further detail herein, a wrapped token encapsulates a defined base token and can be in a recoverable, unrecoverable, or frozen state. Generally, a wrapped token may be received in a wallet in a recoverable state and remain recoverable until a certain threshold amount of time has elapsed. While a wrapped token is in a recoverable state, it may be frozen (for example, based on instructions from a trusted source that the wrapped token was involved in a fraudulent transaction that is subject to cancellation). When a wrapped token is placed in an unrecoverable state, it may be unwrapped, and the base token may be recovered from the wrapped token. By using a wrapped token that may be in a recoverable or unrecoverable state in a transaction executed on a blockchain, aspects of this disclosure may enable the cancellation of a transaction in a variety of cases in which the transaction is determined to be fraudulent or the result of malicious activity. Therefore, the aspects of this disclosure can improve security and trust in blockchain systems, as malicious transactions can be revoked, and reduce the possibility that parties to transactions executed on the blockchain may permanently lose tokens or other digital assets due to a malicious transaction or a malicious party executing a transaction on the blockchain.

[0015] An example of recoverable transaction processing on the blockchain using wrapped tokens Figure 1 shows an exemplary computing environment 100 in which recoverable transactions are executed on a blockchain using wrapped tokens, according to an aspect of this disclosure. As shown, the computing environment 100 includes a transaction processing system 110, a number of wallets 120, and a network 130.

[0016] The transaction processing system 110 generally enables the creation and destruction of recoverable tokens by wrapping a base token into a wrapped token, freezing recoverable tokens, and executing recoverable transactions on the blockchain 132 of the network 130. As illustrated, the transaction processing system 110 includes a token wrapper / unwrapper 112, a token freezer 114, and a transaction processor 116.

[0017] Token wrappers / unwrappers 112 generally allow users associated with a wallet 120 to wrap a base token into a wrapped token, and to unwrap the base token from the wrapped token to execute recoverable transactions on blockchain 132. Generally, recoverable transactions can be executed using the wrapped token, while non-recoverable transactions can be executed using the base token.

[0018] Wrapped tokens generally allow recoverability data to be added to a base token that can be used to execute transactions recorded on the blockchain. Recoverability data may include a recoverability status indicator and a frozen status indicator. The recoverability status indicator may be a Boolean value, for example, where a Boolean value of true is equivalent to the wrapped token being recoverable, and a Boolean value of false is equivalent to the wrapped token being unrecoverable. Similarly, the frozen status indicator may also be a Boolean value, where a Boolean value of true is equivalent to the wrapped token being frozen (and therefore included in a transaction subject to cancellation), and a Boolean value of false is equivalent to the wrapped token not being frozen.

[0019] When a user first creates a wrapped token in wallet 120 based on a base token (for example, from the base token store 126 in wallet 120), the wrapped token may be initialized to an unrecoverable, unfrozen state. That is, since it can be assumed that the user owns the token wrapped via the token wrapper / unwrapper 112, there is no need to put the token in a recoverable state, and it cannot be frozen. After the wrapped token is created, the wrapped token may be added to the unrecoverable token store 124 in wallet 120.

[0020] Furthermore, the token wrapper / unwrapper 112 allows the user to convert the wrapped token back into the base token encapsulated within the wrapped token. Generally, a user may be able to unwrap tokens in an unrecoverable state (for example, tokens in an unrecoverable token store 124 in wallet 120) into base tokens and add the unwrapped base tokens to the base token store 126 in wallet 120. However, the token wrapper / unwrapper 112 may not allow the user to unwrap recoverable tokens in a recoverable token store 122 because these tokens may be frozen if the transaction containing these tokens is subject to cancellation until a threshold amount of time has elapsed from the timestamp associated with the transaction.

[0021] The token freezer 114 generally functions as a governance source that enables the freezing of tokens when a transaction executed on blockchain 132 within network 130 is determined to be potentially fraudulent or malicious (for example, a transaction corresponding to malicious activity such as a token theft event or a ransomware attack where cryptocurrency is used to obtain a decryption key to undo the ransomware attack), and therefore subject to revocation. If the token freezer 114 determines that a transaction executed on blockchain 132 is a fraudulent or malicious transaction, the token freezer 114 can reverse the frozen state of the tokens involved in the transaction and stored in the sender wallet 1202 (for example, changing the frozen state from a boolean false to a boolean true). After freezing the tokens, the token freezer 114 (or any other external governance source) can either revoke the transaction or instruct the transaction processor 116 to revoke the transaction. When revoking a transaction, the frozen tokens may be withdrawn from the recoverable token store 122 in the sender wallet 1201 and returned to the sender wallet 1202.

[0022] In some embodiments, the threshold time for a transaction to be canceled, and therefore the threshold time for freezing tokens involved in a transaction subject to cancellation, may be defined globally (for example, for all transactions executed via the transaction processing system 110). In some embodiments, the threshold time for a transaction to be canceled may be defined according to a policy associated with each recipient wallet. In such cases, the token freezer 114 may maintain a list associated with each recipient wallet containing transactions subject to cancellation.

[0023] Generally, the list of transactions maintained by the token freezer 114 to determine when a transaction is eligible for cancellation can be organized in chronological order (e.g., in a first-in-first-out data structure). As time progresses, the transaction at the head of the data structure (e.g., the earliest transaction) can be terminated by determining whether the transaction is potentially fraudulent / malicious and thus eligible for cancellation. As described, these transactions can be processed according to a threshold amount of time defined for the transaction (which can be a global threshold defined for all transactions executed via the transaction processing system 110 or a per-recipient-wallet threshold defined for transactions executed by a particular sender wallet 120). As time passes and a transaction is terminated, the list of pending transactions can be adjusted to reflect which transactions are still pending and which transactions have been terminated. In some embodiments, the list of transactions maintained by the token freezer 114 may be updated periodically (e.g., at the end of each day), which can enable the deletion of a large number of transactions from the list in a single operation to reduce the network and processing overhead associated with deleting individual transactions from the list as such transactions are terminated. In such cases, the token freezer 114 can scan the list of transactions to identify the next pending transaction and update and / or verify the number of tokens in the recoverable token store 122 based on the number of pending transactions of the user associated with the sender wallet 1201.

[0024] In some embodiments, the token freezer 114 may freeze tokens associated with a transaction subject to revocation based on verification of a token freezing operation performed on the blockchain 132. In such cases, the token freezer 114 and other participants processing transactions on the blockchain 132 may vote on whether the transaction should be subject to revocation and, therefore, whether the tokens associated with the transaction should be frozen. If multiple governance authorities (including the token freezer 114) vote on the blockchain that the transaction should be revoked, the token freezer 114 may freeze tokens in the sender wallet 1201 associated with the transaction. Performing on-chain verification and revocation of fraudulent or malicious transactions through multiple governance authorities may improve the reliability of decisions to revoke a transaction and freeze tokens associated with it, because the determination that a transaction is fraudulent or malicious and therefore subject to revocation may be made by multiple parties, and a significant number of them may need to be undermined to undermine the legitimacy of the transaction record on the blockchain 132 (for example, more than 50 percent of nodes process transactions on the blockchain).

[0025] In some embodiments, the token freezer 114 can freeze tokens associated with a transaction determined to be an unauthorized or malicious transaction between multiple wallets. For example, assume that a malicious transaction occurs where the sender wallet 1202 sends an amount tx0 of tokens to the sender wallet 1201, and multiple additional transactions of amounts tx1, tx2, and tx3 occur downstream of the sender wallet 1201. The token freezer can freeze, at each wallet that receives tokens downstream of the sender wallet 1201, the minimum value of (|tx0|, |tx1|, |tx2|, |tx3|), or an amount of tokens that does not exceed the number of tokens available at each of the wallets where the multiple additional transactions occurred. The transaction to be frozen can be established such that the malicious transaction is the earliest transaction and occurs before the expiration of a time window defined based on a threshold amount of time to cancel the transaction, and the transactions in which tx1, tx2, and tx3 are transferred are later in time and consecutive, so that the timestamp associated with the transfer of tx1 is earlier than the timestamp associated with the transfer of tx2, and the timestamp associated with the transfer of tx2 is earlier than the timestamp associated with the transfer of tx3. When freezing tokens across multiple wallets, the amount frozen can be less than or equal to |tx0|, and as a result, by returning the frozen tokens across multiple wallets to the sender wallet 1202, the sender wallet 1202 is returned to the state prior to the execution of the transaction with the sender wallet 1201.

[0026] Transaction processor 116 generally receives requests to execute a transaction that involves transferring wrapped tokens from sender wallet 1202 to sender wallet 1201. This request generally includes information identifying sender wallet 1201 (e.g., the sender wallet address), information identifying sender wallet 1202 (e.g., the sender wallet address), and the amount of wrapped tokens to be transferred from sender wallet 1201 to sender wallet 1202. Generally, transaction processor can initiate the transfer of tokens from sender wallet 1202 to sender wallet 1201 by verifying that a sufficient number of tokens exist in sender wallet 1202, and if so, by committing a transaction record to blockchain 132 and invoking a smart contract or other programmatic structure on blockchain 132 that causes the tokens to be transferred between sender wallet 1202 and sender wallet 1201.

[0027] Generally, policies associated with the recipient wallet 120 may specify whether a transaction can be executed using recoverable tokens (for example, tokens subject to freezing and transaction cancellation by the token freezer 114 and / or other governance authorities participating in the processing of the transaction on blockchain 132). If the policy specifies that a transaction can be executed using non-recoverable tokens, the transaction processor 116 may examine the non-recoverable token store 124 of the sender wallet 1202 to determine whether a sufficient amount of tokens is available for the transaction. In some embodiments, if the amount of tokens in the non-recoverable token store 124 is insufficient to fulfill the transaction, the transaction processor 116 may prevent the transaction from being executed and committed to blockchain 132. In some embodiments, if the amount of tokens in the non-recoverable token store 124 is insufficient to fulfill the transaction, the transaction processor 116 may wrap the tokens in the base token store 126 and move the wrapped tokens to the non-recoverable token store 124 for use when executing the transaction.

[0028] If the policy associated with the recipient wallet 120 allows the transaction to be executed using recoverable tokens, the transaction processor 116 can examine both the recoverable token store 122 and the non-recoverable token store 124 of the sender wallet 1202 to determine if there is a sufficient amount of tokens in total to execute the transaction. If there is a sufficient amount of tokens in total, the transaction processor 116 can select the tokens to be transferred from the sender wallet 1202 to the sender wallet 1201 from either or both of the recoverable token store 122 and / or the non-recoverable token store 124. In some embodiments, tokens may be transferred from the non-recoverable token store 124 until there are no more tokens left in the non-recoverable token store 124. Once the supply of tokens in the non-recoverable token store 124 is depleted, the transaction processor 116 may also be able to transfer the tokens stored in the recoverable token store 122 of the sender wallet 1202 to the recipient wallet 1201. In some embodiments, tokens may be transferred from the recoverable token store 122 of the sender wallet 1202 until no tokens remain in the recoverable token store 122. When the supply of tokens in the recoverable token store 122 is depleted, the transaction processor 116 also transfers tokens stored in the non-recoverable token store 124 of the sender wallet 1202 to the sender wallet 1202. 2 It may be possible to transfer from there to recipient wallet 1201.

[0029] Example of executing a recoverable transaction on the blockchain using wrapped tokens Figure 2 shows a timeline 200 for executing a recoverable transaction on the blockchain using wrapped tokens according to an embodiment of the present disclosure.

[0030] As illustrated, in timeline 200, transaction 210 is executed at time t. Transaction 210, as described, generally involves the transfer of tokens from sender wallet to sender wallet (e.g., between wallets 120 shown in Figure 1) and is recorded and processed on the blockchain (e.g., blockchain 132 shown in Figure 1). When executing transaction 210, wrapped tokens may be transferred from sender wallet to sender wallet. Tokens withdrawn from sender wallet may be in an unrecoverable state, or a mixture of recoverable and unrecoverable tokens, depending on the policy defined for users associated with the sender wallet (e.g., identifying whether users associated with the sender wallet can execute transactions using recoverable wrapped tokens). When the transaction is executed, a certain amount of wrapped tokens is transferred from sender wallet to sender wallet. Upon receipt in the sender wallet, the received wrapped tokens are placed in a recoverable state for a threshold time period (e.g., stored in a portion of the wallet where recoverable tokens are stored, such as the recoverable token store 122 shown in Figure 1).

[0031] Before the threshold time elapses (for example, before time t+threshold_time), a governance authority (for example, the token freezer 114 and / or other governance authorities shown in Figure 1) may determine that transaction 210 is an illegal, malicious activity or otherwise subject to revocation. If a governance authority (or, if the transaction and token freeze are verified on the chain, the majority of governance authorities) determines that the transaction is subject to revocation before the threshold time elapses, the governance authority may determine that the tokens associated with the transaction may be frozen for future recovery.

[0032] In block 212, which occurs after t+threshold_time, the transaction processor can determine whether transaction 210 has been validated as a legitimate transaction, or whether it is an illegal, malicious activity, or otherwise subject to cancellation. If, in block 212, the transaction processor determines that transaction 210 has been validated as a legitimate transaction, the transaction processor can mark the tokens involved in transaction 210 as unrecoverable. For example, the tokens may be migrated to a wallet that stores unrecoverable tokens, or the tokens involved in transaction 210 may have an updated status indicator that reflects that such tokens are now unrecoverable tokens. The owner of the wallet receiving these tokens may perform subsequent transactions using these unrecoverable tokens, such as performing further transactions that involve the transfer of these unrecoverable tokens, or unwrapping these unrecoverable tokens into the base tokens encapsulated within them.

[0033] However, if in block 212 the transaction processor determines that transaction 210 is an illegal, malicious activity or otherwise subject to revocation, then in block 216 the transaction processor may freeze the tokens associated with transaction 210. In some embodiments, a single governance authority (e.g., the token freezer 114 shown in Figure 1) can be used to determine that a transaction is subject to revocation. In such cases, the token freezer 114 can determine that a transaction is subject to revocation at any point before the threshold time has elapsed and can freeze the tokens associated with transaction 210. That is, although timeline 200 indicates that transaction 210 is subject to revocation after the threshold time has elapsed from the time transaction 210 was executed, it should be understood that the transaction can be considered subject to revocation and the corresponding tokens can be frozen at any point before time t+threshold_time. In some embodiments, if transaction reversibility and token freezing are performed based on a consensus derived from the determinations of multiple governance authorities, transaction 210 may be deemed reversible if, at any point before the threshold time period has elapsed, a threshold number of governance authorities determine that the transaction is fraudulent, malicious activity or otherwise subject to reversal.

[0034] After the token is frozen in block 216, the token may be recovered in the sender wallet. To recover the token, a subsequent transaction may be recorded on blockchain 132 to prove that transaction 210 has been canceled. The token may be removed from the sender wallet (and potentially from downstream sender wallets, as described above) and returned to the sender wallet through this subsequent transaction recorded on blockchain 132. The token removed from the sender wallet may, in some aspects, be a token stored in an unrecoverable token store, or it may be the token that was initially transferred to the sender wallet (for example, if the token is unique and non-fungible). In some cases, this subsequent transaction to recover the token may not undergo a waiting period before the token involved in this subsequent transaction is deemed unrecoverable, and rather, based on the determination that the token was transferred as part of a recoverable transaction, the token returned to the sender wallet may be returned in an unrecoverable state and made available for subsequent use.

[0035] Example of operation for processing recoverable transactions on the blockchain using wrapped tokens Figure 3 shows an exemplary operation 300 for executing a recoverable transaction on a blockchain according to an embodiment of the present disclosure. Operation 300 may be executed, for example, by a transaction processing system (e.g., transaction processing system 110 shown in Figure 1) used by users associated with a sender wallet and a receiver wallet to execute a recoverable transaction on a blockchain.

[0036] Operation 300 begins in block 310 with receiving a request to execute a transaction on the blockchain, as illustrated. This request typically includes a request to transfer a quantity of tokens on the blockchain from the sender wallet to the recipient wallet identified in the request. The tokens may be wrapped tokens that encapsulate the base tokens exchanged in the transaction on the blockchain.

[0037] In block 320, operation 300 proceeds to add the sequential cumulative sum of tokens in the recipient wallet that are in a recoverable state by the amount of tokens identified in this request.

[0038] In block 330, operation 300 proceeds to determine whether the transaction was frozen after a threshold time period from the timestamp associated with the received request.

[0039] In block 340, operation 300 proceeds to subtract the amount of tokens from the sequential cumulative total of tokens in the recoverable recipient wallet, and add the amount of tokens to the sequential cumulative total of tokens in the unrecoverable recipient wallet.

[0040] In some embodiments, the sequential accumulation of tokens in a recoverable recipient wallet includes transferring an amount of tokens from the sender wallet to the recipient wallet to a portion of the recipient wallet that stores the recoverable tokens.

[0041] In some embodiments, the amount of tokens may be drawn from tokens in an irrecoverable state within the sender's wallet. In some embodiments, transferring the amount of tokens may involve sending a first amount of tokens from tokens in an irrecoverable state within the sender's wallet before sending a second amount of tokens from tokens in an irrecoverable state. The sum of the first amount of tokens and the second amount of tokens is equal to the amount of tokens, and the first amount of tokens is less than the amount of tokens.

[0042] In some embodiments, the amount of tokens may be drawn from recoverable tokens in the sender's wallet. Transferring the amount of tokens may involve sending a first amount of tokens from recoverable tokens in the sender's wallet before sending a second amount of tokens from unrecoverable tokens. The sum of the first amount of tokens and the second amount of tokens is equal to the amount of tokens, and the first amount of tokens is less than the amount of tokens.

[0043] In some embodiments, a policy associated with the recipient wallet identifies whether an amount of tokens can be withdrawn from a portion of the sender wallet where recoverable tokens are stored. Operation 300 may further include determining a first amount of unrecoverable tokens in the sender wallet and a second amount of recoverable tokens in the sender wallet based on records stored on the blockchain. Generally, the second amount of recoverable tokens may be identified based on transaction records on the blockchain relating to transactions in which a threshold time amount has not elapsed.

[0044] In some embodiments, operation 300 further includes, based on the determination that a transaction has been frozen, adding a sequential cumulative sum of tokens in the recipient wallet that is frozen by the amount of tokens.

[0045] In some embodiments, operation 300 further includes receiving instructions from a defined governance source that the transaction should be canceled. Based on the received instructions, the amount of tokens is restored to the sender wallet.

[0046] In some embodiments, a chain of wallets, including the recipient wallet, is identified in order to restore the amount of tokens to the sender wallet. The chain of wallets may generally correspond to the wallets to which the tokens associated with the transaction were transferred. These wallets may be identified based on the timestamps associated with a series of transactions, such that the total amount of tokens frozen across the chain of wallets equals the amount of tokens. The tokens are transferred from the chain of wallets to the sender wallet. In some embodiments, the series of transactions includes a chain of transactions that are sequentially ordered in time and executed after each transaction.

[0047] Exemplary system for processing recoverable transactions on a blockchain using wrapped tokens Figure 4 shows an exemplary system 400 configured to perform the methods described herein, including, for example, the operation 300 in Figure 3. In some embodiments, the system 400 may function as a transaction processing service, such as the transaction processing system 110 shown in Figure 1, which receives requests to transfer tokens between sender wallets and commits a record of such transactions to the blockchain.

[0048] As illustrated, system 400 includes a central processing unit (CPU) 402, one or more I / O device interfaces 404 that can enable connections of various I / O devices 414 (e.g., keyboard, display, mouse device, pen input, etc.) to system 400, a network interface 406 to which system 400 is connected to a network 690 (which may be a local network, intranet, internet, or any other group of computing devices connected to communicate with each other), memory 408, and interconnection lines 412. The I / O devices 414 and / or the network interface 406 may be used to receive requests to bridge transactions between different blockchains, such as a Layer 1 blockchain and a Layer 2 blockchain.

[0049] The CPU 402 can retrieve and execute programming instructions stored in memory 408. Similarly, the CPU 402 can retrieve and store application data present in memory 408. The interconnection line 412 transmits programming instructions and application data between the CPU 402, the I / O device interface 404, the network interface 406, and memory 408.

[0050] CPU402 is included to represent a single CPU, multiple CPUs, a single CPU with multiple processing cores, and so on.

[0051] Memory 408 represents volatile memory such as random access memory, or non-volatile memory such as non-volatile random access memory or phase-change random access memory. As shown in the figure, memory 408 includes a token wrapper / unwrapper 420, a token freezer 430, and a transaction processor 440.

[0052] The token wrapper / unwrapper 420 may correspond to the token wrapper / unwrapper 112 shown in Figure 1. Generally, the token wrapper / unwrapper 420 creates a wrapped token from a base token and unwraps the base token from the wrapped token. When creating a wrapped token, the token wrapper / unwrapper 420 encapsulates a base token that may be used in a transaction executed and recorded on the blockchain, and adds the additional functionality that allows the base token to be placed in a recoverable, unrecoverable, and frozen state when the token is transferred in a transaction that is the result of fraudulent, malicious activity, or otherwise marked as subject to revocation. Generally, the token wrapper / unwrapper 420 may be able to unwrap the token into the base token when such a token is in an unrecoverable state, but may not be able to unwrap the token when such a token is in a recoverable state (because these tokens may be associated with a transaction subject to revocation and therefore may be tokens that can be returned to the sender's wallet).

[0053] Token Freezer 430 may correspond to Token Freezer 114 shown in Figure 1. Generally, Token Freezer 430 acts as a governance authority for transactions recorded on the blockchain, enabling it to mark transactions as fraudulent, malicious activity, or otherwise subject to revocation, and enabling the tokens transferred in these transactions to be frozen with awaiting further review and / or returned to the sender wallet. Generally, Token Freezer 430 may determine at any time before the expiration time, defined based on the timestamp associated with the transaction and a threshold time amount to wait for the transaction to be verified (or for the transaction to be marked as subject to revocation), that a transaction is subject to revocation and therefore the associated tokens should be frozen with awaiting the return of such tokens to the recipient wallet. If Token Freezer 430 does not mark the transaction as subject to revocation before the expiration time, the transaction may be terminated, and the tokens transferred as part of the transaction may move from a recoverable state to an unrecoverable state. Otherwise, the transaction may be terminated, and the tokens may move from a recoverable token store to an unrecoverable token store.

[0054] Transaction processor 440 may correspond to transaction processor 116 shown in Figure 1. Generally, transaction processor 440 executes transactions on the blockchain and accomplishes the transfer of tokens from the sender wallet to the receiver wallet. Generally, tokens transferred to the receiver wallet may be transferred in a recoverable state and may transition to an unrecoverable state when the timer associated with the transaction expires. Transaction processor 440 can select the tokens to be exchanged between the sender wallet and the receiver wallet based on various techniques, such as transferring only tokens that are in an unrecoverable state, or transferring tokens in an unrecoverable state before transferring tokens that are in a recoverable state. Transaction processor 440 may also execute transactions to recover frozen tokens associated with transactions deemed by a governance authority (e.g., token freezer 430 and / or other governance authorities).

[0055] Exemplary clause Details of the various implementations of this disclosure are described in the following numbered clauses.

[0056] Clause 1: A computer implementation method comprising receiving a request to execute a transaction on a blockchain, the request including a request to transfer an amount of tokens on the blockchain from a sender wallet to a recipient wallet identified in the request, the tokens including a wrapped token that encapsulates a base token to be exchanged in a transaction on the blockchain; adding the amount of tokens identified in the request to the sequential cumulative total of tokens in a recoverable recipient wallet; determining whether the transaction is frozen after a threshold time period from the timestamp associated with the received request; subtracting the amount of tokens from the sequential cumulative total of tokens in a recoverable recipient wallet based on the determination that the transaction is not frozen; and adding the amount of tokens to the sequential cumulative total of tokens in an unrecoverable recipient wallet.

[0057] Clause 2: The method according to Clause 1, further comprising adding the cumulative total of tokens in the recipient's wallet that are frozen, based on the determination that a transaction has been frozen, by the amount of tokens.

[0058] Clause 3: The method of Clause 2, further comprising receiving instructions from a defined governance source that a transaction should be canceled, and, based on the received instructions, restoring the amount of tokens to the sender's wallet.

[0059] Clause 4: The method of Clause 3, wherein restoring the amount of tokens to the recipient wallet includes identifying the wallet chain containing the recipient wallet to which the transaction-related tokens were transferred, based on the timestamps associated with the series of transactions, such that the total amount of tokens frozen across the wallet chain equals the amount of tokens, and transferring the tokens from the wallet chain to the sender wallet.

[0060] Clause 5: The method according to Clause 4, wherein a series of transactions are sequentially ordered in time and include a chain of transactions that are executed following one transaction.

[0061] Clause 6: The method in Clause 1, which includes adding up the sequential cumulative amount of tokens in a recoverable recipient wallet, and transferring the amount of tokens from the sender wallet to the recipient wallet to a portion of the recipient wallet that stores the recoverable tokens.

[0062] Clause 7: Transferring a quantity of tokens is the method described in Clause 6, including sending a quantity of tokens from tokens in an irrecoverable state within the sender's wallet.

[0063] Clause 8: Transferring a token amount includes sending a first amount of tokens from a recoverable token in the sender's wallet before sending a second amount of tokens from an irrecoverable token, the sum of the first amount of tokens and the second amount of tokens being equal to the token amount, and the first amount of tokens being less than the token amount, as described in Clause 6 or 7.

[0064] Clause 9: A policy relating to the recipient wallet shall identify whether the amount of tokens can be withdrawn from a portion of the sender wallet in a recoverable state, as described in any one of Clauses 6 through 8.

[0065] Clause 10: The method according to any one of Clauses 1 to 9, further comprising determining a first amount of tokens in an irrecoverable state and a second amount of tokens in a recoverable state in the sender wallet based on records stored on the blockchain, wherein the second amount of tokens in a recoverable state is identified based on transaction records on the blockchain relating to transactions for which a threshold time amount has not elapsed.

[0066] Clause 11: A system comprising memory storing executable instructions and a processor configured to execute executable instructions in order to perform any one of Clauses 1 through 10.

[0067] Clause 12: A system comprising means for performing any one of the operations described in Clauses 1 through 10.

[0068] Clause 13: A computer-readable medium on which instructions are stored that, when executed by a processor, perform any of the operations described in any one of Clauses 1 through 10.

[0069] Additional considerations The foregoing description is provided to enable those skilled in the art to implement the various embodiments described herein. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may apply to other embodiments. For example, changes may be made to the function and configuration of the elements described herein without departing from the scope of this disclosure. Various examples may omit, replace, or add various procedures or components as needed. Also, features described in some examples may be combined in some other examples. For example, an apparatus may be implemented or a method may be carried out using any number of embodiments described herein. Furthermore, the scope of this disclosure shall cover, in addition to or in addition to the various embodiments of this disclosure described herein, such apparatuses or methods carried out using other structures, functions, or structures and functions. It should be understood that any embodiment of this disclosure disclosed herein may be embodied by one or more elements of the claims.

[0070] As used herein, the phrase “at least one of” the list of items refers to any combination of those items that includes a single member. For example, “at least one of a, b, or c” shall cover a, b, c, ab, ac, bc, and abc, as well as any combination with multiple identical elements (for example, aa, aaa, aab, aac, abb, acc, bb, bbb, bbc, cc, and ccc, or any other ordering of a, b, and c).

[0071] As used herein, the term “decision-making” encompasses a wide variety of actions. For example, “decision-making” may include calculating, calculating, processing, deriving, investigating, looking up (e.g., looking up in a table, database, or other data structure), and confirming. It may also include receiving (e.g., receiving information), accessing (e.g., accessing data in memory), and further, resolving, selecting, choosing, and establishing.

[0072] The methods disclosed herein include one or more steps or actions for achieving the method. The steps and / or actions of the method may be interchangeable with one another without departing from the claims. In other words, unless a particular order of steps or actions is specified, the order and / or use of any particular steps and / or actions may be modified without departing from the claims. Furthermore, the various operations of the methods described above may be performed by any suitable means capable of performing the corresponding functions. The means may include, but are not limited to, various hardware and / or software components and / or modules, including circuits, application-specific integrated circuits (ASICs), or processors. Generally, where there are operations shown in the figures, those operations may have corresponding counterpart means and functional components having similar numbering.

[0073] The various exemplary logic blocks, modules, and circuits described in this disclosure may be implemented or run using general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices (PLDs), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but alternatively, a processor may be any commercially available processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors working with a DSP core, or any other such configuration.

[0074] The processing system may be implemented using a bus architecture. The bus may include any number of interconnection buses and bridges, depending on the specific application and overall design constraints of the processing system. The bus may link various circuits to one another, including, among other things, processors, machine-readable media, and input / output devices. User interfaces (e.g., keypads, displays, mice, joysticks, etc.) may also be connected to the bus. The bus may also link various other circuits, such as timing sources, peripherals, voltage regulators, and power management circuits, but these circuits are well known in the art and therefore will not be described further. The processor may be implemented using one or more general-purpose processors and / or dedicated processors. Examples include microprocessors, microcontrollers, DSP processors, and other circuits capable of running software. Those skilled in the art will recognize how to best implement the described functions for the processing system, depending on the specific application and the overall design constraints imposed on the overall system.

[0075] When implemented in software, functions may be stored on or transmitted via computer-readable media as one or more instructions or code. Software is broadly interpreted to mean instructions, data, or any combination thereof, whether referred to as software, firmware, middleware, microcode, hardware description language, etc. Computer-readable media includes both computer storage media and communication media, such as any medium that enables the transfer of computer programs from one location to another. A processor may be responsible for bus management and general processing, including the execution of software modules stored on computer-readable storage media. Computer-readable storage media may be coupled to a processor so that the processor can read information from and write information to the storage media. Alternatively, this storage media may be integrated into the processor. For example, computer-readable media may include computer-readable storage media containing instructions, separate from the transmission lines, data-modulated carriers, and / or wireless nodes, all of which may be accessed by the processor via a bus interface. As an alternative or addition, computer-readable media, or any part thereof, may be incorporated into the processor, as well as caches and / or general-purpose register files. Examples of machine-readable storage media may include, for example, RAM (random access memory), flash memory, ROM (read-only memory), PROM (programmable read-only memory), EPROM (erasable programmable read-only memory), EEPROM (electrically erasable programmable read-only memory), registers, magnetic disks, optical disks, hard drives, or any other suitable storage media, or any combination thereof. Machine-readable media may be embodied in computer program products.

[0076] A software module may contain a single instruction or many instructions and may be distributed across several different code segments, between different programs, and across multiple storage media. Computer-readable media may contain several software modules. A software module contains instructions that, when executed by a device such as a processor, cause a processing system to perform various functions. A software module may include send modules and receive modules. Each software module may reside in a single storage device or be distributed across multiple storage devices. For example, a software module may be loaded from a hard drive into RAM when a trigger event occurs. While a software module is executing, the processor may load some of the instructions into a cache to increase access speed. One or more cache lines may then be loaded into a general-purpose register file for execution by the processor. When referring to the functionality of a software module, it will be understood that such functionality is implemented by the processor when executing instructions from that software module.

[0077] The following claims are not intended to be limited to the embodiments described herein, but should be given the full scope consistent with the language of the claims. In the claims, references to singular elements mean "one or more" and not "one of a kind" unless otherwise explicitly stated. Unless otherwise explicitly stated, the term "several" means one or more. Claim elements should not be construed under 35 U.S. SC § 112(f) unless they are expressly described using the phrase "means for" or, in the case of a method claim, using the phrase "steps for". All structural and functional equivalents of the elements of various aspects described throughout this disclosure, known to those skilled in the art or to be known thereafter, are expressly incorporated herein by reference and are encompassed by the claims. Furthermore, nothing disclosed herein is intended to be made public, whether such disclosure is expressly stated in the claims or not.

Claims

1. Receiving a request to execute a transaction on the blockchain, the request including a request to transfer an amount of tokens on the blockchain from a sender wallet to a recipient wallet identified in the request, the tokens including a wrapped token that encapsulates the base tokens exchanged in the transaction on the blockchain, The amount of the token identified in the request is added to the sequential cumulative total of tokens in the recipient wallet that are in a recoverable state, Determining whether the transaction is frozen after a threshold time period based on the timestamp associated with the received request, Based on the determination that the aforementioned transaction is not frozen, Subtracting the amount of the tokens from the sequentially cumulative total of the tokens in the recipient wallet that are in a recoverable state, A computer implementation method comprising adding the sequential cumulative sum of tokens in the recipient wallet that are in an irrecoverable state to the amount of the tokens.

2. The method according to claim 1, further comprising determining that the transaction is frozen, adding the cumulative total of the tokens in the recipient wallet that are frozen by the amount of the tokens.

3. Receiving instructions from a defined governance source that the transaction should be canceled, The method of claim 2, further comprising restoring the amount of the token to the sender wallet based on the received instructions.

4. Restoring the aforementioned amount of the aforementioned token to the recipient wallet is: Identifying the wallet chain including the recipient wallet to which the tokens associated with a series of transactions were transferred, based on the timestamp associated with a series of transactions, such that the total amount of tokens frozen across the wallet chain is equal to the amount of the tokens; The method according to claim 3, further comprising transferring a token from the wallet's chain to the sender wallet.

5. The method according to claim 4, wherein the series of transactions includes a chain of transactions that are sequentially ordered in time and executed following the transactions.

6. The method according to claim 1, wherein adding the sequential cumulative amount of tokens in the recoverable recipient wallet includes transferring the amount of tokens from the sender wallet to the recipient wallet to a portion of the recipient wallet in which the recoverable tokens are stored.

7. The method according to claim 6, wherein transferring the amount of the tokens includes sending the amount of the tokens from the irrecoverable tokens in the sender wallet.

8. Transferring the amount of the tokens includes sending a first amount of the tokens from the recoverable tokens in the sender wallet before sending a second amount of the tokens from the irrecoverable tokens, The sum of the first amount of the token and the second amount of the token is equal to the amount of the token. The method according to claim 6, wherein the first amount of the token is less than the amount of the token.

9. The method according to claim 6, wherein the policy relating to the recipient wallet identifies whether the amount of the tokens can be withdrawn from the portion of the sender wallet in which the recoverable tokens are stored.

10. The method according to claim 1, further comprising determining a first amount of tokens in an unrecoverable state and a second amount of tokens in a recoverable state in the sender wallet based on records stored on the blockchain, wherein the second amount of tokens in a recoverable state is identified based on transaction records on the blockchain relating to transactions in which the threshold time amount has not elapsed.

11. It is a system, Memory containing executable instructions, A processor configured to execute the aforementioned executable instruction, wherein the executable instruction is configured to the system A request is received that asks to execute a transaction on the blockchain, the request includes a request that an amount of tokens on the blockchain be transferred from the sender wallet to the recipient wallet identified in the request, the tokens include a wrapped token that encapsulates the base tokens exchanged in the transaction on the blockchain, The amount of the token identified in the request is added to the sequential cumulative total of the tokens in the recoverable recipient wallet. After a threshold time period has elapsed from the timestamp associated with the received request, determine whether the transaction is frozen. Based on the determination that the aforementioned transaction has not been frozen, The sequential cumulative total of tokens in the recipient wallet that is in a recoverable state is subtracted by the amount of the tokens. A system comprising a processor that causes the sequential cumulative total of tokens in the recipient wallet, which is in an irrecoverable state, to be increased by the amount of the tokens.

12. The system according to claim 11, wherein the processor is further configured to cause the system to add the sequentially accumulated amount of tokens in the recipient wallet that are frozen by the amount of the tokens, based on the determination that the transaction has been frozen.

13. The processor in the system The system receives instructions from a defined governance source that the transaction should be canceled. The system according to claim 12, further configured to restore the amount of the tokens to the sender wallet based on the received instructions.

14. In order to restore the amount of the aforementioned token to the recipient wallet, the processor, in the system, Based on the timestamps associated with a series of transactions, identify the wallet chain containing the recipient wallet to which the tokens associated with the transaction were transferred, such that the total amount of tokens frozen across the wallet chain is equal to the amount of the tokens. The system according to claim 13, configured to transfer tokens from the wallet's chain to the sender wallet.

15. The system according to claim 11, wherein, in order to add the sequential cumulative amount of tokens in the recoverable recipient wallet, the processor is configured to cause the system to transfer the amount of tokens from the sender wallet to the recipient wallet to a portion of the recipient wallet in which the recoverable tokens are stored.

16. The system according to claim 15, wherein, in order to transfer the amount of the token, the processor is configured to cause the system to send the amount of the token from the irrecoverable token in the sender wallet.

17. In order to transfer the amount of the tokens, the processor is configured to cause the system to send a first amount of the tokens from the recoverable tokens in the sender wallet before sending a second amount of the tokens from the unrecoverable tokens. The sum of the first amount of the token and the second amount of the token is equal to the amount of the token. The system according to claim 15, wherein the first amount of the token is less than the amount of the token.

18. The system according to claim 15, wherein the policy associated with the recipient wallet identifies whether the amount of the tokens can be withdrawn from the portion of the sender wallet in which the tokens in a recoverable state are stored.

19. The system according to claim 11, wherein the processor is further configured to cause the system to determine a first amount of irrecoverable tokens in the sender wallet and a second amount of recoverable tokens in the sender wallet based on records stored on the blockchain, the second amount of recoverable tokens being identified based on transaction records on the blockchain relating to transactions in which the threshold time amount has not elapsed.

20. A computer-readable medium storing instructions, wherein the instructions, when executed by a processor, Receiving a request to execute a transaction on the blockchain, the request including a request to transfer an amount of tokens on the blockchain from a sender wallet to a recipient wallet identified in the request, the tokens including a wrapped token that encapsulates the base tokens exchanged in the transaction on the blockchain, The amount of the token identified in the request is added to the sequential cumulative total of tokens in the recipient wallet that are in a recoverable state, Determining whether the transaction is frozen after a threshold time period based on the timestamp associated with the received request, Based on the determination that the aforementioned transaction is not frozen, Subtracting the amount of the tokens from the sequentially cumulative total of the tokens in the recipient wallet that are in a recoverable state, A computer-readable medium that performs an operation including adding the sequential cumulative sum of tokens in the recipient wallet, which are in an irrecoverable state, to the aforementioned amount of tokens.

Images