Cross chain token exchange

Abstract

A method for cross-blockchain transactions includes receiving, from a user, a request to exchange a first amount of a first token on a first blockchain for a second token on a second blockchain. A first smart contract on the first blockchain is executed to lock the first amount of the first token. Based on the first amount and an exchange rate of the first token to the second token, a second amount of the second token is determined. A second smart contract on the second blockchain is executed to release the second amount of the second token to a wallet owned by the user, the wallet being associated with the second blockchain.

Description

Attorney Docket No.: 120640-0015CROSS CHAIN TOKEN EXCHANGECROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority' to U.S. Provisional Application No. 63 / 683,311, filed August 15, 2024, which is incorporated by reference herein.TECHNICAL FIELD

[0002] The present disclosure is related to cross-chain communication, for example, between host-chains and a target-blockchain using multichain contracts. More specifically, the present disclosure is directed to a multi-chain platform using smart contracts to transfer or swap (e.g., buy or sell) tokens that are not available in a current blockchain maintaining funds corresponding to the buyer.BACKGROUND

[0003] Cryptocurrency wallets (or ‘crypto wallets’) are software or hardware tools that enable users to store, use, and manage digital assets on blockchain networks. Cryptocurrencies exist solely as digital records on distributed ledgers and do not rely on physical currency and centralized institutions. However, there is a need for individuals and organizations to understand ownership of digital assets and to be able to know how much is held, much like a bank account provides a bank balance.

[0004] Users can use crypto wallets to validate account balances, providing visibility into how much digital assets the user owns, receive digital assets, and interact with Web3 decentralized applications (dApps) and decentralized finance (DeFi) services. DeFi users may use smart contract platforms to trade native or fungible tokens in blockchains. Typically, blockchains provide a native coin by default that is used for transactions. A crypto wallet has to have native tokens of the blockchain it operates to be able to execute any of the transactions and pay transaction fees (or ‘gas’). Users must acquire the native token before they can execute any operations on the network, creating a barrier to entry' and limiting interoperability' between different blockchain ecosystems.SUMMARY

[0005] The present disclosure is directed to methods and systems for cross chain token swapping for any token to any blockchain in a multichain platform. The method includes1DM_US 2136129S2-1 120640 0015Attorney Docket No.: 120640-0015 receiving a request to swap tokens, locking a token at a host blockchain, sending a generic message to a target blockchain, releasing the counter token in the target blockchain to a crypto wallet corresponding to the request.

[0006] The present disclosure relates to cross-blockchain transactions. In one aspect, a method is provided that includes receiving, from a user, a request to exchange a first amount of a first token on a first blockchain for a second token on a second blockchain. The method further includes executing a first smart contract on the first blockchain to lock the first amount of the first token. Based on the first amount of the first token and an exchange rate of the first token to the second token, a second amount of the second token is determined. A second smart contract on the second blockchain is executed to transfer the second amount of the second token to a wallet owned by the user, the wallet being associated with the second blockchain.

[0007] In another aspect, a non-transitory computer-readable medium stores a program for cross-blockchain transactions. When executed by a computer, the program configures the computer to receive a request from a user to exchange a first amount of a first token on a first blockchain for a second token on a second blockchain. The program further configures the computer to execute a first smart contract on the first blockchain to lock the first amount of the first token. The program further configures the computer to determine a second amount of the second token based on the first amount of the first token and an exchange rate of the first token to the second token. The program further configures the computer to execute a second smart contract on the second blockchain to transfer the second amount of the second token to a wallet owned by the user, where the wallet is associated with the second blockchain.

[0008] In yet another aspect, a system for cross-blockchain transactions is provided. The system includes one or more processors and a non-transitory7computer-readable medium that stores a set of instructions. When executed by at least one of the processors, the instructions configure the system to receive a request from a user to exchange a first amount of a first token on a first blockchain for a second token on a second blockchain. The instructions further configure the system to execute a first smart contract on the first blockchain to lock the first amount of the first token. The instructions further configure the system to determine a second amount of the second token based on the first amount of the first token and an exchange rate of the first token to the second token. The instructions further configure the system to execute a second smart contract on the second blockchain to transfer the second amount of the second token to a wallet owned by the user, where the wallet is associated with the second blockchain.2DM_US 2136129S2-1 120640 0015Attorney Docket No.: 120640-0015BRIEF DESCRIPTION OF THE DRAWINGS

[0009] FIG. 1 illustrates a network architecture used for a blockchain and smart contracts, as described herein.

[0010] FIG. 2 is a block diagram illustrating components and steps in a network including multiple host blockchains linked to a target blockchain hosting multiple users via a bridge application, according to some embodiments.

[0011] FIG. 3 is a block diagram illustrating cross chain swaps, according to some embodiments.

[0012] FIG. 4 is a block diagram illustrating an example computer system with which aspects of the subject technology’ can be implemented.

[0013] FIG. 5 is a flowchart illustrating a process for cross-chain transactions, according to some embodiments.

[0014] In one or more implementations, not all of the depicted components in each figure may be required, and one or more implementations may include additional components not shown in a figure. Variations in the arrangement and ty pe of the components may be made without departing from the scope of the subject disclosure. Additional components, different components, or fewer components may be utilized within the scope of the subject disclosure.DETAILED DESCRIPTION

[0015] In the following detailed description, numerous specific details are set forth to provide a full understanding of the present disclosure. It will be apparent, however, to one ordinarily skilled in the art, that the embodiments of the present disclosure may be practiced without some of these specific details. In other instances, well-known structures and techniques have not been shown in detail so as not to obscure the disclosure.

[0016] It is to be understood that the present disclosure includes examples of the subject technology and does not limit the scope of the included clauses. Various aspects of the subject technology will now be disclosed according to particular but non-limiting examples. Various embodiments described in the present disclosure may be carried out in different ways and variations, and in accordance with a desired application or implementation.3DM_US 2136129S2-1 120640 0015Attorney Docket No.: 120640-0015

[0017] In the following detailed description, numerous specific details are set forth to provide a full understanding of the present disclosure. It will be apparent, however, to one ordinarily skilled in the art, that embodiments of the present disclosure may be practiced without some of the specific details. In other instances, well-known structures and techniques have not been shown in detail so as not to obscure the disclosure.

[0018] A crypto wallet provides a way for users to validate an account balance and provide visibility into how much digital assets the user owns. A crypto wallet enables users to send and receive digital assets; an approach that is similar in concept to how a traditional bank account enables users to send and receive money. For many users, a crypto wallet is a primary mechanism for managing cryptocurrency balances. But a crypto wallet is also required to connect and interact with Web 3.0 decentralized applications that operate on smart contracts.

[0019] Blockchains typically provide a native coin (herein referred to as a “gas token”) by default. A crypto wallet has to have gas token of the blockchain it operates to be able to execute any of the transactions mentioned above. When the users sign up with a crypto wallet providers, they are automatically assigned one or more blockchain addresses (similar to bank account numbers) and these blockchain addresses initially have zero (0) digital assets balances including the gas token of the blockchain. These addresses may then be funded with an initial amount of gas token from other addresses to be able to start executing transactions. This creates a friction point for a user whenever they wish to operate in a new blockchain, forcing the user to find ways to procure gas tokens along with their initial transaction.

[0020] When a de-centralized finance (DeFi) user wants to trade a native or fungible token (e.g, ERC20 token) in the blockchain of their choice, they may use smart contract based Automated Market Makers (AMMs), by connecting their crypto wallet to a decentralized application (dApp). When a DeFi user desires to move their token from their original blockchain to another blockchain for a given transaction (e.g., trading, staking, and the like), they may use a bridge. A bridge is a paid service / application that facilitates the transfer of tokens from one chain to another. In some embodiments, bridge applications are created and operated by 3rdparties. However, to use a bridge to send a coin from one blockchain to a user wallet, that token may be “wrapped” by the bridge, and converted to a token based on the target blockchain. In some embodiments, the user’s crypto wallet at the target would receive a “bridge” version of the source blockchain coin that has been converted to a fungible token in Ethereum Virtual Machine (EVM) compatible blockchains. A ty pical “wrapping” may include locking or burning a token4DM_US 2136129S2-1 120640 0015Attorney Docket No.: 120640-0015 on the source blockchain and then releasing or minting on the target blockchain. These actions can be reversed to move a token back to the original source blockchain. Once the users receive their token in the target blockchain, they are free to use them as they please because they have their assets in their crypto wallet in the target blockchain that gives them full control. The source blockchain address and the target blockchain addresses may be the same. The users can interact with many different dApps of their choice from this point forward. Accordingly, assets named slightly different amongst different blockchains can become increasingly confusing and error prone as the number of assets and blockchains involved increases.

[0021] According to the present disclosure, users can buy a crypto token that is not available in the blockchain where they currently have their funds. Users may deposit their token or blockchain assets into a smart contract in their originating / host chain from their crypto wallet. For example, a user in host blockchain H comprising token or native coin X may w'ant to buy token or native coin Y that is only available in blockchain T. In some embodiments, a token X may be locked in a smart contract in blockchain H. A cross-chain message may be sent (e.g., via a third-party bridge) to blockchain T from blockchain H, and a smart contract in blockchain T releases the token Y to the user’s crypto wallet. According to some embodiments, the price of token Y is predetermined. Therefore, the trading process may be performed fully on-chain.

[0022] In some embodiments, ownership of the user’s token X may be immediately transferred from the user’s wallet to the smart contract in blockchain H. This “fire and forget” scenario relies upon the transaction being guaranteed with zero risk of slippage. In other embodiments, the token X may be held in escrow, and ownership transferred to the smart contract upon receiving confirmation that the transaction has completed at blockchain T. For example, a cross-chain message may be sent (e.g., via a third-party bridge) from blockchain T to blockchain H, which then releases the token from escrow'. As an example, the tokens may be held in escrow' in the same smart contract or in a separate smart contract.

[0023] As another example, the user can sell token or native coin Y from blockchain T . In this instance, the token or native coin X is released in blockchain H, or if available the token or native coin X is delivered in another blockchain C, D ,E, etc.

[0024] In some embodiments, pre-funded liquidity pools are maintained on both the host and target blockchains. In the buy example above, in some embodiments the facilitator has to have enough Y inventory in the blockchain T to fulfill the delivery. Likewise, in the sell example5DM_US 2136129S2-1 120640 0015Attorney Docket No.: 120640-0015 above, the facilitator has to have enough X inventory' in the blockchain T, C, D or E to fulfill the delivery. In other embodiments, if there isn't enough inventory of the desired token in the target blockchain, the transaction may be queued rather than failing it outright. After additional inventory' is deposited into the target pool and sufficient inventory' is available, the transaction may then be fulfilled.

[0025] Advantages of some embodiments include eliminating slippage in price, as the predetermined exchange rate can be locked for the transaction. Another advantage is guaranteed delivery', as the transaction will be finalized once inventory' is available. Yet another advantage is the lack of failure or reversion, since unlike systems that rely on external exchanges, some embodiments avoid transaction failure due to price or liquidity changes.

[0026] Unlike traditional swap implementations, in some embodiments the token or native coin X stays in blockchain H during an exchange. Similarly, token or native coin Y always remains in blockchain T. A token that is bought / sold never leaves the originating blockchain. Instead, assets are locked in a smart contract in their host chain. A message may be sent to the smart contract counterpart in the target blockchain, providing specifics of the transaction including but not limited to one or more of order id, nonce, transaction type, user address, token symbol, quantity, and timestamp. A portfolio bridge contract may be used to transmit the message. Once the message is received by its counterpart, a token or native coin of the counterpart is released to the user’s crypto wallet. The users can exchange their assets with any other that is deemed tradable by the administrator in both the host and the target blockchains.

[0027] FIG. 1 illustrates a network architecture used for a blockchain and smart contracts, as disclosed herein. The network architecture of FIG. 1 includes one or more client devices and one or more servers which are communicatively coupled through the network. The servers provide services such as Internet based services including web2 services and web3 services, for example, to the client devices. As such, the servers may implement a computer application for a smart contract, cryptocurrency-based services, transaction services, payment services, look up sendees, data services, query sendees, and the like. The network may include a wired network (e.g, via fiber optic or copper wire, telephone lines, and the like) or wireless network (e.g., a cellular network, radio-frequency (RF) network. Wi-Fi. Bluetooth, and the like). The client devices may be any one of a mobile device, a laptop, a desktop, a tablet (e.g., palm or pad) device, a television, a display device, and / or the like.6DM_US 2136129S2-1 120640 0015Attorney Docket No.: 120640-0015

[0028] FIG. 2 is a block diagram 200 illustrating components and steps in a network including multiple host blockchains (e.g., MainnetRfq Hostl 211. MainnetRfq Host2 212, ... MainnetRfq Hostn 213) linked to a target blockchain MainnetRfq Target 214 hosting multiple users via a bridge application 215. In some embodiments, one or more bridges (e.g., bridge 1, bridge 2, ... bridge n) may connect one or more host blockchains with one or more target blockchains.

[0029] The target blockchain holds a portfolio of fungible assets for each user (e.g., fungible asset 221, fungible asset 222). Messages may be exchanged between the host blockchains and the bridge application 215 via bridge aggregators, described below. The information flow for messages between MainnetRfq host and MainnetRfq target, may be as follows:MainnetRfq Host (1 / 2 / n) => PortfolioBridgeMain(l / 2 / n) => BridgeProvider(l / 2 / n) => PortfolioBridgeMain => MainnetRfq TargetMainnetRfq Target=> PortfolioBridgeMain => BridgeProviderl / 2 / n => PortfolioBridgeMain(l / 2 / n) => MainnetRfq Host (1 / 2 / n)

[0030] In some embodiments, bridge aggregators in the host chain may relay messages to / from the host chain and are bridge-agnostic. In this example, bridge aggregator PortfolioBridgeMain 1 231 corresponds to MainnetRfq Hostl 211, PortfolioBridgeMainl 232 corresponds to MainnetRfq Hostl 212, and PortfolioBridgeMainl 233 corresponds to MainnetRfq Hostl 213. Accordingly, in some embodiments, the bridge application 215 may be a third-party application.

[0031] In some embodiments, a bridge aggregator in the target blockchain may also relay messages to / from the target blockchain and is also bridge-agnostic. In this example, bridge aggregator '‘PortfolioBridgeMain” 251 in the host chain validates the symbol with the destination blockchainid before the message is transmitted to target chain for extra layer of security. Similarly, the bridge aggregators (e.g., PortfolioBridgeMainl 231, PortfolioBridgeMain2 232, PortfolioBridgeMain3 233, etc. in the host chain also validate the incoming message before passing it along to their corresponding blockchains (e.g., MainnetRfq Hostl 211, MainnetRfq Host2 212, MainnetRfq Host3 213, etc.) for the delivery of the token in the received message.

[0032] In some embodiments, a third-party bridge application “Layer Zero” (not shown in FIG. 2) may provide an initial setup where both the PortfolioBridgeMain of the host chain and the PortfolioBridgeMain of the target chain are securely tied and only transmit messages amongst each other. Layer Zero may include security protocols to make sure the messages have7DM_US 2136129S2-1 120640 0015Attorney Docket No.: 120640-0015 a guaranteed delivery, are delivered in sequence (without skipping a nonce), and remain immutable while they are being transmitted.

[0033] FIG. 3 is a block diagram 300 illustrating cross chain swaps, according to one or more embodiments. A user, having a crypto wallet 305 in host blockchain 310 and another crypto wallet 311 in target blockchain 315, can initiate buying a token Y which can only exist in target blockchain 315. The request can only be initiated in host blockchain 310, not in the target blockchain 315. For example, to buy a token Y, the user sends token X to a smart contract 320 of host blockchain 310. The token X stays in the smart contract 320 of the host blockchain 310. The host blockchain 310 sends, via a portfolio bridge application 360. a “deliver token Y” message to the target blockchain 315. Upon receiving the message, a smart contract 330 of the target blockchain 315 deposits the token Y into the crypto wallet 311 in the target blockchain 315, assuming there is enough token Y inventory at the target blockchain 315. If there is not enough inventory, the message may be queued to be processed when inventory' is made available by the admins.

[0034] The user may also sell token Y. The selling operation can only be initiated in the target blockchain 315. The user sends, from their crypto wallet 311, a token Y to the smart contract 330 of the target blockchain 315. Token Y can only exist in the target blockchain 315. Therefore, the smart contract 330 of the target blockchain 315 sends, via a portfolio bridge application 361, a “deliver token X” message to the host blockchain 310. Upon receiving the message, the host blockchain 310 deposits token X into the user’s cry pto wallet 305 in the host blockchain 310, assuming there is enough token X inventory’ at the host blockchain 310. If there is not enough inventory, the message may be queued to be processed when inventory is made available by the admins.

[0035] In some embodiments, an initial inventory of the tokens that are allowed to be swapped are supplied to the smart contracts on each host / target blockchain (e.g., smart contract 320 and smart contract 330) by the admins. Admins are also responsible for manual or automated periodic rebalancing of the tokens in case of deficit or excess of certain tokens.

[0036] In some embodiments, the smart contracts on each host / target blockchain (e.g., smart contract 320 and smart contract 330) take advantage of off chain prices supplied by admins to provide token swaps on Ethereum Virtual Machine (EVM)-compatible or non-EVM compatible chains. Users may request a quote via a Request For Quote (RFQ) API that is off-chain. Using8DM_US 2136129S2-1 120640 0015Attorney Docket No.: 120640-0015 this quote, they may execute the cross chain swaps using a function call (e.g., xChainSwap() call) which locks funds in the current (host) chain and sends a message to the destination (target) chain to release funds. The smart contract may also support executing a traditional swap on the current chain (e.g., simpleSwap() or partialSwapQ calls) where the exchange of the tokens happens immediately in the current chain.

[0037] According to some embodiments, an API call for a swap function with a quote may be configured to exchange a taker asset (assets involved in orders placed by a "taker," who matches and executes against existing buy or sell orders) with a maker asset (those involved in orders placed by a "maker," who creates a new buy or sell order). In times of high volatility, the API may adjust the expiry of the quote. Embodiments may include monitoring (e.g.. via a SwapExpired() event) to verify if a swap has been adjusted. Adjusting the quote may be resorted to in periods of high volatility for quotes that do not properly represent the liquidity of the blockchain.

[0038] FIG. 4 is a block diagram illustrating an exemplary computer system 400 with which aspects of the subject technology can be implemented. In certain aspects, the computer system 400 may be implemented using hardware or a combination of software and hardw are, either in a dedicated server, integrated into another entity, or distributed across multiple entities.

[0039] Computer system 400 (e.g., server and / or client) includes a bus 408 or other communication mechanism for communicating information, and a processor 402 coupled with bus 408 for processing information. By way of example, the computer system 400 may be implemented with one or more processors 402. Processor 402 may be a general-purpose microprocessor, a microcontroller, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a state machine, gated logic, discrete hardware components, or any other suitable entity that can perform calculations or other manipulations of information.

[0040] Computer system 400 can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them stored in an included memory 404, such as a Random Access Memory (RAM), a flash memory, a Read-Only Memory (ROM), a Programmable Read-Only Memory (PROM), an Erasable PROM (EPROM), registers, a hard disk, a removable disk, a CD-9DM_US 2136129S2-1 120640 0015Attorney Docket No.: 120640-0015ROM, a DVD, or any other suitable storage device, coupled to bus 408 for storing information and instructions to be executed by processor 402. The processor 402 and the memory 404 can be supplemented by, or incorporated in, special purpose logic circuitry.

[0041] The instructions may be stored in the memory' 404 and implemented in one or more computer program products, i.e.. one or more modules of computer program instructions encoded on a computer-readable medium for execution by, or to control the operation of, the computer system 400, and according to any method well-known to those of skill in the art, including, but not limited to, computer languages such as data-oriented languages (e.g., SQL, dBase), system languages (e.g., C. Objective-C. C++. Assembly), architectural languages (e.g., Java. .NET), and application languages (e.g., PHP. Ruby, Perl, Python). Instructions may also be implemented in computer languages. Memory' 404 may also be used for storing temporary variable or other intermediate information during execution of instructions to be executed by processor 402.

[0042] A computer program as discussed herein does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, subprograms, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication netw ork. The processes and logic flow s described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output.

[0043] Computer system 400 further includes a data storage device 406 such as a magnetic disk or optical disk, coupled to bus 408 for storing information and instructions. Computer system 400 may be coupled via input / output module 410 to various devices. The input / output module 410 can be any input / output module. Exemplary input / output modules 410 include data ports such as USB ports. The input / output module 410 is configured to connect to a communications module 412. Exemplary' communications modules 412 include networking interface cards, such as Ethernet cards and modems. In certain aspects, the input / output module 410 is configured to connect to a plurality of devices, such as an input device 414 and / or an output device 416. Exemplary input devices 414 include a keyboard and a pointing device, e.g., a mouse or a trackball, by which a user can provide input to the computer system 400. Other10DM_US 2136129S2-1 120640 0015Attorney Docket No.: 120640-0015 kinds of input devices 414 can be used to provide for interaction with a user as well, such as a tactile input device, visual input device, audio input device, or brain-computer interface device. For example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, audi lory feedback, or tactile feedback, and input from the user can be received in any form, including acoustic, speech, tactile, or brain wave input. Exemplary output devices 416 include display devices such as an LCD (liquid crystal display) monitor, for displaying information to the user.

[0044] According to one aspect of the present disclosure, the above-described gaming systems can be implemented using a computer system 400 in response to processor 402 executing one or more sequences of one or more instructions contained in memory 404. Such instructions may be read into memory 404 from another machine-readable medium, such as data storage device 406. Execution of the sequences of instructions contained in the main memory 404 causes processor 402 to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in memory 404. In alternative aspects, hard-wired circuitry may be used in place of or in combination with software instructions to implement various aspects of the present disclosure. Thus, aspects of the present disclosure are not limited to any specific combination of hardware circuitry and software.

[0045] Various aspects of the subject matter described in this specification can be implemented in a computing system that includes a back end component, e.g., such as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g.. a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. The communication network can include, for example, any one or more of a LAN, a WAN, the Internet, and the like. Further, the communication network can include, but is not limited to, for example, any one or more of the following network topologies, including a bus network, a star network, a ring network, a mesh network, a star-bus network, tree or hierarchical network, or the like. The communications modules can be, for example, modems or Ethernet cards.11DM_US 2136129S2-1 120640 0015Attorney Docket No.: 120640-0015

[0046] Computer system 400 can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. Computer system 400 can be, for example, and without limitation, a desktop computer, laptop computer, or tablet computer. Computer system 400 can also be embedded in another device, for example, and without limitation, a mobile telephone, a PDA. a mobile audio player, a Global Positioning System (GPS) receiver, a video game console, and / or a television set top box.

[0047] The term “machine-readable storage medium” or “computer-readable medium” as used herein refers to any medium or media that participates in providing instructions to processor 402 for execution. Such a medium may take many forms, including, but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks, such as data storage device 406. Volatile media include dynamic memory, such as memory 404. Transmission media include coaxial cables, copper wire, and fiber optics, including the wires that comprise bus 408. Common forms of machine-readable media include, for example, floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH EPROM, any other memory chip or cartridge, or any other medium from which a computer can read. The machine- readable storage medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more of them.

[0048] As the user computing system 400 reads game data and provides a game, information may be read from the game data and stored in a memory device, such as the memory 404. Additionally, data from the memory 404 servers accessed via a network, the bus 408, or the data storage 406 may be read and loaded into the memory 404. Although data is described as being found in the memory 404, it will be understood that data does not have to be stored in the memory 404 and may be stored in other memory accessible to the processor 402 or distributed among several media, such as the data storage 406.

[0049] FIG. 5 is a flowchart illustrating a process 500 for cross-chain transactions performed by a client device (e.g., from client devices 110) and / or a client server (e.g., from servers 130), according to some embodiments. In some embodiments, one or more operations in process 50012DM_US 2136129S2-1 120640 0015Attorney Docket No.: 120640-0015 may be performed by a processor executing instructions stored in a memory circuit of a sy stem as disclosed herein. For example, some operations in process 500 may be performed by various software modules, hardware elements, or some combination thereof. Moreover, in some embodiments, a process consistent with this disclosure may include at least operations in process 500 performed in a different order, simultaneously, quasi-simultaneously, or overlapping in time.

[0050] At 510, the process 500 includes receiving, from a user, a request to exchange an amount of a first token on a first blockchain for a second token on a second blockchain. In some embodiments, the request may be received via an Application Programming Interface (API).

[0051] At 520. the process 500 includes executing a smart contract on the first blockchain to lock the amount of the first token. In some embodiments, executing the smart contract includes receiving the amount of the first token directly from a user-owned wallet associated with the first blockchain.

[0052] In some embodiments, ownership of the first token may be immediately transferred from the user to the smart contract on the first blockchain. This “fire and forgef ’ scenario may be enabled by virtue of the transaction being guaranteed with zero risk of slippage. In other embodiments, the smart contract (or another smart contract on the first blockchain) holds the amount of the first token in escrow' until the transaction is finalized. Ownership may then be transferred to the smart contract upon receiving confirmation that the transaction has been completed at the second blockchain, as discussed below7with reference to operation 540 of process 500.

[0053] At 530, the process 500 includes determining an equivalent amount of the second token that corresponds to the first amount of the first token. The equivalent amount may, for example, be based on the amount of the first token and an exchange rate of the first token to the second token. The exchange rate may be a pre-determined exchange rate, a real-time exchange rate, a received exchange rate, or calculated according to other criteria, including but not limited to user criteria, blockchain criteria, and token criteria. The exchange rate may be locked at the time of the request, to ensure that there is no slippage for the transaction, even if the transaction is not immediately completed.

[0054] At 535, the process 500 may also determine whether a smart contract on the second blockchain stores sufficient inventory of the second token, i.e., the amount determined above at 530. If the smart contract on the second blockchain has sufficient inventory of the second token,13DM_US 2136129S2-1 120640 0015Attorney Docket No.: 120640-0015 the process 500 continues to 540, which is described below. If the smart contract on the second blockchain does not have sufficient inventory of the second token, the process 500 continues to 536, which is described below.

[0055] In some embodiments, determination of the exchange rate and / or inventory' availability7in steps 530 and 535 may be performed by an off-chain controller. This component may maintain real-time data about token inventories across blockchains and facilitates pricing decisions, in order to guarantee delivery7and avoid slippage.

[0056] In some embodiments, the process 500 may send a message from the smart contract on the first blockchain to the smart contract on the second blockchain, to authenticate, initiate and / or validate the transaction. The process 500 may perform operations at one or more of 530, 535, 536, 537, and / or 540 as described below, based on receipt and / or contents of the message. The message may include specifics of the transaction including but not limited to one or more of an order id, a nonce, a transaction type, a user address, a token symbol, a quantity, and a timestamp.

[0057] At 536, the process 500 places the request into a queue. Alternatively, the request may already be in the queue, and the process maintains the request therein.

[0058] At 537, the process 500 determines whether the amount of the second token in the smart contract on the second blockchain has been replenished. The second token may be replenished by a manual process performed by an administrator, or an automated process activated based on trigger conditions or other criteria. If the amount of the second token has been sufficiently replenished, the process continues to 540, which is described below. In this case, the determination at 537 also keeps track of the needed amount of the second token associated with the request.

[0059] Alternatively (though not shown in FIG. 5), the process 500 may simply assess that there has been some type of wallet activity7, and the process 500 may return to 535, which is described above. In this case, the determination at 537 does not need to track the needed amount of the second token associated with the request.

[0060] At 540, the process 500 includes executing the smart contract on the second blockchain to transfer the amount of the second token to a user-ow ned wallet associated w ith the second blockchain. The user-owned wallets may have the same wallet addresses on both blockchains, or different wallet addresses. The second amount of the second token may be directly transferred14DM_US 2136129S2-1 120640 0015Attorney Docket No.: 120640-0015 from the smart contract on the second blockchain to the user-owned wallet on the second blockchain.

[0061] In some embodiments in which the first token is held in escrow on the first blockchain, the process 500 may send a cross-chain message (e.g., via a third-party bridge) from the second blockchain to the first blockchain to validate and / or finalize the transaction, upon which the first token is released from escrow. The message may include specifics of the transaction including but not limited to one or more of an order id, a nonce, a transaction type, a user address, a token symbol, a quantity7, and a timestamp.

[0062] Some embodiments provide a computer-implemented method, that includes: receiving a request for a transaction at a first blockchain from a user associated with swapping a token from a second blockchain, the first blockchain comprising token X and second blockchain comprising token Y, locking token X in a smart contract in the first blockchain, transmitting, via bridge, a generic message from the first to the second blockchain, releasing the token Y from a smart contract in the second blockchain B to a crypto wallet of the user.

[0063] Some embodiments provide a non-transient computer-readable storage medium having instructions embodied thereon, the instructions being executable by one or more processors to perform a method that includes: receiving a request for a transaction at a first blockchain from a user associated with swapping a token from a second blockchain, the first blockchain comprising token X and second blockchain comprising token Y, locking token X in a smart contract in the first blockchain, transmitting, via bridge, a generic message from the first to the second blockchain, releasing the token Y from a smart contract in the second blockchain B to a crypto wallet of the user.

[0064] Some embodiments provide a system that includes one or more processors, and a memory storing instructions which, when executed by the one or more processors, cause the system to perform operations including: receiving a request for a transaction at a first blockchain from a user associated with swapping a token from a second blockchain, the first blockchain comprising token X and second blockchain comprising token Y, locking token X in a smart contract in the first blockchain, transmitting, via bridge, a generic message from the first to the second blockchain, releasing the token Y from a smart contract in the second blockchain B to a crypto wallet of the user.15DM_US 2136129S2-1 120640 0015Attorney Docket No.: 120640-0015

[0065] Embodiments consistent with the present disclosure may include the embodiments described above, combined with any of the following aspects, in any number and permutation thereof or any other combination of features described in aspects of embodiments described herein.

[0066] Aspect 1. wherein the methods and systems further include wherein the price of token Y is predetermined. Aspect 2, wherein the swapping is performed fully on-chain. Aspect 3, wherein the methods and systems further include receiving a request for a quote via an API, and executing a swap on the first blockchain based on the API. Aspect 4, wherein the generic message is targeted to multiple different chains.

[0067] As used herein, the phrase "‘at least one of’ preceding a series of items, with the terms “and” or “or” to separate any of the items, modifies the list as a whole, rather than each member of the list (i.e. , each item). The phrase “at least one of’ does not require selection of at least one item; rather, the phrase allows a meaning that includes at least one of any one of the items, and / or at least one of any combination of the items, and / or at least one of each of the items. By way of example, the phrases “at least one of A, B, and C” or “at least one of A, B, or C” each refer to only A. only B, or only C; any combination of A, B, and C; and / or at least one of each of A, B, and C.

[0068] To the extent that the term “include,” “have,” or the like is used in the description or the clauses, such term is intended to be inclusive in a manner similar to the term “include” as “include” is interpreted when employed as a transitional word in a clause. The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0069] A reference to an element in the singular is not intended to mean “one and only one” unless specifically stated, but rather “one or more.” All structural and functional equivalents to the elements of the various configurations described throughout this disclosure that are known or later come to be known to those of ordinary' skill in the art are expressly incorporated herein by reference and intended to be encompassed by the subject technology. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the above description. No clause element is to be construed under the provisions of 35 U.S.C. §112, sixth paragraph, unless the element is expressly recited using the16DM_US 2136129S2-1 120640 0015Attorney Docket No.: 120640-0015 phrase “means for’ or, in the case of a method clause, the element is recited using the phrase “step for.”

[0070] While this specification contains many specifics, these should not be construed as limitations on the scope of what may be claimed, but rather as descriptions of particular implementations of the subject matter. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

[0071] The subject matter of this specification has been described in terms of particular aspects, but other aspects can be implemented and are within the scope of the following clauses. For example, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. The actions recited in the clauses can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the aspects described above should not be understood as requiring such separation in all aspects, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.17DM_US 2136129S2-1 120640 0015

Claims

Attorney Docket No.: 120640-0015CLAIMS1. A method for cross-blockchain transactions, comprising: receiving, from a user, a request to exchange a first amount of a first token on a first blockchain for a second token on a second blockchain; executing a first smart contract on the first blockchain to lock the first amount of the first token; based on the first amount of the first token and an exchange rate of the first token to the second token, determining a second amount of the second token that corresponds to the first amount of the first token; and executing a second smart contract on the second blockchain to transfer the second amount of the second token to a wallet owned by the user, the wallet being associated with the second blockchain.

2. The method of claim 1, wherein the wallet is a first wallet, and executing the first smart contract comprises receiving the first amount of the first token directly from a second wallet owned by the user, the second wallet being associated with the first blockchain.

3. The method of claim 1, wherein the wallet is a first wallet, and the second amount of the second token is directly transferred from the second smart contract.

4. The method of claim 3, further comprising: upon receiving the request, making a first determination that the second smart contract stores less than the second amount of the second token; responsive to the first determination, placing the request into a queue; and subsequent to placing the request into the queue, making a second determination that the second smart contract stores at least the second amount of the second token, wherein the second amount of the second token is directly transferred from the second smart contract responsive to the second determination.18DM_US 2136129S2-1 120640 0015Attorney Docket No.: 120640-00155. The method of claim 1, wherein the wallet is a first wallet, and executing the first smart contract further comprises transferring ownership of the first amount of the first token from the user to the first smart contract.

6. The method of claim 5, further comprising sending a first message from the first smart contract to the second smart contract, wherein transferring the second amount of the second token is responsive to receiving the first message at the second smart contract.

7. The method of claim 6, further comprising sending a second message from the second smart contract to the first smart contract, wherein transferring ownership of the first amount of the first token is responsive to receiving the second message at the first smart contract.

8. The method of claim 1, wherein the request is received via an Application Programming Interface (API).

9. A non-transitory computer-readable medium storing a program for cross-blockchain transactions, which when executed by a computer, configures the computer to: receive, from a user, a request to exchange a first amount of a first token on a first blockchain for a second token on a second blockchain; execute a first smart contract on the first blockchain to lock the first amount of the first token; based on the first amount of the first token and an exchange rate of the first token to the second token, determine a second amount of the second token that corresponds to the first amount of the first token; and execute a second smart contract on the second blockchain to transfer the second amount of the second token to a wallet owned by the user, the wallet being associated with the second blockchain.

10. The non-transitory computer-readable medium of claim 9, wherein the wallet is a first wallet, and executing the first smart contract comprises receiving the first amount of the first token directly from a second wallet owned by the user, the second wallet being associated with the first blockchain.19DM_US 2136129S2-1 120640 0015Attorney Docket No.: 120640-001511. The non-transitory computer-readable medium of claim 9, wherein the wallet is a first wallet, and the second amount of the second token is directly transferred from the second smart contract.

12. The non-transitory computer-readable medium of claim 11, wherein the program when executed by the computer further configures the computer to: upon receiving the request, make a first determination that the second smart contract stores less than the second amount of the second token; responsive to the first determination, place the request into a queue; and subsequent to placing the request into the queue, make a second determination that the second smart contract stores at least the second amount of the second token, wherein the second amount of the second token is directly transferred from the second smart contract responsive to the second determination.

13. The non-transitory computer-readable medium of claim 9, wherein the wallet is a first wallet, and executing the first smart contract further comprises transferring ownership of the first amount of the first token from the user to the first smart contract.

14. The non-transitory computer-readable medium of claim 13, wherein the program when executed by the computer further configures the computer to send a first message from the first smart contract to the second smart contract, wherein transferring the second amount of the second token is responsive to receiving the first message at the second smart contract.

15. The non-transitory computer-readable medium of claim 14, wherein the program when executed by the computer further configures the computer to send a second message from the second smart contract to the first smart contract, wherein transferring ownership of the first amount of the first token is responsive to receiving the second message at the first smart contract.

16. A system for cross-blockchain transactions, comprising: one or more processors; and20DM_US 2136129S2-1 120640 0015Attorney Docket No.: 120640-0015 a non-transitory computer readable medium storing a set of instructions, which when executed by at least one of the one or more processors, configure the system to: receive, from a user, a request to exchange a first amount of a first token on a first blockchain for a second token on a second blockchain; execute a first smart contract on the first blockchain to lock the first amount of the first token; based on the first amount of the first token and an exchange rate of the first token to the second token, determine a second amount of the second token that corresponds to the first amount of the first token; and execute a second smart contract on the second blockchain to transfer the second amount of the second token to a wallet owned by the user, the wallet being associated with the second blockchain.

17. The system of claim 16, wherein the wallet is a first wallet, and executing the first smart contract comprises receiving the first amount of the first token directly from a second wallet owned by the user, the second wallet being associated with the first blockchain.

18. The system of claim 16. wherein the wallet is a first wallet, and the second amount of the second token is directly transferred from the second smart contract.

19. The system of claim 16, wherein the instructions when executed further configure the system to: upon receiving the request, make a first determination that the second smart contract stores less than the second amount of the second token; responsive to the first determination, place the request into a queue; and subsequent to placing the request into the queue, make a second determination that the second smart contract stores at least the second amount of the second token, wherein the second amount of the second token is directly transferred from the second smart contract responsive to the second determination.21DM_US 2136129S2-1 120640 0015Attorney Docket No.: 120640-001520. The system of claim 16. wherein the wallet is a first wallet, and executing the first smart contract further comprises transferring ownership of the first amount of the first token from the user to the first smart contract.22DM_US 2136129S2-1 120640 0015

Images