WO2019239086A1 - Token generation - Google Patents

Token generation Download PDF

Info

Publication number
WO2019239086A1
WO2019239086A1 PCT/GB2018/052779 GB2018052779W WO2019239086A1 WO 2019239086 A1 WO2019239086 A1 WO 2019239086A1 GB 2018052779 W GB2018052779 W GB 2018052779W WO 2019239086 A1 WO2019239086 A1 WO 2019239086A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
smart contract
party
transaction
cryptocurrency
Prior art date
Application number
PCT/GB2018/052779
Other languages
French (fr)
Inventor
Garry STEIN
Datuk Lim CHEE-WAH
William WELSER
Stephen Hill
Original Assignee
WRT Technologies Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by WRT Technologies Limited filed Critical WRT Technologies Limited
Publication of WO2019239086A1 publication Critical patent/WO2019239086A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/18—Legal services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • the token is held by a third party until the completion of the contract.
  • a third party preferably a party with no interest in the smart contract, holding the token acts in a similar way as escrow, whereby the first and second party need not trust each other.
  • transfers may take place as with other parties; as an example without a third party a token may be transferred from a/the first party to a/the second party upon completion of the contract.
  • the token is, optionally, transferred from the first party to the third party upon generation and then the third party to the second party upon completion of the contract.
  • the party related to the transaction is a state, preferably wherein the state is related to a currency used in the transaction.
  • the state is a state which backs and/or issues a currency used in the transaction.
  • a platform or system as herein described optionally adapted to use the token as herein described and/or adapted to use the method of generating a token as herein described.
  • FIG. 6b there is shown an exemplary smart contract 601 , where fields corresponding to those in the token are indicated.
  • thw smart contract 601 is provided.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Finance (AREA)
  • Tourism & Hospitality (AREA)
  • Human Resources & Organizations (AREA)
  • General Health & Medical Sciences (AREA)
  • Economics (AREA)
  • Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Technology Law (AREA)
  • Marketing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

The present disclosure relates to a computer-implemented method of generating a token for use in a transaction, the method comprising: providing a smart contract; extracting data from the smart contract; and initialising said token based on the extracted data thereby to enable the token to be used only in respect of the completion of the smart contract. A token corresponding to this method is also disclosed.

Description

Token generation
Field of invention
The present invention relates to a method of generating, and using, a token, which is transferable between parties. In particular, the present invention relates to the generation of, and use of, a cryptocurrency token to transfer a sum of currency between parties. The invention also relates to the token itself, to an apparatus for generating, and using, the token, and to a system that is adapted to use the token.
Background
Existing financial infrastructure used to transfer assets or funds internationally, settle trade, and register transactions is often dated, lethargic, and expensive to operate and use. Several factors in the economic and political environment, such as inefficient settlement systems and the potential for corruption, further compound issues for financial ecosystems for value transfer. Additionally, there is a growing trend of distrust in both the public and private financial institutions responsible for operating these systems. As a direct result of this distrust and the resulting loss of confidence, cryptocurrencies and digital transaction platforms are increasingly being developed. However, current versions of these systems retain numerous drawbacks and are notably imperfect for rapid, simple, large-scale transfer of funds across multiple currency systems.
Summary
Aspects and embodiments of the present invention are set out in the appended claims. These and other aspects and embodiments of the invention are also described herein.
According to least one aspect, there is described a computer implemented method of generating a token for use in a transaction, the method comprising providing a smart contract; extracting data from the smart contract; and initialising said token based on the extracted data thereby to enable the token to be used only in respect of the completion of said smart contract. This method allows a token to be linked to a certain transaction, or a certain group of transactions, at the time of generation. This linking diminishes the worth of holding the token, since it cannot be freely traded (having no worth apart from for the use specified within the contract). This enables the creation of a stable cryptocurrency. A smart contract can be created and shared using a computer device, this enables parties to reach agreement on the terms of a contract. Once confirmed, a token can be automatically generated and transferred as appropriate. Once the contract is completed, either successfully or unsuccessfully, the token can be transferred, and converted into another currency entirely automatically. The use of a smart contract enables the processes of generating and using the token to proceed automatically after the point of transfer of an initial currency. This enables a cryptocurrency that does not need to be held, or even seen, by any party making use of the cryptocurrency.
Preferably, the initialisation step comprises assigning a contract identifier, based on the smart contract, to the token. This assignment allows the token to be easily linked to a smart contract so that it can only be used for the purposes defined within the smart contract.
Preferably, the initialisation step comprises assigning a value, based on the smart contract, to the token. Preferably assigning a value comprises relating the token to an amount of cryptocurrency. Preferably the token comprises a cryptocurrency address.
Preferably the extracted data comprises at least one of: a receiving party; a sending party; an amount of a transaction; a date of a transaction; a currency used by a receiving party; a currency used by a sending party; contractual terms; and a completion time. These features are useable to define certain aspects of a transaction and may be recorded for review before, during, and/or after completion of a contract.
Preferably, enabling the token to be used only in respect of the completion of said smart contract comprises enabling the token to be used only for a specific transaction, preferably wherein the specific transaction relates to a payment for completion of contractual terms.
Preferably, the token is only useable during a predetermined time period. This further ensures that the cryptocurrency is not held by any party for the sake of speculation.
Optionally the token is only useable before a predetermined end time. Optionally the token is only useable after a predetermined start time.
Preferably, the time period during which the currency is useable corresponds to the expected completion time of the smart contract.
Preferably, the token is useable for less than an hour, more preferably the token is useable for less than a minute, yet more preferably the token is useable for less than a second. Being generated and transferred in a short amount of time reduces the possibility of foreign exchange rates changing where the transaction involves different ingoing and outgoing currencies. This also reduces the ability for parties to hold the token, improving the stability of the cryptocurrency.
Preferably, the token specifies an owner, wherein the owner is the only party that may redeem the token for an asset, preferably wherein the asset is a currency. By specifying an owner, there is no requirement to not share certain details related to the token. The token can be fully displayed to all parties with the knowledge that only the owner can redeem the token. This also allows a party to immediately redeem the token if the owner of the token is changed.
Preferably, the owner of the token is altered upon completion of a term specified in the agreement. By linking a change of ownership to the completion of a term in a smart contract, the token can be effectively transferred between two parties who need not necessarily trust each other (or any third party).
Preferably, the owner of the token is changed after a predetermined time period. Preferably the predetermined time period corresponds to the expected completion date of the agreement. This enables the token to be transferred to a suitable party at the conclusion of a contract. If the contract has been completed, the party to which the token is transferred is preferably the party performing the service. If the contract has not been successfully completed, the party to which the token is transferred is preferably the party for whom the service is being performed.
Preferably, the token is generated upon receipt of an asset. The token is preferably generated automatically once the first party has deposited in the relevant account an amount of currency as specified in the smart contract.
Optionally, upon completion of a term within the smart contract, the token is unassigned from the smart contract. This enables the token to, at a later date, be used for a different agreement.
Preferably, upon completion of the smart contract the token is transferred from a first party to a second party. Preferably the transferral process is automatic, so that the second party does not need to trust the first party to transfer the token and does not need to wait for the token to be transferred.
Preferably, the token is converted to a different asset immediately after being transferred from the first party to the second party. Preferably this asset is at least one of: a fiat currency; and a different token. The token being automatically converted to a different asset immediately upon receipt reduces the possibility of a party holding an amount of cryptocurrency, which may affect the value of the cryptocurrency or the amount of the cryptocurrency which is allocated to other parties.
Preferably, the token is held by a third party until the completion of the contract. A third party, preferably a party with no interest in the smart contract, holding the token acts in a similar way as escrow, whereby the first and second party need not trust each other. Where a third party is involved, transfers may take place as with other parties; as an example without a third party a token may be transferred from a/the first party to a/the second party upon completion of the contract. In embodiments where there is a third party, the token is, optionally, transferred from the first party to the third party upon generation and then the third party to the second party upon completion of the contract.
Preferably, the value assigned to the token is dependent upon the assets of a party related to the transaction, preferably the preferably the assets of the party related to the transaction are determined using publicly available information. This allows the supply of cryptocurrency to be limited to ensure that the cryptocurrency is not issued to parties/currencies which may not have sufficient wealth to back the issued cryptocurrency. Notably, this may be used to ensure that the maximum amount of cryptocurrency which is backed by a certain fiat currency does not exceed the asset wealth of the state backing that currency. The use of public records increases the simplicity and the transparency of the valuation.
Preferably, a maximum value of token that can be generated is determined based upon the assets of the party related to the transaction.
Preferably, the party related to the transaction is a state, preferably wherein the state is related to a currency used in the transaction. Preferably the state is a state which backs and/or issues a currency used in the transaction.
Optionally, the token is not held for more than an hour by any party, preferably the token is not held for more than a minute by any party, more preferably the token is not held for more than a second by each party. By limiting the amount of time that the token can be held by an party, the risk of currency speculation is diminished.
Optionally, the agreement is completed when confirmation is received from a plurality of trusted validators. Preferably, the trusted validators comprise at least one of: parties to the smart contract; trusted third parties; and parties involved in carrying out the terms of the contract. In order to verify that a smart contract has been successfully completed, consensus from a certain number of parties (or validators), who may be selected from a larger set of parties, may be required. This aids in ensuring that contracts are not fraudulently marked as completed.
Optionally, information related to the token and/or the agreement is stored on an immutable ledger. This ensures that suitable parties are able to review details of previous contracts at a later date.
Preferably, only parties with certain permissions are able to view the information, preferably only permissioned parties defined in the agreement are able to view the information. Parties may not be comfortable with details of agreements and transactions being publically available. By limiting access to certain relevant parties, confidentiality can be protected. Optionally, upon completion of the smart contract, the token is deleted and/or data assigned to the token is deleted. Preferably, all data contained within the token is deleted. This further aids in ensuring that the confidentiality of parties to the smart contract is not breached.
Optionally, the token is reassignable to a further smart contract. Preferably, data related to the smart contract is deleted before reassignment. While reusing tokens may be desirable to ensure that a wider range of cryptocurrency methods are useable, it may be desirable to ensure that each transaction is treated separately. This may help to protect confidentiality.
Optionally, the token is only useable for a single smart contract.
Preferably, information related to the token and/or the smart contact is stored on a blockchain. This enables relevant parties to view information related to the token and smart contract and enables the implementation of numerous consensus systems.
Optionally, a distributed ledger and/or a decentralised ledger is used to store information related to at least one of: the smart contract; the token; and the transaction.
Optionally, a plurality of tokens are generated. Preferably the plurality of tokens relate to a plurality of transactions within the smart contract and/or a plurality of parties to the smart contract.
According to another aspect, there is provided a computer-implemented token, the token comprising data extracted from a smart contract; wherein the usability of the token is dependent upon the extracted data such that the token is useable only in respect of the completion of said smart contract.
Preferably, the token comprises a contract identifier based on the smart contract.
Preferably, the token is assigned a value, preferably wherein the token is assigned a value related to an amount of cryptocurrency.
Preferably, the token comprises an owner identifier related to a party able to redeem the token.
Preferably, the token comprises a deadline identifier related to a completion deadline, preferably wherein the owner identifier is dependent upon the deadline identifier. The owner identifier may be arranged to change dependent upon the deadline identifier. If a deadline passes, the owner identifier may be changed so that the token is returned to the principal.
According to a further aspect, there is provided a computer implemented token generated according to any method as described herein. According to yet a further aspect, there is provided a method of performing a transaction using a token as described herein.
According to a further aspect, there is provided a computer program comprising software code adapted when executed to carry out any method as described herein.
According to another aspect, there is provided an apparatus adapted to execute a computer program product described herein.
According to yet another aspect, there is provided a financial system adapted to use any method as described herein.
According to yet another aspect, there is provided a financial system adapted to use a token as described herein.
According to yet another aspect, there is provided an ecosystem adapted to use any method as described herein.
According to yet another aspect, there is provided an ecosystem adapted to use a token as described herein.
Preferably, this ecosystem comprises at least: a party issuing tokens; and a plurality of parties performing a transaction.
In another aspect, there is provided a platform or system as herein described, optionally adapted to use the token as herein described and/or adapted to use the method of generating a token as herein described.
In a further aspect, there is provided a transaction system as herein described, optionally adapted to use the token as herein described.
The token as described herein may be considered a‘transitive token’ that is linked to a specific purpose and a specific transaction between two or more parties. The token may be considered to come into existence upon the agreement of a smart contract, be useable only in relation to the completion of that smart contract, and disappear upon completion of the smart contract. This token may also be considered as an‘ephemeral token’.
The token preferably comes into existence, or is initialised, upon agreement of a smart contract or, optionally, upon the receipt of an amount of currency. The token is initialised such that it is tied to the smart contract, and can only be used for the purposes specified within that smart contract and/or for purposes related to the completion of that smart contract, such as payment for completion of the contract. Preferably, the an amount of cryptocurrency is assigned to the token to enable the token to be used for payment. The token is effectively created at the beginning of a transaction, has an underlying, or associated, value related to the smart contract and is limited in use in dependence upon the smart contract.
The token is preferably transferred between parties on completion of the smart contract and/or on completion of a specified term within the smart contract, where this transfer is optionally achieved by altering an owner assigned to the smart contract.
After the transfer, the token is preferably redeemable for another asset and, once this occurs, the token effectively disappears. This disappearance may be effectively achieved by permanently assigning no owner to the token, assigning a value of zero to the token, or overwriting each field within the token to a null value. Optionally, the token is overwritten at the time of‘disappearance’ so that it may later be reused without retaining any information related to the first use.
The‘transitive token’ is useable to simplify transactions, particularly those using multiple currencies, as well as to discourage speculation, which might lead to volatility in the value of the assigned cryptocurrency. Thereby the ‘transitive token’ is useable to achieve a stable cryptocurrency.
A smart contract for which the token is used may last for any period of time, and the token may be held in escrow during the time that the smart contract is outstanding. Optionally, the token is used for short transactions, where the token is generated using a first currency, immediately transferred to another party, and immediately converted into a second currency (which may be the same as the first currency). Within this system, there may be some delay due to performing, regulating, or approving processes, so that, for example an hour may pass between ‘immediate’ transfers and conversions. Such an implementation of the ‘transitive token’ further discourages parties from attempting to speculate using the token, as it cannot be held for any substantial length of time.
The invention extends to any novel aspects or features described and/or illustrated herein. Further features of the disclosure are characterised by the other independent and dependent claims.
Any feature in one aspect of the disclosure may be applied to other aspects of the disclosure, in any appropriate combination. In particular, method aspects may be applied to apparatus aspects, and vice versa.
Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly.
Any apparatus feature as described herein may also be provided as a method feature, and vice versa. As used herein, means plus function features may be expressed alternatively in terms of their corresponding structure, such as a suitably programmed processor and associated memory.
It should also be appreciated that particular combinations of the various features described and defined in any aspects of the disclosure can be implemented and/or supplied and/or used independently.
The disclosure also provides a computer program and a computer program product comprising software code adapted, when executed on a data processing apparatus, to perform any of the methods described herein, including any or all of their component steps.
The disclosure also provides a computer program and a computer program product comprising software code which, when executed on a data processing apparatus, comprises any of the apparatus features described herein.
The disclosure also provides a computer program and a computer program product having an operating system which supports a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.
The disclosure also provides a computer readable medium having stored thereon the computer program as aforesaid.
The disclosure also provides a signal carrying the computer program as aforesaid, and a method of transmitting such a signal.
The disclosure extends to methods and/or apparatus substantially as herein described with reference to the accompanying drawings.
Aspects and embodiments of the disclosure will now be described, purely by way of example, with references to the accompanying drawings in which:
Figure 1 shows a system in which two companies wish to make a transaction;
Figure 2 illustrates a computer device on which a token is generated, and transactions are processed;
Figure 3 shows a system in which a first company and a second company perform a transaction;
Figure 4 shows a system within which transactions occur;
Figure 5 shows a subsection of the system of Figure 4;
Figure 6 (a) - (b) shows an exemplary token and an exemplary smart contract.
Figure 7 is a flowchart of a method of generating a token for a purpose specified in a smart contract; Figure 8 is a flowchart of a method of generating a token;
Figure 9 shows a flowchart of a method of obtaining and processing a smart contract; Figure 10 shows a flowchart of a method of linking an allotment of cryptocurrency to assets related to one or more parties;
Figure 1 1 shows an exemplary transaction between a first company and a second company;
Figure 12 shows a method of performing a transaction between numerous parties, which is observed by a notary;
Figure 13 shows an exemplary transaction between a sender and a beneficiary; and Figure 14 shows an exemplary delivery transaction between an importer and an exporter.
Detailed description
Referring to Figure 1 , there is shown a system in which two companies wish to make a transaction.
To facilitate this transaction, the two companies 10, 20 are arranged to communicate, directly or indirectly.
In a transaction involving the two companies 10, 20, there are numerous concerns that may arise due to, for example, a lack of trust between the involved companies 10, 20. Therefore, a system is provided herein so that two companies 10, 20 are able to communicate via a trust 100, which facilitates aspects of the transaction. This communication may be direct, or indirect, e.g. via an intermediary.
The system also allows for a third party 30 that has an interest in the transaction, such as an accountant, a lawyer, or an investor. The third party 30 is arranged to communicate with at least one of the companies, in this embodiment the first company 10, and to communicate with the trust 100.
The parties form an ecosystem 50 within which the methods, systems, and tokens as described herein are implemented.
Described herein is a method and system for performing transactions. In a embodiment, tokens related to a digital asset, herein referred to as a‘cryptocurrency’, are generated and/or issued by the trust 100. These tokens are generated based upon a smart contract, the parties to which are, at least, the first company 10 and the second company 20. The tokens are useable to perform transactions between the first company 10 and the second company 20 as agreed in the smart contract. Each agreement and transaction is recorded on a blockchain, where they are approved and/or viewed by the third party 30 as appropriate. Referring to Figure 2, there is shown a computer device on which aspects of the methods and systems described herein are implemented.
Each computer device 1000 comprises a processor in the form of a CPU 1002, a communication interface 1004, a memory 1006, storage 1008, removable storage 1010 and a user interface 1012 coupled to one another by a bus 1014. The user interface 1012 comprises a display 1016 and an input/output device, which in this embodiment is a keyboard 1018 and a mouse 1020.
The CPU 1002 executes instructions, including instructions stored in the memory 1006, the storage 1008, and/or the removable storage 1010.
The communication interface 1004 is typically an Ethernet network adaptor coupling the bus 1014 to an Ethernet socket. The Ethernet socket is coupled to a network, such as the Internet. The communication interface 1004 facilitates communication between each of the first company 10, second company 20, third party 30, and trust 100.
The memory 1006 stores instructions and other information for use by the CPU 1002. The memory 1006 is the main memory of the computer device 1000. It usually comprises both Random Access Memory (RAM) and Read Only Memory (ROM).
The storage 1008 provides mass storage for the computer device 1000. In different implementations, the storage 1008 is an integral storage device in the form of a hard disk device, a flash memory or some other similar solid state memory device, or an array of such devices.
The removable storage 1010 provides auxiliary storage for the computer device 1000. In different implementations, the removable storage 1010 is a storage medium for a removable storage device, such as an optical disk, for example a Digital Versatile Disk (DVD), a portable flash drive or some other similar portable solid state memory device, or an array of such devices. In other embodiments, the removable storage 1010 is remote from the computer device 1000, and comprises a network storage device or a cloud- based storage device.
Each of the first company 10, second company 20, third party 30, and trust 100 use computer devices 1000 to implement aspects of the methods and systems as described herein. The computer devices 1000 used may be the same, but in most implementations the computer devices 1000 will differ from one another somewhat to suit the different specific purposes and functions of the first company 10, second company 20, third party 30, and trust 100 respectively. For example, the primary function of the third party 30 may be recording aspects of transactions. The storage 1008 of the computer device 1000 which the third party 30 uses may therefore have large storage capacity, e.g. the storage 1008 is a storage device with large capacity. Alternatively, the removable storage 1010 of the computer device 1000 which the third party 30 uses may be a high capacity network storage device. As another example, an important function of the trust 100 is processing data related to the issuance of currency. The CPU 1002 of the computer device 1000 which the trust 100 uses typically therefore has high processing power. Additionally, the trust 100 is, in some embodiments, designed to generate and transfer tokens automatically based upon digital contracts, so that the computer device 100 that the trust 100 uses may have a minimal user interface 1012. In yet another example, the computer devices 1000 which the first company 10 and second company 20 use may be optimised for usability, in that they may be personal computers, laptop computers, tablet computers or such like.
A computer program product is provided that includes instructions for carrying out aspects of the method(s) described below. The computer program product is stored, at different stages, in any one of the memory 1006, storage device 1008 and removable storage 1010. The storage of the computer program product is non-transitory, except when instructions included in the computer program product are being executed by the CPU 1002, in which case the instructions are sometimes stored temporarily in the CPU 1002 or memory 1006. It should also be noted that the removable storage 1008 is removable from the computer device 1000, such that the computer program product is held separately from the computer device 1000 from time to time. Different computer program products, or different aspects of a single overall computer program product, are present on the computer devices 1000 used by the first company 10, second company 20, third party 30, and trust 100, as evident from the description below.
The first company 10, second company 20, third party 30, and trust 100 may use a plurality of computer devices 1000. Different aspects of the trust 100 may be operated on a plurality of different computer devices 1000 and/or a plurality of computer devices 1000 may be utilised in the confirmation of a transaction and/or the storage of a transaction ledger. More generally, a combination of computer devices 1000 may be used to store relevant information and carry out aspects of the methods described herein, where these computer devices 1000 may each store copies of the same information, or may store differing information that can be combined.
In some embodiments, aspects of the methods described herein are implemented using blockchain technology and/or a distributed ledger, which are stored upon a plurality of computer devices. This distributed ledger may, for example, store information about the implemented cryptocurrency, which may relate to previous transfers of cryptocurrency and/or current owners of tokens to which cryptocurrency is assigned. The first company 10, second company 20, third party 30, and trust 100 may use, at various times, different computer devices 1000 to carry out aspects of the methods, where different computer devices 1000 may have different permissions, so that only on certain systems, or with certain passwords, can a party access certain information and/or system capabilities.
Separate parties may have access to separate records: the distributed ledger is preferably accessible by every party (although this ledger may contain information that not every party can view), there may, however, also be certain data which is held solely on the computer device 1000 of each party.
Referring to Figure 3, there is shown the ecosystem 50 in which the first company 10 and the second company 20 perform a transaction.
The second company 20 is arranged to communicate with the first company 10; in particular, the second company 20 is arranged to transfer money to the first company 10 in the form of the token. In order to obtain the token required for the transaction, the second company 20 is arranged to communicate with a second bank 50. The second bank is arranged to communicate with the trust 100 in order to obtain the token and transfer the token to the second company 20. In this way the second company 20 is arranged to indirectly receive the token in exchange for money - the token may also be received in exchange for other assets, for example goods and/or services. In some embodiments, the second company 20 directly obtains the token from the trust 100.
The first company 10 is arranged to communicate with the second company 20 to receive the token. The first company 10 is also arranged to communicate, optionally via a first bank 40, with the trust 100 so that it can exchange the token for a different asset, e.g. a fiat currency or another cryptocurrency.
While this system has been described in terms of the second company 20 being arranged to transfer the token to the first company, more generally the parties can be arranged to communicate such that the first party can transfer tokens to the second party and/or to any other party.
Each party is arranged to record, approve, and/or authorise transactions using smart contracts. This may involve receipt of information via the communication interface 1004 of the computer device used by the party. The smart contract is stored upon a blockchain ledger within the storage 1008 of one or more parties. A number of third parties 30 that have an interest in the transaction are arranged to receive, authorise (e.g. confirm that it should be added to the ledger), and/or view the smart contract. In some embodiments, the token is not useable until the smart contract has been authorised.
Referring to Figure 4, there is shown a system within which transactions occur. The first company 10 and the second company 20 are users within the system. A third company 22 is also present. More generally, any number of users may be present in a system, and any number of users may participate in a transaction.
The first company 10 is arranged to communicate with the trust 100 through the first bank 40 and the second company 20 and third company 22 are arranged to communicate with the trust 100 through the second bank 50. The trust 100 is arranged to communicate with one or more central banks 70, which in some embodiments are the central banks of states. In some embodiments, there is a value of cryptocurrency allocated to each fiat currency dependent upon the resources of the states that backs the fiat currency.
That the trust 100 is arranged to communicate with central banks 70 enables the current value of cryptocurrency issued against each currency to be simply tracked. This communication also enables the trust 100 and central banks 70 to transfer fiat currencies and cryptocurrencies between themselves and enables the central banks 70 to, where appropriate, approve, validate, and/or view, transactions. This decreases the proliferation of, for example, money laundering and tax fraud.
Referring to Figure 5, there is shown a subsection of the system of Figure 4.
The central banks 70 are arranged to communicate between themselves to facilitate fiat to fiat transfer. This fiat to fiat transfer preferably occurs only between central banks 70 - and is optionally coordinated by the trust 100. This enables the first company 10 and the second company 20 and/or the first bank 40 and the second bank 50 to transact without concern of fiat currency exchange. These parties can use their own fiat currencies, where these are, as a matter of course, converted to the cryptocurrency as suitable.
In a practical example of, the first company 10, second company 20, and third company 22 agree on a smart contract related to a transaction. The smart contract contains payment terms in both the paying and receiving currencies as well as conditions that need to be met for payment to be released. The first company 10 transfers an amount of fiat currency as agreed in the smart contract to the trust 100 via first bank 40. The trust 100 verifies that the amount of cryptocurrency issued against the fiat currency used by the first company 10 is less than the overall allocation. The trust 100 then transfers at least one token to the first company 10 via the first bank 40, the token(s) having assigned to them an amount of cryptocurrency related to a transaction within the smart contract. Where three or more parties are involved in a transaction, or where there are a plurality transactions specified within the smart contract, multiple tokens are issued. The token(s) are tied to the smart contract, which specifies at least the amount and the parties involved. This prevents the token(s) being used for another purpose. The first company 10 transfers the token(s) to the second company 20 and the third company 22 upon completion of the smart contract. The second company 20 and the third company 22 transfer the token(s) to the trust 100 via the second bank 50, where they are converted into a fiat currency as agreed in the initial smart contract.
The trust 100 communicates with a network of central banks 70 to convert between fiat currencies as appropriate. Such conversions optionally occur in large sums, which may comprise a plurality of transactions, to obtain optimal conversion rates.
The trust 100 also records the amount of cryptocurrency, in the form of tokens, that has been issued against each fiat currency, and the amount of fiat currency to which the cryptocurrency relates. The trust 100 is able to determine how much cryptocurrency is backed by any fiat currency and can limit the issue of further cryptocurrency, in the form of tokens, to ensure that no cryptocurrency is issued against a fiat currency that is at risk of exceeding a determined allocation. As an example, if companies within a country have deposited a first amount of a fiat currency in exchange for the issuance of tokens, the trust 100 is aware of this. Upon a company requesting further issuance of tokens in exchange for (or against) a further amount of the fiat company, the trust 100 can determine whether issuance of this further token would result is an allocation determined for the fiat currency being exceeded. When the smart contracts related to relevant transactions are completed, and the tokens issued related to the fiat currency are redeemed, this is also recorded by the trust 100. A method of allocating an amount of cryptocurrency to a party is described further with reference to Figure 10.
The time at which the conversions of the first currency to the token, and the token to the second currency, take place differs in various embodiments. In some embodiments, the conversions take place in rapid succession at the time of agreeing a contract - this ensures that the exchange rate is known. The trust 100 may then hold the second currency until the contract is completed. The conversion into the second currency may instead take place upon completion of the contract, where instead the token is held until the contract is completed. Where the token is converted into the second currency upon completion of the contract, the token may not be held by the trust 100 and may instead be distributed to one or more parties. In this case, the token cannot be used and/or redeemed apart from as specified within the smart contract. Even if a malicious party obtains the token, it cannot use or redeem the token as it could a currency.
A record of the transaction is stored, for example using distributed ledger technology (DLT) and/or a decentralised ledger.
Consensus on each transaction involves the parties that are stakeholders of the transaction and, where appropriate, the central banks 70 and / or third parties 30, such as government regulators. In some embodiments, parties are divided between validating and non-validating parties. Validating parties, which preferably include parties to the transaction as well as trusted third parties, check the validity of each transaction. Non-validating parties are used for time-stamping purposes and do not need to see underlying details of the transaction. Depending on, for example, the sensitivity of the transaction, different parties may fall into different categories.
The cryptocurrency is issued to parties in the form of tokens, where each token contains a number of fields, each field relating to a certain type of information.
Referring to Figure 6a, there is shown an exemplary token 600. A token is assigned fields that define aspects of its operation, such as:
• sender 602: the party transferring money during a transaction (e.g. the first company 10);
• receiver 604: the party receiving money during a transaction (e.g. the second company 20);
• input fiat 606: the currency transferred by the sender;
• output fiat 608: the currency received by the receiver;
• input amount 610: the amount to be transferred by the sender;
• output amount 612: the amount to be received by the receiver;
• contract identifier 614: an identification tag related to a relevant smart contract;
• owner 616: the party that may use and/or redeem the token;
• contractual terms 618: the agreed actions required for the contract to be successfully completed; and
• completion time 620: a date and/or time related to the period during which the contractual terms 618 must be met for the receiver 604 to receive the money. This may, more generally, be any time related to the contract, such as a start time, an expected completion time or a completion deadline.
Referring to Figure 6b, there is shown an exemplary smart contract 601 , where fields corresponding to those in the token are indicated.
These values for fields within the token 600 are extracted from the smart contract 601 , where upon agreement of the smart contract 601 a token 600 is automatically generated using the extracted values.
The values within the token 600 may be directly or indirectly defined by the smart contract. As an example, an input amount 606 is agreed in an input fiat 606; the sender 10 agrees to transfer this amount to the trust 100. These values can be directly assigned to the token 600. The output amount 612 may then be determined, and assigned to the token 600, based upon an output fiat 308 and an agreed exchange rate 611.
There are, in some embodiments, default values used for a number of these fields, such as the output fiat 608 being dollars or the output fiat 608 being the currency commonly used within the location of the receiver 20. The parties to the smart contract are required to agree on using any default values.
In some embodiments, the token 600 contains a contract identifier 616 linked to a specific smart contract 601. The token 600 is only usable for a specific purpose defined within that contract 601 , such as a specific transaction. It may then be checked, for example at the time of any attempted transaction, that the attempted transaction corresponds to the transaction specified within the smart contract 601.
The token 600 is, preferably, automatically transferred to a party upon the completion of the smart contract 601. In some embodiments, this transfer occurs using an owner field 616. At the time of generation of the token 600, details of the token 600 are shared with each relevant party. The owner field 616 is initially be that of the first company 10, however in some embodiments the owner field 616 is set to that of a trusted third party, such as the trust 100. The owner field 616 may also be set as empty (so that there is no owner of the token, and no party is initially able to redeem it). At the time of completion of the contract, the owner field 616 is changed to the receiver 20. Only the owner of the token 600 is able to redeem the token for fiat currency (or another cryptocurrency).
The smart contract 601 optionally contains a completion time 620; this completion time 620 may correspond to an expected time of the contract being completed, or to a completion deadline. The completion date may also be a period during which the contract can be completed. If this completion time 620 is a deadline, and that deadline passes, the contract is considered unsuccessfully completed and the owner field 616 is changed to the sender 10, who may then redeem the token 600 to recover their initial amount. The ownership of the token 600 is, in some embodiments, determined entirely by the agreed smart contract 601. Each party is able to view the properties of the token 600, such as the input amount 610 and the output amount 612, so that each party can ensure that the input payment has been made correctly and that the output payment will be that expected. Each party can be confident that the token 600 will be transferred if, and only if, the smart contract 601 is completed (either successfully or unsuccessfully). This mechanism acts as a form of escrow, without the requirement to trust a third party to hold the money.
A contract may be considered completed, for example: when a relevant party has met the terms of the contract; when the terms of the contract can no longer be met, for example if a completion deadline has passed; if the receiver no longer has the capability to complete the contract; or if all parties to the contract agree to complete the contract (either successfully or unsuccessfully).
In some embodiments, the token 600 contains a field which indicates a current value, for example in terms of a cryptocurrency. A token may relate to 1 .1 coins of“Examplecrypto”. The value of a token 600 is preferably assigned during its generation, being linked to the amounts specified in the contract so that the cryptocurrency valuation is preferably inherent in the token 600 itself, and does not need generally to be specified.
Referring to Figure 7, there is shown the process of generating a token in relation to a smart contract. More specifically, there is shown a process for generating and using the token for the completion of the smart contract. This process takes place within the ecosystem 50.
In a first step 120, the smart contract 601 is provided. In a simple example, a smart contract 600 may be transferred by a party to the trust 100 using the communication interface 1004 of the computer devices 1000 used by the party and the trust 100. This smart contract 601 is approved, e.g. signed, by at least the first company 10 and the second company 20.
In a second step 134, the input amount 610 specified in the smart contract is received from the first company 10 by the trust 100, optionally via the first bank 40.
In a third step 136, a token 600 is generated by the trust 100. The token 600 is, as described above, linked to a purpose defined within the smart contract 601. Depending upon the implementation of the token 600, the token 600 may be transferred to the first company 10 and/or where the owner field 616 is used, the token 600 may be transferred to each party since the owner is the only party able to redeem the token 600.
In a fourth step 138, it is detected whether the terms of the smart contract 601 have been met. Consensus on this is required by a number of validating parties; these parties may, for example be: the parties to the contract; delivery companies; regulators; and/or trusted notaries.
If the terms of the smart contract have been met, in a fifth step 142, the token 600 is redeemed for the agreed output amount 612 in the output fiat currency 608 specified by the second company 20. This currency is then transferred, in a sixth step 144, to the second company 20.
If, at the time of the fourth step 138, the terms of the smart contract 601 have not been met, in an optional fifth step 152, it is determined whether a completion time 620 defined in the smart contract 601 has been exceeded. If this completion time 620 has been exceeded, in a sixth step 154, the token 600 is redeemed in the fiat currency 606 defined by the first company 10 and in a seventh step 156, this currency is transferred to the first company 10.
The token 600 may then be unassigned, whereby it may later be used again, or deleted, where, for example, the specific pointer to an amount of cryptocurrency is removed from circulation.
Referring to Figure 8, there is shown in more detail the generation of the token 600.
In a first step 182, thw smart contract 601 is provided.
In a second step 184, data is extracted from the smart contract 601. This involves determining suitable data, such as that described with reference to Figure 6 and extracting it from the smart contract 601. In some embodiments, a template smart contract is provided where there are clearly marked fields into which relevant data is entered by the parties to the contract 601 . This relevant data can then be easily extracted when required. Text analysis techniques may also be used to determine the locations of relevant information within the smart contract 601 .
In a third step 186, the token 600 is initialised. The token 600 is initialised such that it is only useable for purposes defined within the smart contract 601 , preferably this purpose is related to the completion of the smart contract 601 .
In a fourth, optional, step 188, a contract identifier 614 is assigned to the token 600. This contract identifier 614 is useable to determine the smart contract 601 to which the token is related and thereby to determine how the token 600 may be used.
In a fifth, optional, step 189, a value, or a worth, is assigned to the token 600. This value is preferably related to a cryptocurrency. In some embodiments, the token 600 is assigned a cryptocurrency address (or cryptocurrency addresses) related to an amount of cryptocurrency that corresponds to an amount specified within the smart contract 601 . In some embodiments, the token itself forms a cryptocurrency address and/or the token 601 has an inherent value associated with a cryptocurrency where the initialisation occurs such that the token 601 immediately, and inherently, has the relevant value.
In some embodiments, a contract identifier 614 is assigned to the token 600 to relate the token 600 to a specific smart contract 601 . There are numerous other methods which could be used to relate the token 600 to the smart contract 601 , such as assigning to the token 601 the relevant contractual terms 618, or specifying a combination of the sender 602, the receiver 604, the input and output fiats 606, 608, and the input and output amounts 610, 612. These properties, along with additional information if necessary, may be sufficient to relate the token 600 to the smart contract 601 . In some embodiments, the token 600 is assigned to a number of contracts 601 and/or situations. As an example, the token 600 may be assigned such that it is transferrable to the party that completes a piece of work first; this may involve numerous separate contracts being used, each specifying a different receiver 604, output fiat 608 and output amount 612, where only a subset of the possible transactions are eventually executed and only a subset of issued tokens may be eventually redeemed by receiving parties.
In some embodiments, the token 600 is assigned to a range of purposes as defined by the smart contract 601 . For example, the token 600 may be useable for a number of potential transactions between two parties where only the sender 602, receiver 604, input amount 610, and output amount 612 are specified.
Referring to Figure 9, there is shown further detail of the obtaining and processing of the smart contract 601.
In a first step 122, the smart contract 601 is received by the trust 100. This smart contract 601 may be sent by any party.
In a second step 124, it is determined whether each party mentioned within the smart contract 601 has the correct permissions to approve, e.g. sign, the smart contract. Permissions may refer to, for example, the right for a party to be issued tokens, the right for two parties to engage in an agreement, and the maximum transaction amount that a party is allowed to specify.
In a third step 126, if each party has the correct permissions, the allocations relevant to the smart contract 601 are checked. The determination of allocations is determined as described with reference to, for example, Figure 10. More specifically, in some embodiments, it is determined whether the input fiat currency amount 608 and the output fiat currency amount 610 would result in the total amount of cryptocurrency allocated to the defined currencies exceeding their allowed allocations.
In a fourth step 128, if each currency has a sufficient allocation, it is checked that each signatory required has confirmed the contract 601. This notably includes the first company 10 and the second company 20 and may also include third parties 30, such as regulators.
In a fifth step 129, if all required signatories have confirmed, the token 600 is specified.
The input amount 608, output amounts 610 and input and output currencies 606, 608, and the contract identifier 614 are defined. There may also be defined contractual terms 618, which must be met to successfully complete the contract 601.
If at any step the determination is that a requirement has not been met, the smart contract 601 is returned to the relevant parties, and the problems are identified. There may be a suggestion of how these problems can be rectified - as an example, the maximum transaction amount may be identified based upon relevant allocations and/or permissions.
The method optionally involves allocating an amount of the cryptocurrency to each country, where the amount of cryptocurrency that can be issued against each fiat currency is limited. This allotment is preferably determined based upon the wealth of the country.
Referring to Figure 10, there is shown a method for linking an allotment of the cryptocurrency to assets related to one or more parties.
In some cases, it is desirable to link the cryptocurrency to an asset, such as gold, gas, or oil. This is likely to result in a more stable cryptocurrency, in terms of the value of one ‘coin’, than a non asset-backed currency. It is also more likely to bring the cryptocurrency into compliance with Sharia law, which is especially desirable from businesses operating in the Middle East or Indonesia.
A potential problem with this asset-backing of a cryptocurrency is one party, such as the first bank 40, the second bank 50, and/or a third bank 60, having access to an amount of cryptocurrency greater than their stock of assets.
In order to avoid this, the method described herein evaluates publicly available data to obtain an assessment of each party’s wealth. Each party, or the currency related to each party, is allotted an amount of cryptocurrency commensurate to theirwealth.
In some embodiments, private data is used instead of, or in addition to, public data, in the assessment of a party’s assets.
In some embodiments, the parties communicating with the trust 100 are banks. In other embodiments, these parties may be, for example, companies, governments, regional organisation, individual consumers, or stated.
States, or banks, are able to assess related recipients at the time of a transaction. As an example, the second bank 50 may be allocated an amount of the cryptocurrency at the time when the second company 20 attempts the transaction. The second bank 50 then determines whether to allow the transaction, for example based on the bank account of the second company 20. Since, in some embodiments, the trust 100 allocations cryptocurrency on a high-level, e.g. at a country, or bank, level, the trust 100 does not require intrusive, personal, information on each user of the cryptocurrency. This assessment is made by the country/bank. However, there is still some limitation to the control of the cryptocurrency made from the high-level assessment. This ensures that the cryptocurrency is backed by assets, which prevents, for example, speculation leading to significant swings in the value of the cryptocurrency.
Referring to Figure 11 , there is shown an exemplary transaction between the first company 10 and the second company 20.
In a first step 1 12, prior to the transaction, the first bank 40, which here is the bank of a first nation, is allocated an amount of the cryptocurrency that it may hold. Here, the first bank 40 is allocated 1000 of the cryptocurrency.
In a second step 1 14, the first trust 100 issues an amount, here 100, of the cryptocurrency to the first company 10. This may occur via the first bank 40. In some embodiments, there is a required relationship between the first bank 40 and the first company 10, for example, the first company 10 may be required to be located within the jurisdiction of the first bank 40 (in the case where the first bank 40 is that of a nation). The first company 10 may be required to operate in the same currency as the first bank 40 and/or to hold an account with the first bank 40.
In a third step 1 16 that occurs prior to, along with, or subsequent to, the first company 10 being issued an amount of the cryptocurrency, the second bank 50 is allocated an amount of cryptocurrency commensurate with its assets. In some embodiments, this allocation occurs beforehand: where the second bank 50 is that of a nation, the wealth, or assets, of the nation is preferably evaluated before any transactions are made. If the second bank 50 has not yet been given an allocation, the evaluation, and allocation, occurs at the time of the transaction. The second bank 50 is allocated an amount of the cryptocurrency and the second company 20 is able to hold a portion of this amount.
In a fourth step 118, the first company 10 transfers an amount of the cryptocurrency to the second company 20, where this amount is limited by the amount of cryptocurrency allocated to the second bank 50 by the trust 100 and to the second bank 50 to the second company 20. In this example, the allocation of the second company 20 is the amount of the transaction.
In a fifth step 119, the second company 20 is then able to redeem the cryptocurrency either directly or indirectly, e.g. via the second bank 50, with the trust 100. The second company 20 then receives money, in an appropriate currency, of the value of the cryptocurrency redeemed.
The evaluation of the assets of the second bank 50, which is used to determine a suitable allocation of currency, is useable for future transactions. This evaluation may be updated periodically, or after a number of transactions. In some embodiments, the evaluation takes place before each transaction. ln some embodiments, the value of the cryptocurrency is fixed relative to one or more currencies at the time that it is transferred to the first company 10. This is useful for transactions where the payment currency and the withdrawal currency differ, as may occur when the two companies 10, 20 involved are located in different countries. The cryptocurrency is then useful as an instrument of foreign exchange; while a transaction may take some time to complete, the cryptocurrency ensures that each party to the transaction knows the eventual transaction amount. The cryptocurrency may be fixed in value in relation to both the payment currency and the withdrawal currency to protect either of the companies 10, 20 from currency fluctuations. In this case, one of the companies 10, 20 may be required to compensate the trust 100 for any currency fluctuations.
In some embodiments, the use of the cryptocurrency is limited to the transaction for which it is requested. When the first company 10 requests an amount of the cryptocurrency, it must identify the use for this cryptocurrency. If the use is a transaction, the second company 20 is, optionally, required to agree to the use. This may be recorded using a smart contract. This limitation prevents the cryptocurrency being traded and ensures that each party to the transaction is confident that the transaction will occur as set out in the smart contract.
In some situations, an allocation of cryptocurrency is made for a currency, so that the companies 10, 20 are not allocated an amount of cryptocurrency by the banks 40, 50. Rather, there is a maximum amount of cryptocurrency that can be issued against each currency.
In some situations, a transaction may require the approval of a number of parties, for example the first company 10, the second company 20, and a lawyer.
Referring to Figure 12, there is shown a method of performing a transaction between numerous parties, which is observed by a notary.
Party A, which is the first company 10, agrees a transaction with Party B, which is the second company 20. The first company 10 generates a transaction, signs this transaction, and sends it to the second company 20.
The second company 20, inspects the transaction, signs the transaction, and returns the signature to the first company 10.
The first company 10 inspects the signature before sending the transaction, which has been signed by the first company 10 and the second company 20, to an approver 32. The approver 32 may, for example, be a creditor that can confirm that the first company 10 has the fund to perform the transaction. The approver 32 identifies and signs the transaction before returning the signature to the first company 10. There may be a further notary 34, which receives the contract and each signature from the first party 10, carries out certain checks on the contract, such as uniqueness checks, and returns final approval. The transaction is then completed, and confirmation is broadcast to each party.
This process is recorded in a blockchain. The approvals, and any modifications to the transaction or objections are recorded and can be viewed by suitable parties at a later date. The use of a blockchain, which is preferably stored on a decentralised ledger, gives confidence to each party, as well as any other observers, that the transaction data cannot be modified at a later date.
Referring to Figure 13, an exemplary illustration of a transaction between the first company 10 and the second company 20 is shown.
In a first step, the first company, in this example a sender 10, initiates a relationship with the first bank 40. The first bank 40 is able to carry out certain steps, such as Know Your Customer (KYC) checks and wealth evaluations. The first bank 40 then receives a transfer request from the sender 10. The first bank 40 transfers fiat currency from an account held by the sender 10 to an escrow account of the trust 100. At the time of sending, the fiat currency is converted into the cryptocurrency; this cryptocurrency is assigned to a token that is generated in relation to a smart contract that specifies the transaction. In this embodiment the token is immediately converted into the second currency. The second currency is held by the trust 100 until the completion of the contract. This ensures that the beneficiary does not suffer financial penalties due to currency fluctuations that occur while the transaction amount is held in the escrow account.
The transaction information is recorded in a smart contract. A third party, in this case a regulator 30, is able to review the smart contract. Certain conditions may need to be met before the money is released from the escrow account, for example anti money laundering (AML) checks may be carried out.
Once the required conditions are met, the money is released from the escrow account, converted from the cryptocurrency into a suitable fiat currency, and transferred to the second bank 50. The second bank 50 may then carry out checks, such as KYC checks, before transferring the money to the beneficiary 20.
Each part of the transaction is recorded in a distributed ledger. This enables the regulator 30 to review the transaction post-payment and also any party involved in, or interested in, the transaction to review the transaction, e.g. to review the KYC and AML checks that have been carried out. The cryptocurrency used is, in preferred embodiments, linked to the specific transaction taking place, so that the cryptocurrency cannot be held, and cannot be used for purposes other than that in the smart contract.
In an example, this is implemented by the cryptocurrency being generated upon the agreement of the smart contract or, alternatively, upon receipt of a first currency. The first company 10 and the second company 20 agree on certain terms for a specific transaction, e.g. a price for a service to be performed. Once the smart contract is agreed, an amount of cryptocurrency corresponding to this amount is generated - the appropriate amount being dependent upon the current value of the crypto currency - and assigned to a token. The token is linked to the smart contract and is only useable for the purposes specified in the smart contract. On completion of the contract, e.g. when the terms of the contract are met, the token is transferred to the second bank 50, where it is redeemed and the assigned cryptocurrency is converted into an appropriate fiat currency. Since the token need not be held by a person (all the processes occurring automatically), and since the token is non-transferrable (being useable only for a specific transaction), there is no opportunity for speculation. This decreases volatility, leading to a stable cryptocurrency.
The described process may happen rapidly, so that the cryptocurrency may be generated, transferred, and converted in a matter of seconds, or even a matter of milliseconds. The cryptocurrency is, optionally, converted into the second currency immediately and the second currency is held by the trust 100 until the completion of the contract.
In various embodiments, the settlement of the transactions, the processing of transactions, and the recording of transactions, occur using a combination of various technologies, such as distributed ledger technology (DLT) and/or permissioned DLT where the validating and/or viewing nodes are preferably those parties defined in, or related to, the smart contract. A decentralised ledger may also be used. The validation of transactions, which may involve only validation of a time and/or transaction ID may be universally visible, specific details may only be visible and/or validatable, by relevant parties.
Referring to Figure 14, an exemplary illustration of a delivery transaction between the first company 10 and the second company 20 is shown.
In a first step, the first company, in this example an importer 10, agrees an order with the second company, in this example an exporter 20. The agreement is recorded as a smart contract, which is viewable, and optionally authorised, by the first bank 40.
The exporter 20 then initiates the delivery, where this may involve inspection by an inspection company 37, a first customs organisation 38, and/or a second customs organisation 39. Any actions taken by any party are recorded on the blockchain. Once the importer 10 has received the goods, the receipt is recorded on the blockchain by the final party, here the second customs organisation 39, as well as the importer 10.
The first bank 40 is able to confirm that the goods have arrived and release the payment to the second bank 50.
In some embodiments, the first bank 40 transfers the payment sum in escrow in the currency decided by the first company 10. Once the contract is completed, e.g. once the goods are delivered, the fiat currency held by the first bank 40 is converted into the cryptocurrency and transferred to the second bank 50, where it is converted into the fiat currency desired by the second company 20.
The effective exchange rate between fiat currencies is, in some embodiments, determined at the time of signing the contract so that each party involved has knowledge of the amount of fiat currency being paid and that being eventually received. The amount of the cryptocurrency that is generated at the time of the transfer between the first bank 40 and the second bank 50 depends upon this agreed effective exchange rate. Even if the direct exchange rate between the two currencies has fluctuated during the duration of the deal, the effective exchange rate achieved during the transaction can be that initially agreed. In some embodiments, this minimises losses due to arbitrage, as the cryptocurrency is only generated at the time of transfer.
Alternatives and modifications
Various other modifications will be apparent to those skilled in the art for example, for example, while the majority of the detailed description has considered the described cryptocurrency being converted to and/or from a fiat currency, this cryptocurrency could also be converted to and/or from another cryptocurrency, or other asset.
The detailed description considers the first company 10 and the second company 20 converting a fiat currency into the cryptocurrency. The cryptocurrency could be held only by the first bank 40 and the second bank 50, or any combination of the parties.
The cryptocurrency is not necessarily shown to, or held by, any person within the first company 10 and/or second company 20. The cryptocurrency exchanges may occur entirely on computer devices 1000 that are not used by any person and may remain largely invisible to any user. The user would instead view only the amounts of fiat currency being transferred.
In order to achieve a stable cryptocurrency, there is described a method of relating the supply of cryptocurrency to the assets owned by various parties. Other methods of stability are also useable, such as modifying the supply of a cryptocurrency to control the price, or backing a cryptocurrency with another cryptocurrency. As has been described herein, stability may also be achieved by limiting the time that any party is able to hold the cryptocurrency, or limiting the usability of the currency. Any of these methods of achieving stability are useable in any combination to achieve a desired level of stability.
In some embodiments, the token generated is linked to a specific transaction as specified within the agreement. Once generated the token is not alterable; specifically, the value of the token, the parties to the agreement (notably the first company 10 and the second company 20), and the completion terms cannot be altered. In other embodiments, it is possible to alter one or more features of the token, where certain fields of the token remain unalterable. As an example, the expected completion time of the token may be alterable, to take account of delays in a delivery. Any alteration would require approval from each party to the agreement. In some embodiments, alteration would require approval from the trust 100.
In some embodiments, while information related to transactions is stored on a single chain, the viewable information is limited by permissions. In this way, any party is only able to view details for those transactions relevant to themselves.
It will be understood that the present invention has been described above purely by way of example, and modifications of detail can be made within the scope of the invention.
Reference numerals appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims.

Claims

Claims
1. A computer implemented method of generating a token for use in a transaction, the method comprising:
providing a smart contract;
extracting data from the smart contract; and
initialising said token based on the extracted data thereby to enable the token to be used only in respect of the completion of the smart contract.
2. A method according to Claim 1 , wherein the initialisation step comprises assigning a contract identifier, based on the smart contract, to the token.
3. A method according to Claim 1 or 2, wherein the initialisation step comprises assigning a value, based on the smart contract, to the token, preferably wherein assigning a value comprises relating the token to an amount of cryptocurrency, more preferably, wherein the token comprises a cryptocurrency address.
4. A method according to any preceding claim, wherein the extracted data comprises at least one of: a receiving party; a sending party; an amount of a transaction; a date of a transaction; a currency used by a receiving party; a currency used by a sending party; contractual terms; and a completion time.
5. A method according to any preceding claim, wherein enabling the token to be used only in respect of the completion of said smart contract comprises enabling the token to be used only for a specific transaction, preferably wherein the specific transaction relates to a payment for completion of contractual terms.
6. A method according to any preceding claim, wherein the token is only useable during a predetermined time period, preferably wherein the token is only useable before a predetermined end time and/or wherein the token is only useable after a predetermined start time.
7. A method according to Claim 6, wherein the time period during which the token is useable is dependent upon the expected completion time of the smart contract.
8. A method according to Claims 6 or 7, wherein the token is useable for less than an hour, preferably wherein the token is useable for less than a minute, more preferably wherein the token is useable for less than a second.
9. A method according to any preceding claim, wherein the token specifies an owner, preferably wherein the owner is the only party that may redeem the token, preferably wherein the owner of the token is altered upon completion of a term specified in the smart contract.
10. A method according to Claim 9, wherein the owner of the token is altered after a predetermined time period, preferably wherein the predetermined time period corresponds to the expected completion time of the smart contract.
1 1. A method according to any preceding claim, wherein the token is generated upon receipt of an asset, preferably the asset is specified within the smart contract.
12. A method according to any preceding claim, wherein upon completion of a term within the smart contract the token is transferred from a first party to a second party, preferably wherein the token is converted to a different asset immediately after being transferred from the first party to the second party, preferably wherein this asset is at least one of: a fiat currency; and a cryptocurrency.
13. A method according to any preceding claim, wherein the token is held by a third party until completion of the smart contract.
14. A method according to any of Claims 3 to 13, wherein the value assigned to the token is dependent upon the assets of a party related to the transaction, preferably wherein the assets of the party related to the transaction are determined using publicly available information, more preferably wherein a maximum value that can be assigned is determined based upon the assets of the party related to the transaction.
15. A method according to Claim 14, wherein the party related to the transaction is a state, preferably wherein the state is related to a currency used in the transaction.
16. A method according to any preceding claim, wherein the token is not held for more than an hour by any party, preferably wherein the token is not held for more than a minute by any party, more preferably wherein the token is not held for more than a second by each party.
17. A method according to any preceding claim, wherein the smart contract is deemed to be completed when confirmation is received from a plurality of trusted validators, preferably wherein the trusted validators comprise at least one of: parties to the smart contract; trusted third parties; and parties involved in carrying out the terms of the contract.
18. A method according to any preceding claim, wherein information related to the token and/or the smart contract is stored on an immutable ledger, preferably wherein only parties with certain permissions are able to view the information, preferably wherein only permissioned parties defined in the smart contract are able to view the information.
19. A method according to any preceding claim, wherein upon completion of the smart contract, the token is deleted and/or the data assigned to the token is deleted.
20. A method according to any preceding claim, wherein the token is reassignable to a further smart contract, preferably wherein data related to the smart contract is deleted before any reassignment.
21. A method according to any of Claims 1 to 19, wherein the token is useable for only a single smart contract.
22. A method according to any preceding claim, wherein information related to the token and/or the smart contract is stored on a blockchain.
23. A method according to any preceding claim, wherein information related to at least one of: the smart contract; the token; and the transaction is stored on a distributed ledger and/or a decentralised ledger.
24. A method according to any preceding claims, wherein a plurality of tokens are generated, preferably wherein the plurality of tokens relate to at least on of: a plurality of transactions within the smart contract; and a plurality of parties to the smart contract.
25. A computer-implemented token, the token comprising:
data extracted from a smart contract;
wherein the usability of the token is dependent upon the extracted data such that the token is useable only in respect of the completion of said smart contract.
26. A token according to Claim 25, wherein the token comprises at least one of: a contract identifier based on the smart contract;
an owner identifier related to a party able to redeem the token; and a deadline identifier related to a completion deadline, preferably wherein a/the owner identifier is dependent upon the deadline identifier.
27. A token according to Claim 25 or 26, wherein the token is assigned a value, preferably wherein the token is assigned a value related to an amount of cryptocurrency.
28. A computer implemented token generated according to the method of any of Claims 1 to 24.
29. A method of performing a transaction using a token according to any of Claims 25 to 28.
30. A computer program comprising software code adapted when executed to carry out the method of any of Claims 1 to 24.
31. An apparatus adapted to execute the computer program product of Claim 30.
32. A system substantially as herein described and/or as illustrated with reference to the accompanying drawings.
33. A method substantially as herein described and/or as illustrated with reference to the accompanying drawings.
34. An apparatus substantially as herein described and/or as illustrated with reference to the accompanying drawings.
PCT/GB2018/052779 2018-06-15 2018-09-28 Token generation WO2019239086A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1809888.9 2018-06-15
GB1809888.9A GB2575624A (en) 2018-06-15 2018-06-15 Token generation

Publications (1)

Publication Number Publication Date
WO2019239086A1 true WO2019239086A1 (en) 2019-12-19

Family

ID=63042177

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2018/052779 WO2019239086A1 (en) 2018-06-15 2018-09-28 Token generation

Country Status (2)

Country Link
GB (1) GB2575624A (en)
WO (1) WO2019239086A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2023030028A (en) * 2022-12-15 2023-03-07 直樹 柴田 Block chain system and computer program for preventing crash while suppressing fluctuation in coin value
WO2023075848A1 (en) * 2021-10-27 2023-05-04 Burkhan LLC Systems and methods for monetization of time and activity on a digital ledger

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170048234A1 (en) * 2015-07-14 2017-02-16 Fmr Llc Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems
US20170048209A1 (en) * 2015-07-14 2017-02-16 Fmr Llc Crypto Key Recovery and Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems
US20170048235A1 (en) * 2015-07-14 2017-02-16 Fmr Llc Crypto Captcha and Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems
WO2017145004A1 (en) * 2016-02-23 2017-08-31 nChain Holdings Limited Universal tokenisation system for blockchain-based cryptocurrencies

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170048234A1 (en) * 2015-07-14 2017-02-16 Fmr Llc Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems
US20170048209A1 (en) * 2015-07-14 2017-02-16 Fmr Llc Crypto Key Recovery and Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems
US20170048235A1 (en) * 2015-07-14 2017-02-16 Fmr Llc Crypto Captcha and Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems
WO2017145004A1 (en) * 2016-02-23 2017-08-31 nChain Holdings Limited Universal tokenisation system for blockchain-based cryptocurrencies

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023075848A1 (en) * 2021-10-27 2023-05-04 Burkhan LLC Systems and methods for monetization of time and activity on a digital ledger
JP2023030028A (en) * 2022-12-15 2023-03-07 直樹 柴田 Block chain system and computer program for preventing crash while suppressing fluctuation in coin value
JP7290299B2 (en) 2022-12-15 2023-06-13 直樹 柴田 Blockchain system and computer program that suppresses fluctuations in coin value and prevents crashes

Also Published As

Publication number Publication date
GB2575624A (en) 2020-01-22
GB201809888D0 (en) 2018-08-01

Similar Documents

Publication Publication Date Title
US20190012665A1 (en) Systems and Methods that Utilize Blockchain Digital Certificates for Data Transactions
Natarajan et al. Distributed ledger technology and blockchain
US20220101435A1 (en) Global liquidity and settlement system
US20190228407A1 (en) Digital property management on a distributed transaction consensus network
US20220309505A1 (en) Reissuing obligations to preserve privacy
JP2022547130A (en) Systems and methods for providing a blockchain-based process of record
JP2022103306A (en) Method for splitting blockchain-registered digital asset and autonomous computing agent
JP2021061021A (en) Device, system, and method for facilitating low trust and zero trust value transfer
CA3004263C (en) Virtual currency system
US20170330159A1 (en) Resource allocation and transfer in a distributed network
US20150206106A1 (en) Method for creating, issuing and redeeming payment assured contracts based on mathemematically and objectively verifiable criteria
US20180204190A1 (en) Systems and methods for management of asset or obligation-backed virtual receipts on a distributed system
Brühl Virtual currencies, distributed ledgers and the future of financial services
CN110221919B (en) Virtual resource allocation method and device based on block chain
US20210192520A1 (en) Distributed credit ecosystem
US20210224759A1 (en) Method and System for Implementing a Currency Guaranteed By An Investment Vehicle
CN112561407B (en) Asset management method, system and device based on block chain
WO2019239086A1 (en) Token generation
WO2023201360A2 (en) Method, controller, and computer-readable medium for replacement of a cancelled repeating transfer data structure on a distributed transfer network
WO2021060340A1 (en) Transaction information processing system
US20200027082A1 (en) Virtual currency payment agent device, virtual currency payment agent method, and program recording medium
JP3659491B2 (en) Electronic settlement mediation method, electronic settlement mediation system, and electronic settlement mediation program
JP7054288B1 (en) Program and information processing method
Kumar Escrow transactions and crypto governance
Alirhayim et al. The Ethereum-powered Reputation Platform for Commerce

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18782496

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18782496

Country of ref document: EP

Kind code of ref document: A1