GB2570469A

GB2570469A - Arrangements relating to cryptocurrency

Info

Publication number: GB2570469A
Application number: GB1801275.7A
Authority: GB
Inventors: Khemani Karan
Original assignee: Neuchatel Ltd
Current assignee: Neuchatel Ltd
Priority date: 2018-01-26
Filing date: 2018-01-26
Publication date: 2019-07-31
Also published as: GB201801275D0

Abstract

Executing a secure transaction comprises constructing a cryptographically verified liquidity pool 202 on a secured processor which acts as a broker or intermediary to receive, hold and pay out funds. A user 210 sets up the secure transaction 302, and a stake for the transaction is provided 304 to the liquidity pool. The secure transaction is completed within a specified time frame and produces a transaction result. The transaction result may be reviewed to determine if the result is favourable to the user. If so, the user receives 310 their stake plus a return from the liquidity pool. Otherwise, the stake is retained by the liquidity pool. A divided fee may be paid 306, 308 to the liquidity pool’s creator 204 or those who provided initial liquidity to the pool 206. The liquidity pool may be funded by either fiat currency or cryptocurrency, and may be governed by a smart contract 100 on a blockchain. The stake may be held by a temporary escrow 212 before being transferred to the liquidity pool. The method may be used to replace a human intermediary in stock or foreign currency exchanges, invoice factoring, sports betting or online casino gambling.

Description

The following terms are registered trade marks and should be read as such wherever they occur in this document:

BITCOIN

Intellectual Property Office is an operating name of the Patent Office www.gov.uk/ipo

ARRANGEMENTS RELATING TO CRYPTOCURRENCY

Field of Invention

This invention relates to a Blockchain based decentralised, autonomous liquidity pool provision for financial technology based on a secured network.

Background of Invention

This invention relates to a Decentralised Autonomous Liquidity pool (DALP) framework, for use with a blockchain. The invention can be used to support trading and betting decentralised applications, and also provides a smart contract incentive structure for funders of the liquidity pool framework, as well as providing a protocol for how off-site user cryptocurrency wallets and in-platform private-escrow wallets interact with a liquidity pool framework provided on a secured hardware network.

A blockchain is a distributed digital ledger that supports cryptocurrency such as bitcoins. Conventional government backed currencies such as GB£ or US$ are known as fiat currencies, they have a physical form (bank notes and coins) and the currency typically has an intrinsic value related to another commodity such as gold. By contrast, a cryptocurrency has no physical form and is not issued or regulated by a central banking authority, instead the generation and transfer of cryptocurrency is regulated by encryption. Cryptocurrencies can be used to pay for goods and services in exactly the same way as fiat currencies, and they are becoming more commonly used as the digital economy evolves. Blockchain is the ledger system that supports cryptocurrency. Cryptocurrency is generated through a process of electronic mining, and the blockchain ledger records the currency generation by storing data simultaneously on a network of linked computers. Each of the blocks will contain a hash pointer to the previous block, a timestamp and transaction data. Use of cryptographic techniques means that the blockchain is immutable, as it cannot be deleted/amended but only added to. Hence, the blockchain keeps an unalterable record of the cryptocurrency generated and also the transactions with the cryptocurrency. The blockchain is set up and managed on a peer-to-peer network as a distributed model, with no overall central control.

Blockchain was initially proposed as the technology underpinning bitcoin (the first cryptocurrency) in 2008. Since that time many other cryptocurrencies have been developed (e.g Ethereum, litecoin, ripple etc..). Typically, these currencies have been used for transactions in financial services, but the ideas underpinning blockchain ledgers can be used for many other purposes that require data to be stored in a way that the data is always verifiable.

In current systems of financial trading, traders typically trade instruments such as binary/digital options or CFDs (contracts for differences) in Foreign Exchange and other assets. Typically, the trader will do so by depositing money for the trade at a broker's bank account, and then using a web-based platform will trade the financial markets with the aim to grow their capital. If the trader wins, the broker takes a direct balance sheet loss, whereas if the trader loses, the broker makes money on the trader's loss as a book gain. This could be considered as a conflict of interest, in that it may be in the broker's interest to ensure the depositors lose funds over time. This results in billions of pounds of trader's money being lost each year and the problem is due to the centralisation of funds.

Generally, brokers may be able to do any of the following:

game price feeds resulting in poor trade entries and exits;

trade on behalf of the client without their permission;

freeze or delay withdrawals all causing major financial losses.

This trading model is rife with fraud and despite regulation, brokers still are able to find ways to game client accounts.

In the invention, fiat or cryptocurrency funds are stored in fiat solutions or cryptocurrency smart contracts or wallets, and the funds can interact with a liquidity pool framework in a smart-contract governed relationship, via web-based decentralised applications. All transactions are carried out on secured hardware, such as a secured processor or server. The contractual relationship between the parties determines the flows of funds from a user's cryptocurrency wallets (that can be offsite and onsite) to and from rrl the liquidity pool framework and from the liquidity pool framework into a 3 party cryptocurrency contract or wallet that may be used to pay dividends or revenues to holders of cryptocurrency tokens.

Summary of the invention

Accordingly, the invention seeks to mitigate, alleviate or eliminate one or more of the abovementioned disadvantages singly or in any combination.

According to a first aspect of the present invention, there is provided a method for executing a secured transaction comprising the steps of a)constructing a cryptographically verified liquidity pool on a secured processor wherein said pool is configured to receive, hold and pay-out funds; b) setting up a cryptographically secure user transaction on said secured processor; c)providing a transaction stake for said secure transaction to said liquidity pool; d)completing the secure transaction on said secured processor within a specified time frame to produce a transaction result.

According to a preferred embodiment of the invention the method may further comprise the step of reviewing the transaction result and it the result is favourable for the user then the user receives the transaction stake and a transaction return from said liquidity pool, otherwise the transaction stake is retained in the liquidity pool.

Further preferably, if the result is favourable, the transaction return is a percentage of the initial transaction stake. In some cases, the percentage of the initial transaction stake is between 25-300%.

A method according to any preceding claim further comprising the step of paying a fee as a percentage of the initial transaction stake to one or more external parties with an interest in said liquidity pool from the liquidity pool. Preferably, the fee to one or more external parties is between 0.5-10% of the value of the secure transaction, still further preferably, the fee to one or more external parties is 2% of the value of the secure transaction. In an embodiment of the invention the one or more external parties includes the creator of the liquidity pool and/or token holders who have provided liquidity to the pool.

Preferably, the specified time frame for completing the transaction is at least 1 minute, and still further preferably the time frame is at least 5 minutes.

Further preferably the liquidity pool is generated as an initial step preceding step (a), and is funded by cryptocurrency, the pool generation may also be governed by a smart contract.

In a preferred embodiment, the maximum value of the secured transaction is set to a percentage of the total value of the liquidity pool. Preferably, the maximum value of the secured transaction is between 0.1-50% of the total value of the liquidity pool.

Preferably, the transaction stake is provided to a secure intermediary before being provided to the liquidity pool.

In a preferred embodiment of the invention, said secure transaction is initiated from a decentralised application accessible by the user, wherein the decentralised application is selected from a range of applications. Preferably, further decentralised applications can be added to the range of applications at any time.

In a preferred embodiment of the invention all the steps are broadcast on the blockchain.

This invention also allows for the tokenisation and subsequent decentralisation of profits generated in the liquidity pool framework/universe into tradeable tokens.

The invention also provided a secure liquidity pool multi-signature protocol wallet that ensures funds for counterparty acceptance of transactions are always safe and present. This liquidity pool is a pool of cryptocurrency and/or fiat denominated liquid assets that is secured using the blockchain and acts as counterparty (where relevant) to transactions generated on DAPPs.

A global, well recognised blockchain such as Ethereum is provided to validate all transactions and smart contracts. The use of smart contracts replaces human broker functions with computerised instructions that ensure no moral hazard enters the game.

These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter.

Brief description of the drawings

Further details, aspects and embodiments of the invention will be described, by way of example only, with reference to the drawings. In the drawings, like reference numbers are used to identify like or functionally similar elements. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale.

FIGURE 1 is a flow chart illustrating how a smart contract is created;

FIGURE 2 illustrates the creation of the liquidity pool;

FIGURE. 3 illustrates on overview of the participants in the secure transaction system;

FIGURE 4 illustrates the steps involved in a successful secured transaction;

FIGURE 5 illustrates the steps involved in an unsuccessful secured transaction.

Detailed Description

A Decentralised Autonomous Liquidity Pool (DALP framework) solution provided on secure hardware (such as a secured processor or node) associated with the Blockchain, has the advantage of disintermediating brokers, whilst still retaining the key functions of the broker, such as creating a market for an asset, acting as counterparty to most (if not all) trades on the platform and allows for traders to trade directly from their cryptocurrency wallets (held on a secured hardware system) via the blockchain, against the liquidity pool framework directly, without any possibility of human intervention and thus, without the accompanying conflicts of interest.

The ability to accept trades and determine if the trade has won or lost followed by a subsequent payment either from the liquidity pool framework to the trader's cryptocurrency wallet or from the wallet to the liquidity pool framework is coded within a computerised smart contract. A smart contract is a piece of software code released on a global ledger (the blockchain, for example the Ethereum blockchain) and is copied across thousands of nodes (where the node is a secure processor such as a server, personal computer etc.). Each of the nodes can self-monitor for changes in the code of the smart contract and should any changes in the contract occur, they will be rejected. This immutability ensures that programmed conditions, can never be changed, thus disallowing any conflicts of interest that may muddy a fair and transparent trading environment.

Figure 1 shows the stages involved in the creation of a smart contract 100. At step 102 the smart contract is coded, this includes writing, compilation and debugging steps. Step 104 is to test the contract on a private node. Step 106 is an optional step to have the contract audited. The final step, 108, is to deployed the finalised contract on the blockchainin the preferred embodiment it is deployed on the Ethereum blockchain. Deploying the contract on the blockchain incurs a transaction fee that is levied on the user initiating the transaction and awarded to a miner node.

Smart contracts are immutable pieces of software code that are copied on to all hardware nodes (servers/secure processors) that comprise a blockchain (e.g. Ethereum, Waves, EOS and others) that have the pre-coded instructions required to determine whether or not a pay-out is to be made either to a user of a DAPP who has placed a transaction which has engaged the liquidity pool framework. Traditionally, in a centralised scenario, the transaction decision is in the hands of a human intermediary, such as a broker. In this invention, the human intermediate is not needed and their responsibilities are precoded into a smart contract on the secure system.

During the deployment of the smart contract 100 on the blockchain, the smart contract code will be processed by all of the nodes involved in the Blockchain to reach an agreement that a transaction is valid. A majority of the nodes (at least 51%) are required to confirm the validity of any new blocks before they are added to the existing blockchain, All nodes contain identical information on the blockchain and so all of the nodes need to know details of the specific smart contract. After the contract has been deployed on the blockchain it becomes immutable.

Under this decentralised system, traders do not need to deposit funds at the broker's bank account. Instead the traders have cryptocurrency wallets 210 with cryptocurrency to purchase trades on the specified trading platform.

Figure 2 illustrates the steps involved in the creation of the liquidity pool 202 on a secure processor such as a server or a node. In step 250 token holders 206 fund the liquidity pool 202 via a token generation event. The funds are provided in cryptocurrency (such as bitcoin, Ethereum or others) to the smart contract address of the creator 204. In step 252 dividend bearing tokens are issues to wallets 210 of the token holders 206. The value of the token is dependent on the total amount of funds invested by the token holder in the token generation event 250. At step 254 the creator 204 takes a portion of all of the received funds and capitalizes the liquidity pool 202. The funds for the pool 202 are stored in a smart contract 100 or a collection of multiple smart contracts 100. Once the liquidity pool 100 has been generated, it can be used as a source of liquidity for various transactions in a trading system.

Figure 3 shows the various parties who are involved in the cryptocurrency trading system. The overall trading framework 200 is governed by the smart contract 100, generated as discussed above.

The system comprises a DALP liquidity pool 202, a creator of the pool 204, token holders 206 who fund the pool, decentralized applications (DAPPs) 208 who use the pool for transactions and a cryptocurrency wallet 210, holding cryptocurrency funds that finance the transactions.

The Decentralised Autonomous Liquidity Pool 202 is a decentralised pool of funds, either denominated in cryptocurrency or fiat currency, that offers liquidity to a range of financial, web or mobile based decentralised applications (DAPPS) 208 that use blockchains for disintermediation of middle-men. In return for the provision of liquidity by acting as an automatic or conditional counterparty to bets, trades and other transactions that can result in financial loss, the liquidity pool 202 receives a fee that is algorithmically determined based on provably fair outcomes as deemed so by a smart contract 100, where the smart contract 100 monitors real world or mathematical data points, in order to determine whether or not the liquidity pool 202 should be paid or whether the liquidity pool 202 should pay.

A transaction is typically generated by the owner of a cryptocurrency wallet 210 (MEW, Exodus, Metamask are examples of currently known cryptocurrency wallets that may be used with this invention) by a confirmation button on the DAPP 208, where the button may be on a mobile device, or computer, or some other interactive device. Once the user confirms the transaction on the DAPP 208, the user's stakes a predetermined amount from the cryptocurrency wallet 210 and this initial stake is broadcast to the entire underlying distributed ledger/blockchain, for transfer to temporary escrow storage 212 that is governed by the rules of the smart contract 100. Transaction funds are held on behalf of the user in the temporary escrow storage 212 during which the outcome of the staked event becomes known. Depending on the outcome of the transaction, the funds are either i) sent back to the user's cryptocurrency wallet 210 if the outcome is a tie, ii) sent on to the liquidity pool framework 202 if the user has lost or iii) returned to the user's wallet 210 along with the variable promised pay-out from the liquidity pool 202 for a win. Simultaneously, the value of the staked amount is charged to the liquidity pool 202 and a dividend fee is paid out to both the Creator 204 and the cryptocurrency token holders 206 of the liquidity pool 202, from the pool 202.

There are various relationships between the components of the framework 200. These are described as follows.

The cryptocurrency wallets 240 in which user funds are stored interact with a range of DAPPs 208 that are developed externally to this overall framework. DAPPs 208 are the source of funds for individual conditional transactions (such as bets, trades, purchases and so forth). Additional DAPPs 208 may be added to the framework at any time after the initial set up of the framework, and then used for further transactions after they have been added. There is no limit on the number of DAPPs 208 that may be added to and supported by the liquidity pool framework.

There is no direct interaction between cryptocurrency wallets 210 of users and the liquidity pool 202. However, the relationship which governs transfers of funds from wallet 210 to liquidity pool 202 or vice versa is pre-coded into immutable smart contract 100 ensuring no intervention with the purpose to game or otherwise, is possible.

There is no direct interaction between cryptocurrency wallets 210 of users and the Creator 204, and the client is in charge of their funds at all times. This is one of the key distinctions of a centralised broker/provider of liquidity versus the liquidity pool 202 framework. Unless the cryptocurrency 210 wallet owner were to divulge the private key of their wallet to the Creator 204, there is no way to hack the wallet 210 as it would require hacking the entire blockchain which is not feasible. Neither the DAPP 208 nor the Creator 204 have access to any of the funds stored in the user's wallet 210, whether these are onsite private escrow smart contracts 100 created for the user on the DAPP 208 level, or in the users' off-site cryptocurrency wallets 210. The indirect relationship, however, exists that owing to the fee incentivization structure embedded in the liquidity pool 202 framework, each time a user transacts using one of the connected DAPPS 208, a percentage of transaction value fee is paid via smart contract 100 to the Creator 204 from the liquidity pool (III). This fee is a fixed percentage of the value of the transaction, typically between 0.510% of the value, and generally 2% of the transaction value.

There is no direct interaction between cryptocurrency wallets 210 of users and token holders 206. Unless the cryptocurrency wallet owner were to divulge the private key of their wallet 210 to token holders 206, there is no way to hack the wallet 210 as it would require hacking the entire blockchain. Neither the DAPP 208 nor the token holders 206 have access to funds stored in the user's wallets 210, whether these are on-site private escrow smart contracts 100 created for the user on the DAPP 208 level or their off-site cryptocurrency wallets 210. There is a fee incentivization structure embedded in the liquidity pool 202 framework, whereby each time a user executes a transaction using one of the connected DAPPS 208, a percentage of the transaction fee value is paid via smart contract 100 to the token holders 206 from the liquidity pool 202 (as a dividend), via an intermediary smart contract dividend wallet (not shown) that accumulates these dividend fees and allows token holders 206 to withdraw the fees at periodic intervals as desired.

The cryptocurrency wallets 210 of users interact indirectly with the smart contract 100 as the latter governs the flow of funds from funds sent from the wallet 210 to the intermediate escrow storage 212 and depending on the outcome of transactions and trades, escrow storage 212 will either send the held funds back to wallet 210 or send the funds on to the liquidity pool 202. This will depend on the outcome of the trade, and is determined from real world data points that are monitored in real time by the smart contract.

The DAPPS 208 channel in-platform volumes to the liquidity pool 202 via the smart contract 100. DAPPS 208 are where users effectively place transactions through their rrl cryptocurrency wallets 210. DAPPS 208 are developed either by the Creator 204 or 3 party developers (not shown). All DAPPS 208 access the global blockchain and using the smart contract 100, interface with the liquidity pool 202 in some way. DAPPs 208 are generally partially or fully decentralised applications and must use the liquidity pool 202 in order to be accepted into the liquidity pool 202 framework.

DAPPS 208 generate dividends for token holders 206. Token holders 206 can also participate in trading, betting or transacting on the DAPPS 208. They will participate in exactly the same way as described above. The link between DAPPs 208 and token holders 206 is established via the smart contract 100 and the liquidity pool 202. As mentioned above, new DAPPs may be added to the overall framework at any time, and connected to the liquidity pool 202, to be used for different transactions, according to what the DAPP is for.

DAPPS 208 interact and use the smart contract 100 for real world verification of outcomes and initiation of transactions at the DAPP 208 level.

The liquidity pool 202 and Creator 204 have no direct link, in that the creator 204 cannot access the pool 202. In order to change the balances held in the liquidity pool 202, this must be a user generated transaction on the DAPP 208. Each transaction that occurs on a DAPP 208 generates a volume based fee which is paid by the liquidity pool 202 to the Creator 204.

The liquidity pool 202 and token holders 206 have no direct link in that the token holder 206 cannot access the pool 202. In order to change the balances held in the liquidity pool 202, this must be a user generated transaction on the DAPP 208. Each transaction that occurs on a DAPP 208, generates a volume based dividend which is paid by the liquidity pool 202 to the token holders 206.

The liquidity pool 206 sends and receives funds based on instructions received by the smart contract 100 which itself monitors real world and mathematical data in order to govern provably fair outcomes for transactions initiated on the DAPPs 208.

The Creator 204 and token holders 206 have no direct link, nor is there any direct link between the token holders 206 and the smart contract 100. Indirectly, the Creator 204 issued tokens to the token holders 206 at the initial capitalisation event that gave rise to the liquidity pool framework 202.

There is no direct link between Creator 204 and smart contract 100 from the fact that the Creator 204 engineered and audited the smart contract 100 upon inception of the liquidity pool framework 202.

If the traders win, they will get paid directly from the liquidity pool framework 202. If the traders lose, the funds get sent to the liquidity pool framework 202 from the escrow storage 212. There are fees involved in these transactions, all of which are paid automatically, via smart contract trade by trade, to both the creator of the liquidity pool framework and token holders who hold participatory rights in the liquidity pool framework (These participatory rights arise as the liquidity pool framework was initially funded via a crowd-sale).

Because the liquidity pool 200 framework can disintermediate financial brokers, essentially middle-men, it removes middle-man and the associated risk in a range of adjacent sectors such as e-sports, betting, gambling, social trading, invoice factoring. As a result, the creation of decentralised applications 208 that plug into a liquidity pool 202 framework structure, all of which who have their own user bases, will generate volumes in which the liquidity pool 202 framework participates and part of these are paid out, as mentioned earlier, via smart contract 100, to the creator 204 of the liquidity pool 202 framework and token holders 206 who hold participatory rights in the liquidity pool 202 framework (from the liquidity pool framework was initially funded via a crowd-sale).

Thus, the following problem(s) has (have) been resolved, by the present invention: delaying of withdrawals; gaming of price feeds; theft of client funds; trading on the clients' behalf; financial broker driven moral hazard in a financial trading scenario.

When a transaction is generated on one of the DAPPS 208 that connect to the liquidity pool 202, a value-based fee is charged, by smart contract 100, to the liquidity pool 202 framework, resulting in the fee being paid automatically to both the Creator 204 and the cryptocurrency token holders206 who had originally funded the liquidity pool 202 framework through a crowd-sale. The fee varies depending on the DAPP 208 that is processing the transaction.

The situation and sequence described above pays out if the DAPP 208 is a prediction market platform, financial trading platform, gambling platform, betting platform, sportsbetting, e-sports platform, social trading platform or financial market signals platform. However, if the DAPP's volumes or transactions are not dependent on user generated transactions but instead the DAPP 208 is algorithmically vested in passive income generation activities that may be risky (e.g. investing, invoice factoring, loans underwriting) or risk-less (e.g. investment in income generating equipment such as mining rigs, property assets, financial assets amongst others), then the flow of funds occurs strictly from the DAPP 208 to the liquidity pool 202 framework, with a variable fee as determined by the Creator 204 when the DAPP 208 is coded, and this variable fee is paid from the liquidity pool 202 and paid to the Creator 204 and cryptocurrency token holders 206 of the liquidity pool 202 framework.

An example of how the above described liquidity pool 202 can be used is provided as follows in figures 4 and 5

Figure 4 shows the steps involved in a successful transaction. The smart contract 100, wallet 210, liquidity pool 202, DAPPS 208, creator 204 and token holders 206 are as described previously. The first stage in the transaction is step 302. In this step a trader places a US$100 trade on the price of an underlying asset (e.g. Euro/USD) rising between the instant time and the end of the next five minutes. The liquidity pool 202 immediately accepts the trade and becomes the counterparty as per the pre-coded smart contract 100. The funds for the trade are transferred from wallet 210 to intermediate secure escrow storage 212. For security, this initial transaction is broadcast on the global blockchain (in this case the Ethereum blockchain). The instant the trade is placed, steps 306 and 308 occur in real time. In these steps a fee (a percentage of the trade value) is paid to the pool creator 204 at step 306, and paid to the token holders 206 at step 308. In both cases the fee is paid from the liquidity pool 202. The fees and dividend percentages will vary according to the originating DAPP 28 or the specific smart contract 100. In a preferred embodiment, the fee is 2% of the original trade value for both the creator and the token holders, in this case the dividend fee is US$2.00. The smart contract 100 monitors the real-world price feeds for the EUR/USD over the defined duration and when the time for the trade expires, the smart contract 100 receives the price of the currency pair and compares it to the entry price. At step 304, the fixed time (5 minutes) for the trade has expired and the initially staked funds are released from storage 212 to the liquidity pool 202. If the trader wins the trade (for example the price is higher as predicted), as verified by the smart contract 100, the trader will earn a set return. In this case the return is 75% ROI equivalent to US$75.00 (or the cryptocurrency equivalent). This is returned to the trader wallet 210 from the liquidity pool

202 at step 310, immediately at the end of the specified time period. In step 310 the initial stake US$100 is also released from the liquidity pool 202 (where it has arrived from storage 212) and is then returned back to the wallet 210 from the liquidity pool 202. All of the steps in the transaction are governed by the smart contract 100 and also broadcast on the blockchain in real time as they occur, these provide additional layers of security to the transaction.

Figure 5 shows the steps involved in an unsuccessful transaction. The steps 302, 306 and 308 are as described above for a successful transaction. However, unlike in figure 4, at step 304 the trade is unsuccessful, so the funds are released by intermediate storage 212 and provided and retained by liquidity pool 202. The user does not get any return from the liquidity pool 202, nor do they have the initial stake returned from the liquidity pool 202. All of steps 302-310 are governed by the underlying blockchain.

For both successful and unsuccessful transactions as shown in figures 4 and 5 the fee to token holders is sent via smart contract 100 (and broadcast on the global blockchain) to a dividend wallet (not shown) where dividends accumulate until token holders can withdraw them at periodic intervals or receive them automatically in their cryptocurrency wallets.

At no point during the transaction (steps 302-310) can the Creator 204 intervene in any of the steps of the trade process. The smart contract 100 in place ensures trade acceptance, trade outcome determination and the subsequent flow of funds to and from the liquidity pool 200 to various parties such as the trader wallet 210, the Creator 204 and token holders 206. As all smart contracts 100 are monitored and verified by the global blockchain, it is not possible for the Creator 204 to change the code of the smart contract 100 once the contract is live on the blockchain, or to engineer an intervention. It is also noteworthy that in this decentralised liquidity pool 200, at no point is the trader depositing money with the Creator 204 or on the DAPP 208. Trader funds are always stored either in their cryptocurrency wallet 210 that is offsite or on a private-escrow smart contract (not shown) that is created for them when they create a trading account on the DAPP 208. The private keys are always with the trader which means only they have control over their funds.

In the examples of figures 4 and 5 the trader uses a particular specified DAPP 208 for the specific transaction. As mentioned, there are a range of DAPPs available, according to the specific transaction that is required. Additionally, further DAPPs may be added to the framework at any time. These DAPPs will contribute to the liquidity of the pool 202, and transactions over the DAPPs that are added to the framework will generate dividend payments for the creator 204 and token holders 206 in the manner discussed above, when that DAPP is selected for a transaction.

DAPP 208, such as a financial trading platform allows traders to take long and short positions on financial assets and is therefore well suited to the structure of the liquidity pool 202 and the underlying framework.

The framework 200 described above allows the replacement of a financial broker (with associated bank accounts) and their balance sheet by an independent secure verified liquidity pool 200. The replacement of human functions such as accepting depositor funds, creating a market, determining outcomes of trades, bets and transactions and deciding whether or not to pay-out gains or deposits is completely computerised into immutable smart contracts 100 that are governed by the blockchain.

The liquidity pool framework can be applied in all the following fin-tech sectors: Retail financial trading (digital options, fx, stocks, bonds, CFDs etc); Invoice factoring; Microloans; Sports betting; Online casinos; Social trading.

Typically, the DAPP may be accessed from a web-based browser, a downloadable executable (desktop based) app, or via a mobile telephone or other portable handheld or tablet device.

The example given above is for a financial application. However, as mentioned above the liquidity pool can be used in other areas.

For example, a DAPP may be a sports betting app. A user of the app may match a bet across users (a peer to peer network) or the user bets against the house (in this case the house would be a standard online bookmaker or other betting application). The liquidity framework of this application would replace the house and the liquidity pool would pay token holders and the pool creator the dividend fee in the manner discussed above. The dividend fee would be a set % per bet/transaction based on the overall value of the bet. The outcome for the user may be a binary outcome (the team/sports participant the user is betting on either wins or loses the event that is the subject of the bet) or granular (the team/participant the user has bet on wins/loses the event by x goals, x points or some other specific parameter). The specific odds for the event will be created by software within the DAPP control system prior to the bets being offered.

In the foregoing specification, the invention has been described with reference to specific examples of embodiments of the invention. It will, however, be evident that various modifications and changes may be made therein without departing from the scope of the invention as set forth in the appended claims and that the claims are not limited to the specific examples described above.

Any arrangement of components to achieve the same functionality is effectively 'associated' such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as 'associated with' each other such that the desired functionality is achieved, irrespective of architectures or intermediary components. Likewise, any two components so associated can also be viewed as being 'operably connected,' or 'operably coupled,' to each other to achieve the desired functionality.

Furthermore, those skilled in the art will recognize that boundaries between the above described operations are merely illustrative. The multiple operations may be combined into a single operation, a single operation may be distributed in additional operations and operations may be executed at least partially overlapping in time. Moreover, alternative embodiments may include multiple instances of a particular operation, and the order of operations may be altered in various other embodiments.

However, other modifications, variations and alternatives are also possible. The specifications and drawings are, accordingly, to be regarded in an illustrative rather than in a restrictive sense.

In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word 'comprising' does not exclude the presence of other elements or steps then those listed in a claim. Furthermore, the terms 'a' or 'an,' as used herein, are defined as one or more than one. Also, the use of introductory phrases such as 'at least one' and 'one or more' in the claims should not be construed to imply that the introduction of another claim element by the indefinite articles 'a' or 'an' limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases 'one or more' or 5 'at least one' and indefinite articles such as 'a' or 'an.' The same holds true for the use of definite articles. Unless stated otherwise, terms such as 'first' and 'second' are used to arbitrarily distinguish between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other prioritization of such elements. The mere fact that certain measures are recited in mutually different claims does not indicate that a 10 combination of these measures cannot be used to advantage.

Claims

1. A method for executing a secure transaction comprising the steps of

a) constructing a cryptographically verified liquidity pool on a secured processor wherein said pool is configured to receive, hold and pay-out funds;

b) setting up a cryptographically secure user transaction on said secured processor;

c) providing a transaction stake for said secure transaction to said liquidity pool;

d) completing the secure transaction on said secured processor within a specified time frame to produce a transaction result.

2. A method according to claim 1 further comprising the step of

e) reviewing the transaction result and if the result is favourable for the user then the user receives the transaction stake and a transaction return from said liquidity pool, otherwise the transaction stake is retained in the liquidity pool.

3. A method according to claim 2 wherein if the result is favourable, the transaction return is a percentage of the initial transaction stake.

4. A method according to claim 3 wherein the percentage of the initial transaction stake is between 25-300%

5. A method according to any preceding claim further comprising the step of paying a dividend fee as a percentage of the initial transaction stake to one or more external parties with an interest in said liquidity pool from the liquidity pool

6. A method according to claim 3 wherein the one or more external parties includes the creator of the liquidity pool.

7. A method according to claim 3 or claim 4 wherein said one or more external parties includes token holders who have provided initial liquidity to the pool.

8. A method according to any of claims 5 to 7 wherein the fee to one or more external parties is between 0.5-10% of the value of the secure transaction.

9. A method according to claim 8 wherein the fee to one or more external parties is 2% of the value of the secure transaction.

10. A method according to any preceding claim wherein the specified time frame is at least 1 minute.

11. A method according to claim 10 wherein the known time frame is at least 5 minutes.

12. A method according to any preceding claim wherein the construction of said liquidity pool on said secured processor is funded by cryptocurrency.

13. A method according to claim 12 wherein the generation of the liquidity pool is governed by a smart contract.

14. A method according to any preceding claim wherein the maximum value of the secured transaction is set as a percentage of the total value of the liquidity pool.

15. A method according to claim 12 wherein the maximum value of the secured transaction is between X-Y % of the total value of the liquidity pool.

16. A method according to any preceding claim wherein the transaction stake is provided to a secure intermediary before being provided to the liquidity pool.

17. A method according to any preceding claim wherein said secure transaction is initiated from a decentralised application accessible by the user.

18. A method according to claim 17 wherein the decentralised application is selected from a range of applications.

19. A method according to claim 18 wherein further decentralised applications can be

5 added to the range of applications at any time.

20. A method according to any preceding claim wherein said transaction stake is provided from a cryptographically secure wallet.

10

21. A method according to any preceding claim wherein all steps are broadcast on the blockchain.