WEB3 transport protocol

Abstract

Methods, systems, and devices for data management are described. A self-executing program of a blockchain distributed data repository may receive a first message including an indication of a sender address and a first number of first encrypted token types to be received by a recipient address. The self-executing program may verify that the first message is effectively signed by an operator associated with the self-executing program based at least in part on execution of the self-executing program. The operator may be associated with a hosted token platform that verifies information and signs messages. Upon verifying that the first message has been signed effectively, the self-executing program may broadcast one or more second messages configured to transfer a first number of the first encrypted token type to the recipient address.

Description

[0001] Cross-referencing This patent application claims priority to U.S. Patent Application No. 18 / 122,647, filed March 16, 2023, entitled “WEB3 TRANSFER PROTOCOL”, which has been assigned to the assignee of this application and is expressly incorporated herein by reference. Technical Field

[0002] This disclosure generally relates to data management, including Web3 transport protocol technology. Background Technology

[0003] Blockchain and related technologies can be used to support the recording of digital asset ownership, such as crypto tokens, fungible tokens, and non-fungible tokens (NFTs). Typically, peer-to-peer networks support transaction verification on the blockchain and record the transfer of such digital assets. Peer-to-peer networks can implement various types of consensus mechanisms to confirm transactions and add transaction blocks to the blockchain network. Example consensus mechanisms include Proof-of-Work and Proof-of-Stake implemented by the Ethereum network. Some nodes in the blockchain network may be associated with digital asset exchanges, allowing users to access these exchanges to trade digital assets or exchange them for fiat currency. Attached Figure Description

[0004] Figure 1 Examples of computing environments supporting the Web3 transport protocol are shown in accordance with various aspects of this disclosure.

[0005] Figure 2 Examples of computing environments supporting the Web3 transport protocol are shown in accordance with various aspects of this disclosure.

[0006] Figure 3 An example of a schematic diagram of a transport protocol supporting the Web3 transport protocol according to various aspects of this disclosure is shown.

[0007] Figure 4 An example of a process flow supporting the Web3 transport protocol is shown in accordance with various aspects of this disclosure.

[0008] Figure 5 A block diagram of an apparatus supporting the Web3 transport protocol according to various aspects of this disclosure is shown.

[0009] Figure 6 A block diagram of a transfer intention manager supporting the Web3 transport protocol is shown, according to various aspects of this disclosure.

[0010] Figure 7A schematic diagram of a system including a device supporting the Web3 transport protocol is shown, according to various aspects of this disclosure.

[0011] Figure 8 A block diagram of an apparatus supporting the Web3 transport protocol according to various aspects of this disclosure is shown.

[0012] Figure 9 A block diagram of a program execution component supporting the Web3 transport protocol is shown, according to various aspects of this disclosure.

[0013] Figure 10 A schematic diagram of a system including a device supporting the Web3 transport protocol is shown, according to various aspects of this disclosure.

[0014] Figures 11 to 16 A flowchart illustrating a method for supporting the Web3 transport protocol according to various aspects of this disclosure is shown. Detailed Implementation

[0015] Blockchain networks can execute smart contracts (referred to as "self-executing programs" in this paper) to support different types of functionality, such as decentralized financial services, token minting, and token swapping. In some examples, smart contracts can utilize oracles to identify off-chain data to enable programmatic behavior. For instance, a smart contract can determine whether external data meets conditions specified in the contract, and once the external data meets those conditions, the smart contract can execute a token transfer. However, in some examples, relying on oracles to obtain off-chain data is inefficient in terms of computation and transactions (e.g., in terms of blockchain network fees).

[0016] The technology described in this paper enables smart contract settlement and transfer in a high-speed and low-transaction-cost manner, supporting both off-chain data components and programmatic control of smart contracts without the need for or with limited use of smart contract oracle calls. More specifically, the technology described in this paper enables the transfer of crypto tokens from a sender to a smart contract, and then to a merchant or receiver, where the merchant can specify the type (and quantity) of crypto tokens to receive. Furthermore, the sender can send one or more different types of crypto tokens, and the smart contract (in conjunction with a custodial token platform) can handle verification and token exchange on-chain so that the merchant receives the required tokens and quantities.

[0017] To support these technologies, client applications (such as wallet applications) can be configured to generate transfer requests and send them to a custodian token platform. The custodian token platform can verify all aspects of the request and sign a message containing the sender's address, the recipient's address, and an indication of a first quantity of a first crypto token type, where the first quantity and the first crypto token type are specified by the recipient or merchant. The signed message can then be communicated to the client, which can broadcast the message to the blockchain network. The broadcast message may result in the receipt of the signed message at a smart contract. The smart contract verifies the custodian token platform's signature and causes one or more tokens belonging to the client application to be transferred to the recipient's address via a blockchain distributed data repository. In some examples, the crypto tokens sent by the sender's wallet differ from those received by the recipient's wallet. The smart contract can broadcast one or more messages that cause the sender's crypto tokens to be exchanged for the recipient's or target tokens. For example, the smart contract can invoke a decentralized exchange contract, an unpacking / packing contract, etc., to exchange tokens. After the exchange is complete, the smart contract can broadcast one or more messages that cause the target tokens to be transferred to the recipient's address. Custodial token platforms can verify whether a transfer has occurred by monitoring blockchain transactions associated with smart contracts and recipient addresses.

[0018] Using these technologies, escrow token platforms can verify data (e.g., the sender's token and its quantity, and the recipient's target token) and provide this data to smart contracts, which in turn facilitate the transfer of the target token to the recipient. Therefore, when a merchant wishes to accept one or more token types, and the sender or buyer possesses one or more different token types, the escrow token platform and smart contracts can support the merchant's transaction settlement. Furthermore, the technologies described herein help improve the user experience for both the sender and the recipient. These and other technologies will be described in more detail with reference to the accompanying figures.

[0019] Figure 1 An example of a computing environment 100 supporting the Web3 transport protocol according to various aspects of this disclosure is shown. The computing environment 100 may include a blockchain network 105 supporting a blockchain ledger 115, a custodial token platform 110, and one or more computing devices 140, which can communicate with each other via a network 135.

[0020] Network 135 may allow one or more computing devices 140, one or more nodes 145 of blockchain network 105, and custodial token platform 110 to communicate with each other (e.g., exchange information). Network 135 may include one or more wired networks (e.g., the Internet), one or more wireless networks (e.g., cellular networks), or any combination thereof. Network 135 may include aspects of one or more public or private networks, and secure or insecure networks, or any combination thereof. Network 135 may also include any number of communication links and any number of hubs, bridges, routers, switches, ports, or other physical or logical network components.

[0021] Node 145 of blockchain network 105 can generate, store, process, verify, or otherwise use data from blockchain ledger 115. Node 145 of blockchain network 105 can represent a computing system or device that implements or executes a blockchain application or program for peer-to-peer transactions and program execution, or serve as an example of such a computing system or device. For example, node 145 of blockchain network 105 supports the recording of ownership of digital assets (such as crypto tokens, fungible tokens, non-fungible tokens (NFTs), etc.) and changes in ownership of these digital assets. Digital assets can be referred to as tokens, coins, crypto tokens, etc. Node 145 can implement one or more types of consensus mechanisms to confirm transactions and add blocks of transactions (or other data) (e.g., blocks 120a, 120b, 120c, etc.) to blockchain ledger 115. Example consensus mechanisms include proof-of-work consensus mechanisms and proof-of-stake consensus mechanisms implemented by the Ethereum network.

[0022] When a device associated with blockchain network 105 (e.g., computing devices 140-a, 140-b, or 140-c) executes or completes a transaction associated with a token supported by the blockchain ledger, node 145 of blockchain network 105 can execute a transfer instruction that broadcasts the transaction (e.g., the data associated with the transaction) to other nodes 145 of blockchain network 105. These nodes can then execute blockchain applications to verify the transaction and, after verification, add the transaction to a new block (e.g., block 120-d) of the blockchain ledger (e.g., blockchain ledger 115). Using the implemented consensus mechanism, each node 145 c can play a role in supporting the maintenance of an accurate blockchain ledger 115 and preventing fraudulent transactions.

[0023] Blockchain ledger 115 may include a record of each transaction (e.g., transaction 125) between wallets (e.g., wallet addresses) associated with blockchain network 105. Some blockchains may support smart contracts, such as smart contract 130, which can be an example of a subroutine deployed to the blockchain and executed when one or more conditions defined in smart contract 130 are met. For example, after another device invokes a method or instruction defined in smart contract 130, node 145 of blockchain network 105 may execute one or more instructions of smart contract 130. In some examples, blockchain ledger 115 is referred to as a blockchain distributed data repository.

[0024] Computing device 140 can be used to input or receive information to or from computing system escrow token platform 110, blockchain network 105, or both. For example, a user of computing device 140-a can provide user input via computing device 145-a, which may result in commands, data, or any combination thereof being transmitted via network 135 to computing system escrow token platform 110, blockchain network 105, or both. Additionally or alternatively, computing device 140-a can output (e.g., display) data or other information received from escrow token platform 110, blockchain network 105, or both. For example, a user of computing device 140-a can use computing device 140-a to interact with one or more user interfaces (e.g., graphical user interface (GUI)) to operate or otherwise interact with escrow token platform 110, blockchain network 105, or both.

[0025] Computing device 140 and / or node 145 can be fixed devices (e.g., desktop computers or access points) or mobile devices (e.g., laptops, tablets, or mobile phones). In some examples, computing device 140 and / or node 145 can be commercial computing devices, such as servers or server clusters. And in some examples, computing device 140 and / or node 145 can be virtual devices (e.g., virtual machines).

[0026] Some blockchain protocols support both Layer 1 and Layer 2 crypto tokens. Layer 1 tokens are tokens backed by their own blockchain protocol, meaning they (or their derivatives) can be used to pay transaction fees for transactions conducted using the blockchain protocol. Layer 2 tokens are tokens built on top of Layer 1, for example, using smart contracts or decentralized applications (DApps). Smart contracts or DApps can issue Layer 2 tokens to various users under various conditions, and users can use these Layer 2 tokens to conduct transactions, but transaction fees may be based on Layer 1 tokens (or their derivatives).

[0027] Custodial token platform 110 can support users of custodial token platform 110 in exchanging or trading digital assets, fiat currencies, or both. Custodial token platform 110 can be accessed through a website, a web application, or an application installed on one or more computing devices 140. Custodial token platform 110 can be configured to interact with one or more types of blockchain networks (e.g., blockchain network 105) to support the purchase, exchange, deposit, and withdrawal of digital assets.

[0028] For example, a user can create an account associated with the custodial token platform 110, enabling the purchase, sale, exchange, or trading of digital assets using fiat currency. The key management service of the custodial token platform 110 (e.g., a key manager) can create, manage, or otherwise use private keys associated with user wallets and internal wallets. For example, if a user wishes to withdraw tokens associated with their account to an external wallet address, the key manager 180 can sign transactions associated with the user's wallet and broadcast the signed transactions to node 145 of the blockchain network 105, as described herein. In some examples, users do not have direct access to the private keys associated with wallets or accounts supported or managed by the custodial token platform 110. Therefore, a user wallet of the custodial token platform 110 may be referred to as a non-custodial wallet or a non-custodial address.

[0029] The custodial token platform 110 can create, manage, delete, or otherwise use various types of wallets to support digital asset exchange. For example, the custodial token platform 110 can maintain one or more internal cold wallets 150. Internal cold wallets 150 can be examples of offline wallets, meaning that cold wallets 150 are not directly coupled to other computing systems or networks 135 (e.g., always uncoupled). The custodial token platform 110 can use cold wallets 150 to ensure that the custodial token platform 110 is secure and will not lose assets due to hacking or other types of unauthorized access, and to ensure that the custodial token platform 110 has sufficient assets to cover any potential liabilities. One or more cold wallets 150, as well as other wallets on the blockchain network 105, can be implemented using public-key cryptography, such that cold wallets 150 are associated with public key 155 and private key 160. Public key 155 can be used for public transactions through cold wallets 150, meaning that another wallet can input public key 155 into a transaction to move assets from that wallet to cold wallet 150. Private key 160 can be used to verify transactions transferred from cold wallet 150 (e.g., to digitally sign transactions transferred from cold wallet 150), and node 145 can use the digital signature to verify or authenticate transactions. Other wallets on the custodian token platform 110 and / or blockchain network 105 can also similarly utilize various aspects of public-key cryptography.

[0030] The custodial token platform 110 can also create, manage, delete, or otherwise use inbound wallets 165 and outbound wallets 170. For example, the wallet manager 175 of the custodial token platform 110 can create a new inbound wallet 165 for each user or account of the custodial token platform 110, or for each inbound transaction of the custodial token platform 110 (e.g., a deposit transaction). In some examples, the custodial token platform 110 can implement technologies for moving digital assets between wallets on a digital asset trading platform. Assets can be moved based on schedules, asset thresholds, liquidity requirements, or a combination thereof. In some examples, asset movements or exchanges within the custodial token platform 110 can be “off-chain,” meaning that transactions associated with digital asset movements are not broadcast via the corresponding blockchain network (e.g., blockchain network 105). In this case, the custodial token platform 110 can maintain internal accounting (e.g., a ledger) of assets associated with various wallets and / or user accounts.

[0031] As described herein, wallets (e.g., inbound wallet 165 and outbound wallet 170) can be associated with wallet addresses, which can be examples of public keys, as described herein. Wallets can also be associated with private keys used to sign transactions and messages related to the wallet. Wallets can also be associated with various user interface components and functions. For example, some wallets may be associated with or utilize functions for transferring cryptographic tokens by allowing users to enter transaction amounts, recipient addresses, etc., in the user interface, and then click or activate a UI component so that the transaction is broadcast on the corresponding blockchain network via a node associated with the wallet (e.g., node 145). As used herein, "wallet" and "address" are used interchangeably.

[0032] In some cases, the custodian token platform 110 can implement a transaction manager 185 that supports monitoring one or more blockchains (e.g., blockchain ledger 115) to monitor incoming transactions associated with addresses managed by the custodian token platform 110 and to create and broadcast transactions on the blockchain when a user or client sends digital assets (e.g., withdraws). For example, the transaction manager 185 can monitor the recipient of a client to transfer Level 1 or Level 2 tokens supported by the blockchain ledger 115 to an address managed by the custodian token platform 110. As another example, when a user is withdrawing digital assets (e.g., Level 1 or Level 2 tokens) to an external wallet (e.g., an address not managed by the custodian token platform 110 or an address whose associated private key is inaccessible to the custodian token platform 110), the transaction manager 185 can create transactions based on blockchain applications associated with the blockchain network 105 and broadcast the transactions to one or more other nodes 145 of the blockchain network 105. Therefore, the transaction manager 185 or related components of the custodian token platform 110 can act as nodes 145 of the blockchain network 105.

[0033] As described in this article, the custodial token platform can implement and support various wallets, including inbound wallet 165, outbound wallet 170, and cold wallet 150. Furthermore, the custodial token platform 110 can implement technologies for maintaining and managing the balances of these various wallets. In some examples, the balances of the various wallets are configured to support both security and liquidity. For instance, the custodial token platform 110 can implement transactions that move cryptocurrencies between inbound wallet 165 and outbound wallet 170. These transactions can be referred to as "refresh" transactions and can be performed on a regular or scheduled basis.

[0034] As described herein, various transactions can be broadcast to the blockchain ledger 115 to trigger the transfer of crypto tokens, invoke smart contracts, deploy smart contracts, and so on. In some examples, these transactions may also be referred to as messages. That is, the custodian token platform 110 can broadcast messages to the blockchain network 105 to transfer tokens between wallets managed by the custodian token platform 110, thereby transferring tokens from wallets managed by the custodian token platform 110 to external wallets, deploying smart contracts (e.g., self-executing programs), or invoking smart contracts.

[0035] The escrow token platform 110 can also support an on-chain processing engine that supports Web3 transactions. For example, the escrow token platform 110 (which can act as the operator described herein) can pass detailed information about transfers (e.g., payments, transactions) to an on-chain smart contract (e.g., smart contract 130), and the smart contract can reason (e.g., programmatically) about the details of the payment to process it correctly. Using the technology described herein, the escrow token platform 110 and the smart contract can support the transfer of the correct amount of funds to the merchant in the settlement currency or token specified by the merchant, thereby eliminating the merchant's cryptocurrency volatility risk. For example, a buyer's or sender's wallet may contain highly volatile cryptocurrencies, which the merchant may not want to accept. The technology described herein enables seamless exchange of tokens for the settlement tokens required by the merchant. Furthermore, the technology described herein supports rejecting overpayments / underpayments to eliminate payment anomalies.

[0036] The smart contract can receive payment details (e.g., from a client application on one of the computing devices 140) and execute a set of instructions to exchange funds from the payer's currency (e.g., a token type) to the merchant's settlement currency (e.g., a token type) to obtain the correct amount, control which assets are acceptable, and reject payments that do not meet the smart contract's requirements.

[0037] A message containing payment details can be called a transfer intent (e.g., TransferIntent) because it contains a set of conditions or restrictions for the payment / operation to succeed within the contract. The message may contain information instructing the smart contract on the actions to be taken upon success (delivery to the merchant) or failure (refund to the payer). The message may contain a signature from the operator (e.g., the escrow token platform 110) to facilitate payment security for contract users (e.g., the merchant). The message may also contain metadata used as a reference to off-chain data (e.g., stored by the operator that generated the TransferIntent or some other requester).

[0038] TransferIntent messages can include off-chain generated input data that can be used to modify the behavior of contract execution and provide verified attributes of off-chain metadata for smart contract calls. TransferIntent messages can also provide verifiable off-chain control to prevent the use of smart contracts without on-chain contract data or costly oracle calls. In some cases, TransferIntent messages can be used as deposit messages for consumer custodial wallet use cases or transaction messages for consumer decentralized exchange (DEX) transactions. Therefore, the technology described in this paper supports verifiable Web2 generated input for Web3 execution models of smart contracts.

[0039] Figure 2 An example of a computing environment 200 supporting the Web3 transport protocol according to various aspects of this disclosure is shown. The computing environment 200 can implement... Figure 1 The computing environment 100 includes various aspects. For example, the computing environment 200 includes a custodial token platform 210, which may be... Figure 1 An example of a centrally managed token platform 110. The computing environment 200 also includes a blockchain network 275, which can be... Figure 1 An example of blockchain network 105 is provided. Blockchain network 275 can support smart contracts, as described herein. Therefore, blockchain network 275 can represent multiple computing nodes supporting a blockchain distributed data repository. To support the blockchain distributed data repository, the blockchain network can run virtual machines (e.g., the Ethereum Virtual Machine (EVM)) to execute smart contracts, transactions, etc.

[0040] Users can access user device 240 (e.g., Figure 1 The user device 205 (computing device 140) can access one or more client applications, such as wallet 215 and user interface (UI) client 220, which can be configured to interact with custodial token platform 210 and / or blockchain network 275. In some examples, wallet 215 is a custodial wallet so that the user can maintain and access the private key of wallet 215. Wallet 215 can be an example of a browser wallet, hardware wallet, application wallet, or a combination thereof. The user can use the browser or application of user device 240 to navigate to a Web3 interface or service associated with a merchant, and the user may wish to pay the merchant for products or services using cryptographic tokens owned by wallet 215 via a blockchain distributed data repository. However, the merchant may possess a required settlement token (target token) that is not in the user's wallet 215. Therefore, instead of navigating to another exchange or redemption service to exchange the tokens owned by the user 205 for the target token, the technology described herein enables payments to the merchant using tokens owned by the user 205 (e.g., owned by wallet 215).

[0041] To support such transfers, UI client 220 can be configured to communicate with a custodian token platform (e.g., an operator associated with self-executing program 230) to retrieve a transfer intention message and enable wallet 215 to transmit the transfer intention message to blockchain network 275, thereby enabling the transfer of funds. For example, user 205 can navigate to a merchant or recipient service (e.g., a merchant's website or a website associated with custodian token platform 210) via user device 240. The user can indicate an intention to pay a merchant for a service or product via their user device. In response to this indication, UI client 220 of user device 240 can retrieve information related to wallet 215, such as the wallet address, the crypto token associated with wallet 215, and information associated with the intended transaction, such as the recipient address, the target token type, and the amount to be received at the recipient address. UI client 220 can send a transfer intention request 280 to custodian token platform 210. For example, UI client 220 can send an object containing the retrieved wallet information to an application programming interface (API) endpoint associated with custodian token platform. In some examples, a merchant's website or service can be configured (e.g., via UI client 220) to interact with the escrow token platform 210 to support the technologies described herein. That is, a merchant's website (or other website offering merchant goods or services) can be configured to process transactions using UI client 220 and escrow token platform 210.

[0042] In response to receiving a transfer intention request 280, the escrow token platform 210 can perform various verifications. For example, the escrow token platform 210 can verify that the sender address is not on a blacklist and / or that the recipient address has been authenticated by the escrow token platform 210. Furthermore, the escrow token platform 210 can verify that the user has sufficient funds to pay for the transaction. That is, the escrow token platform 210 can identify the crypto tokens associated with the wallet address of wallet 215 and the quantity of crypto tokens associated with that wallet address. In some examples, this information is transmitted to the escrow token platform by the UI client 220 via the transfer intention request 280. Additionally or alternatively, this information can be retrieved from a blockchain distributed data repository. In other words, the escrow token platform 210 can use public transaction / blockchain information to determine the quantity of crypto tokens belonging to the wallet address of wallet 215.

[0043] In some examples, the escrow token platform 210 and / or UI client 220 can recommend one or more transfer types. That is, based on the crypto tokens associated with the wallet address belonging to wallet 215, the escrow token platform and / or UI client 220 can identify the transfer type. For example, if a user holds native tokens in wallet 215, the escrow token platform 210 can recommend using those native tokens for the transfer. In other examples, if the escrow token platform has two different types of native tokens (e.g., associated with two different blockchain networks), the escrow token platform 210 and / or UI client 220 can recommend transferring one type of native token instead of the other. Additionally or alternatively, the escrow token platform 210 can recommend exchanging crypto tokens (for the target token) instead of exchanging native tokens. In some cases, the UI client 220 can display a ranking of recommended transfer options to the user, who can then select one. In response to the selection, a request message (e.g., transfer intention request 280) can be transmitted to the escrow token platform 210.

[0044] After verifying such information and / or selecting a transfer option, the escrow token platform 210 can generate a message (e.g., transferIntent) containing information that will be used by the self-executing program 230 to perform the transfer. The escrow token platform 210 can sign the generated message using a key associated with the self-executing program 230 to generate a signed transferIntent message 285. This key can be retrieved from a key service 255 managed by the escrow token platform, and can be an example of an operator key. The signed transferIntent message 285 can be returned to the UI client 220, and the UI client can cause the wallet 215 to broadcast a message that causes the signed message to be received by the self-executing program 230.

[0045] The signed message may include information allowing the self-executing program 230 to perform operations to transfer the required token (e.g., the target token) and the required amount to the recipient address 295. The signed transferIntent message 285 can be passed to the self-executing program 230 as a struct calldata parameter and may include various characteristics corresponding to the information. For example, the transferIntent message may include the recipient amount, deadline, sender address, recipient address, recipient currency, refund address, fee amount, identifier, operator, signature, or a combination thereof. The recipient amount may be the amount of currency required for payment, such as 100 USDC. The deadline may correspond to the time when the payment is included in a block, which may prevent the payment from being confirmed after remaining in the mempool for an extended period. The deadline may be a time value representing a timestamp (e.g., hh:mm:ss), but may alternatively represent the block number or block height. The recipient currency is the address of the currency used to price the fee. If the transferIntent message indicates the native currency (e.g., ETH on the Ethereum blockchain or MATIC on Polygon), the recipient currency field can be set to address(0). The refund address can correspond to an address used to return any funds. This address can be used by exchanges that pool funds to provide a refund address for a single user. The refund address can be used for payment reversals but cannot be used to refund any excess portion of a DEX swap transaction (see details in this document). Instead, any excess portion can be returned to the message sender, such as a wallet address associated with wallet 215.

[0046] The fee amount can be the amount sent to an operator (e.g., escrow token platform 210). For example, after the transfer is complete, self-executing procedure 230 can transfer fee 290 to the operator's fee wallet 260. The fee can be paid in the recipient's currency. The fee amount can be included in the transfer intention message, rather than on-chain (e.g., in self-executing procedure 230), to provide greater flexibility. For example, some merchants may negotiate special fees or promotional fees. The identifier included in the transfer intention message can be an example of metadata corresponding to the fee (e.g., an agreement between the payer and the merchant / recipient). Thus, the metadata or identifier can reference off-chain fees associated with the sender's address and the recipient's address. This identifier can be used to track payment progress. In some examples, the identifier is the same size as a UUIDv4, and escrow token platform 210 can store this identifier for payment tracking. The operator is the address of the operator that signed the payload (e.g., the address of escrow token platform 210). The signature is used to prevent tampering with the transfer intent and is calculated as follows: eth_sign(keccak_256(abi.encode(all,other,props)). The operator address should match the address recovered from the signature, as described in further detail in this document.

[0047] Self-executing program 230 is deployed to blockchain network 275 and can be configured to perform functions to facilitate the transfer of cryptographic tokens from wallet 215 to recipient address 295 based on information contained in transferIntent message 285. As described herein, transferIntent message 285 may include information used by self-executing program 230 to facilitate such transfers. For example, if the tokens belonging to wallet 215 and the target cryptographic tokens are different, self-executing program 230 may determine to exchange, redeem, pack, or unpack the cryptographic tokens belonging to the wallet to retrieve the desired cryptographic tokens. Therefore, self-executing program 230 can be configured with various functions to perform these actions, and these actions may depend on the type of token to be transferred from wallet 215 (e.g., the source token) and the type of token received by recipient address 295 (e.g., based on information contained in transferIntent message 285). The types of functions used to transfer the desired tokens to the recipient address can be determined based on the following Table 1: Table 1 In Table 1, the y-axis corresponds to the source token (e.g., the token to be transferred from wallet 215), and the x-axis corresponds to the target token (e.g., the token to be received at recipient address 295). Therefore, if the source token is a blockchain-native token (e.g., ETH on the Ethereum blockchain) and the target token is an ERC-20 token (e.g., a token minted by a smart contract on the Ethereum blockchain), then self-executing program 230 can determine to exchange the source token for the target token. In this case, self-executing program 230 can execute one or more functions (e.g., swapAndTransfer) to make smart contract calls to different smart contracts associated with the DEX (e.g., self-executing program 245) to exchange the source token for the target token and return the target token to recipient address 295. When the source token is a native token and the target token is wrapped (e.g., wrapped ETH or WETH), the self-executing program 230 can execute a function (e.g., wrapAndTransfer) to call the self-executing program 235 to wrap the source token to generate the target token, which is returned to the recipient address 295. If the source token and the target token are the same, the self-executing program 230 can execute the transfer function to transfer the token to the recipient address 295. If the source token is a wrapped token and the target token is a native token, the self-executing program 230 can execute the unwrapAndTransfer function to call the self-executing program 235 to unwrap the source token to generate the target token, which is returned to the recipient address 295.

[0048] In some cases, these functions may differ from those shown in Table 1. For example, different functions can be used to increase granularity. These different functions may include functions for transferring native tokens (e.g., `transferNative(transferNative)`), functions for transferring ERC20 tokens without swapping (e.g., `transferToken(transferToken)`), functions for wrapping native tokens and transferring them (e.g., `wrapAndTransfer(wrapAndTransfer)`), and functions for unwrapping native tokens before transferring them (e.g., `unwrapAndTransfer(unwrapAndTransfer)`). These functions may also include functions for swapping ERC20 tokens (e.g., other types of DApp tokens) for native tokens before transferring them (e.g., `swapAndTansferUniswapV3Native`). This function can be used to call a self-executing program 245 (e.g., a DEX) to perform the token swap. These functions may also include functions for swapping ERC20 tokens for different ERC20 tokens and transferring them (e.g., `swapAndTansferUniswapV3Token`). Other function types and combinations are also envisioned within the scope of this disclosure.

[0049] Therefore, the self-executing procedure 230 is configured to obtain funds from the sender and distribute the funds to the recipient by generating one or more messages in response to receiving the transferIntent message 285. Furthermore, the self-executing procedure 230 can also be responsible for fee capture, preventing payment anomalies, and issuing events for off-chain reconciliation. The self-executing procedure 230 may not hold any funds on behalf of the user and can collect fees based on the signed transferIntent message 285, returning those fees to the operator, which in the illustrated example is the escrow token platform 210. Therefore, the operator can collect fees based on those transferIntent messages signed by the operator.

[0050] The custodial token platform 210 may maintain various services to support the technologies described herein. A transfer service 265 (also known as an exchange service) may be used to interact with a DEX aggregator service to generate quotes (e.g., based on exchange rates or conversion ratios) and identify tokens that can be used to support payments. For example, upon receiving a token instruction at an address belonging to wallet 215, the transfer service 265 may refer to the DEX aggregator to determine: (1) whether the source token can be exchanged for the target token and transferred to the recipient address 295; and (2) whether the wallet address has sufficient source tokens to pay the target funds. In this case, the DEX aggregator may provide one or more exchange rates (e.g., conversion ratios) between the source and target tokens to determine whether the wallet has sufficient funds. Furthermore, as described herein, the custodial token platform 210 may include a key service 255 for managing user keys and / or platform keys that can be used to sign transferIntents as an operator.

[0051] The custodial token platform 210 can also maintain one or more management wallets 250, which can be used to deploy and run smart contracts, such as self-executing programs 230. For example, management wallets 250 can be used to activate and / or suspend self-executing programs 230, assign administrative permissions to self-executing programs 230 to other wallets, etc. These functions can be performed using control messages 292 transmitted from management wallets 250 to self-executing programs 230. The custodial token platform 210 can also use an event consumer service 270 to monitor transaction data on the blockchain. For example, event consumer service 270 can determine when a transfer corresponding to a signed transferIntent message is completed. Event consumer service 270 can maintain an internal data repository of pending transactions, completed transactions, and / or failed transactions. Furthermore, event consumer service 270 can use identifiers (e.g., metadata) included in the transfer intent to monitor and log transactions occurring via self-executing programs 230.

[0052] Therefore, the technology described herein supports decentralized payment settlement, which uses relevant and credible information provided by the operator to settle payments. That is, the self-executing procedure 230 can rely on and verify information provided by the operator, and the self-executing procedure 230 can contain instructions to process and settle transfers based on the information provided by the operator.

[0053] Figure 3An example of a schematic diagram 300 supporting a Web3 transport protocol according to various aspects of this disclosure is shown. The schematic diagram 300 of the transport flow includes a user 305 having a user device 340, which may be an example of a user device described herein. The user 305 can navigate to web pages, service pages, product pages, or applications associated with a merchant 325, as described herein. The user 305 can add a product or service to a shopping cart, for example, a product or service (hereinafter referred to as the "goods") priced at $100.

[0054] Box 310 shows example crypto tokens that a user can use to pay a merchant. Crypto tokens can be native tokens of one or more blockchains, Layer 2 tokens, non-native tokens (e.g., tokens supported by DApps or contracts), non-fungible tokens, etc. User 305 can choose the token to use for transferring funds to merchant 325. In some examples, user 305 selects one or more transfer options from a list of recommended transfer options displayed on the user interface of user device 340. The transfer request is sent to operator 330, and a transfer intention message is returned to the client application of user device 340. The user can then use the user interface to select or approve the transfer, and the transfer intention message is sent to a smart contract (e.g., ...). Figure 2 (Self-executing procedure 230 in the example). In the example shown, the smart contract uses DEX 315 (or a redemption service) to redeem the token for the preferred token of merchant 325. DEX 315 outputs token 320, and a portion of the funds is settled to merchant 325. Fees may be transferred to operator 330.

[0055] Figure 4 An example of a process flow 400 supporting the Web3 transport protocol according to various aspects of this disclosure is shown. Process flow 400 includes a user device 405 having a client application 410, a receiver address 415, a self-executing program 420, and an operator 425, which may be... Figures 1 to 3 Examples of the corresponding devices and systems described herein. For example, client application 410 may be an example of a wallet application as described herein. Operator 425 may be an example of a custodial token platform as described herein or associated with a custodial token platform as described herein. Alternatively, operator 425 may be associated with other devices or systems. In the following description of process flow 400, operations between devices and systems in process flow 400 may be transmitted in a different order than the order shown in the examples, or the operations may be performed in a different order or at different times. Certain operations may also be omitted in process flow 400, and other operations may be added to process flow 400.

[0056] At 430, user equipment 405 can receive (e.g., via a user interface and / or client application 410) user input to transfer funds to a recipient (e.g., at recipient address 415). For example, a user can navigate to a website, service, DApp, etc., and select a UI component to make a payment to the recipient for a product or service. At 435, client application 410 can determine recipient information, such as recipient address 415, recipient token (e.g., target token), payment amount, etc.

[0057] At 440, client application 410 of user equipment 405 may send a request to transfer a first quantity of a first cryptographic token type from a sender address (e.g., associated with client application 410) to a receiver address, and operator 425 may receive the request to transfer the first quantity of the first cryptographic token type from the sender address (e.g., associated with client application 410) to the receiver address. The request may include an indication of a return address, receiver amount, receiver token, or other information. In some examples, the first message includes a second quantity of a second cryptographic token type (e.g., a source token) to be sent by a sender address (e.g., the address sending the second cryptographic token). The sender address may be a sender address (e.g., the address sending the second cryptographic token).

[0058] At point 445, operator 425 can verify the sender address using off-chain data and a second quantity of the second crypto token type associated with the sender address via a blockchain distributed data repository. For example, the sender address can be checked against a blacklisted address or a list of blocked addresses (e.g., sanctioned addresses). The blacklisted address list can be maintained by operator 425, by an external service, or by both. Verification of the second quantity may include retrieving the conversion ratio between the second crypto token type and the first crypto token type. The conversion ratio (e.g., exchange rate) can be maintained by operator 425 based on transaction data at operator 425, and / or can be retrieved from an external data source (e.g., a DEX service, a DEX aggregator, etc.). Operator 425 can also use the conversion ratio to determine that a transfer of the second quantity of the second crypto token type will result in at least a transfer of the first quantity of the second crypto token type. That is, operator 425 can determine whether the sender's wallet has sufficient funds (based on the conversion ratio) to pay the recipient's amount. In some examples, operator 425 can determine whether the token supports the transfer (e.g., whether the token is on a rejection list). Therefore, operator 425 can reject a transfer request based on whether the sender address has sufficient funds or whether the funds correspond to one or more token types.

[0059] At point 450, through a blockchain-based distributed data repository, operator 425 can send an instruction for at least one recommended transfer type and / or client application 410 can display an instruction for at least one recommended transfer type, which is at least partially based on a second quantity of one or more second cryptographic token types associated with the sender's address. Therefore, operator 425 or client application 410 can retrieve the second quantity from the blockchain and issue a payment recommendation to the user based on the second quantity. In some cases, native token payments may take precedence over non-native tokens or ERC-20 tokens, as described herein. Furthermore, or alternatively, low-volatility tokens may have a higher payment priority than high-volatility tokens.

[0060] At 455, operator 425 can receive instructions from client application 410 to select a transfer type from at least one recommended transfer type.

[0061] At point 460, operator 425 can use the public key associated with the operator to sign a message containing an indication of a first quantity of a first cryptographic token type, the sender's address, the receiver's address, and the first quantity. The signed message may be an example of a transfer intention. The signed message may also include a time value indicating the time when the message instructing the transfer of the first quantity to the receiver's address is included in a block on the blockchain's distributed data repository. Additionally or alternatively, the signed message may include metadata referencing off-chain fees associated with the sender's and receiver's addresses.

[0062] At point 465, operator 425 can transmit the signed message to client application 410.

[0063] At 470, client application 410 can display transaction information associated with the received signed message on user equipment 405. The transaction information may indicate the payment amount, recipient amount, corresponding token type, recipient address, return address, fees, etc. At 475, client application 410 can receive input to accept transaction information.

[0064] At 480, in response to receiving input, client application 410 may broadcast a first message, which self-executing program 420 (stored in a blockchain distributed data repository) may receive. This first message includes an indication of the sender address and a first quantity of a first type of cryptographic token to be received by the recipient address. The first message may contain a signed transfer intention message received from operator 425.

[0065] At 485, the self-executing program 420 may verify, at least in part, whether the first message was validly signed by an operator 425 (e.g., operator 425) associated with the self-executing program, based on the execution of the self-executing program 420 (e.g., in response to a received first message). The operator's instructions (e.g., a public key) may be encoded in or accessed by the self-executing program 420.

[0066] At 490, the self-executing program 420 may generate one or more second messages. For example, the self-executing program 420 may generate an exchange message configured to exchange a second quantity of a second cryptographic token type belonging to the sender's address in the blockchain's distributed data repository for a first quantity of a first cryptographic token type. Additionally or alternatively, the self-executing program 420 may generate this exchange message configured to invoke a second self-executing program associated with a decentralized exchange protocol. In this case, the second self-executing program exchanges the second quantity of the second cryptographic token type for the first quantity of the first cryptographic token type and returns the first quantity of the first cryptographic token type to the address associated with the self-executing program. The exchange message may include an indication of the first quantity of the first cryptographic token type, such that if the second quantity is insufficient, the transaction fails. Additionally or alternatively, the self-executing program 420 may generate a wrapping message configured to wrap or unwrap the second quantity of the second cryptographic token type to obtain the first quantity of the first cryptographic token type. Therefore, in response to receiving a message / transaction at 480, the self-executing procedure 420 can generate one or more messages / transactions to execute the transaction / message received at 480.

[0067] At address 495, the target token (e.g., a first cryptographic token type) is transferred to recipient address 415. For example, executor 420 broadcasts a transfer message configured to transfer a first quantity of the first cryptographic token type to the recipient address. In other cases, the target token may be transferred by the appropriate executor (e.g., a DEX or packaging service) in response to a redemption / packaging message.

[0068] At point 498, operator 425 can detect, via the blockchain distributed data repository, a message associated with the sender's address that transfers a first quantity of a first type of cryptographic token to the recipient's address. Operator 425 can execute an event consumer to monitor transaction settlement. For example, operator 425 can monitor the blockchain data store for the existence of transactions containing metadata corresponding to fees.

[0069] Figure 5A block diagram 500 of a system 505 supporting the Web3 transport protocol according to various aspects of this disclosure is shown. System 505 may include an input interface 510, an output interface 515, and a transfer intention manager 520. System 505 may also include a processor. Each of these components can communicate with each other (e.g., via one or more buses, communication links, communication interfaces, or any combination thereof).

[0070] Input interface 510 can manage input signaling of system 505. For example, input interface 510 can receive input signaling (e.g., messages, packets, data, instructions, commands, transactions, or any other form of encoded information) from other systems or devices. Input interface 510 can send signaling corresponding to (e.g., representing or otherwise based on) such input signaling to other components of system 505 for processing. For example, input interface 510 can transmit such corresponding signaling to transfer intention manager 520 to support the Web3 transport protocol. In some cases, input interface 510 can be a component of network interface 725, as referenced. Figure 7 As stated above.

[0071] Output interface 515 can manage the output signaling of system 505. For example, output interface 515 can receive signaling from other components of system 505 (e.g., transfer intention manager 520) and can transmit output signaling corresponding to that signaling (e.g., output signaling representing or otherwise based on that signaling) to other systems or devices. In some cases, output interface 515 may be as described in the reference. Figure 7 The components of the network interface 725 described.

[0072] For example, the transfer intention manager 520 may include a transfer intention interface 525, a signature verification component 530, a transfer message component 535, or any combination thereof. In some examples, the transfer intention manager 520 or its components may be configured to use or otherwise cooperate with the input interface 510, the output interface 515, or both to perform various operations (e.g., receiving, monitoring, transmitting). For example, the transfer intention manager 520 may receive information from the input interface 510, send information to the output interface 515, or integrate with the input interface 510, the output interface 515, or both to receive information, transmit information, or perform various other operations as described herein.

[0073] The transfer intention manager 520 may support data processing according to the examples disclosed herein. The transfer intention interface 525 may be configured or otherwise supported to receive a first message at a self-executing program stored in a blockchain distributed data repository, the first message including an indication of a sender address and a first quantity of a first cryptographic token type to be received by the recipient address. The signature verification component 530 may be configured or otherwise supported to verify, at least in part, that the first message has been validly signed by an operator associated with the self-executing program based on the execution of the program. The transfer message component 535 may be configured or otherwise supported to generate one or more second messages after verifying that the first message has been validly signed, these second messages being configured to transfer a first quantity of a first cryptographic token type to the recipient address.

[0074] Figure 6 A block diagram 600 is shown of a transfer intention manager 620 supporting the Web3 transport protocol according to various aspects of this disclosure. The transfer intention manager 620 may be an example of a transfer intention manager as described herein, or a transfer intention manager 520, or a combination thereof. The transfer intention manager 620 or its various components may be examples of devices for performing various aspects of the Web3 transport protocol as described herein. For example, the transfer intention manager 620 may include a transfer intention interface 625, a signature verification component 630, a transfer message component 635, an exchange component 640, a packaging component 645, a return component 650, or any combination thereof. Each of these components may communicate with each other (e.g., via one or more buses, communication links, communication interfaces, or any combination thereof).

[0075] The transfer intention manager 620 can support data processing according to examples disclosed herein. The transfer intention interface 625 can be configured or otherwise supported for receiving a first message at a self-executing program stored in a blockchain distributed data repository, the first message containing an indication of a sender address and a first quantity of a first cryptographic token type to be received by the recipient address. The signature verification component 630 can be configured or otherwise supported for verifying, at least in part, that the first message has been validly signed by an operator associated with the self-executing program based on the execution of the program. The transfer message component 635 can be configured or otherwise supported for generating one or more second messages after verification that the first message has been validly signed, these second messages being configured to transfer a first quantity of a first cryptographic token type to the recipient address.

[0076] In some examples, to support the generation of one or more second messages, the exchange component 640 may be configured or otherwise supported to generate an exchange message configured to exchange a second quantity of a second cryptographic token type belonging to a sender address in a blockchain distributed data repository for a first quantity of a first cryptographic token type. In some examples, to support the generation of one or more second messages, the transfer message component 635 may be configured or otherwise supported to generate a transfer message configured to transfer a first quantity of a first cryptographic token type to a receiver address.

[0077] In some examples, to support the generation of exchange messages, the exchange component 640 may be configured or otherwise supported to generate exchange messages that are configured to invoke a second self-executing program associated with a decentralized exchange protocol, wherein the second self-executing program exchanges a second quantity of a second cryptographic token type for a first quantity of a first cryptographic token type and returns the first quantity of the first cryptographic token type to an address associated with the self-executing program.

[0078] In some examples, to support the generation of exchange messages, the exchange component 640 may be configured or otherwise supported to support devices for generating exchange messages, which include an indication of a first quantity of a first cryptographic token type.

[0079] In some examples, to support the generation of one or more second messages, the packaging component 645 may be configured or otherwise supported for generating a packaged message configured to package or unpack a second quantity of a second cryptographic token type to obtain a first quantity of a first cryptographic token type. In some examples, to support the generation of one or more second messages, the transfer message component 635 may be configured or otherwise supported for generating a transfer message configured to transfer a first quantity of a first cryptographic token type to a recipient address.

[0080] In some examples, the return component 650 may be configured or otherwise support means for generating a third message configured to return a second quantity of a second cryptographic token type to the sender address, the second quantity being at least partially based on the conversion ratio between the first cryptographic token type and the second cryptographic token type.

[0081] In some examples, the first message and one or more second messages also include metadata referencing the off-chain fees associated with the sender's address and the receiver's address.

[0082] In some examples, the first message includes a time value indicating when the message instructing the transfer of the first amount to the recipient's address is included in a block on the blockchain's distributed data repository. In some examples, the self-executing program is configured to verify the time value before generating one or more second messages. In some examples, the first message includes the fee amount to be sent to the operator.

[0083] In some examples, the first message includes a second quantity of a second cryptographic token type to be sent by the sender address that sent the first message.

[0084] Figure 7 A schematic diagram of system 700, including system 705 supporting the Web3 transport protocol, is shown according to various aspects of this disclosure. System 705 may be an example of system 505 as described herein or may include components of system 505 as described herein. System 705 may include components supporting blockchain services and interactions, such as transfer intention manager 720, input information 710, output information 715, network interface 725, memory 730, processor 735, and storage device 740. Each of these components can communicate with each other (e.g., via one or more buses, communication links, communication interfaces, or any combination thereof).

[0085] Network interface 725 enables system 705 to exchange information (e.g., input information 710, output information 715, or both) with other systems or devices (not shown). For example, network interface 725 enables system 705 to connect to a network (e.g., network 135 as described herein). Network interface 725 may include one or more wireless network interfaces, one or more wired network interfaces, or any combination thereof.

[0086] Memory 730 may include RAM, ROM, or both. Memory 730 may store computer-readable, computer-executable software, including instructions that, when executed, cause processor 735 to perform various functions described herein, such as functions supporting the Web3 transport protocol. In some cases, memory 730 may contain a Basic Input / Output System (BIOS), which controls basic hardware or software operations, such as interaction with peripheral components or devices. In some cases, memory 730 may be as described in the reference... Figure 1 Examples of one or more components of the described custodial token platform 110.

[0087] Processor 735 may include intelligent hardware devices (e.g., general-purpose processors, DSPs, CPUs, microcontrollers, ASICs, field-programmable gate arrays (FPGAs), programmable logic devices, discrete gate or transistor logic components, discrete hardware components, or any combination thereof). Processor 735 may be configured to execute computer-readable instructions stored in memory 730 to perform various functions (e.g., functions or tasks supporting the Web3 transport protocol). Although Figure 7 The example depicts a single processor 735, but it should be understood that system 705 may include any number of one or more processors 735, and a group of processors 735 may collectively perform one or more functions attributed herein to a processor (e.g., processor 735).

[0088] Storage device 740 can be configured to store data generated, processed, stored, or otherwise used by system 705. In some cases, storage device 740 may include one or more HDDs, one or more SDDs, or both. In some examples, storage device 740 may be an example of a single database, a distributed database, multiple distributed databases, a data repository, a data lake, or an emergency backup database.

[0089] The transfer intention manager 720 can support data processing according to the examples disclosed herein. For example, the transfer intention manager 720 can be configured or otherwise supported to receive a first message at a self-executing program stored in a blockchain distributed data repository, the first message including an indication of a sender address and a first quantity of a first cryptographic token type to be received by a recipient address. The transfer intention manager 720 can be configured or otherwise supported to verify, at least in part, that the first message has been validly signed by an operator associated with the self-executing program based on the execution of the self-executing program. The transfer intention manager 720 can be configured or otherwise supported to generate one or more second messages after verification that the first message has been validly signed, the second messages being configured to transfer a first quantity of a first cryptographic token type to the recipient address.

[0090] By including or configuring the transfer intention manager 720 according to the examples described herein, system 705 can support techniques to reduce the processing load of blockchain nodes by reducing external data calls (e.g., via oracles), which incur significant processor and resource overhead.

[0091] Figure 8A block diagram 800 of a system 805 supporting the Web3 transport protocol according to various aspects of this disclosure is shown. System 805 may include an input interface 810, an output interface 815, and a program execution component 820. System 805 may also include a processor. Each of these components can communicate with each other (e.g., via one or more buses, communication links, communication interfaces, or any combination thereof).

[0092] Input interface 810 can manage the input signaling of system 805. For example, input interface 810 can receive input signaling (e.g., messages, data packets, data, instructions, commands, or any other form of encoded information) from other systems or devices. Input interface 810 can send signaling corresponding to (e.g., representing or otherwise based on) such input signaling to other components of system 805 for processing. Input interface 810 can send aspects of these input signals to other components of system 805 for processing. For example, input interface 810 can transmit such corresponding signaling to program execution component 820 to support the Web3 transport protocol. In some cases, input interface 810 can be as described in the reference... Figure 10 The components of the network interface 1010.

[0093] Output interface 815 can manage the output signaling of system 805. For example, output interface 815 can receive signaling from other components of system 805 (such as program execution component 820) and can transmit such output signaling corresponding to that signaling (e.g., such output signaling representing or otherwise based on that signaling) to other systems or devices. In some cases, input interface 810 may be as follows: Figure 10 The components of network interface 1010 shown.

[0094] Program execution component 820 may include a transfer intent request interface 825, a sender verification component 830, a message signature component 835, a message interface 840, a transfer verification component 845, or any combination thereof. In some examples, program execution component 820 or its components may be configured to use input interface 810, output interface 815, or both, or otherwise cooperate with input interface 810, output interface 815, or both to perform various operations (e.g., receiving, monitoring, transmitting). For example, program execution component 820 may receive information from input interface 810, send information to output interface 815, or integrate with input interface 810, output interface 815, or both to receive information, transmit information, or perform various other operations as described herein.

[0095] Program execution component 820 may support data processing according to examples disclosed herein. Transfer intention request interface 825 may be configured or otherwise supported for receiving, at the operator's location, a request from a client application to transfer a first quantity of a first cryptographic token type from a sender address to a receiver address. Sender verification component 830 may be configured or otherwise supported for verifying a sender address via a blockchain distributed data repository using off-chain data and a second quantity of a second cryptographic token type associated with the sender address. Message signing component 835 may be configured or otherwise supported for signing a message containing a sender address, a receiver address, and a first quantity of the first cryptographic token type using a public key associated with the operator. Message interface 840 may be configured or otherwise supported for transmitting the signed message to a client application. Transfer verification component 845 may be configured or otherwise supported for detecting, via a blockchain distributed data repository, a message associated with a sender address that has transferred a first quantity of the first cryptographic token type to a receiver address.

[0096] Figure 9 A block diagram 900 illustrates a program execution component 920 supporting the Web3 transport protocol according to various aspects of this disclosure. Program execution component 920 may be an example of a program execution component as described herein, or a program execution component 820, or a combination thereof. Program execution component 920 or its various components may be examples of devices for executing various aspects of the Web3 transport protocol as described herein. For example, program execution component 920 may include a transfer intent request interface 925, a sender verification component 930, a message signature component 935, a message interface 940, a transfer verification component 945, a quantity identification component 950, a transfer recommendation component 955, a conversion ratio component 960, a request rejection component 965, or any combination thereof. Each of these components may communicate with each other (e.g., via one or more buses, communication links, communication interfaces, or any combination thereof).

[0097] The program execution component 920 may support data processing according to the examples disclosed herein. The transfer intention request interface 925 may be configured or otherwise supported for receiving, at the operator's location, a request from a client application to transfer a first quantity of a first cryptographic token type from a sender address to a receiver address. The sender verification component 930 may be configured or otherwise supported for verifying a sender address via a blockchain distributed data repository using off-chain data and a second quantity of a second cryptographic token type associated with the sender address. The message signing component 935 may be configured or otherwise supported for signing a message containing an indication of the sender address, receiver address, and the first quantity of the first cryptographic token type using a public key associated with the operator. The message interface 940 may be configured or otherwise supported for transmitting the signed message to a client application. The transfer verification component 945 may be configured or otherwise supported for detecting, via a blockchain distributed data repository, a message associated with a sender address that transfers a first quantity of a first cryptographic token type to a receiver address.

[0098] In some examples, the quantity identification component 950 may be configured or otherwise supported to support means for retrieving a corresponding second quantity of one or more second cryptographic token types associated with a sender address via a blockchain distributed data repository. In some examples, the transfer recommendation component 955 may be configured or otherwise supported to support means for transmitting to a client application an indication of at least one recommended transfer type based at least partially on the corresponding second quantity. In some examples, the transfer recommendation component 955 may be configured or otherwise supported to support means for receiving from a client application an indication of a selection of a transfer type among at least one recommended transfer type, wherein the message is signed upon receiving the selection.

[0099] In some examples, to support the verification of a second quantity of a second cryptographic token type, the conversion ratio component 960 may be configured or otherwise supported to support means for retrieving a conversion ratio between the second cryptographic token type and the first cryptographic token type. In some examples, to support the verification of a second quantity of a second cryptographic token type, the sender verification component 930 may be configured or otherwise supported to support means for determining, using the conversion ratio, a second quantity of the second cryptographic token type to at least produce a first quantity of the first cryptographic token type, wherein the message is signed at least in part based on this determination.

[0100] In some examples, the request includes an indication of the return address, and the signed message also includes an indication of the return address.

[0101] In some examples, to support message signing, the message signing component 935 can be configured or otherwise supported for signing devices that include a time value indicating the time when a message indicating a first amount to be transferred to the recipient's address is included in a block on the blockchain's distributed data repository.

[0102] In some examples, to support message signing, the message signing component 935 can be configured or otherwise supported for signing devices that include metadata referencing off-chain fees associated with the sender and receiver addresses.

[0103] In some examples, the transfer intention request interface 925 may be configured or otherwise supported for receiving a second request to transfer a second quantity of a second cryptographic token type from a second sender address to a second receiver address. In some examples, the request rejection component 965 may be configured or otherwise supported for rejecting the second request at least in part based on the second receiver address or a third cryptographic token type belonging to the second sender address via a blockchain distributed data repository.

[0104] In some examples, to support the rejection of a second request, message interface 940 can be configured or otherwise supported to send an indication to the client application that a request has been rejected, or to prevent the signing of a second message, or both.

[0105] Figure 10 A schematic diagram of a system 1000 including a device 1005 supporting the Web3 transport protocol is shown according to various aspects of this disclosure. Device 1005 may be an example of system 805 as described herein or a component including system 805 as described herein. Device 1005 may include components for blockchain protocol execution, such as program execution component 1020, network interface 1010, database controller 1015, memory 1025, processor 1030, and database 1035. Each of these components can communicate with each other (e.g., via one or more buses, communication links, communication interfaces, or any combination thereof). In some examples, system 1000 or device 1005 may correspond to or represent certain aspects of a blockchain network node, such as... Figure 1 Node 145 in the middle.

[0106] Network interface 1010 can manage input signals 1045 and output signals 1050 of device 1005. Network interface 1010 can also manage peripheral devices not integrated into device 1005. In some cases, network interface 1010 can represent a physical connection or port to an external peripheral device. In some cases, network interface 1010 can use an operating system such as iOS®, ANDROID®, MS-DOS®, MS-WINDOWS®, OS / 2®, UNIX®, LINUX®, or other known operating systems. In other cases, network interface 1010 can represent, or interact with, a modem, keyboard, mouse, touchscreen, or similar device. In some cases, network interface 1010 can be implemented as part of processor 1030. In some examples, a user can interact with device 1005 via network interface 1010 or via hardware components controlled by network interface 1010.

[0107] Database controller 1015 manages data storage and processing within database 1035. In some cases, users can interact with database controller 1015. In other cases, database controller 1015 can operate automatically without user interaction. Database 1035 can be an example of a single database, a distributed database, multiple distributed databases, a data repository, a data lake, or an emergency backup database.

[0108] Memory 1025 may include RAM and ROM. Memory 1025 may store computer-readable, computer-executable software, including instructions, which, when executed, enable processor 1030 to perform the various functions described herein. In some cases, memory 1025 may, among other functions, include a BIOS that controls basic hardware or software operations, such as interaction with peripheral components or devices.

[0109] Processor 1030 may include intelligent hardware devices (e.g., general-purpose processors, DSPs, CPUs, microcontrollers, ASICs, FPGAs, programmable logic devices, discrete gate or transistor logic components, discrete hardware components, or any combination thereof). In some cases, processor 1030 may be configured to operate a memory array using a memory controller. In other cases, the memory controller may be integrated into processor 1030. Processor 1030 may be configured to execute computer-readable instructions stored in memory 1025 to perform various functions (e.g., functions or tasks supporting the Web3 transport protocol).

[0110] The program execution component 1020 can support data processing according to the examples disclosed herein. For example, the program execution component 1020 can be configured or otherwise supported to support means for receiving, at an operator's location, a request from a client application to transfer a first quantity of a first cryptographic token type from a sender address to a receiver address. The program execution component 1020 can be configured or otherwise supported to support means for verifying a sender address via a blockchain distributed data repository using off-chain data and a second quantity of a second cryptographic token type associated with the sender address. The program execution component 1020 can be configured or otherwise supported to support means for signing a message containing an indication of the sender address, receiver address, and the first quantity of the first cryptographic token type using a public key associated with the operator. The program execution component 1020 can be configured or otherwise supported to support means for transmitting the signed message to the client application. The program execution component 1020 can be configured or otherwise supported to support means for detecting, via a blockchain distributed data repository, a message associated with the sender address that transfers the first quantity of the first cryptographic token type to the receiver address.

[0111] The program execution component 1020 may be an example of an aspect of a virtual machine or operating system (such as an EVM) that executes a blockchain protocol. Therefore, the program execution component 1020 may include instructions for smart contracts or self-executing programs, and may execute these instructions based on transactions or messages received from other devices or systems.

[0112] Figure 11 A flowchart illustrating a method 1100 supporting the Web3 transport protocol according to this disclosure is shown. The operation of method 1100 can be implemented by a custodial token platform or its components as described herein. For example, the operation of method 1100 can be implemented by a reference... Figures 1 to 7 The described escrow token platform performs the functions described herein. In some examples, the escrow token platform may execute a set of instructions to control the functional elements of the escrow token platform to perform the described functions. Additionally or alternatively, the escrow token platform may use dedicated hardware to perform certain aspects of the described functions.

[0113] At point 1105, the method may include: receiving a first message at a self-executing program stored in a blockchain distributed data repository, the first message including a sender address and an indication of a first quantity of a first cryptographic token type to be received by the receiver address. The operation of point 1105 can be performed according to the examples disclosed herein. In some examples, certain aspects of the operation of point 1105 may be derived from references... Figure 6 The described transfer intention interface 625 is executed.

[0114] At 1110, the method may include: verifying, at least in part, that the first message was effectively signed by an operator associated with the self-executing program based on the execution of the self-executing program. The operation at 1110 may be performed according to the examples disclosed herein. In some examples, aspects of the operation at 1110 may be derived from, as referenced... Figure 6 The signature verification component 630 described is executed.

[0115] At 1115, the method may include: generating one or more second messages after verifying that the first message has been validly signed, the second messages being configured to transfer a first quantity of a first cryptographic token type to a recipient address. The operation at 1115 can be performed according to the examples disclosed herein. In some examples, aspects of the operation at 1115 may be derived from, as referenced... Figure 6 The described transfer message component 635 is executed.

[0116] Figure 12 A flowchart illustrating a method 1200 supporting the Web3 transport protocol according to various aspects of this disclosure is shown. The operation of method 1200 can be implemented by the custodial token platform or its components described herein. For example, the operation of method 1200 can be implemented by reference to... Figures 1 to 7 The described custodial token platform performs the functions described. In some examples, the custodial token platform may execute a set of instructions to control the functional elements of the custodial token platform to perform the described functions. Additionally or alternatively, the custodial token platform may use dedicated hardware to perform aspects of the described functions.

[0117] At point 1205, the method may include: receiving a first message at a self-executing program stored in a blockchain distributed data repository, the first message including a sender address and an indication of a first quantity of a first cryptographic token type to be received by the receiver address. The operation of point 1205 can be performed according to the examples disclosed herein. In some examples, aspects of the operation of point 1205 may be derived from, as referenced... Figure 6 The described transfer intention interface 625 is executed.

[0118] At 1210, the method may include: verifying, at least in part, that the first message was effectively signed by an operator associated with the self-executing program based on the execution of the self-executing program. The operation of 1210 may be performed according to the examples disclosed herein. In some examples, aspects of the operation of 1210 may be derived from, as referenced... Figure 6 The signature verification component 630 described is executed.

[0119] At point 1215, the method may include: after verifying that the first message has been effectively signed, generating one or more second messages, the second messages being configured to transfer a first quantity of a first cryptographic token type to a recipient address. The operation at point 1215 can be performed according to the examples disclosed herein. In some examples, aspects of the operation at point 1215 may be derived from, as referenced... Figure 6 The described transfer message component 635 is executed.

[0120] At 1220, the method may include: generating an exchange message configured to exchange a second quantity of a second cryptographic token type belonging to a sender address in a blockchain distributed data repository for a first quantity of a first cryptographic token type. The operation at 1220 can be performed according to the examples disclosed herein. In some examples, aspects of the operation at 1220 may be derived from, as referenced... Figure 6 The described switching component 640 is executed.

[0121] At 1225, the method may include: generating a transfer message configured to transfer a first quantity of a first cryptographic token type to a recipient address. The operation at 1225 can be performed according to the examples disclosed herein. In some examples, aspects of the operation at 1225 may be derived from, as referenced... Figure 6 The described transfer message component 635 is executed.

[0122] At 1230, the method may include: generating an exchange message configured to invoke a second self-executing program associated with a decentralized exchange protocol, wherein the second self-executing program exchanges a second quantity of a second cryptographic token type for a first quantity of a first cryptographic token type, and returns the first quantity of the first cryptographic token type to an address associated with the self-executing program. The operation at 1230 may be performed according to the examples disclosed herein. In some examples, the operation at 1230 may be performed by, as referenced... Figure 6 The described switching component 640 is executed.

[0123] Figure 13 A flowchart illustrating a method 1300 supporting the Web3 transport protocol according to various aspects of this disclosure is shown. Operation of method 1300 may be implemented by a managed token platform or its components as described herein. For example, operation of method 1300 may be implemented by reference to... Figures 1 to 7 The escrow token platform performs the functions described herein. In some examples, the escrow token platform may execute a set of instructions to control the functional elements of the escrow token platform to perform the functions. Additionally or alternatively, the escrow token platform may use dedicated hardware to perform certain aspects of the functions.

[0124] At point 1305, the method may include: receiving a first message at a self-executing program stored in a blockchain distributed data repository, the first message including a sender address and an indication of a first quantity of a first cryptographic token type to be received by the recipient address. The operation of point 1305 can be performed according to the examples disclosed herein. In some examples, aspects of the operation of point 1305 may be derived from, as referenced... Figure 6 The described transfer intention interface 625 is executed.

[0125] At 1310, the method may include: verifying, at least in part, that the first message was effectively signed by an operator associated with the self-executing program based on the execution of the self-executing program. The operation of 1310 may be performed according to the examples disclosed herein. In some examples, aspects of the operation of 1310 may be derived from, as referenced... Figure 6 The signature verification component 630 described is executed.

[0126] At point 1315, the method may include: after verifying that the first message has been effectively signed, generating one or more second messages, the second messages being configured to transfer a first quantity of a first cryptographic token type to a recipient address. The operation at point 1315 can be performed according to the examples disclosed herein. In some examples, aspects of the operation at point 1315 may be derived from, as referenced... Figure 6 The described transfer message component 635 is executed.

[0127] At 1320, the method may include: generating a third message configured to return a second quantity of a second cryptographic token type to the sender address, the second quantity being at least partially based on a conversion ratio between the first and second cryptographic token types. The operation at 1320 can be performed according to the examples disclosed herein. In some examples, aspects of the operation at 1320 may be derived from, as referenced... Figure 6 The described return component 650 is executed.

[0128] Figure 14 A flowchart illustrating a method 1400 supporting the Web3 transport protocol according to various aspects of this disclosure is shown. Operation of method 1400 can be implemented by a server or its components as described herein. For example, operation of method 1400 can be provided by reference to... Figures 1 to 4 and Figures 8 to 10 The server performs the described functions. In some examples, the server may execute a set of instructions to control the server's functional elements to perform the described functions. Additionally or alternatively, the server may use dedicated hardware to perform certain aspects of the described functions.

[0129] At 1405, the method may include: receiving, at the operator's location, a request from a client application to transfer a first quantity of a first cryptographic token type from a sender's address to a receiver's address. The operation at 1405 can be performed according to the examples described herein. In some examples, aspects of the operation at 1405 may be derived from, as referenced... Figure 9 The described transfer intention request interface 925 is executed.

[0130] At 1410, the method may include: verifying the sender address via a blockchain distributed data repository using off-chain data and a second quantity of a second cryptographic token type associated with the sender address. The operation of 1410 can be performed according to the examples disclosed herein. In some examples, aspects of the operation of 1410 may be derived from, as referenced... Figure 9 The described sender verification component 930 is executed.

[0131] At 1415, the method may include: signing a message including the sender address, the receiver address, and an indication of the first quantity of the first cryptographic token type using a public key associated with the operator. The operation at 1415 can be performed according to the examples disclosed herein. In some examples, aspects of the operation at 1415 may be derived from, as referenced... Figure 9 The described message signing component 935 is executed.

[0132] At 1420, the method may include transmitting the signed message to the client application. The operation at 1420 can be performed according to the examples disclosed herein. In some examples, aspects of the operation at 1420 may be derived from, as referenced... Figure 9 The described message interface 940 is executed.

[0133] At 1425, the method may include: detecting, via the blockchain distributed data repository, a message associated with the sender address that transfers the first quantity of the first cryptographic token type to the recipient address. The operation at 1425 may be performed according to the examples disclosed herein. In some examples, aspects of the operation at 1425 may be derived from, as referenced... Figure 9 The described transfer verification component 945 is executed.

[0134] Figure 15 A flowchart is shown of a method 1500 supporting the Web3 transport protocol according to various aspects of this disclosure. Operation of method 1500 may be implemented by a server or its components as described herein. For example, operation of method 1500 may be provided by reference to... Figures 1 to 4 and Figures 8 to 10The server described herein performs the function. In some examples, the server may execute a set of instructions to control the server's functional elements to perform the function. Additionally or alternatively, the server may use dedicated hardware to perform aspects of the function.

[0135] At 1505, the method may include: receiving, at the operator's location, a request from a client application to transfer a first quantity of a first cryptographic token type from a sender's address to a receiver's address. The operation at 1505 can be performed according to the examples disclosed herein. In some examples, aspects of the operation at 1505 may be derived from, as referenced... Figure 9 The described transfer intention request interface 925 is executed.

[0136] At point 1510, the method may include: verifying the sender address via a blockchain distributed data repository using off-chain data and a second quantity of a second cryptographic token type associated with the sender address. The operation of 1510 can be performed according to the examples disclosed herein. In some examples, aspects of the operation of 1510 may be derived from, as referenced... Figure 9 The described sender verification component 930 is executed.

[0137] At point 1515, the method may include: retrieving a corresponding second quantity of one or more second cryptographic token types associated with the sender address via the blockchain distributed data repository. The operation at point 1515 can be performed according to the examples disclosed herein. In some examples, aspects of the operation at point 1515 may be derived from references... Figure 9 The quantity recognition component 950 described is executed.

[0138] At 1520, the method may include: transmitting to the client application an indication of at least one recommended transfer type, at least partially based on the corresponding second quantity. The operation of 1520 can be performed according to the examples disclosed herein. In some examples, aspects of the operation of 1520 may be derived from references... Figure 9 The described transfer recommendation component 955 is executed.

[0139] At 1525, the method may include: receiving from the client application an indication of selecting a transfer type among the at least one recommended transfer type, wherein, upon receiving the selection, the message is signed. The operation of 1525 can be performed according to the examples disclosed herein. In some examples, aspects of the operation of 1525 may be derived from references... Figure 9 The described transfer recommendation component 955 is executed.

[0140] At 1530, the method may include: signing a message including a sender address, a receiver address, and a first quantity of a first cryptographic token type using a public key associated with the operator. The operation at 1530 can be performed according to the examples disclosed herein. In some examples, aspects of the operation at 1530 may be derived from, as referenced... Figure 9 The described message signing component 935 is executed.

[0141] At step 1535, the method may include transmitting the signed message to a client application. The operation at step 1535 can be performed according to the examples disclosed herein. In some examples, aspects of the operation at step 1535 may be derived from, as referenced... Figure 9 The described message interface 940 is executed.

[0142] At point 1540, the method may include: detecting, via a blockchain distributed data repository, a message associated with a sender address that transfers a first quantity of a first cryptographic token type to a recipient address. The operation at point 1540 can be performed according to the examples disclosed herein. In some examples, aspects of the operation at point 1540 may be derived from, as referenced... Figure 9 The described transfer verification component 945 is executed.

[0143] Figure 16 A flowchart illustrating a method 1600 supporting the Web3 transport protocol according to various aspects of this disclosure is shown. Operation of method 1600 can be implemented by a server or its components as described herein. For example, operation of method 1600 can be provided by reference to... Figures 1 to 4 and Figures 8 to 10 The server performs the described functions. In some examples, the server may execute a set of instructions to control the server's functional elements to perform the described functions. Additionally or alternatively, the server may use dedicated hardware to perform certain aspects of the described functions.

[0144] At 1605, the method may include: receiving, at the operator's location, a request from a client application to transfer a first quantity of a first cryptographic token type from a sender's address to a receiver's address. The operation at 1605 can be performed according to the examples disclosed herein. In some examples, aspects of the operation at 1605 may be derived from, as referenced... Figure 9 The described transfer intention request interface 925 is executed.

[0145] At 1610, the method may include: verifying the sender address via a blockchain distributed data repository using off-chain data and a second quantity of a second cryptographic token type associated with the sender address. The operation of 1610 can be performed according to the examples disclosed herein. In some examples, aspects of the operation of 1610 may be derived from, as referenced... Figure 9 The described sender verification component 930 is executed.

[0146] At point 1615, the method may include: retrieving a conversion ratio between the second cryptographic token type and the first cryptographic token type. The operation at 1615 can be performed according to the examples disclosed herein. In some examples, aspects of the operation at 1615 may be derived from, as referenced... Figure 9 The described conversion ratio component 960 is executed.

[0147] At 1620, the method may include: determining, using a conversion ratio, that a second quantity of transfers of the second cryptographic token type will at least produce a first quantity of the first cryptographic token type, wherein the message is signed at least in part based on this determination. The operation at 1620 can be performed according to the examples disclosed herein. In some examples, aspects of the operation at 1620 may be derived from, as referenced... Figure 9 The described sender verification component 930 is executed.

[0148] At 1625, the method may include: signing a message including a sender's address, a receiver's address, and a first quantity of a first cryptographic token type using a public key associated with the operator. The operation at 1625 can be performed according to the examples disclosed herein. In some examples, aspects of the operation at 1625 may be derived from, as referenced... Figure 9 The described message signing component 935 is executed.

[0149] At 1630, the method may include transmitting the signed message to a client application. The operation at 1630 can be performed according to the examples disclosed herein. In some examples, aspects of the operation at 1630 may be derived from, as referenced... Figure 9 The described message interface 940 is executed.

[0150] At point 1635, the method may include: detecting, via a blockchain distributed data repository, a message associated with a sender address that transfers a first quantity of a first cryptographic token type to a recipient address. The operation at point 1635 can be performed according to the examples disclosed herein. In some examples, aspects of the operation at point 1635 may be derived from, as referenced... Figure 9 The described transfer verification component 945 is executed.

[0151] A data processing method is described. The method may include: receiving a first message at a self-executing program stored on a blockchain distributed data repository, the first message including a sender address and an indication of a first quantity of a first cryptographic token type to be received by a recipient address; verifying, at least in part, that the first message has been effectively signed by an operator associated with the self-executing program based on the execution of the self-executing program; and generating one or more second messages after verifying that the first message has been effectively signed, the second messages being configured to transfer the first quantity of the first cryptographic token type to the recipient address.

[0152] This invention describes a data processing apparatus. The apparatus may include a processor, a memory coupled to the processor, and instructions stored in the memory. These instructions can be executed by the processor to cause the apparatus to: receive a first message at a self-executing program stored on a blockchain distributed data repository, the first message including an indication of a first quantity of a first cryptographic token type to be received at a sender address and a receiver address; verify, at least in part, that the first message has been effectively signed by an operator associated with the self-executing program based on the execution of the self-executing program; and, after verifying that the first message has been effectively signed, generate one or more second messages configured to transfer the first quantity of the first cryptographic token type to the receiver address.

[0153] The present invention describes another apparatus for data processing. The apparatus may include: means for receiving a first message at a self-executing program stored on a blockchain distributed data repository, the first message including an indication of a sender address and a first quantity of a first cryptographic token type to be received by a receiver address; means for verifying, at least in part, that the first message has been effectively signed by an operator associated with the self-executing program based on the execution of the self-executing program; and means for generating one or more second messages after verifying that the first message has been effectively signed, the second messages being configured to transfer the first quantity of the first cryptographic token type to the receiver address.

[0154] A non-transitory computer-readable medium for storing data processing code is described. The code may include instructions executable by a processor to: receive a first message at a self-executing program stored on a blockchain distributed data repository, the first message including an indication of a sender address and a first quantity of a first cryptographic token type to be received by a receiver address; verify, at least in part, that the first message has been effectively signed by an operator associated with the self-executing program based on the execution of the self-executing program; and, after verifying that the first message has been effectively signed, generate one or more second messages configured to transfer the first quantity of the first cryptographic token type to the receiver address.

[0155] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, generating one or more second messages may include operations, features, devices, or instructions for generating exchange messages and transfer messages, the exchange messages being configured to exchange a second quantity of a second cryptographic token type belonging to a sender address in a blockchain distributed data repository for a first quantity of a first cryptographic token type, and the transfer messages being configured to transfer the first quantity of the first cryptographic token type to a receiver address.

[0156] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, generating an exchange message may include operations, features, devices, or instructions for generating the exchange message, which may be configured to invoke a second self-executing program associated with a decentralized exchange protocol, wherein the second self-executing program exchanges a second quantity of a second cryptographic token type for a first quantity of a first cryptographic token type and returns the first quantity of the first cryptographic token type to an address associated with the self-executing program.

[0157] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, generating an exchange message may include operations, features, devices, or instructions for generating an exchange message that includes an indication of a first number of first cryptographic token types.

[0158] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, generating one or more second messages may include operations, features, devices, or instructions for generating a packaging message and a transfer message, the packaging message being configured to package or unpack a second quantity of a second cryptographic token type to obtain a first quantity of a first cryptographic token type, and the transfer message being configured to transfer the first quantity of the first cryptographic token type to a recipient address.

[0159] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may also include operations, features, devices, or instructions for generating a third message that can be configured to return a second quantity of a second cryptographic token type to a sender address, the second quantity being at least partially based on a conversion ratio between the first and second cryptographic token types.

[0160] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, the first message and one or more second messages also include metadata referencing off-chain fees associated with the sender's address and the receiver's address.

[0161] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, the first message includes a time value indicating the time when a message indicating the transfer of a first quantity to the recipient's address is included in a block on a blockchain distributed data repository, and the self-executing program can be configured to verify the time value before generating one or more second messages.

[0162] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, the first message includes the amount of fee to be sent to the operator.

[0163] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, the first message includes a second quantity of a second cryptographic token type to be sent by the sender address that sent the first message.

[0164] A data processing method is described. This method may include: receiving, at an operator's location, a request from a client application to transfer a first quantity of a first cryptographic token type from a sender's address to a receiver's address; verifying the sender's address via a blockchain distributed data repository using off-chain data and a second quantity of a second cryptographic token type associated with the sender's address; signing a message including the sender's address, the receiver's address, and the first quantity of the first cryptographic token type using a public key associated with the operator; transmitting the signed message to the client application; and detecting, via the blockchain distributed data repository, the message associated with the sender's address that has transferred the first quantity of the first cryptographic token type to the receiver's address.

[0165] A data processing apparatus is described. The apparatus may include a processor, memory coupled to the processor, and instructions stored in the memory. These instructions are executable by the processor to cause the apparatus to: receive, at an operator's location, a request from a client application to transfer a first quantity of a first cryptographic token type from a sender's address to a receiver's address; verify the sender's address via a blockchain distributed data repository using off-chain data and a second quantity of a second cryptographic token type associated with the sender's address; sign a message including an indication of the sender's address, the receiver's address, and the first quantity of the first cryptographic token type using a public key associated with the operator; transmit the signed message to the client application; and detect, via the blockchain distributed data repository, the message associated with the sender's address that has transferred the first quantity of the first cryptographic token type to the receiver's address.

[0166] Another apparatus for data processing is described. This apparatus may include: means for receiving, at an operator's location, a request from a client application to transfer a first quantity of a first cryptographic token type from a sender's address to a receiver's address; means for verifying a sender's address via a blockchain distributed data repository using off-chain data and a second quantity of a second cryptographic token type associated with the sender's address; means for signing a message including an indication of the sender's address, the receiver's address, and the first quantity of the first cryptographic token type using a public key associated with the operator; means for transmitting the signed message to the client application; and means for detecting, via the blockchain distributed data repository, the message associated with the sender's address that has transferred the first quantity of the first cryptographic token type to the receiver's address.

[0167] A non-transitory computer-readable medium is described, storing code for data processing. The code may include instructions executable by a processor to: receive, at an operator's location, a request from a client application to transfer a first quantity of a first cryptographic token type from a sender's address to a receiver's address; verify the sender's address via a blockchain distributed data repository using off-chain data and a second quantity of a second cryptographic token type associated with the sender's address; sign a message including the sender's address, the receiver's address, and the first quantity of the first cryptographic token type using a public key associated with the operator; transmit the signed message to the client application; and detect, via the blockchain distributed data repository, the message associated with the sender's address that has transferred the first quantity of the first cryptographic token type to the receiver's address.

[0168] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may also include operations, features, devices, or instructions for: retrieving a corresponding second quantity of one or more second cryptographic token types associated with a sender address via a blockchain distributed data repository; transmitting to a client application an indication that can be based at least partially on at least one recommended transfer type; and receiving from the client application an indication of selection of a transfer type among at least one recommended transfer type, wherein the message may be signed after the selection is received.

[0169] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, verifying a second quantity of a second cryptographic token type may include operations, features, devices, or instructions for: retrieving a conversion ratio between a second cryptographic token type and a first cryptographic token type, and using the conversion ratio to determine that a transfer of a second quantity of the second cryptographic token type would at least produce a first quantity of the first cryptographic token type, wherein a message may be signed at least in part based on this determination.

[0170] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, the request includes an indication of a return address, and the signed message includes an indication of a return address.

[0171] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, signing a message may include operations, features, devices, or instructions for signing a message containing a time value indicating the time when a message indicative of a first quantity to be transferred to a recipient address is included in a block on a blockchain distributed data repository.

[0172] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, signing a message may include operations, features, devices, or instructions for signing a message containing metadata referencing off-chain fees associated with a sender's address and a receiver's address.

[0173] Examples of the methods, apparatuses, and non-transitory computer-readable media described herein may also include operations, features, devices, or instructions for receiving a second request to transfer a second quantity of a second cryptographic token type from a second sender address to a second receiver address and for rejecting the second request via a blockchain distributed data repository based at least in part on the second receiver address or a third cryptographic token type belonging to the second sender address.

[0174] In some examples of the methods, apparatuses, and nontransitory computer-readable media described herein, rejecting a second request may include operations, features, devices, or instructions for transmitting to a client application an indication that the request may be rejected, or that signing of the second message may be avoided, or both.

[0175] It should be noted that the above method describes possible implementations, the operations and steps of which can be rearranged or otherwise modified, and other implementations are also possible. Furthermore, aspects of two or more methods can be combined.

[0176] The description herein, illustrated with reference to the accompanying drawings, describes exemplary configurations and does not represent all implementable examples or examples within the scope of the claims. The term "exemplary" as used herein means "serving as an example, instance, or illustration," and not "preferred" or "superior to other examples." The detailed description includes specific details intended to aid in understanding the described techniques. However, these techniques can be practiced without these specific details. In some cases, well-known structures and devices are shown in block diagram form to avoid obscuring the concepts of the examples.

[0177] In the accompanying drawings, similar components or features may have the same reference numerals. Furthermore, various components of the same type can be distinguished by adding a dash after the reference label and a second label to differentiate similar components. If only the first reference label is used in the specification, the description applies to any similar components having the same first reference label, regardless of the second reference label.

[0178] The information and signals described herein can be represented using a variety of different techniques and methods. For example, the data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description can be represented by voltage, current, electromagnetic waves, magnetic fields or particles, light fields or particles, or any combination thereof.

[0179] The various illustrative blocks and modules described in connection with the disclosure herein may be implemented or executed by a general-purpose processor, DSP, ASIC, FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof, which are intended to perform the functions described herein. A general-purpose processor may be a microprocessor, but alternatively, it may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, multiple microprocessors, a combination of one or more microprocessors with a DSP core, or any other such configuration).

[0180] The functions described herein can be implemented by hardware, processor-executed software, firmware, or any combination thereof. If implemented by processor-executed software, these functions can be stored on or transmitted via a computer-readable medium as one or more instructions or code. Other examples and implementations are within the scope of this disclosure and the appended claims. For example, due to the nature of software, the above-described functions can be implemented using processor-executed software, hardware, firmware, hardwiring, or a combination thereof. Features implementing the functions can also be physically located in different locations, including distributed across different physical locations, such that some functions are implemented in different physical locations. Furthermore, the system used herein can be a collection of multiple devices, a single device, or aspects within a single device.

[0181] Furthermore, the word “or” as used herein (including the claims) in a list of items (e.g., a list of items beginning with phrases such as “at least one of…” or “one or more of…”) indicates an inclusive list, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Additionally, the phrase “based on” as used herein should not be construed as referring to a closed set of conditions. For example, an exemplary step described as “based on condition A” may be based on both condition A and condition B simultaneously without departing from the scope of this disclosure. In other words, the phrase “based on” as used herein should be interpreted in the same manner as the phrase “at least partially based on.”

[0182] Computer-readable media include non-transitory computer storage media and communication media, wherein communication media includes any medium that facilitates the transfer of a computer program from one place to another. Non-transitory storage media can be any available medium accessible by a general-purpose or special-purpose computer. By way of example, and not limitation, non-transitory computer-readable media can include RAM, ROM, EEPROM, optical disc (CD) ROM or other optical disc storage, disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to carry or store required program code units in the form of instructions or data structures and is accessible by a general-purpose or special-purpose computer or a general-purpose or special-purpose processor. Furthermore, any connection can be appropriately referred to as computer-readable media. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are all included in the definition of media. The disks and optical discs used in this article include CDs, laserdiscs, optical discs, digital multifunction discs (DVDs), floppy disks, and Blu-ray discs, where disks typically copy data magnetically, while optical discs use lasers to copy data optically. The combination of these is also included within the scope of computer-readable media.

[0183] The description herein is intended to enable those skilled in the art to make or use the present disclosure. Various modifications to the present disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the scope of the present disclosure. Therefore, the present disclosure is not limited to the examples and designs described herein, but should be given the widest scope consistent with the principles and novel features described herein.

Claims

1. A data processing method, comprising: The operator receives a request from the client application to transfer a first quantity of a first type of encrypted token from the sender's address to the receiver's address. The sender address is verified using off-chain data and a second quantity of a second cryptographic token type associated with the sender address via a blockchain distributed data repository. The message, which includes the sender's address, the receiver's address, and an indication of the first quantity of the first cryptographic token type, is signed using the public key associated with the operator. The signed message is transmitted to the client application; as well as The message associated with the sender address, which transfers the first quantity of the first cryptographic token type to the recipient address, is detected via the blockchain distributed data repository.

2. The method according to claim 1, further comprising: Retrieve a corresponding second quantity of one or more second cryptographic token types associated with the sender address via the blockchain distributed data repository; Transmit to the client application an indication of at least one recommended transfer type, based at least in part on the corresponding second number; as well as The client application receives an instruction to select a transfer type from the at least one recommended transfer type, wherein the message is signed upon receiving the selection.

3. The method according to claim 1, wherein, Verifying the second quantity of the second cryptographic token type includes: Retrieve the conversion ratio between the second cryptographic token type and the first cryptographic token type; and The transfer of the second quantity of the second cryptographic token type determined by the conversion ratio will at least produce the first quantity of the first cryptographic token type, wherein the message is signed at least in part based on the determination.

4. The method according to claim 1, wherein, The request includes an indication of the return address, and the signed message includes an indication of the return address.

5. The method according to claim 1, wherein, Signing the message includes: The message, including a time value, is signed, the time value indicating the time when the message indicating the first amount transferred to the recipient address is included in a block on the blockchain's distributed data repository.

6. The method according to claim 1, wherein, Signing the message includes: The message, including metadata, is signed, which references an off-chain protocol between the payer and the receiver associated with the sender's address and the receiver's address.

7. The method according to claim 1, further comprising: Receive a second request to transfer a second quantity of a second encrypted token type from a second sender address to a second receiver address; as well as The second request is rejected, at least in part, based on the second recipient address or a third cryptographic token type belonging to the second sender address, via the blockchain distributed data repository.

8. The method according to claim 7, wherein, Denying the second request includes: Send an indication to the client application that the request has been rejected, or avoid signing the second message, or both.

9. A data processing apparatus, comprising: processor; A memory coupled to the processor; as well as Instructions, which are stored in the memory and can be executed by the processor, to cause the device to perform the following operations: The operator receives a request from the client application to transfer a first quantity of a first type of encrypted token from the sender's address to the receiver's address. The sender address is verified using off-chain data and a second quantity of a second cryptographic token type associated with the sender address via a blockchain distributed data repository. The message, which includes the sender's address, the receiver's address, and an indication of the first quantity of the first cryptographic token type, is signed using the public key associated with the operator. The signed message is transmitted to the client application; as well as The message associated with the sender address, which transfers the first quantity of the first cryptographic token type to the recipient address, is detected via the blockchain distributed data repository.

10. The apparatus according to claim 9, wherein, The instructions can also be executed by the processor to cause the device to perform the following operations: Retrieve a corresponding second quantity of one or more second cryptographic token types associated with the sender address via the blockchain distributed data repository; Transmit to the client application an indication of at least one recommended transfer type, based at least in part on the corresponding second number; as well as The client application receives an instruction to select a transfer type from the at least one recommended transfer type, wherein the message is signed upon receiving the selection.

11. The apparatus according to claim 9, wherein, The instructions for verifying the second quantity of the second cryptographic token type are executable by the processor, causing the device to perform the following operations: Retrieve the conversion ratio between the second cryptographic token type and the first cryptographic token type; and The transfer of the second quantity of the second cryptographic token type determined by the conversion ratio will at least produce the first quantity of the first cryptographic token type, wherein the message is signed at least in part based on the determination.

12. The apparatus according to claim 9, wherein, The request includes an indication of the return address, and the signed message includes an indication of the return address.

13. The apparatus according to claim 9, wherein, Instructions for signing the message can be executed by the processor to cause the device to perform the following operations: The message, including a time value, is signed, the time value indicating the time when the message indicating the first amount transferred to the recipient address is included in a block on the blockchain's distributed data repository.

14. The apparatus according to claim 9, wherein, Instructions for signing the message can be executed by the processor to cause the device to perform the following operations: The message, including metadata, is signed, which references an off-chain protocol between the payer and the receiver associated with the sender's address and the receiver's address.

15. A non-transitory computer-readable medium storing code for data processing, the code including instructions executable by a processor to perform the following operations: The operator receives a request from the client application to transfer a first quantity of a first type of encrypted token from the sender's address to the receiver's address. The sender address is verified using off-chain data and a second quantity of a second cryptographic token type associated with the sender address via a blockchain distributed data repository. The message, which includes the sender's address, the receiver's address, and an indication of the first quantity of the first cryptographic token type, is signed using the public key associated with the operator. Transmit the signed message to the client application; and The message associated with the sender address, which transfers the first quantity of the first cryptographic token type to the recipient address, is detected via the blockchain distributed data repository.

16. The non-transitory computer-readable medium according to claim 15, wherein, The instructions can also be executed by the processor for: Retrieve a corresponding second quantity of one or more second cryptographic token types associated with the sender address via the blockchain distributed data repository; Transmit to the client application an indication of at least one recommended transfer type, based at least in part on the corresponding second number; as well as The client application receives an instruction to select a transfer type from the at least one recommended transfer type, wherein the message is signed upon receiving the selection.

17. The non-transitory computer-readable medium according to claim 15, wherein, The instructions for verifying the second quantity of the second cryptographic token type can be executed by the processor for: Retrieve the conversion ratio between the second cryptographic token type and the first cryptographic token type; and The transfer of the second quantity of the second cryptographic token type determined by the conversion ratio will at least produce the first quantity of the first cryptographic token type, wherein the message is signed at least in part based on the determination.

18. The non-transitory computer-readable medium according to claim 15, wherein, The request includes an indication of the return address, and the signed message includes an indication of the return address.

19. The non-transitory computer-readable medium according to claim 15, wherein, Instructions for signing the message can be executed by the processor for: The message, including a time value, is signed, the time value indicating the time when the message indicating the first amount transferred to the recipient address is included in a block on the blockchain's distributed data repository.

20. The non-transitory computer-readable medium according to claim 15, wherein, Instructions for signing the message can be executed by the processor for: The message, including metadata, is signed, which references an off-chain protocol between the payer and the receiver associated with the sender's address and the receiver's address.

Images