WO2022224188A1

WO2022224188A1 - Systems and methods for multi-currency gaming

Info

Publication number: WO2022224188A1
Application number: PCT/IB2022/053735
Authority: WO
Inventors: Gabriel Joseph HARKHAM; Randall Paul MIDDLETON; Steve Stein
Original assignee: Xmlabs Ltd.
Priority date: 2021-04-21
Filing date: 2022-04-21
Publication date: 2022-10-27

Abstract

Systems, methods, and computer readable media for providing multi-currency gaming are disclosed. Systems, methods, devices, and non-transitory computer readable media may involve at least one processor configured to accept submitted funds from players of a game, wherein each of the players submits funds a different held currency, wherein the submitted funds contribute towards a prize pool; and following a decision point in the game for determining a winning player of the players of the game, to provide the prize pool or a portion thereof to the winning player in the held currency of the winning player.

Description

SYSTEMS AND METHODS FOR MULTI-CURRENCY GAMING

BACKGROUND

An online game may be a video game played over a network on some form of computer, mobile device, or on a video game console. Many online games require skill and strategy and enable players to compete head-to-head, in a tournament, or for the highest score on a leaderboard. Example categories of online skills-based games include first person shooters, real time strategy games, social games, role-playing games, board games, card games, etc.

Some skills-based gaming sites require an entry fee or enable players to place wagers on the outcome of the game. Wagering may also take place for any verifiable event (sports events, election results, and so forth). Wagering may also be used by players in luck-based games or events. The wager or entry fee (referred to herein as “funds” may be some form of currency or may be anything of value that may be bartered, traded, or used - collectively referred to herein as “currency.” Players typically provide the funds at the start of the game and a winning player may be paid out after a decisive point in the game. The gaming platform typically takes a playing/management fee or “rake” from the provided funds. The funds may typically be stored in a game “wallet” on the gaming platform. Depending on the currency used, one or more players may be required to convert their funds from the player’s “held currency” into a “gaming currency” accepted by the gaming platform or by the other players.

This currency conversion process may result in inconvenience and uncertainty for players. For example, a player may need to convert a minimum amount of their held currency into the gaming currency and, following completion of the game, may now hold a small remaining amount of gaming currency in a “small wallet” that may be below the minimum amount allowed for conversion back into the held currency. Further, where conversion in both directions is possible, the player may incur conversion fees in both conversion directions. Further, some held currencies may be regarded as “unstable currencies,” such as digital/cryptocurrencies where the currency exchange rate relative to the gaming currency or the other player’s held currency may vary from the game start to the game end. Yet further, some held currencies may not be directly tradeable against the gaming currency, thus necessitating use of an interim currency, further increasing the possibility of unwanted small wallets and unwanted fees.

These currency conversion issues may be magnified by the number of games and gaming platforms, where each may have varying gaming currency requirements, and may ultimately discourage players from playing games due to the above currency conversion issues. This issue may be even further complicated by the advent of metaverses and virtual reality worlds that host gaming environments where players from multiple worlds may wish to compete using their “home- world” currencies.

SUMMARY

This disclosure presents various systems and methods for online gaming systems. Aspects of the systems and methods may be used to enable game players to play against one another using different currencies on any type of game or platform. Aspects of the systems and methods may further be used to enable wagering for any verifiable event such as but not limited to a sports competition or election, where the parties placing a wager may be using different currencies. In some implementations, the platform manages the exchanging of currencies so that each party may provide and receive funds in a held currency of their choice, despite the other party or gaming platform having used a different currency.

Multiple scenarios (for two or multiple players) may be supported by the disclosed system including players with the following currency combinations:

• Fiat or stable currency vs. fiat or stable currency;

• Unstable currency vs. the same unstable currency;

• Fiat or stable currency vs. unstable currency; and

• Unstable currency vs. a different unstable currency.

Advantageously, the above combinations enable players to compete online without inconvenience and uncertainty as players need not be concerned about converting their held currency in order to compete.

The term “currency” as used herein may refer to any one of stable currency, or unstable currency. Stable currencies may be defined herein as currencies having a substantially fixed or substantially stable exchange rate relative to other stable currencies. Stable currencies may include fiat money or cryptocurrencies. In some embodiments, the exchange rate of a stable currency pair may not vary by more than l%-3% per day. Unstable currencies may be defined herein as currencies with a substantially fluctuating exchange rate relative to any stable currency. In some embodiments, the exchange rate of an unstable currency may vary by more than 3% per day relative to a stable currency. Unstable currencies may include cryptocurrencies, tokens, or non- fungible tokens (NFTs), or may be items of value that may be bartered or traded where the comparative value (exchange rate) of two items may not be fixed. As described herein a player may be said to submit or receive funds in a “held currency” (the currency that is held in the player wallet to be used by the player) while other players may submit or receive funds in a “foreign currency” (the held currency of the other players).

The term “game” or “gaming session” as used herein may refer to any verifiable event or any online game where two or more players submit funds (also referred to herein as “entry fee” or wager). Thus, though some wagered-upon events may not be part of a game, the term “game” as used herein should be considered as describing such events as well. The outcome of these games and/or events may be skill-based or luck-based. “Online games” as used herein also may include offline connected (asynchronous) games such as games where a portion of the gameplay may take place while a player may not be online. While the full gameplay process is not described herein it should be appreciated that the act of providing funds and receiving payments may be part of this full gameplay process and only the relevant parts of the gameplay process are described herein.

A “player” as used herein may refer to a participant in a game paying an entry fee or providing a wager in order to compete in a game or place a wager on an event. A player may be any one of a human player, a human controlled player (such as an avatar in a metaverse), or a computer-controlled player (such as an AI player, smart contract, or NFC). As above, although some wagered-upon events may not be games, the participants may nonetheless be referred to herein as “players”.

Players contribute, wager with, or otherwise use “funds” for participating in a game. The combined funds submitted by players may contribute towards a “prize pool” after fee deductions as described herein. A game “decision” or “outcome” as described herein refers to a point in the game or event where one or more players may be defined as eligible to receive the prize pool or a portion thereof. The game decision may be at a decision point mid-game or at the end of the game. In the implementations described herein, a rake may be taken prior to the game, during the game, or after the game. Where a rake is described herein, non-limiting examples of the rake amount may include: a percentage of submitted funds, a fixed value, a variable amount based on costs to support any currency exchange, a consensus amount decided by the players, or a variable amount depending on the number of players (lower for a smaller number and higher for a larger number), and so forth. In some implementations, no rake may be taken. Non-limiting examples of no-rake arrangements include: a free game, free game entry to subscribed players, or a game subsidized by an advertiser or sponsor, and so forth. In some implementations, the rake may include a slippage fee for the currency conversions performed as part of the game. In some implementations, a slippage fee may be included in the entry fee.

In some implementations, either of no rake or a discounted rake may be taken for one or more currencies that may be used by players in a game to thereby incentivize the use of specific currencies by one or more players. In some embodiments, either of no rake or a discounted rake may be taken for one or more currencies that may be used by a player in a game where the player chooses to use a specific currency for which the no-rake or discounted rake is provided, while still using a different held currency for playing a game. For example, a user may interact with a game or setting on a user device as described hereinbelow to enable a toggle to use a specific token for receiving a rake discount but still enter into games with other held currencies such that the discounted rake will be taken from the rake discount currency and two currencies would be used for the game.

Where the disclosed system is described herein as holding funds, the holding methods may include but are not limited to entry into a ledger following removal from a player funds, transfer to an escrow wallet via a smart contract, transfer to a reserve wallet via a smart contract, locking of funds into a smart contract, and so forth.

In the below disclosure, a “parent” currency may be said to be swapped into a “wrapped currency” (or “wrapped equivalent currency”) where wrapped currency as used herein refers to a token (currency) that has an exchange rate pegged to the particular parent currency but can operate on a blockchain that supports multiple wrapped currencies (tokens). In a non-limiting example, wrapped bitcoin or WBTC, for example, has a value based on bitcoin exchange rates but may work on the Polygon network alongside other wrapped currencies such as wrapped Ethereum (WETH), where the WETH has a value based on Ethereum exchange rates. In some implementations, a currency/wrapped currency swap may be performed by a currency network gateway that is part of the systems as described herein. In some embodiments, a currency/wrapped currency swap may be provided by a third-party service. In some implementations, the process of currency to wrapped currency swapping may be performed without a fee charge (or alternatively a small charge compared to the fees typically associated with the parent currency blockchains).

It should be appreciated that use of wrapped currencies on a multi-currency blockchain enables players to maintain wallets in a wrapped currency that has the same exchange rates as their preferred held currency while benefiting from a multi-wrapped-currency blockchain that is faster and has lower fees than that of the parent blockchains.

Consistent with disclosed embodiments, systems, methods, and computer readable media for providing multi-currency gaming are disclosed. Systems, methods, devices, and non-transitory computer readable media may involve at least one processor configured to accept submitted funds from players of a game, wherein each of the players submits funds a different held currency, wherein the submitted funds contribute towards a prize pool; and following a decision point in the game for determining a winning player of the players of the game, to provide the prize pool or a portion thereof to the winning player in the held currency of the winning player.

The at least one processor may be further configured to swap the losing player contribution towards the prize pool in the losing player’s held currency into the winning player’s held currency using a cross-token exchange. The at least one processor may be further configured to swap each held currency of the submitted funds into an equivalent wrapped held currency.

The at least one processor may be further configured to swap all or a portion of the losing player contribution towards the prize pool in the losing player’s wrapped held currency into the winning player’s wrapped held currency. The at least one processor may be further configured to when the held currency of a first player is a stable currency and the held currency of a second player is an unstable currency, provide a loan in a stable currency equal to the unstable currency funds, and place the loan on hold.

The at least one processor may be further configured to when the player submitting funds in the stable currency is the winner, remove a rake from the loaned funds and convert the loaned funds remaining after removal of the rake into the held currency of the winning player. The at least one processor may be further configured to when the player submitting funds in the unstable currency is the winner, remove a rake from the funds submitted in the stable currency, settle the loaned funds so as to return the funds in the unstable currency to the winning player, and to convert the stable currency funds remaining after removal of the rake into the held currency of the winning player.

The at least one processor may be further configured to when the held currency of each player is a different unstable currency, provide a loan in stable currency equal to each of the submitted funds in unstable currency, place the loaned funds on hold, remove a rake from the loaned funds of the losing player, and convert the remaining loaned funds after removal of the rake into the held currency of the winning player. The at least one processor may be further configured to when the different held currency of each player is a stable currency, collect a rake from the submitted funds of each player and to convert remaining funds of a losing player after removal of the rake into the held currency of the winning player.

The at least one processor may be further configured to when the held currency of each player is the same unstable currency, place the submitted funds on hold and to remove a rake from each of the submitted funds. In some implementations, a game is one of a verifiable event or an online game where two or more players submit funds as an entry fee. In some implementations, a player is one of a human player, a human controlled player, or a computer-controlled player.

In some embodiments, a non-transitory computer readable medium contains instructions that when executed by at least one processor, cause at least one processor to perform operations including: accepting funds from players of a game, wherein each player submits funds in a different held currency, wherein the combined funds form a prize pool; and following a decision point in the game for determining an outcome or interim outcome of the game, providing a portion of the prize pool to the one or more winning players, each in the held currency of the winning players.

In some embodiments, the held currency of each player may be a stable currency, and the operations further include collecting a rake from the submitted funds of each player and converting the remaining funds of the losing player into the held currency of the winning player. In some embodiments, the held currency of each player may be the same unstable currency and the operations further include placing the submitted funds in escrow and removing a rake from each of the submitted funds. In some embodiments, the held currency of a first player may be a stable currency and held currency of a second player may be an unstable currency and the operations further include: providing a loan in stable currency equal to the unstable funds and placing the loaned funds on hold. In some embodiments, the player providing the stable currency may be the winner and the operations further include removing a rake from the loaned funds and converting the loaned funds into the held currency of the winning player. In some embodiments, the player providing the unstable currency may be the winner and the operations further include removing a rake from the provided stable currency funds, settling the loaned funds, and converting the stable currency funds into the held currency of the winning player. In some embodiments, the held currency of each player may be a different unstable currency and the operations further include providing a loan in stable currency equal to each of the unstable funds, and placing the loaned funds on hold, removing a rake from the loaned funds of the losing player, and converting the loaned funds into the held currency of the winning player.

In some embodiments, a system may include: at least two user devices, wherein each device may be used by a player of a game to play a game; and a competition platform; wherein the competition platform may be configured for accepting funds from the players of a game, wherein each player submits funds in a different held currency, wherein the combined funds form a prize pool; and wherein following a decision point in the game for determining an outcome or interim outcome of the game, providing a portion of the prize pool to the one or more winning players, each in the held currency of the winning players.

In some embodiments, a system may include at least two user devices, wherein each device may be used by a player of a game to play a game; a decentralized ledger; and an oracle, wherein the user devices may be configured for accepting funds from the players of a game, wherein each player submits funds in a different held currency, wherein the combined funds form a prize pool; and wherein following a decision point in the game for determining an outcome or interim outcome of the game, providing a portion of the prize pool to the one or more winning players, each in the held currency of the winning players, wherein the currency management rules may be stored in the decentralized platform, and wherein the oracle confirms the decision point.

This Summary is provided to introduce a selection of concepts in a simplified form that may be further described in the Detailed Description below. It may be understood that this Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. The details of one or more implementations may be set forth in the accompanying drawings and the description below. Other features will be apparent from the description and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments and, together with the description, serve to explain the disclosed principles. In the drawings:

FIG. 1A illustrates a system for providing multi-currency gaming consistent with some implementations described herein;

FIGS. IB- ID are block diagrams of user device implementations in accordance with implementations described herein;

FIG. IE illustrates a system for providing multi -currency gaming consistent with some implementations described herein;

FIG. 2 is a diagram of an example process for processing a multi-currency gaming session in accordance with implementations described herein;

FIG. 3 is a diagram of an example process for processing a multi-currency gaming session in accordance with implementations described herein;

FIGS. 4A and 4B are diagrams of an example process for processing a multi-currency gaming session in accordance with implementations described herein;

FIG. 5 is a diagram of an example process for processing a multi-currency gaming session in accordance with implementations described herein.

FIG. 6 is a diagram of an example process for processing a multi-currency gaming session in accordance with implementations described herein

FIGS. 7A and 7B are diagrams of an example process for processing a multi -currency gaming session involving multiple players in accordance with implementations described herein.

DETAILED DESCRIPTION

Reference will now be made in detail to non-limiting examples within this disclosure, which may be illustrated in the accompanying drawings. The examples are described below by referring to the drawings, wherein like reference numerals refer to like elements. When similar reference numerals are shown, corresponding description(s) are not repeated, and the interested reader is referred to the previously discussed figure(s) for a description of the like element(s).

Aspects of this disclosure may provide a technical solution to the challenging technical problem of gaming or other platforms serving players with different currencies with the system having at least one processor (e.g., processor, processing circuit or other processing structure described herein), including methods, systems, devices, and computer-readable media. For ease of discussion, example methods may be described below with the understanding that aspects of the example methods apply equally to systems, devices, and computer -readable media. For example, some aspects of such methods may be implemented by a computing device or software running thereon. The computing device may include at least one processor (e.g., a CPU, GPU, DSP, FPGA, ASIC, or any circuitry for performing logical operations on input data) to perform the example methods. Other aspects of such systems and methods may be implemented over a network (e.g., a wired network, a wireless network, or both).

As another example, some aspects of such systems and methods may be implemented as operations or program codes in a non-transitory computer-readable medium. The operations or program codes may be executed by at least one processor. Non-transitory computer readable media, as described herein, may be implemented as any combination of hardware, firmware, software, or any medium capable of storing data that may be readable by any computing device with a processor for performing methods or operations represented by the stored data. In a broadest sense, the example methods are not limited to particular physical or electronic instrumentalities, but rather may be accomplished using many differing instrumentalities.

FIGS. 1A-1E illustrate systems 100, 160 for providing multi-currency online gaming and/or event wagering consistent with some implementations described herein. In system 100, users interact with a competition platform 110 and gaming server 120 using user devices 130-1, 130-2, 130-3 to 130-n using wired or wireless network configurations and protocols that facilitate the intercommunication of computing devices. Competition platform 110 may also interact with external services 150 over wired or wireless networks. For example, each of the components of system 100 in FIG. 1 A may be implemented in a localized or distributed fashion in a network.

Competition platform 110 and the modules and components that may be included in competition platform 110 may run on a single computing device (e.g., a server) or multiple computing devices (e.g., multiple servers) that may be configured to perform the functions and/or operations necessary to provide the functionality described herein, the computing devices having at least one processor.

Competition platform 110 and the modules and components that are included in competition platform 110 may include a non-transitory computer readable medium containing instructions that when executed by the at least one processor are configured to perform the functions and/or operations necessary to provide the functionality described herein. Where competition platform 110 may be said herein to provide specific functionality or perform actions, it should be understood that the functionality or actions are performed by the at least one processor executing instructions contained on non-transitory computer readable medium that may call on or interact with other components of competition platform 110 and/or user devices 130 and/or external systems 150 and/or external services 160.

While competition platform 110 is presented herein with specific components and modules, it should be understood by one skilled in the art, that the architectural configuration of system 100 as shown may be simply one possible configuration and that other configurations with more or fewer components may be possible. As referred to herein, the “components” of competition platform 110 may include one or more of the modules or services shown in FIG. 1A as being included within competition platform 110.

A user device 130 may include a non-transitory computer readable medium containing instructions that when executed by at least one processor of user device 130 are configured to perform user device functionality as described herein. User devices 130 may be of varying type, capabilities, operating systems, etc. For example, user devices 130 may include PCs, tablets, mobile phones, laptops, virtual reality or augmented reality glasses or other wearables, holographic interfaces, or any other mechanism that allows for online gaming.

In some embodiments, such as shown in FIG. IB, a user using user device 130 may interact with competition platform 110 via a game app 132 installed on user device 130. Game app 132 may include an interface 136 to interact with competition platform 110 for enabling online gaming in game app 132. Non-limiting examples of interface 136 include, an API, a smart contract, or a coded interface integrated into the game app 132. In some implementations, a user using user device 130 may interact with competition platform 110 via a metaverse application installed on user device 130 that integrates game app 132 within the metaverse. In some embodiments, such as shown in FIG. 1C, a user device 130 may interact with competition platform 110 via a game instance 133 over a web browser 134 running on user device 130. For example, the user may navigate in web browser 134 to a web address provided by a gaming server 120 including an interface 122 for interacting with competition platform 110. Non limiting examples of interface 122 include, an API, a smart contract, or a coded interface integrated into the game. In some implementations, a user using user device 130 may interact with competition platform 110 via a metaverse application provided through a web browser that integrates game instance 133 or game app 132 within the metaverse.

In some embodiments, such as shown in FIG. ID, a user using user device 130 may interact with competition platform 110 via a game client 135 running on user device 130. Game client 135 may be a stand-alone application, one or more application plug-ins, and/or a browser extension. Game client 135 interacts with a gaming server 120 that may include an interface 122 for interacting with competition platform 110. In some implementations, a user using user device 130 may interact with competition platform 110 via a metaverse client running on user device 130 that integrates game client 135 or game app 132 within the metaverse.

Integrations of game apps 132, instances 133 or clients 135 into a metaverse (not shown) environment may be seamless and in such cases reference to game apps 132, instances 133 or clients 135 within the context of a metaverse is intended to include such seamless metaverse implementations.

In FIG. 1A, devices 130-1 and 130-2 are shown as connecting to competition platform 110 such as through interface 136 and devices 130-3 to 130-n are shown as connecting to gaming server 120 that in turn connects to competition platform 110 via interface 122. It should be appreciated that some devices 130 may support multiple types of connections (such as shown in FIGS. IB ID). FIGS. 1B-1D show separate implementations for simplicity.

Interfaces 122 and 136 may be configured to enable users to compete against each other in online games, to enable the users to interact with a competition server 110, and to enable the devices 130 to exchange data with competition server 110. The code of interfaces 122, 136 may be integrated into the code of a game client 132 or gaming server 120. Interfaces 122, 136 may be configured for receiving instructions from the users, transmitting the instructions to the server, receiving data from the server according to the user instructions, and displaying the data to the users. In some embodiments, the code of interfaces 122, 136 may not be game-specific and may be configured for being easily integrated into the code of any game to add online competitive functionality to any game such as of game client 132 and gaming server 120.

Competition platform 110 may include a competition management module 112 that may be configured to enable users to compete against each other in online games. Non-limiting examples of supported online games include player vs player gaming, bracket/tiered gaming competitions, tournaments, luck-based or gambling styles of games or competitions, skill-based gaming, competitions requiring currency or virtual currency entry, offline connected, multiplayer gaming including turn based, real-time, 1 versus 1, any versus any, 1 versus system/platform (bots/automation) or any versus system/platform (bots/automation).

Competition platform 110 may include a currency module 114 that may be configured to enable users holding different combinations of stable and unstable currencies to compete against each other in online games as will be further described below. Currency module 114 may include currency interfaces (not shown) to enable playing/wagering with supported currencies. Non limiting examples of currency interfaces include fiat handlers (bank accounts in multiple currencies), cryptocurrency wallets, currency exchange interfaces, interfaces to currency network bridges for providing wrapped currencies, smart contracts, and so forth.

In system 160, users interact with a decentralized platform such as blockchain 162 using user devices 130. using wired or wireless network configurations and protocols that facilitate the intercommunication of computing devices. In the embodiment of system 160, user devices 130 rely on, for example, a smart contract 164 on blockchain 162 to define the currency conversion rules (and other functionality that would be provided by platform 110) based on the outcome of a game or event. Smart contract 164 may also provide for rake payments to a 3 ^rd party. In some embodiments, the outcome may be provided or confirmed by a trusted oracle 166. In some embodiments, the game/event outcome may be provided by the game client 135 or instance 133 running on devices 130-1 and 130-2. In some embodiments, one or all of devices 130, smart contract 164, and/or the oracle 166 may be in data communication with external systems 150 for receiving the game/event outcome.

In system 160, interfaces 122 and 136 may be configured to enable users to compete against each other and to interact with a decentralized system such as blockchain 162. In some embodiments, devices 130 (here shown as 130-3 and 130-4) configured in any of the embodiments of FIGS. 1B-1D, may play/wager against one another directly such as by using a wireless interface. In such embodiments, the currency conversion rules may be integrated into any of game app 132, game instance 133, and/or game client 135. In some embodiments, game app 132, game instance 133, and/or game client 135 may be in data communication with one or both of an oracle 166 or external system 150 for receiving or confirming a game/event outcome.

In some implementations, system 160 may include a currency network bridge 168 for conversion of currencies (such as fiat or tokens) to the currency supported by blockchain 162. In a non-limiting example, in system 160, blockchain 162 may support wrapped (tokenized) versions of currencies held and used by players such as but not limited to Ether eum, Bitcoin, Tezos, etc.

In some embodiments, currency network bridge supports unstable currencies for the purposes of games played on systems 100 or 160. A non-limiting example of a blockchain supporting wrapped currencies is the Polygon network. In use, currency network bridge 168 may allocate an equivalent amount of a wrapped currency into a player’s wrapped currency wallet on blockchain 162 in order to allow that player to participate in a game. For example, a player may use their held BTC that may be converted by currency network bridge 168 into an equivalent amount of wrapped BTC tokens on blockchain 162 in a player wallet. Similarly, other competing players may be provided each with a player wallet of their own wrapped tokens.

All game transactions (rakes, fees, prize pool allocations) may then take place within blockchain 162. Following completion of a game, players may be provided with funds in their held currency that have been converted back by currency network bridge 168. It should be appreciated that the approach described above using currency network bridge 168 and wrapped tokens may not require slippage fees for the currency/wrapped token pair and players therefore may not incur costs to use wrapped versions of their held currencies on blockchain 162 as part of a game.

In some implementations, currency module 114 of system 100 may also utilize a currency network bridge as part of competition platform 110.

Competition platform 110 and/or smart contract/s 164 may be provided and operated by a “platform operator”. Rake fees may be collected by the platform operator during games. The operator may offer discounts on rake fees or may waive rake fees paid in an operator-defined rake currency in order to incentivize use of the operator-defined rake currency.

In some implementations, currency conversions as described herein may use a liquidity pool (not shown) managed by the platform operator or by an external 3rd party. In some embodiments, currency conversions as described herein may use currency reserves held by the platform operator or by an external 3rd party.

FIG. 2 is a diagram of an example process 200 for processing a multi-currency gaming session in accordance with implementations described herein. This process 200 may for example be performed by system 100 or 160 as described above. The steps below are described with reference to a non-transitory computer readable medium containing instructions that when executed by one processor performs one or more of operations described at each step. The processor may correspond to competition platform 110 and/or user device 130 or a processor that partakes in operation of blockchain 162.

In process 200, two or more players may join a gaming session where the funds submitted by all the players may be of fiat money or a stable currency. FIG. 2 shows process 200 for two players but it should be appreciated that multiple players may be supported. In step 202, as part of the gameplay process, the players submit the funds (entry fee) in each players held currency. In some implementations, the players may not be aware that other players may be using a foreign currency different to their held currency.

In some implementations, the competition platform displays the entry fee to each player according to one of the held currency used by that player based on a current exchange rate, a stable currency that may or may not be the held currency, a listing of multiple currencies, or a currency chosen by the player. As illustrated, Player 1 submits funds in a first (fiat or stable) currency and Player 2 submits funds in a second (fiat or stable) currency.

In step 204, in some implementations, a rake may be taken from the submitted funds for each of the players. The remaining funds (after deduction of the rake) form the prize pool and include both of the first and second fiat or stable currency. In step 206, following a decision in the game as to a winner, the winning player may be awarded the prize pool. In process 200 as illustrated, Player 2 is shown as the winner and Player 1 as the loser, but it should be appreciated that this outcome is purely illustrative. The portion of the prize pool that is in a foreign currency may be converted into the held currency of the winning player and, in step 208, the prize pool including a held currency and converted foreign currency may be awarded to the winning player in the players held currency. In step 210, in most game scenarios the losing player receives no prize for having played and the losing player therefore loses their funds. Advantageously, both players use their held currencies to play the game and are not required to perform any conversion of their held currencies into a gaming currency. In some implementations, in step 208, the winning player may choose to receive the prize pool in more than one currency including both of the held first currency portion and the second (foreign) currency portion with no currency conversion.

In some implementations, in step 208, the winning player may choose to receive the prize pool in a currency of their choice (optionally with the deduction of a slippage fee). In some implementations, in step 208, the winning player may choose to receive winnings in a specific currency associated with a discount on the rake or no rake such that the prize pool may include the winning player’s rake contribution or a return of at least a discounted portion of the winning player’s rake contribution.

FIG. 3 is a diagram of an example process 300 for processing a multi-currency gaming session in accordance with implementations described herein. This process 300 may for example be performed by system 100 or 160 as described above. The steps below are described with reference to a non-transitory computer readable medium containing instructions that when executed by one processor performs one or more of operations described at each step. The processor may correspond to competition platform 110 and/or user device 130 or a processor that partakes in operation of blockchain 162 and currency network bridge 168.

In process 300, two or more players may join a gaming session where the funds submitted by all the players may be of the same unstable currency (displayed as “BTC” in Fig. 3). FIG. 3 shows process 300 for two players but it should be appreciated that multiple players may be supported. In step 302, as part of the gameplay process, the players submit the funds (entry fee) in the same unstable held currency. The submitted funds may be held in escrow during the gameplay. In some implementations, the unstable currency used by the players may be swapped into a wrapped equivalent currency prior to the start of gameplay. For example, the BTC of a player may be placed on hold while an equivalent (wrapped) WBTC is allocated to a player wallet for use within the game. Thus “BTC” as used in FIG. 3 may refer to WBTC. It should be appreciated that the use of BTC and WBTC is illustrative, and any currency and its wrapped equivalent may be used.

In step 304, in some implementations, a rake may be removed from the submitted funds for each of the players. The rake amount or a no-rake arrangement may be as described in the Summary above. The rake may actually be taken prior to the game, during the game, or after the game. The remaining funds (after deduction of the rake) form the prize pool. In step 306, following a decision in the game as to a winner, the winning player may be awarded the prize pool where step 306 may include removing the hold on both players submitted funds. In process 300 as illustrated, Player 1 is shown as the winner and Player 2 as the loser, but it should be appreciated that this outcome is purely illustrative. Since both players are using the same unstable currency, no currency conversion is needed. In most game scenarios in step 308 the losing player receives no prize for having played and the losing player therefore loses their funds that were previously placed on hold. Advantageously, since no currency conversion is required, no currency conversion fees are incurred, and no unneeded wallets are formed.

Where a wrapped currency was used, the swap from the wrapped currency back to the player’s held currency may take place when the prize is awarded or alternatively a player may continue to use the wallet of the wrapped currency for further gameplay and only perform the reverse currency swap (back to the parent currency) at a later time. When a reverse currency swap takes place for the awarded prize pool, the player’s original held parent currency that was put on hold may be released along with the additional amount won in the game.

In some implementations, in step 306, the winning player may choose to receive winnings in a specific currency associated with a discount on the rake or no rake such that the prize pool may include the winning player’s rake contribution or a return of at least a discounted portion of the winning player’s rake contribution.

FIGS. 4A and 4B are diagrams of an example process 400 for processing a multi-currency gaming session in accordance with implementations described herein. This process 400 may for example be performed by system 100 or 160 as described above. The steps below are described with reference to a non-transitory computer readable medium containing instructions that when executed by one processor performs one or more of operations described at each step. The processor may correspond to competition platform 110 and/or user device 130 or a processor that partakes in operation of blockchain 162 and currency network bridge 168.

In process 400, two or more players may join a gaming session where the funds submitted by a first player are of fiat money or a stable currency and those of a second player are of an unstable currency. FIG. 4A shows process 400 when the game is won by the player using stable currency and FIG. 4B shows process 400 when the game is won by the player using the unstable currency. FIGS. 4A and 4B show process 400 for two players but it should be appreciated that multiple players may be supported.

In step 402, as part of the gameplay process, the players submit the funds (entry fee) in each players held currency. In some implementations, the players may not be aware that other players may be using a foreign currency different to their held currency. In some implementations, the competition platform displays the entry fee to each player according to the held currency used by that player based on a current exchange rate. As illustrated, Player 1 submits funds in a first currency (unstable - here shown as “BTC”) and Player 2 submits funds in a second currency (stable - here shown as “Fiat or stable”).

In some implementations, both of the stable and unstable currency used by the players may be swapped into wrapped equivalent currencies prior to the start of gameplay. For example, the BTC of Player 1 may be placed on hold while an equivalent (wrapped) WBTC is allocated to a Player 1 wallet for use within the game. Thus “BTC” as used in FIG. 4 may refer to WBTC and the fiat or stable currency may refer to an equivalent wrapped version of the fiat or stable currency. It should be appreciated that the use of BTC and WBTC is illustrative, and any currency and its wrapped equivalent may be used.

To facilitate handling of the unstable currency, process 400 provides for an interim loan of a stable currency equivalent to the unstable currency with the addition of a loan (lending) fee while the funds provided in unstable currency may be held. Thus, more specifically in step 402-1 since the first currency is an unstable currency, the unstable currency player’s entry fee may be calculated to include a lending fee in addition to the game entry fee. In some implementations, the process of managing the loan may be transparent to the player with the unstable currency, i.e.: the player simply provides an entry fee in the unstable currency and either wins or loses funds in the same held (unstable) currency without knowing that a loan process has taken place. For the player with the stable currency, in step 402-2, the entry fee may be held pending the result of the game.

In step 404-1, an interim loan of a stable currency (shown as “USDT” in FIG. 4A) equivalent to the unstable currency may be provided for the player using the unstable currency (referred to herein as “loaned funds”). Alternatively, where wrapped currencies are used, a wrapped stable currency (such as but not limited to WUSDT) may be used for the loan. The funds in unstable currency provided by the player may be held in step 404-2. The platform operator may operate a “lending USDT ledger/wallet” for providing such services (that may be part of competition platform 110 (FIG. 1A) or alternatively be a part of blockchain 162 (FIG. IE).

Reference is made to FIG. 4A, where the stable currency player (Player 2) is determined to be the game winner after a game decision. In step 406, following a decision in the game as to a winner, in some implementations, a rake that may be sufficient for both players may be removed from the loaned funds. The remaining funds (after deduction of the rake) may be added to the prize pool along with the stable currency entry fee. The prize pool thus may include both of the loaned stable currency and the stable currency entry fee.

In step 408, the winning player may be awarded the prize pool. In FIG. 4A as illustrated, Player 2 is shown as the winner and Player 1 as the loser, but it should be appreciated that this outcome is purely illustrative. The portion of the prize pool that is in a loaned stable currency may be converted (optionally including a slippage fee) into the held (stable) currency of the winning player and, in step 410-1, the prize pool including a loaned currency converted into the winning player held currency and the stable currency entry fee may be awarded to the winning player in the player’s (stable) held currency. In step 410-2 the losing player loses their funds that were put on hold as part of step 404-2 including any loan fee if charged.

In some implementations, in step 410-1, the winning player may choose to receive winnings in a specific currency associated with a discount on the rake or no rake such that the prize pool may include the winning player’s rake contribution or a return of at least a discounted portion of the winning player’s rake contribution.

Reference is made to FIG. 4B, where the unstable currency player (Player 1) is the winner. In step 420, following a decision in the game as to a winner, in some implementations, a rake that may be sufficient for both players may be removed from the entry fee of the stable currency player. The remaining funds (after deduction of the rake) may be added to the prize pool. The prize pool thus may include only the second (stable) currency.

In step 422, the winning player may be awarded the prize pool. In FIG. 4B as illustrated, Player 1 is shown as the winner and Player 2 as the loser, but it should be appreciated that this outcome is purely illustrative. The prize pool (being in stable currency) may be converted into the held (unstable) currency (optionally including a slippage fee) of the winning player (Player 1) and, in step 424, the prize pool may be awarded to the winning player in the player’s (unstable) held currency. In step 426, the unstable currency funds that were put on hold in step 404-2 may be used to settle the loan of step 404 and may be returned to Player 1. In step 428 the losing player loses their entry fee (in some implementations, collected by the network operator). Advantageously, both players use their held currencies and may be not required to perform any conversion of their held currencies into a gaming currency. In some implementations, in step 424, the winning player may choose to receive winnings in a specific currency associated with a discount on the rake or no rake such that the prize pool may include the winning player’s rake contribution or a return of at least a discounted portion of the winning player’s rake contribution.

Where wrapped currencies were used, the swap from the wrapped currency back to the winning player’s held currency may take place when the prize is awarded or alternatively a player may continue to use the wallet of the wrapped currency for further gameplay and only perform the reverse currency swap (back to the parent currency) at a later time. When a reverse currency swap takes place for the awarded prize pool, the player’s original parent currency that was put on hold may be released along with the additional amount won in the game. The entry fee of the losing player that was put on hold may be released from hold and absorbed by the network operator.

FIG. 5 is a diagram of an example process 500 for processing a multi-currency gaming session in accordance with implementations described herein. This process 500 may for example be performed by system 100 or 160 as described above. The steps below are described with reference to a non-transitory computer readable medium containing instructions that when executed by one processor performs one or more of operations described at each step. The processor may correspond to competition platform 110 and/or user device 130 or a processor that partakes in operation of blockchain 162 and currency network bridge 168.

In process 500, two or more players may join a gaming session where the funds submitted by a first player may be of an unstable currency and those of a second player may be of a different unstable currency. It should be appreciated that the two unstable currencies may or may not be directly traded against one another in currency markets. FIG. 5 shows process 500 for two players but it should be appreciated that multiple players may be supported.

In step 502, as part of the gameplay process, the players submit the funds (entry fee) in each players held (unstable) currency. In some implementations, the players may not be aware that other players may be using a foreign currency different to their held currency. In some implementations, the competition platform displays the entry fee to each player according to the held currency used by that player based on a current exchange rate. As illustrated, Player 1 submits funds in a first unstable currency (“BTC” in FIG. 5) and Player 2 submits funds in a second unstable currency (“ETH” in FIG. 5).

In some implementations, both of unstable currencies used by the players may be swapped into wrapped equivalent currencies prior to the start of gameplay. For example, the BTC of Player 1 may be placed on hold while an equivalent (wrapped) WBTC is allocated to a Player 1 wallet for use within the game. Similarly, the ETH of Player 2 may be placed on hold while an equivalent (wrapped) WETH is allocated to a Player 2 wallet for use within the game. Thus “BTC” as used in FIG. 5 may refer to WBTC and ETH may refer to WETH. It should be appreciated that the use of BTC, WBTC, ETH and WETH is illustrative, and any currency and its wrapped equivalent may be used.

To facilitate handling of the unstable currencies, process 500 provides for an interim loan of a stable currency equivalent to the unstable currency with the addition of a loan (lending) fee while the funds provided in unstable currency may be held. Thus, more specifically in step 502 each player’s entry fee may be calculated to include a lending fee in addition to the game entry fee. In some implementations, the process of managing the loan may be transparent to the players with the unstable currency, i.e.: each player simply provides an entry fee in their own held (unstable) currency and either wins or loses funds in the same held (unstable) currency without being aware of the loan process.

In step 504-1, an interim loan of a stable currency (“USDT” in FIG. 5) equivalent to the unstable currency (ETH, BTC) may be provided for each unstable currency player (referred to herein as “loaned funds”). Alternatively, where wrapped currencies are used, a wrapped stable currency (such as but not limited to WUSDT) may be used for the loan. In step 504-2, the funds in unstable currency provided by each player may be held. The platform operator may operate a “lending USDT ledger/wallet” for providing such services (that may be part of competition platform 110 (FIG. 1A) or alternatively be a part of blockchain 162 (FIG. IE).

In step 506, following a decision in the game as to a winner, in some implementations, a rake that may be sufficient for both players may be removed from the loaned funds of the losing player. The remaining funds (after deduction of the rake) may be added to the prize pool. In step 508, the winning player may be awarded the prize pool. In FIG. 5 as illustrated, Player 1 is shown as the winner and Player 2 as the loser, but it should be appreciated that this outcome is purely illustrative. The prize pool of the loaned stable currency may be converted into the held (unstable) currency of the winning player at the current market rate (optionally including a slippage fee) and, in step 510, the prize pool including the loaned currency of the losing player converted to the held currency of the winning player may be awarded to the winning player in the player’s (unstable) held currency and the winning player’s entry fee put on hold in step 504-2 may be returned to the winning player with a deduction of the lending fee of step 504-1. In some implementations, in step 510, the winning player may choose to receive winnings in a specific currency associated with a discount on the rake or no rake such that the prize pool may include the winning player’s rake contribution or a return of at least a discounted portion of the winning player’s rake contribution. In step 512 the losing player loses their held funds that were put on hold as part of step 504-2 including any loan fee if charged.

FIG. 6 is a diagram of an example process 600 for processing a multi-currency gaming session in accordance with implementations described herein. This process 600 may for example be performed by system 100 or 160 as described above. The steps below are described with reference to a non-transitory computer readable medium containing instructions that when executed by one processor performs one or more of operations described at each step. The processor may correspond to competition platform 110 and/or user device 130 or a processor that partakes in operation of blockchain 162 and currency network bridge 168.

In process 600, two or more players may join a gaming session where the funds submitted by all the players are of different unstable currencies (shown as “BTC” and “ETH” in Fig. 6). FIG. 6 shows process 600 for two players but it should be appreciated that multiple players may be supported each with different unstable currencies.

In some implementations, both of unstable currencies used by the players may be swapped into wrapped equivalent currencies prior to the start of gameplay. For example, the BTC of Player 1 may be placed on hold while an equivalent (wrapped) WBTC is allocated to a Player 1 wallet for use within the game. Similarly, the ETH of Player 2 may be placed on hold while an equivalent (wrapped) WETH is allocated to a Player 2 wallet for use within the game. Thus “BTC” as used in FIG. 6 may refer to WBTC and ETH may refer to WETH. It should be appreciated that the use of BTC, WBTC, ETH and WETH is illustrative, and any currency and its wrapped equivalent may be used.

In step 602, as part of the gameplay process, the players submit the funds (entry fee) in their unstable held currency and the submitted funds may be placed on hold in step 604.

In step 606, following determination of the winning player, in some implementations, a rake may be removed from the submitted funds of the losing player. The rake amount or a no-rake arrangement may be as described in the Summary above. The remaining funds (after deduction of the rake) form the prize pool along with the held currency of the winning player. In step 608, the remaining funds of the losing player (after the rake) may be converted into the held currency of the winning player and the winning player may be awarded the prize pool including the submitted funds of the winning player that may be removed from the hold of step 604 and the converted remaining funds of the losing player.

In some implementations, the currency conversion or swapping of the losing player contribution in the losing player’s held currency into the winning player’s held currency may use a cross-token exchange. A cross-token exchange may use blockchain-based smart contracts to facilitate the (decentralized) trading of different currencies. Pairs of currencies may be swapped via liquidity pools, which use smart contracts to automatically rebalance after every trade. A non- limiting example of a cross-token exchange is Uniswap that can support the exchange of any currency (token) that adheres to the Ether eum technical standard (ERC-20).

In some implementations, the currency conversion of the losing player contribution into the winning player held currency may be made on a wrapped-currency blockchain (such as Blockchain 162) where all of the player’s used currencies have been swapped into wrapped currencies. In practice a winning player may be provided with their submitted wrapped held currency as well as the submitted wrapped currency of the losing player converted into the equivalent wrapped held currencies. The losing player’s submitted wrapped currency may be transferred to a liquidity pool of that (losing) held currency and the converted funds in the winning player’s held currency may be provided from a liquidity pool of that (winning) held currency. In some implementations, the liquidity pools may be provided as part of the blockchain (by users of the blockchain) and/or by the network operator.

In process 600 as illustrated, Player 1 may be shown as the winner and Player 2 as the loser, but it should be appreciated that this outcome may be purely illustrative.

In some implementations, in step 608, the winning player may choose to receive winnings in a specific currency associated with a discount on the rake or no rake such that the prize pool may include the winning player’s rake contribution or a return of at least a discounted portion of the winning player’s rake contribution. In most game scenarios the losing player receives no prize for having played and the losing player (in this case Player 2) therefore loses their funds.

FIGS. 7A and 7B are diagrams of an example process 700 for processing a multi -currency gaming session involving multiple players in accordance with implementations described herein. This process 700 may for example be performed by system 100 or 160 as described above. The steps below are described with reference to a non-transitory computer readable medium containing instructions that when executed by one processor performs one or more of operations described at each step. The processor may correspond to competition platform 110 and/or user device 130 or a processor that partakes in operation of blockchain 162 and currency network bridge 168.

In process 700, multiple players may join a gaming session where the funds submitted by a first group of players may be of fiat money or a stable currency and those of a second group of players may be of an unstable currency. FIGS. 7A and 7B show process 700 when the game may be won by one of the players using a stable currency or one of the players using an unstable currency. Although process 700 shows two groups of players (according to currency) It should be appreciated that this does not imply that each group is competing/wagering together - rather the stable and unstable currency groups are shown together for simplicity.

In step 702, as part of the gameplay process, the players submit the funds (entry fee) in each players held currency. In some implementations, the players may not be aware that other players may be using a foreign currency different to their held currency. In some implementations, the competition platform displays the entry fee to each player according to the held currency used by that player based on a current exchange rate.

In some implementations, the unstable currencies used by the players may be swapped into wrapped equivalent currencies prior to the start of gameplay. For example, the BTC of BTC Player may be placed on hold while an equivalent (wrapped) WBTC is allocated to a BTC Player wallet for use within the game. Similar swaps may be performed for other players including ETH player, ERC20 player and the fiat/stable players. Thus “BTC” as used in FIG. 7 may refer to WBTC and other currencies may refer to their wrapped equivalents. It should be appreciated that the use of particular currencies is illustrative, and any currency and its wrapped equivalent may be used.

To facilitate handling of the unstable currency players, process 700 may provide for an interim loan of a stable currency equivalent to the unstable currency with the addition of a loan (lending) fee while the funds provided in unstable currency may be held. Thus, more specifically in step 702-1 since the first set of currencies are unstable currencies, the entry fee may be calculated to include a lending fee in addition to the game entry fee. In some implementations, the process of managing the loan may be transparent to the players with the unstable currency, i.e.: the players simply provide an entry fee in the unstable currency and either win or lose funds in the same held (unstable) currency without being aware of the loan process.

In step 704-1, an interim loan of a stable currency equivalent to the unstable currency may be provided for each player using unstable currency (referred to herein as “loaned funds”). Alternatively, where wrapped currencies are used, a wrapped stable currency (such as but not limited to WUSDT) may be used for the loan. The platform operator may operate a “lending USDT ledger/wallet” for providing such services (that may be part of competition platform 110 (FIG. 1 A) or alternatively be a part of blockchain 162 (FIG. IE). In step 704-2, the funds for each of the players using unstable currency may be held. For the players with stable currency, in step 705, the entry fee may be put on hold pending the result of the game.

In step 706, in some implementations, a rake may be removed from the loaned funds and the stable currency funds. The remaining funds (after deduction of the rake) may be added to the prize pool along with the stable currency entry fee. The prize pool thus may include both of the loaned stable currencies and the stable currencies.

Where one of the stable currency players is the winner, in step 708, the winning stable currency player may be awarded the prize pool. The portion of the prize pool that is in a loaned stable currency may be converted (optionally including a slippage fee) into the held (stable) currency of the winning player and the prize pool including a converted loaned currency and the held currency may be awarded to the winning player in the player’s (stable) held currency. The losing players lose their stable and loaned funds including any loan fee if charged.

Where one of the unstable currency players is the winner, in step 710, the winning unstable currency player may be awarded the prize pool. The prize pool may be converted into the held (unstable) currency (optionally including a slippage fee) of the winning player and awarded to the winning player in the player’s (unstable) held currency. The unstable currency funds that were held in step 704 may be used to settle the loan of step 704 and may be returned to the winning player. The losing players lose their stable and loaned funds including any loan fee if charged. Advantageously, both players use their held currencies and may be not required to perform any conversion of their held currencies into a gaming currency.

In some embodiments, such as in step 712, where multiple players are winners, these winning players may be paid in their held currencies according to the distribution of winnings determined by the game. The portion of the prize pool for stable currency winners may be converted (optionally including a slippage fee) into the held (stable) currency of the winning players. The portion of the prize pool for unstable currency winners may include unstable currency funds that were held in step 704-2 that may be used to settle the loan of step 704-1 and may be returned to the winning unstable currency player. The losing players lose their stable and loaned funds including any loan fee if charged.

In a bracketed or tiered game featuring multiple players, the funds of players that lose at various stages of the competition/tournament may be continually held (an extension of the holding of steps 704-2 and 705) until a decision/outcome when the prize pool, including these held funds, may be released to one or more winners.

Where wrapped currencies were used, the swap from the wrapped currency back to the winning player’s held currency may take place when the prize is awarded or alternatively a player may continue to use the wallet of the wrapped currency for further gameplay and only perform the reverse currency swap (back to the parent currency) at a later time. When a reverse currency swap takes place for the awarded prize pool, the player’s original parent currency that was put on hold may be released along with the additional amount won in the game. The entry fees of losing players that were put on hold may be released from hold and absorbed by the network operator.

Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art. The materials, methods, and examples provided herein are illustrative only and not intended to be limiting.

Implementation of the method and system of the present disclosure may involve performing or completing certain selected tasks or steps manually, automatically, or a combination thereof. Moreover, according to actual instrumentation and equipment of preferred embodiments of the method and system of the present disclosure, several selected steps may be implemented by hardware (HW) or by software (SW) on any operating system of any firmware, or by a combination thereof. For example, as hardware, selected steps of the disclosure could be implemented as a chip or a circuit. As software or algorithm, selected steps of the disclosure could be implemented as a plurality of software instructions being executed by a computer using any suitable operating system. In any case, selected steps of the method and system of the disclosure could be described as being performed by a data processor, such as a computing device for executing a plurality of instructions.

As used herein, the terms “machine-readable medium” “computer-readable medium” refers to any computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term “machine-readable signal” refers to any signal used to provide machine instructions and/or data to a programmable processor. Various implementations of the systems and techniques described here may be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various implementations may include implementation in one or more computer programs that may be executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

Although the present disclosure may be described with regard to a “computing device”, a "computer", or “mobile device”, it should be noted that optionally any device featuring a data processor and the ability to execute one or more instructions may be described as a computing device, including but not limited to any type of personal computer (PC), a server, a distributed server, a virtual server, a cloud computing platform, a cellular telephone, an IP telephone, a smartphone, a smart watch or a PDA (personal digital assistant). Any two or more of such devices in communication with each other may optionally comprise a "network" or a "computer network".

To provide for interaction with a user, the systems and techniques described here may be implemented on a computer having a display device (a LED (light-emitting diode), or OLED (organic LED), or LCD (liquid crystal display) monitor/screen) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user may provide input to the computer. Other kinds of devices may be used to provide for interaction with a user as well; for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.

The systems and techniques described here may be implemented in a computing system that may include a back end component (e.g., as a data server), or that may include a middleware component (e.g., an application server), or that may include a front end component (e.g., a client computer having a graphical user interface or a Web browser through which a user may interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components. The computing system may utilize a blockchain, decentralized storage, and/or smart contracts. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (“LAN”), a wide area network (“WAN”), and the Internet.

The computing system may include clients and servers. A client and server may generally be 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.

It should be appreciated that the above-described methods and apparatus may be varied in many ways, including omitting, or adding steps, changing the order of steps and the type of devices used. It should be appreciated that different features may be combined in different ways. In particular, not all the features shown above in a particular embodiment or implementation may be necessary in every embodiment or implementation of the invention. Further combinations of the above features and implementations may be also considered to be within the scope of some embodiments or implementations of the invention.

While certain features of the described implementations have been illustrated as described herein, many modifications, substitutions, changes, and equivalents will now occur to those skilled in the art. It is, therefore, to be understood that the appended claims may be intended to cover all such modifications and changes as fall within the scope of the implementations. It should be understood that they have been presented by way of example only, not limitation, and various changes in form and details may be made. Any portion of the apparatus and/or methods described herein may be combined in any combination, except mutually exclusive combinations. The implementations described herein may include various combinations and/or sub-combinations of the functions, components and/or features of the different implementations described.

Claims

WHAT IS CLAIMED IS:

1. A non-transitory computer readable medium containing instructions that when executed by at least one processor, cause the at least one processor to perform operations for providing multi-currency gaming comprising: accepting submitted funds from players of a game, wherein each of the players submits funds a different held currency, wherein the submitted funds contribute towards a prize pool; and following a decision point in the game for determining a winning player of the players of the game, providing the prize pool or a portion thereof to the winning player in the held currency of the winning player.

2. The non-transitory computer readable medium of claim 1, the operations further comprising swapping of the losing player contribution towards the prize pool in the losing player’s held currency into the winning player’s held currency using a cross token exchange.

3. The non-transitory computer readable medium of claim 1, the operations further comprising swapping each held currency of the submitted funds into an equivalent wrapped held currency.

4. The non-transitory computer readable medium of claim 3, the operations further comprising: swapping of all or a portion of the losing player contribution towards the prize pool in the losing player’s wrapped held currency into the winning player’s wrapped held currency.

5. The non-transitory computer readable medium of claim 1, the operations further comprising, when the held currency of a first player is a stable currency and the held currency of a second player is an unstable currency, providing a loan in a stable currency equal to the unstable currency funds, and placing the loan on hold.

6. The non-transitory computer readable medium of claim 5, the operations further comprising: when the player submitting funds in the stable currency is the winner, removing a rake from the loaned funds and converting the loaned funds remaining after removal of the rake into the held currency of the winning player.

7. The non-transitory computer readable medium of claim 5, the operations further comprising: when the player submitting funds in the unstable currency is the winner, removing a rake from the funds submitted in the stable currency, settling the loaned funds so as to return the funds in the unstable currency to the winning player, and converting the stable currency funds remaining after removal of the rake into the held currency of the winning player.

8. The non-transitory computer readable medium of claim 1, the operations further comprising: when the held currency of each player is a different unstable currency, providing a loan in stable currency equal to each of the submitted funds in unstable currency, placing the loaned funds on hold, removing a rake from the loaned funds of the losing player, and converting the remaining loaned funds after removal of the rake into the held currency of the winning player.

9. The non-transitory computer readable medium of claim 1, the operations further comprising: when the different held currency of each player is a stable currency, collecting a rake from the submitted funds of each player and converting remaining funds of a losing player after removal of the rake into the held currency of the winning player.

10. The non-transitory computer readable medium of claim 1, the operations further comprising: when the held currency of each player is the same unstable currency, placing the submitted funds on hold and removing a rake from each of the submitted funds.

11. The non-transitory computer readable medium of any one of the above claims, wherein a game is one of a verifiable event or an online game where two or more players submit funds as an entry fee.

12. The non-transitory computer readable medium of any one of the above claims, wherein a player is one of a human player, a human controlled player, or a computer-controlled player.

13. A method for providing multi-currency gaming comprising: providing a system for providing multi-currency online gaming, using the system to accept submitted funds from players of a game, wherein each of the players submits funds a different held currency, wherein the submitted funds contribute towards a prize pool; and following a decision point in the game for determining a winning player of the players of the game, using the system to provide the prize pool or a portion thereof to the winning player in the held currency of the winning player.

14. The method of claim 13, further comprising using the system to swap the losing player contribution towards the prize pool in the losing player’ s held currency into the winning player’s held currency using a cross-token exchange.

15. The method of claim 13, further comprising using the system to swap each held currency of the submitted funds into an equivalent wrapped held currency.

16. The method of claim 15, further comprising: using the system to swap all or a portion of the losing player contribution towards the prize pool in the losing player’s wrapped held currency into the winning player’s wrapped held currency.

17. The method of claim 13, further comprising, when the held currency of a first player is a stable currency and the held currency of a second player is an unstable currency, using the system to provide a loan in a stable currency equal to the unstable currency funds, and to place the loan on hold.

18. The method of claim 17, further comprising: when the player submitting funds in the stable currency is the winner, using the system to remove a rake from the loaned funds and to convert the loaned funds remaining after removal of the rake into the held currency of the winning player.

19. The method of claim 17, further comprising: when the player submitting funds in the unstable currency is the winner, using the system to remove a rake from the funds submitted in the stable currency, to settle the loaned funds so as to return the funds in the unstable currency to the winning player, and to convert the stable currency funds remaining after removal of the rake into the held currency of the winning player.

20. The method of claim 13, further comprising: when the held currency of each player is a different unstable currency, using the system to provide a loan in stable currency equal to each of the submitted funds in unstable currency, to place the loaned funds on hold, to remove a rake from the loaned funds of the losing player, and to convert the remaining loaned funds after removal of the rake into the held currency of the winning player.

21. The method of claim 13, further comprising: when the different held currency of each player is a stable currency, using the system to collect a rake from the submitted funds of each player and to convert remaining funds of a losing player after removal of the rake into the held currency of the winning player.

22. The method of claim 13, further comprising: when the held currency of each player is the same unstable currency, using the system to place the submitted funds on hold and to remove a rake from each of the submitted funds.

23. The method of any one of claims 13-22, wherein a game is one of a verifiable event or an online game where two or more players submit funds as an entry fee.

24. The method of any one of claims 13-23, wherein a player is one of a human player, a human controlled player, or a computer-controlled player.

25. A system for providing multi-currency gaming comprising at least one processor configured to:

26. A system comprising: at least two user devices, wherein each device is used by a player of a game to play a game; and a competition platform or blockchain configured to; accept submitted funds from players of a game, wherein each of the players submits funds a different held currency, wherein the submitted funds contribute towards a prize pool; and following a decision point in the game for determining a winning player of the players of the game, to provide the prize pool or a portion thereof to the winning player in the held currency of the winning player.

27. A system comprising: at least two user devices, wherein each device is used by a player of a game to play a game; a decentralized ledger; and an oracle, wherein the user devices are configured to accept submitted funds from players of the game, wherein each of the players submits funds a different held currency, wherein the submitted funds contribute towards a prize pool; and following a decision point in the game for determining a winning player of the players of the game, to provide the prize pool or a portion thereof to the winning player in the held currency of the winning player.