SYSTEMS AND METHODS RELATING TO CRYPTOCURRENCIES

FIELD OF THE INVENTION This invention relates to various systems and methods which enable transacting in cryptographic currencies. In particular, the invention relates to a closed ecosystem for managing and facilitating cryptocurrency-based transacting between various parties forming part of the ecosystem, a cryptocurrency ATM with which amounts of currencies can be exchanged and purchased, a payment system which enables third parties to pay for goods and/or services produced or rendered by users of the system, utilising amounts of cryptocurrency-based currencies, and an electronic commerce gateway which allows users to purchase items electronically utilising cryptocurrencies.

BACKGROUND TO THE INVENTION

The prevalence and use of blockchain-based currencies (also known as cryptographic currencies or“cryptocurrencies”) are increasing. Specifically, cryptocurrencies are valued for their inherent security and (relative) anonymity. However, despite the anonymity of cryptocurrencies, its link to the blockchain renders transactions immutable. In most cases, the identities of payers and payees transacting by way of cryptocurrencies may remain private.

Furthermore, cryptocurrencies provide an attractive prospect due to its decentralised and non-regulated nature. Other than fiat currencies, cryptocurrencies are not linked to a specific geographical or economical region. Consequently, the value of the currency is not influenced by political or other economic factors of a specific area or region, a fact that is of particular value in developing countries, where instability often causes inflation to spiral out of control, and where the value of fiat currencies becomes especially volatile. Rather, the value of cryptocurrencies is determined by supply and demand by a global audience.

Wide-spread acceptance of cryptocurrencies in the normal course of trade has to date been moderate, due to a number of factors.

Firstly, cryptocurrency-based transactions are generally associated with delayed transaction times. This can for the most part be attributed to the time and computer processing required to verify and update the blockchain. Typically, these transaction times range between 10 and 30 minutes in some cases. Compared to conventional fiat transaction times, which have transaction delays in the nano-second sphere, trading in cryptocurrencies remains impractical or even risky to some vendors or purveyors.

The above impracticality and risks are inflated by fast changing cryptocurrency exchange rates, which tend to dissuade merchants, retailers, service providers and the like from accepting cryptocurrencies in exchange for their goods or services.

Furthermore, due to the anonymity of cryptocurrencies, the levying of taxes on transactions, or even the levying of income tax by governing entities is difficult or even impossible. Also, governments are very concerned with money leaving their jurisdiction illegally through the transfer of cryptocurrencies overseas. Consequently, governments tend to dissuade cryptocurrency-based transacting.

Trading in cryptocurrencies is currently associated with various user profiles on various platforms and exchanges, not all of which are necessarily transparent or legitimate. In some cases, this deters implementation and use of cryptocurrencies.

Furthermore, cryptocurrencies are not well understood by the broader public, which causes a general distrust in cryptocurrencies and its use. This sometimes stem from the fact that cryptocurrencies comprise financial systems without third party arbitration or mediation.

A need therefore exists for:

- a means to regulate and control cryptocurrency-based transactions (at least within a predetermined area or entity);

- a payment system which provides a simple, yet trusted and transparent means of exchanging amounts of fiat currencies for amounts of cryptocurrencies and/or amounts of a cryptocurrency for amounts of another cryptocurrency;

- a system that facilitates transacting in cryptocurrencies in exchange for goods and/or services (in the normal course of trade, and even in cases where the providers of the goods and/or services require payment in a fiat currency); and/or

- an e-commerce system or gateway that allows users to pay for goods and services utilizing cryptocurrencies (even in cases where e-commerce service providers do not yet facilitate the use of cryptocurrencies).

OBJECT OF THE INVENTION

Accordingly, it is an object of the present invention to provide various systems and methods which enable transacting in cryptographic currencies, with which the applicant believes the aforementioned disadvantages may at least be alleviated or which may provide useful alternatives for the known systems and methods. SUMMARY OF THE INVENTION

According to a first aspect of the invention there is provided a system for facilitating a transfer of an amount of cryptocurrency from a first known entity to a second known entity, the system comprising a private blockchain comprising a database of user profiles, each user profile associated a specific known entity and with a unique smart contract for storing frontend and backend data relating to the specific known entity; and a user interface for receiving inputs and displaying frontend data stored on the smart contracts, wherein, in use, backend data relating to the second known entity is retrieved from the specific user’s smart contract, and utilised to effect a transfer of the amount of cryptocurrency from the first user to the second user.

Each known entity may be associated with a processing module, which may be provided in communication with the private blockchain.

The user interface may be provided for: receiving, from the first known entity, an input relating to the second known entity;

providing the input to the private blockchain to thereby identify a specific user profile based on the input;

- receiving from a smart contract associated with the specific user frontend data relating the specific user profile; and

displaying the frontend data.

A processing module may be provided for:

- retrieving from the smart contract, backend data relating to the specific entity; and

utilizing the backend data to generate a“receive address” used to transfer the amount of cryptocurrency from the first known entity to the second known entity.

The processing module may be provided in communication with an exchange for exchanging fiat currency to cryptocurrency or for exchanging cryptocurrency to fiat currency. The private blockchain may be decentralised.

The frontend data may comprise at least some of: a name of the entity;

a surname of the entity;

a trade name of the entity; and

contact details of the entity;

The backend data may comprise at least some of:

tax details of the entity;

banking details (of a commercial bank trading in fiat currency) of the entity;

- a cryptocurrency wallet address of the entity;

a public key associated with the wallet;

a private key of the wallet;

data relating to cryptocurrency balances of the wallet; and

transaction record of the entity.

Further according to the first aspect of the invention, there may be provided a governing body for managing and controlling the system. The governing body may prescribe the functioning of the processing module. The receive address may be generated by utilising API keys associated with the governing body. The system may be provided in communication with a crypto ATM for enabling a user to exchange amounts of fiat-based currency for amounts of cryptocurrency and/or amounts of a cryptocurrency for amounts of another cryptocurrency, and thereby to increase a cryptocurrency balance associated with the user. The crypto ATM may furthermore be provided to extract amounts of cryptocurrency from the cryptocurrency balance of the user, and convert the extracted amount to a fiat-based amount.

The system may be provided with communication means for communicating with public blockchains, associated with known cryptocurrencies. The receive address may be generated in a format compatible with a specific cryptocurrency.

According to a second aspect of the invention there is provided a method of transferring an amount of cryptocurrency from a first known entity to a second known entity, the method comprising the steps of:

receiving via a user interface an input from the first entity relating to an identity of the second entity;

utilizing the input to identify a specific user from a database of users stored on a private blockchain; retrieving from a smart contract stored on the blockchain and associated with the identified specific user, backend data relating to the specific user; and

utilizing the backend data relating to the specific user to effect transfer of a preselected amount of cryptocurrency to the second entity.

The method may comprise the further step of utilising the backend data of the identified specific user to generate a payment address (or“receive address”) through an API key. The payment address may be utilised to transfer the preselected amount of cryptocurrency from the first user to the second user.

The method may comprise the further step of verifying that the transfer has been made, by prompting a public blockchain associated with the cryptocurrency that was transferred.

The public blockchain may be prompted by utilising the payment address (or receive address) as input. The transfer may be verified by comparing a balance associated with the payment address (or receive address) with the amount that was intended to be transferred from the first entity to the second entity. The method may furthermore comprise the step of generating a record of the transfer and storing the record on the private blockchain.

The record may be encrypted before being stored on the private blockchain. The record may be processed by a hash algorithm before being stored on the blockchain.

The record of the transfer may be utilised to monitor movements in the user’s cryptocurrency balance.

The method may include preventing a user from transferring an amount of cryptocurrency to an unknown entity which is not associated with a user profile on the private blockchain. Alternatively, the method may limit a total amount of cryptocurrency that a user may transfer to unknown entities, within a predetermined time. The predetermined time may be one of a daily period, a weekly period, a monthly period, and an annual period. The method may include the step of monitoring and recording amounts of cryptocurrency transferred by each user to unknown entities. According to a third aspect of the invention there is provided a system for an administrator to facilitate, on behalf of a first user, the conversion of a fiat amount or a first cryptocurrency amount to a second cryptocurrency amount, the system comprising:

- a processor module and a memory arrangement associated with the administrator, the processor module provided in communication with the memory arrangement, the memory arrangement comprising a database of user profiles;

- a balance amount of the second cryptocurrency, controlled by the administrator;

- an account for receiving from the first user the fiat amount or first cryptocurrency amount;

- an online user interface for enabling the first user to interact with the system; and

- an input module associated with the first user, with which the user interface is accessed by the first user,

wherein the processor module is provided in communication with a cryptocurrency-fiat exchange or a first cryptocurrency-second cryptocurrency exchange, for determining in real time, a cryptocurrency-fiat exchange rate or the first cryptocurrency-second cryptocurrency exchange rate, and for trading fiat amounts or first cryptocurrency amounts for second cryptocurrency amounts. Where the system for an administrator to facilitate, on behalf of a first user, is for the conversion of a fiat amount or a first cryptocurrency amount to a second cryptocurrency amount, the processor module may determine an initial second cryptocurrency amount associated with the fiat amount or the first cryptocurrency amount, and a subsequent second cryptocurrency amount associated with the initial second cryptocurrency amount, and wherein the processor module may effect a transfer of the subsequent second cryptocurrency amount from the balance amount, to the first user. The subsequent second cryptocurrency amount may be transferred from the balance of the second cryptocurrency and may precede the trading of the fiat amount or the first cryptocurrency amount for a second cryptocurrency amount. The input module may be one of a personal or laptop computer, a mobile device such as a smartphone, tablet or the like.

The input module may communicate with the processor via a known wireless communication medium or network.

According to a fourth aspect of the invention there is provided a method for an administrator to facilitate, on behalf of a first user, the conversion of a fiat amount or a first cryptocurrency amount to a second cryptocurrency amount, the method comprising the steps of:

- holding a balance amount of the second cryptocurrency;

- receiving from the first user a fiat amount or first cryptocurrency amount;

- determining an initial second cryptocurrency amount associated with the fiat amount or the first cryptocurrency amount, and transferring a subsequent second cryptocurrency amount, based on the initial second cryptocurrency amount, to the first user from the balance; and

- trading the fiat amount or the first cryptocurrency amount on an exchange and receiving a final second cryptocurrency amount from the exchange, at least partially, to replenish the balance amount.

The initial second cryptocurrency amount may be determined by retrieving from the exchange a fiat-second cryptocurrency exchange rate or a first cryptocurrency-second cryptocurrency exchange rate. The subsequent second cryptocurrency amount may be determined by deducting from the initial second cryptocurrency amount, a reserve amount to account for exchange rate fluctuations. The final second cryptocurrency amount may be an actual second cryptocurrency amount received from the exchange, in exchange for the fiat amount or first cryptocurrency amount. The administrator may receive from the first user a payment address (or “receive address”) that may be used to transfer the subsequent second cryptocurrency amount to the first user. The method may include the step of verifying the correctness of the payment address or the format of the payment address, considering the type of cryptocurrency required by the first user.

Data relating to the conversion of the fiat amount or the first cryptocurrency to the second cryptocurrency amount may be stored on a profile relating to the first user.

The trading of the fiat amount or the first cryptocurrency amount for the final second cryptocurrency amount may be deferred based on prevailing and historic second cryptocurrency-fiat currency exchange rate data or prevailing and historic second cryptocurrency-first cryptocurrency exchange rate data.

According to a fifth aspect of the invention, there is provided a payment system with which an administrator receives, on behalf of a user, cryptocurrency-based payments from a third party, the system comprising: a processing module associated with the administrator; a memory arrangement provided in communication with the processing module, the memory arrangement having stored thereon a database of user profiles, each user profile associated with a specific one of a plurality of registered users;

a profile on an exchange, which profile is associated with the administrator;

a communication means between the processing module and the exchange;

a user interface; and

an input module associated with each of the registered users of the system,

wherein, in use, the input module provides the user with access to the user interface to act as a point of sale associated with the user, and wherein the point of sale enables the third party to transfer cryptocurrency to the system.

The system may furthermore comprise a fiat-based banking account, managed by a commercial bank, and associated with the administrator.

Each user profile may comprise at least some of:

a name of the registered user;

an identity number of the registered user;

a tax number of the registered user; contact information of the registered user;

address information of the registered user;

fiat-based banking details of the registered user;

a cryptocurrency wallet address of the registered user;

a cryptocurrency balance of the registered user;

a fiat balance of the registered user; and

a transaction record of transactions associated with the registered user.

The system may comprise an online user interface for communicating with the respective users.

According to a sixth aspect of the invention, there is provided a method for an administrator to receive, on behalf of a user, a cryptocurrency-based payment from a third party, the method comprising the steps of:

receiving, via an input module associated with the user, an input relating to a transaction amount;

generating a payment address (or“receive address”) to enable the third party to make the cryptocurrency-based payment to the administrator;

transmitting data relating to a payment amount and the payment address to the input module associated with the user; and receiving, on behalf of the user, the amount from the third party.

The method may comprise the step of receiving from the user, an input relating to the completion, by the third party, of the transfer. The method may comprise the further step of verifying that the transfer was successfully effected. The verification may comprise providing to a blockchain associated with the cryptocurrency, the payment address as an input parameter.

The transaction amount may be fiat-based and the method may furthermore comprise the step of converting the fiat-based amount to a cryptocurrency- based amount so that the payment amount may be a cryptocurrency-based amount. The transaction amount may be converted by retrieving a cryptocurrency-fiat currency exchange rate from an exchange. The payment amount may be determined by adding a buffer fee to the transaction amount to account for exchange rate fluctuations.

The method may comprise the further steps of:

trading the payment amount received from the third party on behalf of the user for a fiat-based amount or a different type of cryptocurrency- based amount from type of cryptocurrency of the payment amount on an exchange; receiving a fiat-based amount or the different type of cryptocurrency- based amount on behalf of the user;

verifying that the fiat-based amount or the different type of cryptocurrency-based amount received matches or exceeds the payment amount owed to the user.

The fiat-based amount or different type of cryptocurrency-based amount may comprise the transaction amount owed to the user. The method may comprise the further step of trading a portion of the buffer fee to account for a shortfall between the fiat-based amount or the different type of cryptocurrency-based amount received on behalf of the user and the amount owed to the user. The method may furthermore comprise the step of storing data relating to the transaction on a user profile associated with the user, and updating a cryptocurrency balance and/or fiat balance associated with the user profile.

The method may furthermore comprise the step of transferring an amount equal to the fiat balance stored on the user profile to a commercial bank account associated with the user. According to a seventh aspect of the invention there is provided a system for enabling an administrator to process and place an order with an electronic commerce service provider on behalf of a first user associated with a first user profile, the system comprising:

- an extension module for retrieving a URL relating to a specific page of a domain, which page is identified by the first user;

a background script for storing the URL;

a processor module for scraping relevant information from the specific page, for displaying the scraped information via a user interface to the first user and for providing input to a cryptocurrency payment processor; and

at least a first bot for receiving information relating to an order placed by the first user and information relating to the first user, and utilizing the received information to place an order with the electronic commerce service provider on behalf of the first user.

The domain may be controlled by the electronic commerce service provider. The administrator may be a registered user with the electronic commerce service provider

The extension module may comprise a web extension installed on a web browser utilised by the first user. The user interface may provide means for the first user to provide input relating to the displayed information, thereby to edit information relating to the order before placing the order.

The user interface may comprise a cart table for displaying the relevant information scraped from the specific page.

According to an eighth aspect of the invention there is provided a method for an administrator to process and place an order with an electronic commerce service provider on behalf of a first user associated with a first user profile, the method including the steps of:

- receiving an input from the first user relating to a specific page of a domain;

- based on the input received from the first user, retrieving a URL relating to the specific page of the domain;

- utilizing the URL to scrape relevant information from the webpage;

- receiving payment from the first user;

- utilizing information stored in the first user profile to place an order with the electronic commerce service provider on the user’s behalf. The domain may be controlled by the electronic commerce service provider. The administrator may be a registered user with the electronic commerce service provider. The relevant information may relate to a product and a price charged by the electronic commerce service provider.

The price may be fiat-based. The first user may provide the input through an extension module which may be installed on a web browser utilised by the first user.

The extension module may, in real time, monitor activity of the first user on the specific page.

The method may comprise the step of storing the URL in a background script stored on a memory arrangement associated with the administrator.

The method may include utilising bots associated with a processing module of the administrator, to place the order with the electronic commerce service provider. The payment received from the first user may be a cryptocurrency-based payment. The method of receiving payment from the first user may comprise providing to a payment system in accordance with the fifth aspect of the invention (in which case the administrator is a user of the payment system in accordance with the fifth aspect of the invention), the price charged by the electronic commerce service provider, and providing to the first user, information relating to the price and a payment address generated by the method (in accordance with the method of the sixth aspect of the invention) on behalf of the administrator.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

The invention will now further be described, by way of examples only, with reference to the accompanying diagrams wherein: figure 1 is a diagrammatic representation of a closed ecosystem for facilitating and monitoring cryptocurrency transactions between known entities, according to the invention; figure 2 is a diagrammatic representation of a private blockchain forming part of the closed ecosystem of figure 1 ; figure 3 is a flow diagram setting out a process of registration of a user of the ecosystem of figure 1 ; figure 4 is a flow diagram setting out a process of transferring amounts of cryptocurrency between known entities or users within the ecosystem of figure 1 (split between figures 4A and 4B forming a unit); figure 5 is a flow diagram outlining a payment processing step of the ecosystem of figure 1 ; figure 6 is a flow diagram setting out a process of transferring funds out of the ecosystem of figure 1 (split between figures 6A and 6B forming a unit); figure 7 is a diagrammatic representation of a crypto ATM which forms part of the ecosystem of figure 1 , but which could also be used outside thereof; figure 8 is a flow diagram setting out a process of a user logging in to the crypto ATM of figure 7; figure 9 is a flow diagram setting out a process of trading amounts of fiat currency for amounts of a second cryptocurrency, by utilising the crypto ATM of figure 7 (split between figures 9A and 9B forming a unit); figure 10 is a flow diagram setting out a process of trading amounts of a first cryptocurrency for amounts of a second cryptocurrency, by utilising the crypto ATM of figure 7; figure 11 is a flow diagram setting out a process of transferring an amount of cryptocurrency into the ecosystem of figure 1 , by making use of the crypto ATM of figure 7; figure 12 is a flow diagram setting out a process of trading an amount of cryptocurrency for an amount in fiat currency, by making use of the crypto ATM of figure 7; figure 13 is a flow diagram setting out a process of withdrawing funds from the ecosystem of figure 1 , by making use of the crypto ATM of figure 7; figure 14 is a diagrammatic representation of a cryptocurrency payment system according to the invention; figure 15 is a flow diagram setting out a process where a user of the payment system of figure 14 is paid by a customer or third party, for services or goods provided by the user to the customer or third party; figure 16 is a flow diagram setting out a process with which an amount of cryptocurrency is traded for an amount of fiat currency, should the user of the payment system of figure 14 opt to receive payment in fiat currency; figure 17 is a flow diagram setting out a process with which the fiat currency traded in accordance with the process set out in figure 16, is transferred to the user of the payment system of figure 14; figure 18 is a diagrammatic representation of an electronic-commerce

(e-commerce) gateway according to the invention; figure 19 is a flow diagram setting out a process with which a user of the e-commerce gateway of figure 18 adds items to a cart table which forms part of the gateway of figure 18; figure 20 is a flow diagram setting out a process with which a user of the e-commerce gateway of figure 18 confirms and places an order, relating to items previously added to its cart table, in accordance with the process outlined in figure 19; figure 21 is a flow diagram setting out a process with which the URLs scrape relevant information from the webpage via an API; figure 22 is a flow diagram setting out a process by which payment is made for orders confirmed accordance with figure 20 by the e-commerce gateway of figure 18; figure 23 is a flow diagram setting out a process by which orders confirmed and placed in accordance with figure 20 is processed by the e-commerce gateway of figure 18; figure 24 is a flow diagram setting out a process with which a first user of the ecosystem elects the manner in which to pay or transfer cryptocurrency to a second user or electronic commerce service provider; and figure 25 is a flow diagram setting out a process with which a second user or an electronic commerce service provider elects the manner in which cryptocurrency is transferred or paid by a first user of the ecosystem.

DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION

Glossary of terms:

Throughout this specification (including all portions thereof), the following terms will, unless otherwise stated or unless the specific context dictates otherwise, be understood to have the following meanings:

API: “application programming interface”. An API is a set of functions and procedures that allow the creation of applications which access the features or data of an operating system, application, or other service.

API Key: A code or set of instructions used to track and control the use of an API. When referring to API keys of an administrator, it will be understood that the API keys allows the administrator to perform certain tasks on the exchange, by using the API keys. The API keys are associated with certain permissions or restrictions, that allow prevent certain tasks from being executed.

Blockchain: A digital distributed ledger relating to a chronologic chain of recorded events, such as transactions of cryptocurrencies and the like.

Bot: An autonomous program forming part of a network or system which can interact with systems, users or components of the network or system, in order automatically to execute predetermined tasks.

Cryptocurrency: Cryptographic currency or blockchain-based currency. Crypto ATM: A software-based automated cryptocurrency purchaser as better defined by the third and fourth aspects of the invention and more fully described below with reference to numeral 20 in the figures.

Exchange: A system facilitating the trading or exchanging of a fiat amount or a cryptocurrency amount for a cryptocurrency amount or a different type of cryptocurrency amount, based on a cryptocurrency-fiat exchange rate or a cryptocurrency-cryptocurrency exchange rate. Exchanges are typically hosted by third parties. Node: A device forming part of a blockchain network that performs certain predetermined actions in respect of the blockchain.

Online: Computer controlled and accessible via the internet;

URL: A uniform (or universal) resource locator, that serves as an address of a webpage.

Smart contract: A computer protocol intended to digitally facilitate, verify, or enforce the negotiation or performance of a contract. Smart contracts allow the performance of credible transactions without third party intervention.

These transactions are trackable and irreversible.

Throughout this specification, the term“crypto” will be understood to refer to any or all of“cryptographic”,“cryptographic currency”,“cryptographic-based currency” and/or an amount of a cryptographic-based currency, as will become apparent from the context of each specific instance or use.

A closed ecosystem for facilitating and monitoring cryptocurrency transactions between known entities is indicated by reference numeral 10 in figure 1. The closed ecosystem 10 is governed and controlled by an administrator or governing body 12. The ecosystem 10 comprises a decentralised and private blockchain 14 (which is made up of a network of nodes (not shown)). The private blockchain 14 may run on a known software platform, such as Ethereum.

A user interface 16 is built on top of the blockchain 14. The ecosystem 10 is associated with a commercial banking account 18 (in fiat currency) and a “Crypto ATM” 20 (which is described in more detail below). The ecosystem 10 is associated with a number of users or known entities 22 (such as a first user 22.1 and a second user 22.2). The users communicate with the ecosystem 10 through modules 24 (such as a first module 24.1 associated with the first user 22.1 and a second module 24.2 associated with the second user 22.2) through known communication means 26, which enables the users 22 access to the user interface 16. The modules 24 may for instance comprise laptop or personal computers, smart devices such as smart phones and the like, while the communication means 26 may comprise wireless communication networks, wired communication media and the like.

The ecosystem 10 may communicate, through communication means which will be apparent for those skilled in the art, with various public blockchains 28 (such as a first public blockchain 28.1 , a second public blockchain 28.2, a third public blockchain 28.3, an nth public blockchain 28. n and the like). Each of the public blockchains 28 may be associated with a known cryptocurrency, such as Bitcoin, Litecoin and the like.

The ecosystem 10 may furthermore communicate with an exchange 30 which may be used to trade fiat currencies for cryptocurrencies, cryptocurrencies for a different type of cryptocurrencies, or cryptocurrencies for fiat currencies in known fashion. The ecosystem 10 communicates with the exchange 30 through the crypto ATM 20. The public blockchains 28 as well as the exchange 30 operate separately and independently from the private blockchain 10, in the sense that entities not associated with the ecosystem 10 may interact with these blockchains 28 and the exchange 30 without interacting with the ecosystem 10.

As is best shown in figure 2, a database of user profiles 32 is stored on the private blockchain 14. Each user or entity 22 is associated with a separate user profile 34 (such as a first user profile 34.1 , a second user profile 34.2 and the like) which is stored in the database 32. Each user profile 34 is associated with a smart contract 36, which stores frontend and backend data relating to certain information of the user 22 (it will be understood that the frontend data of various users 22 may be displayed through the user interface 16, and that a first registered user 22.1 may for instance gain access to the front end data of a second registered user 22.2, whereas the backend data is not accessible to any of the users 22). The data may vary based on the type of person (such as a natural person, a business etc.). Typically, the data relates to at least some of the following:

a name 36 and a surname 38 (in the case of a natural person) or tradename (not shown) (in the case of a business);

an identification number 40 (such as an ID or social security number, a passport number, or other identification number used in a particular country) (in some cases, where the ecosystem is used on a smaller scale, the identification number 40 may relate to a membership number, employee number, policy number or the like);

contact information 42 (such as a cellphone number, email address, office phone number, fax number and the like);

address information 44 (such as a physical address) (which address information 44 may in some cases need to be verified by an independent third party);

a wallet or plurality of wallet address(es) 46 (which wallet, or plurality of wallets, is used for storing amounts of cryptocurrencies, and which will be discussed in more detail below);

a public key(s) 48;

a private key(s) 50; a crypto balance(s) 52; and

a transaction record 54.

As will be discussed more fully below, the transaction record 54 comprises a record of encrypted and processed data relating to all transactions and cryptocurrency balance movements associated with a specific user.

Typically, the information relating to the identity of the user or entity 22 may be prescribed by a governing authority tasked with regulating information aimed at preventing corruption (for instance, in South Africa, the required information is prescribed by the Financial Intelligence Centre Act (FICA)).

The process of creating a user profile is indicated by reference numeral 80 in figure 3. A user 22 creates a user profile 34 on the ecosystem by creating login details (such as a username and a password) (shown at 82). In this way the user may obtain access to the ecosystem 10 through various modules 24. Two-factor authentication is however required when a user 22 logs into the ecosystem 10. The user 22 then submits relevant information (shown at 84), such as data items 36 to 44 mentioned above which is stored in the smart contract (shown at 86) associated with the user profile 34. Provision is made for the authentication (shown at 87) of some of the information as may be required (such as by way of one-time pins to authenticate a cell phone number, confirmatory emails and the like).

The wallet address(es) 46, public key(s) 48 and private key(s) 50 (shown at 88) are generated on behalf of the client (through API keys associated with the administrator or governing entity 12) and stored in the smart contract on the private blockchain 14 (at 90). This data (backend data) is never displayed on the user interface 16, and the user 22 can never gain access thereto. The user 22 is notified of successful registration on the system 10 (at 92).

Currently, the user 22 has no amount of cryptocurrency within the ecosystem 10, and the user’s crypto balance 52 will therefore be zero. The only way in which amounts of cryptocurrency is allowed to enter the ecosystem 10 is through the crypto ATM 20 (the process of cryptocurrencies entering or leaving the ecosystem through the crypto ATM 20 is discussed more fully below). As discussed below, the crypto ATM 20 has inherent security features which enables it to authenticate the origin of amounts of cryptocurrencies. Since there is only a single point of entry or exit for cryptocurrencies into or from the ecosystem 10, and since this entry point enables the authentication of the sources of these amounts, all cryptocurrencies within the ecosystem 10 at any point in time may be well regulated and monitored by the governing or regulatory body 12.

Even though transferring of cryptocurrencies from or to the ecosystem 10 is restricted, amounts of cryptocurrencies can easily be transferred within the ecosystem 10 between users or known entities 22 associated with user profiles 34. Again, since a record of all transactions is stored in the various transaction records 54, the origin of amounts of cryptocurrencies within any one of the persons users or entities 22 associated with the ecosystem 10 remains known and well documented.

The process of transferring an amount of a cryptocurrency from a first user 22.1 to a second user 22.2, both of whom are registered users of the ecosystem 10, is indicated by reference numeral 100 in figure 4.

The transfer process 100 is initiated by the first user 22.1 by logging in (at 102) to the ecosystem 10 through its module 24.1 , by utilising its login credentials. As mentioned, two-factor authentication is utilised to verify the credentials and identity of the first user 22.1. The user interface 16 will therefore now be displayed in the module 24.1. The user interface comprises a search function of the known kind. The first user 22.1 searches (at 104) for the second user 22.2. The first user 22.1 therefore provides input data relating to the identity of the second user 22.2. Other than conventional systems, the input data relating to the identity of the second user 22.2 will not relate to a receive address or a wallet address of the second user 22.2. Instead, the input data relates to the name 36.2 and/or surname 38.2 (or the name of an entity in the case of a business or other entity). The ecosystem

10 therefore receives the input data, and searches (at 106) through the database of user profiles 32 on the private blockchain 14 to identify potential user profiles 34 that may match the input data provided by the first user 22.1. The identified potential profiles are evaluated (at 108) and if no relevant user profiles are identified, the first user 22.1 is notified (at 1 10).

The first user 22.1 may now opt to end the process (at 1 12) or refine its search query by providing different input data (at 104). In this way, the ecosystem 10 prevents the transfer of amounts of cryptocurrency to parties outside of the ecosystem 10.

If, however, relevant user profiles are identified (at 108), a list of relevant user profiles is compiled and displayed (at 1 14) to the first user 22.1 via the user interface 16. Only relevant information (frontend information) (excluding wallet addresses 46, public keys 48, private keys 50, crypto balances 52 and transaction records 54) relating to the various identified user profiles 34 is displayed. The first user 22.1 evaluates the list (at 1 16) to ascertain whether the correct second user 22.2 appears on the list. If not, the first user 22.1 may opt to end the transfer process (at 1 12) or return to the search function (at 104) to refine the search by providing alternative inputs.

If the relevant second user 22.2 appears from the list, the first user 22.1 selects the second user 22.2 and selects an option to pay (at 1 18) the second user 22.2. Now, backend data (including at least some of the wallet address 46.2, public key 48.2 and private key 50.2) is retrieved (at 120) from the smart contract associated with the second user profile 34.2. The backend data is utilised to generate a receive address (at 122) on behalf of the second user 22.2. The receive address is not displayed at any point to the first user 22.1.

The first user 22.1 enters an amount of cryptocurrency (at 124) (and may enter a reference for identification purposes) and relevant fees or taxes (as elaborated on more fully below) is added to the amount (at 126) to arrive at a total amount of cryptocurrency required to complete the transaction. The first user’s 22.1 crypto balance 52.1 is retrieved (at 128) and evaluated (at

130) to determine whether the amount of cryptocurrency available is sufficient to complete the transaction. If not, the first user is prompted to re- enter an amount to be transferred (at 124), directed to the crypto ATM to acquire more cryptocurrency (at 132) or the process is ended (at 1 12).

If the first user’s 22.1 crypto balance 52.1 is sufficient to complete the transaction, the transaction is processed (at 134). In the present example, the transaction is conducted in a first cryptocurrency, associated with the first public blockchain 28.1.

The processing of the transaction (134) is conducted in known fashion, by making use of the backend data (such as the wallet addresses 46, public keys 48 and private keys 50) of the first and second users (22.1 , 22.2) and the receive address generated on behalf of the second user 22.2. The transaction is recorded on the first public blockchain 28.1 in known fashion. The ecosystem 10 queries whether the transaction was successful (at 136)

(this is shown in figure 5). The query 136 is conducted by utilising the “receive address” to query (shown at 137) the public blockchain 28 to receive a balance (at 139). This balance received at 139 is compared (at 141 ) to the amount entered by the first user 22.1 to be transferred to the second user 22.2. If these amounts are not equal, the first user 22.1 is provided with a notification (shown at 143) indicating a failed transaction, and again prompted to commence with the process by entering (at 124) a suitable amount of cryptocurrency to transfer to the second user 22.2.

If the transfer was successful, the amount in cryptocurrency is transferred (at 138) to the second user 22.2, the crypto balances (52.1 , 52.2) of the first and second users (22.1 , 22.2) are updated (at 140), the private blockchain 14 is updated (at 142) (all the nodes of the private blockchain 14 are notified) and the first and second users (22.1 , 22.2) are notified of the successful transfer (at 144). The transaction is recorded, and a record of the transfer is encrypted and processed (typically through a hash algorithm) and stored in the first and second users’ (22.1 , 22.2) transaction records (54.1 , 54.2) on their respective smart contracts.

In some cases, a user 22 might need to transfer an amount of cryptocurrency to a third party that does not form part of the ecosystem 10

(for instance, a foreign party). As discussed above, in the normal course of the operation of the ecosystem 10, this will not be possible, as the third party will not be part of the ecosystem 10, and consequently, there will not be a user profile 34 associated with the third party (therefore, with reference to figure 4, at step 108, no relevant party will be identified, the user 22 will be notified (at 1 10) and the process will end (at 1 12)). However, provision is made for the transfer of predetermined amounts of cryptocurrency out of the ecosystem 10. This process is generally designated by reference numeral 160 in figure 6. The smart contract associated with each user profile 34 contains an allowance 56, which is a predetermined amount of cryptocurrency that may be transferred from the ecosystem 10, to third parties outside of the ecosystem 10. The allowance 56 is defined for a specific, predetermined period, and is typically regulated by the governing body 12. The period may typically be an annual period, but other periods, such as daily, weekly and monthly allowances may also be provided for.

The transfer process 160 is again initiated by the first user 22.1 by logging in (at 102) to the ecosystem 10 through its module 24.1 , by utilising its login credentials. From the user interface 16 the first user 22.1 submits a request

(at 162) to transfer funds to a third party 58, which is in no way associated with the ecosystem 10. The first user enters as an input to the system an amount 163 that it wishes to transfer 160 from the ecosystem 10. The first user’s 22.1 allowance 56.1 and crypto balance 52.1 are retrieved (at 164) from the smart contract associated with the user profile 34.1 , which is stored on the private blockchain 14. The system firstly (at 166) determines whether the allowance is positive. If the allowance 56.1 is positive, the system secondly (at 168) determines whether the allowance exceeds the requested amount 163 to be transferred 160 from the ecosystem 10. If the allowance 56 is not positive (at 166), or does not exceed the requested amount 163 (at 168), the request is rejected

(at 170) and the first user 22.1 is notified (at 172). The first user 22.1 may now submit a special clearance request (at 174) to the governing body 12 to allow the transfer of the funds 160 from the ecosystem 10. The governing body 12 may consider this request in terms of a predetermined regulation, and may stipulate certain conditions in terms of which the transfer 160 may be allowed (such as special tax provisions, central bank approval, etc.).

On the other hand, if the allowance 56.1 exceed the requested amount 163 to be transferred 160 from the ecosystem 10, the amount 163 is compared (at 175) with the crypto balance 52.1. If the crypto balance 52.1 exceeds the amount 163, the transaction is allowed (at 176), and executed (at 178) in known fashion. In this regard, it will be appreciated that the third party 58 will have a wallet address 60, public key 62 and private key 64 (none of which are in any way connected with the ecosystem 10). A receive address will be generated by the third party 58 in known fashion and the amount 163 will be transferred in known fashion from the first user 22.1 to the third party 58. The transfer 160 will be recorded (at 180) on the public blockchain 28.1 associated with the specific cryptocurrency (in this case the first cryptocurrency) in known fashion.

The first user 22.1 will be notified (at 182) of the successful transfer 160, and the first user’s 22.1 crypto balance 52.1 and allowance 56.1 will be adjusted (at 184) and a record of the transaction will be encrypted, processed and stored (at 186) as described above.

If the amount 163 exceeds the crypto balance 52.1 (at 175), the first user 22.1 is directed (at 177) to the crypto ATM 20 to increase its crypto balance

52.1. Alternatively, the first user may opt to end (at 179) the transfer 160.

It will be understood that the system 10 will be able to authorise transactions undertaken by a user 22, by utilising the private key 50 as a signature. Even though the user 22 cannot access the private key 50 personally through the user interface 16, the system 10 will only be able to extract and utilise the private key 50 to authorise transactions during a session initiated by the user 22 having validly logged into its account 34. It will also be understood that each transfer of an amount of cryptocurrency to a user 22 is associated with a“receive address” that was generated for the transfer. All of the“receive addresses” relevant to a specific user 22 of the system 10 is stored on the smart contract associated with the user profile 34. The receive addresses stored on the smart contract may be used to query the relevant public blockchain 28 to confirm the balances of the user 22. All transactions undertaken by the system 10 are immutable. A reconciliation of a user’s 22 crypto balances 52 may periodically (such as weekly, monthly, quarterly, biannually or annually) be completed.

It will be apparent from the above examples, that the ecosystem 10 facilitates easy transfers of cryptocurrency between known users of the system 10. The governing body 12 is provided with access to the transaction records 54 of all the users 22, and can monitor fluctuations in the crypto balances 52 of the users 22. The ecosystem 10 furthermore provides a means of ensuring the legitimacy of all the cryptocurrencies within the ecosystem (as the origin of the cryptocurrencies are known). The ecosystem 10 furthermore regulates the transfer of cryptocurrencies out of the ecosystem. In this way, the governing body 12 may be able to levy taxes on transactions, or even income received by the users 22 within the ecosystem 10 (similar to the way in which conventional revenue services (such as the South African Revenue Service (SARS)) levies taxes on income). However, users 22 of the ecosystem 10 will still enjoy inherent benefits of transacting in cryptocurrency, instead of in fiat currency. It will be appreciated that the ecosystem 10 may have a vast number of users 22, and may ultimately constitute an economy on its own, in which amounts of cryptocurrencies are transferred between users in exchange for goods or services. The bounds of the ecosystem 10 may for instance coincide with the borders of a country, and wherein it is required that users

22 be residents, tax residents, citizens or the like. In such a case, the governing body 12 may be a government. Even though the governing body 12 has access to information stored on the private blockchain 14, and may use the information for regulatory purposes, the governing body 12 does not have the power to change any information relating to past transactions stored on the private blockchain 14. All of this information is furthermore encrypted. A consensus mechanism may furthermore be used to verify past transactions. Since a complete record of transactions is available, fraudulent activities can much easier be identified and traced. The transaction records comprise hashes used for identification, and show addresses as aforementioned.

It will also be appreciated that the ecosystem 10 may be scaled down to a much smaller scale, wherein the governing body 12 may for instance, be an employer, a medical or conventional insurance scheme, a loyalty rewards program (wherein the cryptocurrency may be a loyalty point based stable cryptocurrency) etc. In this way, the governing body 12 may dictate where amounts of the cryptocurrency are spent (for instance with preselected loyalty partners etc.).

The ecosystem may furthermore be associated with its own cryptocurrency, which may be associated with a public blockchain 28, or a private blockchain that may form part of the ecosystem 10.

It will be appreciated that small transaction fees may be levied by the governing body 12 on all transfers of cryptocurrency into the ecosystem 10, out of the ecosystem 10, and between users within the ecosystem 10.

Taxation may be based on the user’s 22 account balance. Tax may be added onto each incoming transaction to the user’s 22 account. Tax may be added on top of the transaction fees, and may be payable to the governing body 12. A party paying the user 22 will not be affected directly by the tax but will be directly affected by transaction fees which will be included in every transaction. Transaction fees may be predetermined as a minimal percentage of a total transaction amount. The recipient will not receive the full amount as tax will be deducted from the transaction amount before it enters the recipient’s account. Alternative means of levying tax (as provided for by legislation or regulations) may be employed by the governing body

12. It will be understood that amounts of cryptocurrency associated with a user 22 is stored on the public blockchains 28, and that the ecosystem manages the spending of the cryptocurrency by the user 22. This is achieved by the keys associated with the user 22. Therefore, the amounts of cryptocurrency that the users are permitted to spend are determined by the users’ keys.

The crypto ATM 20 is now discussed in more detail with reference to figures 7 to 12. It will be understood that the crypto ATM 20 is used as a part of the ecosystem 10 as discussed above, but that the crypto ATM 20 could also function as a system on its own, and does not require the closed ecosystem 10 to function.

Registration of a user 22 on the crypto ATM 20 is similar to the process of registering on the closed ecosystem 10 above, and will not be repeated here. When a user 22 is registered on the ecosystem 10, that user 22 will simultaneously be registered on the crypto ATM 20 as well. It will however be appreciated that a user 22 can register on the crypto ATM 20 without having registered on the ecosystem 10. For the present purposes, the crypto ATM 20 will be exemplified with reference to its use within the ecosystem 10, whilst interacting with users 22, who are simultaneously users of the crypto ATM 20. The crypto ATM 20 is shown in more detail in figure 7. The ATM 20 comprises hardware in the form of a processing module 200 and a memory arrangement 202. A server of the known kind may be used to provide the necessary processing module 200 and memory arrangement 202. A user interface 204 for allowing users 22 to interact with the system. The crypto ATM 20 is operated by an administrator 206. The administrator 206 exercises control over the server. The administrator 206 has an associated fiat-based business account 208 at the commercial bank 18. The administrator 206 furthermore has a profile 210 on the exchange 30. The profile 210 is associated with a crypto wallet 212 (or a plurality of crypto wallets associated with different types of cryptocurrencies or a single multi- currency wallet) which has an associated wallet address(es) 214, public key(s) 216, private key(s) 218, crypto balance(s) 220 and fiat balance 222. It will be appreciated that the administrator 206 and the governing body 12, may in some cases be the same entity.

Before a user 22 is capable of utilising the crypto ATM 20, that user 22 will have to log in to the user interface 204. The process of logging in to the user interface 204 is designated by numeral 250 in figure 8. The user 22 enters its username (at 252) and password (at 254). The user completes a verification step (at 256) to distinguish its input from that of a machine (typically by completing a CAPTCHA or the like). Next the processor 202 generates a random key (at 258) and sends the key (at 260) to a known communication address or number (such as an email address or cell phone number which is stored in the user’s profile on the crypto ATM 20). The user 22 enters the key (at 262) received, the system verifies the key entered, and if correct, the user 22 will be logged into its profile.

When logged into the crypto ATM 20, the user 22 will have to opportunity to trade an amount in fiat currency for an amount in cryptocurrency, an amount in a cryptocurrency for an amount in a different cryptocurrency, or an amount of cryptocurrency for an amount in fiat currency, without having to interact with the exchange 30 directly. The user 22 furthermore does not have to be registered as a user on the exchange 30.

The process of trading an amount in fiat currency for an amount in crypto currency is shown by numeral 270 in figure 9.

To start the trade 270, the user 22 logs in (as shown at 250 in figure 8). The user 22 specifies a cryptocurrency that it wishes to receive (at 272), specifies an amount of fiat currency (at 274) that it wants to trade for the specified cryptocurrency, and provides a“receive address” (at 276) to which the cryptocurrency must be transferred. The receive address is generated from wallet information of the user 22 (such as a public key associated with the user 22). The crypto ATM 20 verifies (at 278) that all required information is received. If not, the user 22 is redirected back to the required field to enter the required information.

It should be noted that each type of cryptocurrency requires an address in a specific format. The crypto ATM 20 therefore checks the format of the address (at 280) to confirm that it matches the required format for the type of cryptocurrency selected by the user 22. If the formats do not match, the transfer of the required amount of cryptocurrency will fail, and the amount may be lost.

If the formats do not match, a message is displayed (at 282) and the user is redirected back to the field where the receive address is entered, to correct the receive address.

If the receive address format is correct, the crypto ATM prompts (at 284) the exchange 30 to determine, based on a prevailing exchange rate, the amount of cryptocurrency that can be traded for the fiat amount entered by the user 22. This amount is received by the crypto ATM 20 (at 286).

The administrator 206 maintains a balance of cryptocurrency in its wallet(s) 212. If the balance reaches a threshold value, the administrator 206 is notified. The crypto ATM 20 therefore checks if the balance 212 exceeds the threshold (at 288). If the threshold has been reached, the administrator 206 is notified (at 290) to correct this. The crypto ATM 20 compares (at 292) the available balance 220 with the amount received from the exchange 30. If the available balance does not exceed the amount received from the exchange 30, the user 22 is notified (at 294) and the user 22 is provided with an option (at 296) to request a lower amount (in fiat currency) to be traded. If the user 22 enters a new amount, the exchange 30 is again prompted (at 284) to determine the amount of cryptocurrency, and the process is repeated as explained above. If the user 22 does not enter a lower amount, the process 270 is ended.

If the balance 220 exceeds the amount received from the exchange 30, the crypto ATM 20 is in a position to complete the transaction. The user 22 is redirected (at 300) to a third-party payment processor of the known kind, and the user 22 makes an electronic payment (at 302) of fiat currency into the administrator’s 206 bank account 208 (in known fashion). The user 22 is redirected (at 304) to the crypto ATM 20. The crypto ATM 20 monitors (at 306) whether the payment was successful and redirects the user 22 to the third-party payment processor if not. If the payment was successful, the amount of crypto received from the exchange 30 (minus a small transaction fee which may be levied in cryptocurrency) is transferred from the wallet 212 to the receive address (at 308). The user 22 therefore immediately receives his cryptocurrency, instead of having to wait for the exchange to process the transaction. The user 22 is notified of the successful transaction 270 (at 310) (this can occur by way of an email notification). Simultaneously, a trade request is submitted (at 312) to the exchange 30 to trade the amount received in fiat currency for cryptocurrency. The cryptocurrency traded by the exchange is received in the wallet 212 and the crypto balance 220 is restored. The fee that is levied makes provision for exchange rate fluctuations occurring between the time that the exchange determines the amount (at 286) of crypto currency that can be traded for the desired fiat amount, and the time that the trade request is submitted to the exchange (at 312). The simplified process of trading an amount in a cryptocurrency for an amount in different cryptocurrency is shown by numeral 840 in figure 10. To start the trade 840, the user 22 logs in at the crypto ATM 20 as above. The user 22 then selects a first wallet, associated with a first cryptocurrency, to transfer from. The user 22 then transfers 844 an amount of the first cryptocurrency from the“transfer from” first wallet to a third party holding a second cryptocurrency.

The third party then converts 846 the amount of the first cryptocurrency to a corresponding amount of a second cryptocurrency (amount determined via an exchange), which amount of the second cryptocurrency is then sent 848 from the third party to the user’s 22 elected second wallet as a“transfer to” wallet.

As was stated before, the crypto ATM 20 is the only means by which amounts of cryptocurrency can enter the closed ecosystem 10. The process by which an amount of cryptocurrency is introduced into the ecosystem 10, through the crypto ATM 20, is indicated by reference numeral 320 in figure

1 1 .

The user 22 (of the ecosystem) indicates (at 322) that it wishes to add an amount of cryptocurrency to its crypto balance directed (at 324) from the user interface 16 of the ecosystem 10, to the user interface 204 of the crypto ATM 20. The process of transferring fiat for crypto currency 270 as outlined above will roughly be followed, with the exception that the user 22 will already be logged in to the crypto ATM 20 (as the user 22 had already successfully logged into the ecosystem 10) and the user 22 will not specify a“receive address”.

Instead, as is shown in figure 1 1 , the user 22 specifies the type of crypto currency desired (at 272) and specifies a fiat currency amount (at 274) to be traded. The crypto ATM 20 now prompts (at 326) the ecosystem 10 to retrieve (at 328) backend data of the user 22 (such as the user’s public key 48) which is used to generate a receive address (at 330) on the user’s 22 behalf (as previously discussed). The crypto ATM 20 connects to the ecosystem 10 using a web3 connection. Alternative to the above, the crypto ATM 20 may execute a function to retrieve the address from the blockchain 16. The user login details may be passed as parameters in the function, to search through the smart contract for the required data.

This receive address is sent to the crypto ATM 20 (at 332). The trading process 270 now resumes from step 284 as outlined in figure 9. Once the trade is complete, the crypto ATM 20 notifies the ecosystem 10 (at 334). The ecosystem 10 updates the user’s 22 crypto balance 52 (at 336), updates the private blockchain 14 (at 338), notifies the user 22 of its increased crypto balance 52 (at 340) and encrypts, processes and records the transaction in the smart contract associated with the user profile 34 (at 342).

As stated, the crypto ATM 20 can also be used for trading amounts of cryptocurrency for amounts of fiat currency. This process is indicated by reference numeral 350 in figure 12. The user 22 logs into the crypto ATM 20 (at 250) as previously discussed with reference to figure 8. The user 22 now requests to trade an amount of cryptocurrency for an amount of fiat currency (at 352). The user 22 enters the currency (so that a receive address in the correct format can be generated) (at 254) and an amount of that currency (at 356) that the user 22 would like to trade. The ATM 20 retrieves the user’s 22 fiat banking details (at 358). The user 22 confirms the correctness of the banking details (at 360). If the details are not correct, the user 22 is prompted to enter or correct the details (at 362).

A receive address is generated (at 364) (as previously discussed, by using API keys linked to the administrator’s 206 account on the exchange 30) and provided to the user 22. The user 22 uses the receive address to transfer (at 366) the indicated amount of crypto currency to a wallet 212 of the administrator 206. The crypto ATM 20 verifies (at 368) whether the transfer of the amount of crypto currency was successful. If not, a new receive address is created (at 364) and the process repeats. If the transfer was successful, the crypto ATM 20 submits (at 370) a“sell request” to the exchange 30 of the requested amount of cryptocurrency. When the transaction is successful, the crypto ATM 20 receives a notification (at 372) and receives an amount of fiat currency (at 374) in the business bank account 208 of the administrator 206. A transaction fee is levied (at 376) and the remaining amount of fiat currency is transferred to the business banking account of the user 22 (at 378). The transaction detail is recorded and stored as previously discussed (and indicated at 380).

The process by which an amount of cryptocurrency is withdrawn from the ecosystem 10, through the crypto ATM 20, is indicated by reference numeral 400 in figure 13. The user 22 (of the ecosystem) indicates (at 402) that it wishes to withdraw an amount of cryptocurrency from a crypto balance. The user 22 is directed (at 404) from the user interface 16 of the ecosystem 10, to the user interface 204 of the crypto ATM 20. The process of trading crypto currency for fiat 350 as outlined above will roughly be followed, with the exception that the user 22 will already be logged in to the crypto ATM 20 (as the user 22 had already successfully logged into the ecosystem 10). The crypto ATM retrieves (at 406) the crypto balance 52 and banking details from the smart contract associated with the user profile 34 stored on the private blockchain 14 (as previously discussed). The crypto ATM 20 confirms (at 408) whether the balance 52 is larger than zero. If not, the request is rejected (at 410) and the user 22 is informed (at 412). If the retrieved balance 52 is larger than zero, the user 22 is prompted to enter (at 414) an amount in cryptocurrency that it wishes to withdraw. Even though only withdrawals of amounts of cryptocurrency is described, it will be understood that the user 22 may alternatively select to withdraw an amount in fiat currency. The user interface 200 of the crypto ATM 20 displays the user’s 22 crypto balance, and a corresponding value in fiat currency based on a prevailing or live exchange rate (which is obtained from the exchange 30 in real-time). The ATM 20 verifies whether the balance exceeds the amount entered (at 416). If not, the user 22 is prompted to enter a new amount (at 418), and the process repeats from step 414. If the user 22 opts not to enter a new amount, the request is rejected (at 410). If the balance 52 does exceed the requested amount, the banking details retrieved is displayed (at 420) to the user 22, to confirm (at 422) the correctness thereof. If incorrect, the user 22 enters or updates (at 424) the banking details. Next, a“receive address” is generated (at 426) from the wallet 212 on the exchange 30, and the stated amount of cryptocurrency is transferred from the ecosystem 10 to the wallet 212 (at 428). The transfer is monitored (at 430) and if not successful, a new address is generated as previously stated. If the transfer is successful, a“sell request” is submitted (such as illustrated from step 370 to 380 in figure 12). Once the process is complete, the crypto ATM 20 notifies the ecosystem 10 (at 432) of the successful transfer, the user’s 22 crypto balance 52 is updated (at 434) the private blockchain 14 is updated (at 436), the user 22 is informed (at 438) and the transaction is recorded, encrypted and stored on the transaction record 54 on the smart contract associated with the user profile 34 (at 440).

It will be appreciated that the user 22 does not require a profile on the exchange 30. The administrator 12 can easily change permissions on the exchange 30, change to a different exchange 30 and the like without influencing the user’s interaction with the system 10 or the crypto ATM 20. It will also be understood that more than one exchange may be utilised, and consequently, that the crypto ATM 20 may provide users 22 with access to a wide variety of cryptocurrencies. The crypto ATM 20 enables a user 22 to receive its traded cryptocurrency amount much more expediently than when dealing directly with an exchange 30. Furthermore, since the user 22 provides input and instructions to the crypto

ATM 20 through the input module 506, the crypto ATM 20 can conveniently be accessed and utilised from any location, provided the input module 506 is connected to the internet (typically through a known wired or wireless connection). This means that the crypto ATM 20 can be administrated without the need of providing or maintaining distributed hardware in the form of physical input machines or the like.

It will be understood that the crypto ATM 20 firstly determines an initial crypto amount, based on a current exchange rate, then transfers a subsequent amount, which is determined by deducting from the initial amount, a predetermined fee. The actual amount of cryptocurrency received from the exchange (a final amount) may differ from the initial amount, since the exchange rate may have changed between the time when the initial amount was determined, and the time the exchange is effected.

User 22 may be a user of either the ecosystem 10 or the crypto ATM 20, or both of these systems. A cryptocurrency payment system is generally indicated by reference numeral 500 in figure 14. The payment system 500 is managed or operated by an administrator 502. The payment system 500 is associated with a number of users 504 (such as a first user 504.1 and a second user 504.2).

The users 504 are typically vendors, purveyors, providers of goods or services and the like. Each user 504 is associated with an input module 506. The users 504 provide goods or services to customers 508 (such as a first customer 508.1 and a second customer 508.2). The payment system 500 allows the customers 508 to pay for goods or services provided to them by the users 504, by utilising cryptocurrencies. As will be discussed in more detail below, the payment system 500 furthermore provides the users 504 with the option to receive payment in either fiat currency or cryptocurrency. Each of the customers 508 is associated with an input module 510.

The payment system 500 comprises a user interface 512, a processing module 514, and a memory arrangement 516. The processing module 514 and memory arrangement 516 may take the form of a server hosted by the administrator 502. The users 504 communicate with the user interface 512 through known communication means 517. Each user 504 of the system 500 is associated with a user profile 518 which is stored in a database of user profiles 520. The system 500 is furthermore associated with a fiat banking account 522 at a fiat bank 524, and with a fiat to cryptocurrency exchange 526 of the known kind. The exchange communicates with public blockchains 528, associated with cryptocurrencies 530, in known fashion.

The administrator 502 has a profile 532 on the exchange 526, which links to the administrator’s 502 crypto wallet(s) 534, and contains information on the administrator’s 502 wallet address(es) 536, public key(s) 538, private key(s) 540, crypto balance(s) 542, fiat balance 544 and the like. The administrator 504 may communicate with the exchange 526 via an API and may utilise API keys as previously discussed. The modules (506 and 510) may for instance comprise laptop or personal computers, smart devices such as smart phones and the like, while the communication means may comprise wireless communication networks, wired communication media and the like. The payment system 500 communicates, through communication means which will be apparent for those skilled in the art, with the various public blockchains 528. The known cryptocurrencies 530 may for instance be Bitcoin, Litecoin and the like.

The data stored in the respective user profiles 518 varies depending on the type of user (such as a natural person, companies with varying degrees of liability, partnerships and the like.) Some of the information stored in the user profile 518 may include at least some of the following:

a name 546 (and surname in the case of a natural person) or tradename (not shown) (in the case of a business);

an identification number 548 (such as an ID or social security number, a passport number, or other identification number used in a particular country, or a business registration number);

tax number 550 (such as a personal income tax number, or a value added tax (VAT) number if the entity is registered as a VAT vendor) and other information required by the revenue service;

contact information 552 (such as a cellphone number, email address, office phone number, fax number and the like);

address information 554 (such as a physical address) (which address information 44 may in some cases need to be verified by an independent third party);

fiat banking details 556; a wallet or plurality of wallets address(es) 558 (which wallet, or plurality of wallets, are used for storing amounts of cryptocurrencies, and which will be discussed in more detail below);

a crypto balance(s) 560 relating to each type of cryptocurrency held in the user’s wallet(s);

fiat balance 562; and

a transaction record 564.

The user profile 518 is populated by information provided to the system 500 by the user 504 during registration. The process of registration will not be outlined in detail. Suffice to say, the process of registration comprises authentication of information provided to the system 500, the creation of login credentials and further security measures of the known kind. As was stated above, the system 500 enables the customer 508 to pay for goods and services with cryptocurrencies, whilst allowing the user 504 the option to receive payment in either cryptocurrency or fiat currency. Yet, this is handled by the system 500 instead of the user 504. The user 504 therefore does not require special infrastructure, or special software. Instead, the input module 506 of the user 504 becomes a point of sale, that provides access to the system 500 through the user interface 512. The process of a first customer 510.1 using cryptocurrency to pay for goods at a first user 504.1 , is generally shown at 580 in figure 15. For the purpose of the current example, the first user 504.1 may be a retailer selling goods to the first customer 510.1. The retailer may list the price of the goods in its store in either cryptocurrency or fiat currency. For the present purposes, the goods will be assumed to be listed in fiat currency.

The first customer 510.1 selects the goods it wishes to purchase (at 582) and presents same at the checkout (at 584). The first user 504.1 logs in to the system (at 586) and enters the amount of the goods (in fiat) (at 588). In this way, the input module provides a“mobile” point of sale. The type of cryptocurrency that the customer would like to use to make the payment is indicated (at 590) and the system 500 obtains a prevailing exchange rate of the selected cryptocurrency from the exchange 526 (at 592). The system 500 therefore calculates the outstanding amount in cryptocurrency (at 594) and generates a“receive address” (at 596) (utilising API keys as was discussed more fully above). The converted amount is stored in the web session, to prevent tampering with the amount or the payment by the user 504.1. The amount and receive address are presented to the customer 510.1 (at 598) (typically by representing both in the form of a QR code (of the known kind, and in accordance with known methods)). The customer 510.1 enters the address and amount (typically by scanning the QR code) into its module 510.1 (at 600) and makes the payment (at 602) by transferring cryptocurrency from its wallet to the system 500. The system now utilises the receive address to query the blockchain (at 604) (as was discussed more fully above) to compare (at 606) the balance of the receive address to the amount calculated at 594. If not equal, a new amount is determined and the process from 594 is repeated.

If the balance of the receive address matches the amount determined at 594, the transfer of cryptocurrency was successful. Now the transaction is recorded (at 608) in the first user’s 504.1 transaction record 564.1 , the first user’s 504.1 crypto balance 560.1 is adjusted (at 610), and the first user 504.1 is notified (at 612). If the user 504.1 requires to receive amounts in fiat currency, the cryptocurrency in the client’s 510.1 crypto balance 560.1 needs to be converted to an amount fiat currency. This process is indicated by reference numeral 620 in figure 16. This process is typically repeated each time a payment (as outlined at 580) is made. It will be appreciated that time delays are generally associated with trading cryptocurrencies for amounts in fiat currency. During these time delays, the exchange rate of the relevant cryptocurrency may change. The administrator therefore charges a predetermined handling fee to offset losses that may be incurred because of these fluctuations. The users 504 will typically account for these handling fees by increasing their asking prices for goods or services when trading in cryptocurrencies.

The process 620 is initiated by the system 500 determining the amount of cryptocurrency from the user’s 504.1 crypto balance 560.1 (shown at 622). This amount is transferred to the wallet 534 (at 624). The abovementioned service fee is deducted from the amount to be traded (at 626). The fee remains in cryptocurrency within the wallet 534, to act as a buffer for all future transfers 620.

The relevant amount of cryptocurrency is traded on the exchange (at 628) and an amount of fiat currency is received (at 630). The fiat balance 544 therefore increases by the amount received from the exchange 526. The system 500 queries (at 632) whether the fiat amount received is correct. As stated above, the fiat amount may be higher or lower than initially anticipated, due to exchange rate fluctuations. If the fiat amount is lower than required, a further amount to be traded on the exchange is calculated (at 634) the amount is taken from the buffer stored in the wallet, and traded (the process from 628 is repeated). If the fiat amount received is equal to, or higher than the required amount, the client’s 504.1 fiat balance 562.1 is updated (at 636) and the trade is complete. Any surplus amounts of fiat are kept to act as a buffer, similar to the buffer kept in cryptocurrency, as discussed above. It will be appreciated that a larger buffer amount in fiat currency can be maintained and that the system can be adopted (albeit not indicated) to first query the exchange rate from the exchange 526, to determine whether it would be better to trade more cryptocurrency, or alternatively, to use fiat currency, to make up for a deficit.

At the end of a calendar month, the system 500 transfers the amounts of fiat currency held on behalf of the clients 504 to their respective fiat banking accounts. This is shown by reference numeral 640 in figure 17. At the end of the month, the fiat balances 562 of each user is retrieved (at 642) from the database of user profiles 520 stored on the memory arrangement 516.

A total amount of fiat to be traded for the month is calculated (at 644) from all of the fiat balances. The total amount is retrieved (at 646) from the exchange 526 to the business account 522. The banking details of each user 504 is retrieved (at 648) from the database of user profiles 520 stored on the memory arrangement 516. The relevant amount (in fiat currency) is transferred electronically (at 650) from the business account 522 to the accounts of the users 504, the users 504 are notified (at 652) of the successful transfer, and the fiat balances 562 of the users 504 are adjusted (654).

In cases where a user 504 requires payment from the system in cryptocurrency, the amount may at any time be transferred to a wallet 558 stored in the user account 518.

It will be readily appreciated that the use of the system 500 enables easy and seamless trading between vendors, purveyors, providers of goods and services and the like, and their customers who wish to pay for goods or services utilising cryptocurrencies, and provides the users 504 of the system with the opportunity to receive payment in either cryptocurrency, or fiat currency. It will be readily ascertained that the payment system 500 could easily be incorporated into the closed ecosystem 10 discussed previously, to enable the monitoring and regulation of transactions facilitated by the system 500.

Since the payment system 500 communicates directly with the exchange 30, the user 504 does not have to provide any more payment facilities to enable its customers to make cryptocurrency payments to it in exchange for goods or services. The payments are therefore received from the customer (or third party) directly by the payment system 500, on behalf of the user 504. Since the input module 506 communicates through the user interface, a point of sale is created on any input module 506 through which the user 504 logs into the system 500. Therefore, the user 504 does not have to provide any functionality on its website, or provide a facility for utilising so- called“crypto-credit cards”. Also, the system 500 enables the user to decide whether to receive payment in cryptocurrency or fiat currency. Therefore, a user 504 that has not yet adapted capability of handling or receiving cryptocurrencies, may yet enable its customers to make payment in cryptocurrencies. Also, since only the administrator 502 needs to be registered with the exchange, the administrator 502 may easily adapt the system 500 to be compatible with a large number of cryptocurrencies, to suit the needs of the customers 508 of the users 504. In cases where the user 504 opts to receive payment in cryptocurrency rather than fiat currency, the service fee charged may be reduced, since delayed transaction times and changes in exchange rates, as aforementioned, may not play a role. It will be understood that a user 504 could also specify a specific type of cryptocurrency (such as Bitcoin) in which it wants to receive payment. If the third party used another cryptocurrency, such as Litecoin, the system can handle the exchange thereof, and again, a service charge will be levied. It will also be understood that the service fees will be required to process the transactions, update the blockchain etc.

An electronic-commerce (e-commerce) gateway is generally indicated by reference numeral 700 in figure 18.

The gateway 700 comprises a background script 702 which is stored on a memory arrangement (not shown) and receives input data from an extension module 704. A user interface 706 comprises a cart table 708.

The cart table 708 displays information received from the background script 702. The information is processed by a processing module 710 before being displayed in the cart table 708. The user interface 706 enables a user 712 to edit information contained in the user interface 706. As the user 712 edits information contained in the cart table 708, the processing module 710 updates data stored in the background script 702. The user 712 gains access to the user interface 706 through an input module 714 such as a smart device of the known kind, personal computer or laptop computer of the known kind.

The data stored in the background script 702 may include uniform resource locators (URLs) of websites accessed by the user 712 through its module 714. The extension module 704 takes the form of an application running on the module 714, and in particular, takes the form of a web extension installed on a web browser associated with the module 714. The cart table 708 comprises at least some of the following columns:

- item 716;

- price (in fiat currency) 718; and

- quantity 720. The gateway 700 is operated by an administrator 722. The gateway 700 is provided in communication with a cryptocurrency payment processor 500 as discussed previously. When the payment processor 500 is adapted to operate with the gateway 700, the administrator 722 of the gateway 700 is the user 506 (of the payment processor 500) and the user 712 of the gateway 700, is the customer or third party 508 of the payment processor

500. It will be understood that the payment processor 500 could form part of the architecture of the gateway, and that the user interfaces of the gateway 700 and the payment processor (512 and 706 respectively) could be merged into the user interface 706 of the gateway 700. It will therefore be apparent that the user 712 of the gateway 700, will be registered with the gateway

700 in order to use the gateway 700, but that the user 712, as customer 508 of the payment processor 500, will not have to be registered on the payment processor 500. Alternatively, the payment processor 500 may be operated independently from the gateway 700.

The processing module 710 comprises a plurality of bots 724 that execute certain functions based on inputs received via the processing module 710 from the background script 702.

The user interface 706 may comprise various buttons (such as checkout button 726, add or subtract buttons 728 with which the quantity may be adjusted, or remove button 730 with which a row from the cart table 708 may be removed) with which the user 712 may provide input that the processing module 710 may use to adjust or edit the data in the background script 702. The gateway 700 enables the user 712 to make online purchases utilising a cryptocurrency, on currently available electronic commerce sites, even when these sites do not support the use of cryptocurrencies. Furthermore, the user 712 (being registered on the gateway 700) does not have to be a registered user of these currently available electronic commerce sites. This adds convenience to the experience of online shopping. The registration of the user 712 on the gateway 700 is largely similar to processes as disclosed herein previously, and will not be repeated. Suffice to say, the user will at the very least provide detail pertaining to its identity, contact details, and a shipping address to the gateway 700 upon registering as a user 712. It will be clear that the user interface 706 is specific to the user 712, and only displayed once the user 712 has successfully logged in to the gateway 700.

The process through which the user 712 adds items to its cart table 706, is indicated by reference numeral 750 in figure 19.

The user 712 opens a web browser application (not shown) (on which the extension is installed) on its module 714, and starts browsing (at 752) through e-commerce websites. Throughout this process, the extension module 704 monitors and observes (at 754) the activity in the background

(but does not record any data unless prompted to do so). The extension therefore continuously awaits (at 756) inputs from the user 712. Once the user 712 identifies an item from the e-commerce website that it would like to purchase, it clicks on the extension in the web browser application, and the extension module 704 retrieves the URL of the active session (at 758), and stores the URL (at 760) in the background script 702 associated with the user 712. The extension of the web browser application is therefore directly linked to the user profile of the user 712 on the gateway 700. However, by clicking on the extension, the URL is merely copied to the background script. This does not result in a purchase order being generated, nor does it commit the user 712 to the purchase of the item on the active session.

The extension continues monitoring (at 762) whether the user continues browsing, in which case the process from step 756 will be repeated. This whole process will continuously be repeated each time the user 712 opens its web browsing application.

After the user 712 has identified one or more items (potentially from various e-commerce websites, none of which the user 712 had to log in to as a user) and the user 712 is ready to proceed with the purchasing of the items, the user 712 proceeds with the process of confirming its purchases and placing orders for the various items. This process is shown by reference numeral 770 in figure 20.

The user 712 logs in to the user interface 706 (at 772). The processing module 710 accesses the background script 702 associated with the user

712 (at 774) and retrieves the saved URLs therefrom (at 776). The processor module 710, acting as a web scraping module, utilises each URL to scrape and retrieve data from the websites associated with the URL (at 778). The data is filtered based on the specific website from which the data was scraped, and used to populate the cart table 708 (at 780). The processor automatically picks up is a specific URL appears more than once on the background script 702. In such a case, only one entity on the cart table will be generated, but the quantity (in column 720) will show the number of instances the URL appeared on the background script 702. It will be understood that each row on the cart table 708 will represent an independent item.

The process through which each URL scrapes and retrieves data from the websites associated with the URL (at 778) is indicated by reference numeral 850 in figure 21. Firstly, the URLs are sent 852 to the API which will retrieve the information of items to be purchased. Then a process of looping 854 through the list of URLs commences wherein for each URL, the associated website domain is determined and an appropriate and proprietary (of the system 10) scraping function is selected 854.2 after which the necessary information, including the price and title of the item(s) to be purchased, is scraped and saved 854.3, and then a check 854.4 is implemented to see whether there are any further URLs in the list of URLs remaining. If there are, then the looping 854 commences, however if there are no more URLs in the list, then the saved information as scraped for each URL and each independent item to be purchased is presented 856 on the cart table as described above.

The user 712 now reviews the cart table 708 (at 782) and adjusts the cart table 708 (at 782). The adjusting of the cart table may comprise the user removing certain items from the cart table (by selecting the remove button 730 associated with a specific row of the cart table 708) or adjusting the quantity of a specific item (by utilising the add or subtract buttons 728). As the user 712 adjusts the cart table 708, the processor module 710 processes the inputs, and updates the background script 702 (at 788). It will be clear that the cart table 708 is a visual representation of the background script 702.

Once the user 712 is content with the items, quantities and the like in the cart table 708, the user 712 confirms and places the order (at 790), by clicking on the checkout button 726. The user 712 is now directed to the user interface of the cryptocurrency payment processor 500 (at 792), and the process of making a payment at 794 which is provided in more detail in figure 22.

The process of making payment 794 in figure 20 is indicated by reference numeral 860 as shown in figure 22. After proceeding to payment 862, the user 712 may choose 864 whether the user 712 wishes to pay in either a stable cryptocurrency (or a fiat currency) 864.1 or a non-stable cryptocurrency 864.2. If the user 712 elects to pay in a non-stable cryptocurrency, the purchase price is converted 866 to the user 712 elected non-stable cryptocurrency. Once the purchase price has been established based on the user choice (at 864), then the purchase price (or converted purchase price) is presented 868 to the payment processor 500 via the gateway 700 and the user 712 can submit for payment. Once the user 712 has submitted payment, the payment address is queried 870 by the gateway 700, and the payment can be verified 872 (as at 796 in figure 20). Should the payment not be verified in that there is an outstanding amount on the purchase price noted from the payment address, the outstanding amount is queried 874, and the outstanding amount is presented 868 to the payment processor 500.

It will be understood that the total amount (in fiat currency) of items purchased will automatically be provided to the payment processor 500 as an input from the gateway 700. The payment is verified (at 796) (as discussed above), and the payment processor 500 confirms receipt of payment to the gateway 700 (at 798). The user interface 706 displays a message to the user 712 that the order has successfully been placed. An orders database 802 is stored on a memory arrangement 804 (the background script is also stored on the memory arrangement 804). Once an order is successfully placed (at 800) the order is stored to a“pending orders” list 806 (shown at 808). The process of confirming and placing an order 770 is now complete, and the user logs out of the user interface 706.

In the background, the gateway 700 now has to manage and process orders that were placed by the various users 712 and that are stored in the“pending orders” list. This process is indicated by reference numeral 810 in figure 23.

The processing module 710 awaits the availability of the bots 724. When a bot 724 finishes the processing and placing of a previous order, it indicates its availability to process a new order (at 812). An order is retrieved from the pending orders list (at 814) and allocated to the specific bot 724 (at 816). Orders may be retrieved (according to step 814) from the pending orders list 806 based on the age of the orders, or the urgency of the orders. The urgency may be determined by an input received from the user 712 when placing the order. The gateway may levy an additional fee for increasing the urgency of the order.

The bot 724 retrieves (at 818) the necessary information of the user from the gateway, that will be required to place orders at the various e-commerce service providers. The bot 724 utilises the information of the order and the client to physically place orders at the websites of the various e-commerce service providers 820. The information of the user 712, rather than information pertaining the gateway 700, is used to complete the orders at the various e-commerce sites. These sites can therefore communicate detail of the respective orders, such as delivery addresses and delivery times, directly to the client 712 without further intervention from the gateway 700. Shipping of orders may be directly to an address specified by the user. The gateway 700 pays for the orders placed at the various e-commerce service providers by transferring amounts in fiat currency from its business bank account, or by utilising online payment coupons, if available.

It will be understood that the gateway 700 acts as a middleman between retailers and e-commerce service providers.

Finally, figures 24 and 25 present flow diagrams setting out processes with which either: a first user of the ecosystem may elect the type of currency in which to make a payment or funds transfer to a second user (including an electronic commerce service provider) in or from the ecosystem 10; or a second user (including an electronic commerce service provider) may elect the type of currency in which to receive payment or funds transfer from a first user in or from the ecosystem 10. Those skilled in the art will appreciate that either or both of these processes can be employed at various parts of the ecosystem 10 where a payment or funds transfer (referred to as the transaction in figures 24 and 25) is effected from a first user (referred to as the user in figures 24 and 25) to a second user (referred to as the recipient in figures 24 and 25), but specifically may be employed in the transfer process within the ecosystem 10 as shown in figure 4, specifically when the transaction is processed (at 134), in the transfer process from the ecosystem 10 as shown in figure 6, specifically when the request is executed (at 178), or when a user confirms and places an order via the gateway 700 as shown in figure 20, specifically when the user makes payment (at 794).

Figure 24 shows the process wherein the user of the ecosystem 10 elects the type of currency (which may be any of a stable cryptocurrency, a non stable cryptocurrency and a fiat currency) in which to transact with the recipient, and thereby the user may be required to pay a conversion fee. This process is indicated by reference numeral 880. Firstly, the user receives 882 the payment address from the recipient in the transaction, and may then opt 884 to either convert the transaction amount to a recipient-elected currency or not. Should the user then opt to convert to the elected currency, the user is prompted to accept responsibility to pay an associated conversion fee 886, should they not accept the responsibility, the user is redirected to the start of the process 882. However, should the user accept the responsibility, then the conversion fee is added 888 to the transaction amount and the user then makes the necessary payment 890, which payment is sent to a third party for conversion 892. The currency is then sent 894 from the third party to the recipient.

The process from where the currency is sent 894 from the third party to the recipient is the same as that following on where the user has not opted 884 to convert to the elected currency and rather the user has sent payment in the unconverted currency to the recipient. Accordingly, the recipient is notified 896 of the incoming payment (and may then opt to follow the process of figure 25 indicated by reference numeral 910) and the user is notified of the successful payment 898 and the transaction record is updated

900 accordingly.

Figure 25 shows the process wherein the recipient of the ecosystem 10 elects the type of currency (which may be any of a stable cryptocurrency, a non-stable cryptocurrency and a fiat currency) in which to transact with the user, and thereby the recipient may be required to pay a conversion fee. This process is indicated by reference numeral 880. Firstly, the recipient is notified of an incoming payment and is prompted 912 to elect whether they wish to transfer the incoming transaction payment into a different wallet (or a fiat currency account where relevant). Should the recipient elect a different wallet (or fiat currency account), then the recipient is prompted 914 to accept responsibility to pay an associated conversion fee. Should the recipient not accept the responsibility, the recipient is redirected to the start of the process 912. However, should the recipient accept the responsibility, then the associated conversion fee is added 916 to the transaction amount (i.e. incoming payment amount). The process from where the conversion fee is added to the transaction amount is the same as where the recipient did not elect a different wallet 912, in that the receive address and the transaction amount is presented 918 to the recipient, and the receive address is then sent 920 to the user and the user is notified 922 and may issue payment.

Generally, it will be understood that the governing body (12 in the case of the ecosystem 10) and administrator (206 in the case of the crypto ATM, 502 in the case of the payment system 500 and 722 in the case of the e- commerce gateway 700) performs the task of a third-party intermediary with very limited control and monitoring. As third-party intermediary, the governing body or administrator lends legitimacy to the systems and transactions concluded therewith, from the general public’s point of view. This, to a large degree, solves the problem of distrust from the general public’s point of view. Despite this, the limited control of the governing body or administrator ensures that the potential benefits of blockchain technology are not jeopardised by its presence or control.

It will be appreciated by those skilled in the art that the invention is not limited to the precise details as described herein and that many variations are possible without departing from the scope and spirit of the invention.

The description above is presented in the cause of providing what is believed to be the most useful and readily understandable description of the principles and conceptual aspects of the invention. In this regard, no attempt is made to show structural details of the invention in more detail than necessary for a fundamental understanding of the invention. The words used should therefore be interpreted as words of description rather than words of limitation.