Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
A SYSTEM FOR TRADING IN A CONTRACT-FREE MANNER
Document Type and Number:
WIPO Patent Application WO/2018/060951
Kind Code:
A1
Abstract:
The invention relates to a system for trading, a method of trading using the system, and a device used for trading with the system. The system comprises a network including at least one computing device and network nodes, a digital ledger which establishes the order and state of crypto-currency transactions, crypto-currency market orders and/or crypto-currency market trades, and maintains a record thereof. The digital ledger is connected to the network. The digital ledger is configured to enable a user to transfer data on the network, the data being associated with a crypto-currency, and a value of the crypto-currency correlating to a value of an asset held by an asset holder. The digital ledger is further configured to enable consensus, relating to the data recordable on the digital ledger. A trading platform is generated using the system, which enables the user to transact, store, and/or trade a value of the asset using the digital ledger to change the permission rights of the crypto-currency, such that the trading occurs in a contract-free manner.

Inventors:
OMAR RUZAIQ (ZA)
Application Number:
PCT/IB2017/056018
Publication Date:
April 05, 2018
Filing Date:
September 29, 2017
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
OMAR RUZAIQ (ZA)
KALLA ABDOOL GANI ANVER (ZA)
International Classes:
G06Q20/06
Foreign References:
US20160234026A12016-08-11
US20150324764A12015-11-12
US20150332395A12015-11-19
US20160092988A12016-03-31
US20140164251A12014-06-12
Other References:
FABIAN SCHUH ET AL: "Bitshares 2.0: General Overview", 18 December 2015 (2015-12-18), XP055440532, Retrieved from the Internet [retrieved on 20180112]
FABIAN SCHUH ET AL: "BITSHARES 2.0: FINANCIAL SMART CONTRACT PLATFORM", 12 November 2015 (2015-11-12), XP055440389, Retrieved from the Internet [retrieved on 20180112]
Attorney, Agent or Firm:
EDWARD NATHAN SONNENBERGS INC (ZA)
Download PDF:
Claims:
CLAIMS

1. A system for trading, the system comprising; a network including at least one computing device and network nodes;

a digital ledger which establishes the order and state of crypto-currency transactions, crypto-currency market orders and/or crypto-currency market trades, and maintains a record thereof, the digital ledger being connected to the network;

the digital ledger configured to enable a user to transfer data on the network, the data being associated with a crypto-currency, a value of the crypto-currency correlating to a value of an asset held by an asset holder;

the digital ledger further being configured to enable consensus, relating to the data recordable on the digital ledger;

characterised in that a trading platform is generated enabling the user to transact, store, and/or trade a value of the asset using the digital ledger to change the permission rights of the crypto-currency, such that the transactions and trading occur in a contract-free manner.

2. The system as claimed in claim 1 , further characterised in that no third party clearance or settlement is required when trading using the system.

3. The system as claimed in claims 1 or 2, further characterised in that no other forms of clearance or settlement are required when trading using the system.

4. The system as claimed in any one of claims 1 to 3, characterised in that the system may facilitate atomic exchanges of crypto-currencies between multiple users.

5. The system as claimed in any one of the preceding claims, characterised in that at least one crypto-currency is in the form of a token.

6. The system as claimed in any one of the preceding claims, characterised in that the digital ledger includes a distributed ledger.

7. The system as claimed in claim 6, characterised in that the distributed ledger includes a blockchain architecture including any one or combination of, a blockchain ledger, a decentralized peer-to-peer network, a decentralized consensus finding mechanism, software which is configured to enable the user to connect with components of the blockchain architecture, and a wallet existing in digital form and configured to enable the storage of public and private keys pairs of the crypto- currency, wherein the wallet permits a user to modify the blockchain ledger using the key pairs recorded on the wallet, thereby changing the permission structures of the public and private keys held by the wallet.

8. The system as claimed in claim 7, characterised in that the software is configured to use the blockchain ledger records to display human readable information to the user.

9. The system as claimed in claims 7 or 8, characterised in that the wallet is a component of the software.

10. The system as claimed in any one of claims 7 to 9, characterised in that the software is configured to allow the user to engage the software to perform inputs which result in a transaction on the blockchain architecture.

1 1. The system as claimed in any one of claims 5 to 10, characterised in that the system includes a token generating engine.

12. The system as claimed in claim 1 1 , characterised in that the token generating engine is configured to allow the user to generate a new token and increases and/or decreases the supply of at least one, a portion of, or a plurality of tokens available.

13. The system as claimed in claims 1 1 or 12, characterised in that the token generating engine is a node on the network.

14. The system as claimed in any one of claims 1 1 to 13, characterised in that the token generating engine is the user connected to at least one node on the network.

15. The system as claimed in any one of claims 7 to 14, characterised in that adjustments to the software generate a new token and increase and/or decrease the supply of at least one, a portion of, or a plurality of tokens available.

16. The system as claimed in any one of claims 5 to 15, characterised in that the system is configured to adjust any attribute of a token so as to generate a new token and increase and/or decrease the supply of at least one, a portion of, or a plurality of tokens available.

17. The system as claimed in any one of the preceding claims, characterised in that the wallet is configured to change the permission rights of the crypto-currency by generating a data message on the system, the data message comprising a transaction which is digitally authorised, wherein at least one unspent output of a previous transaction is spent, and wherein a sum of the outputs is not exceeded by a sum of inputs of a previous transaction, the inputs and outputs which result in a transaction on the digital ledger, and wherein the data message is broadcast to at least one network node for validation by the system.

18. The system as claimed in any one of claims 5 to 17, characterised in that the tokens include any one or combination of: a specific supply value which is changeable by the token generating engine, wherein the supply value in units of supply approximates the number of units of the asset held by the asset holder user, and/or the supply value approximates the number of units of the asset that would be similar in value to another asset held by the asset holder; a naming attribute which include a human and/or computer readable attribute which permits the user to associate the token with the asset held by the asset holder; a fungibility value which indicates the number of units a single token unit is broken down into; a suggested market pairing attribute which suggests the token to be exchanged against another appropriate token or another crypto-currency within the blockchain ledger or across blockchain ledgers; description meta data which is a readable attribute permitting the user to obtain information about the token and/or the asset that the token may be associated with; and an expiration wherein the token expires after a designated period of time.

19. The system as claimed in claim 18, characterised in that the description meta data includes a unit value permitting a single token to be associated with one or more units of the asset held by the asset holder.

20. The system as claimed in claims 18 or 19, characterised in that the token self- destroys in full or in part at a specific time upon expiration, or the token self-destroys progressively in parts at times specified.

21. The system as claimed in any one of claims 5 to 20, characterised in that the token includes a whitelisting requirement, wherein the software is configured to allow specific users, with the associated wallets of the users, to transact a specific token, and/or a central authority permits the user to transact a specific token only if the user and the associated wallet is designated as whitelisted or designated as not blacklisted.

22. The system as claimed in any one of claims 1 1 to 21 , characterised in that the token generating engine is configured to reinstate some or all permissions and rights to transact the cryptocurrency back to the token generating engine.

23. The system as claimed in any one of claims 1 1 to 22, characterised in that the token generating engine is configured to transfer all tokens back to the generating wallet or another wallet.

24. The system as claimed in any one of claims 1 1 to 23, characterised in that the token generating engine is configured to freeze the transfer of tokens of one or more user.

25. The system as claimed in any one of claims 1 1 to 24, characterised in that the token generating engine or a network node or a third party authority is prompted to approve any of the token transactions.

26. The system as claimed in any one of claims 1 1 to 25, characterised in that the token generating engine or a network node or a third party authority can prevent any token transactions on the network which cannot be viewed publically when inspecting the digital ledger.

27. The system as claimed in any one of the preceding claims, wherein the asset holder is any entity holding assets where the entity and/or any assets held by the entity are known to at least one user of the system.

28. The system as claimed in any one of claims 5 to 27, characterised in that the asset holder holds assets which correspond in the number of units to the number of token units, wherein the token units have a naming attribute permitting association of the token with the asset.

29. The system as claimed in claim 28, characterised in that the asset holder holds assets which are of similar value to assets the naming attributes of the token which the token is associated with, wherein the asset holder holds an asset x which has a value substantially the same as an asset y, and the asset holder chooses to hold asset x for a token or asset y for a token.

30. The system as claimed in any one of the preceding claims, characterised in that the system uses a token trading engine.

31. The system as claimed in claim 30, characterised in that the token trading engine includes any user conducting token transactions on the system.

32. The system as claimed in claims 30 or 31 , characterised in that the token trading engine is a node on the network.

33. The system as claimed in any one of claims 30 to 32, characterised in that the token generating engine is the token trading engine.

34. The system as claimed in any one of claims 7 to 33, characterised in that the blockchain architecture includes formulas to determine an exchange rate between the tokens or any other crypto-currency being traded.

35. The system as claimed in any one of claims 7 to 34, characterised in that the blockchain architecture is configured to use an external price feed to determine an exchange rate between the tokens or any other crypto-currency being traded.

36. The system as claimed in claims 34 or 35, characterised in that the exchange rate is used to determine thresholds of safety for the user of the system who is engaged in an advanced trade, wherein the system is configured to use the exchange rate information as a trigger to automatically generate transactions.

37. The system as claimed in claim 36, characterised in that the automatically generated transactions are initiated by the blockchain architecture.

38. The system as claimed in any one of claims 5 to 37, characterised in that the blockchain ledger includes at least one pool account which contains at least one or more token type, wherein the pool is funded by at least one user transferring an amount of tokens to the pool account, wherein there is a push transaction to the pool account triggered by the user.

39. The system as claimed in claim 38, characterised in that one or more users can lend, from the at least one pool account, at least one, or a fraction of or a plurality of tokens.

40. The system as claimed in claims 38 or 39, characterised in that the user leverages the value of a token available in the pool account by triggering such a transaction using the software, wherein the pool account includes an amount of the token in a transaction the user is engaged in.

41. The system as claimed in any one of claims 38 to 40, characterised in that the pool account executes the operations of the pool account automatically by using the blockchain architecture, with no central controller or third party being party to its operations.

42. The system as claimed in any one of claims 38 to 41 , characterised in that the pool account executes the operations of the pool account in response to a trigger within the system when certain conditions or parameters are met.

43. The system as claimed in any one of claims 38 to 42, characterised in that the pool account transfers an amount of tokens from a user to the pool account by generating an exchange transaction which causes the user who lent and received tokens from the pool to exit his or her position automatically, wherein there is an automatic pull transaction of tokens from the user to the pool account.

44. The system as claimed in any one of claims 38 to 43, characterised in that tokens lent and received by users from the pool account, return tokens to the pool account by exiting their position manually, wherein there is a manual push transaction from the user to the pool account.

45. The system as claimed in any one of claims 38 to 44, characterised in that tokens funded by users to the pool account are withdrawn by the user from the pool account, wherein there is a pull transaction from the pool account to the user.

46. The system as claimed in any one of claims 5 to 45, characterised in that the blockchain architecture secures and holds tokens provided by a user as collateral during a transaction.

47. The system as claimed in any one of claims 5 to 46, characterised in that the user can exchange at least one, a fraction of or a plurality of tokens or any other crypto- currency for another token or crypto-currency within the same blockchain ledger or in a different blockchain ledger.

48. The system as claimed in any one of the preceding claims, characterised in that the proceeds of a transaction are received by the transacting user or another user of the system.

49. The system as claimed in any one of claims 1 1 to 48, characterised in that the token generating engine or the token trading engine distribute the tokens.

50. A method of trading using the system claimed in any one of claims 1 to 49, the method comprising; accessing a user interface connected to the system;

entitling the user access to the value of the crypto-currency; and

transferring data representing the value of the crypto-currency enabling for transacting, storing and/or trading of a value of the crypto-currency.

51. A device for transacting, storing and/or trading, the device comprising; a user interface, connected to a back-end which includes the system as claimed in any one of claims 1 to 49; first payment means for receiving payment from a user;

receipt issuing means for issuing a receipt to the user;

identification means on the receipt for identifying a value of a crypto-currency obtained by the user which correlates to a value of an asset held by the user; a receipt reader for determining an amount to be paid to the user;

second payment means for paying the user; and

wherein the device is configured to enable a value of the asset to be transacted, stored and/or traded by the user.

52. The device as claimed in claim 51 , characterised in that the crypto-currency obtained by the user is purchased by the user using cash.

53. The device as claimed in claims 51 or 52, characterised in that the crypto-currency obtained by the user is obtained by redeeming a voucher, reward or the like thereof.

54. The device as claimed in any one of claims 51 to 53, characterised in that the device is in the form of a vending machine, wherein the user selects the crypto-currency they wish to obtain and payment is prompted by the machine and made by inserting money into the payment means, and wherein a paper receipt is issued by the vending machine.

55. The device as claimed in any one of claims 51 to 54, characterised in that the paper receipt includes the public and private keys of an account containing the crypto- currency.

56. The device as claimed in any one of claims 51 to 55, characterised in that the vending machine connects to a mobile device of a user using near field communication (NFC), radio frequency identification (RFID), Bluetooth, WiFi or the likes thereof, and wherein the user interface include a mobile or web application (APP) or graphical and/or textual user interface.

57. The device as claimed in any one of claims 51 to 56, characterised in that the receipt is an electronic receipt which includes the public and private keys of an account containing the crypto-currency, wherein the user prompts the device to issue the electronic receipt to a mobile device of the user, or any other mobile device, via the APP, email, or the likes thereof.

58. A method of trading as claimed in claim 50 using the device claimed in any one of claims 51 to 57.

Description:
A system for trading in a contract-free manner

Field of the invention

The invention relates to trading platforms, trading systems and methods of trading. Background to the invention

The creation of the internet has allowed for an improvement in the record and transmission of information and other types of data content. There has been a shift from the written system to a digital system. However, transfer of property and ownership rights have lagged behind and have remained part of legacy systems, wherein things are recorded, whether using a human or computer, by some entity. This is because there was no way of establishing ownership without the use of a trusted third party.

When it comes to stock trading, the need for these centralized ledger keepers or third parties make it impossible to separate the trading service from the entity monetizing or providing the service. Additionally, legacy systems create a need for centralized clearing houses, trusted intermediaries and hosted trading platforms. This means that administratively intensive systems need to be closely regulated as they are easily corruptible due to the substantial involvement of human operators. As a result, the trade of listed shares is difficult or too expensive an exercise to be engaged by an average individual. Charges of approximately 0.62% for EasyEquities™ and minimum fees of approximately $15 per transaction are common. In the case of cross-border share trading the exercise becomes especially unattractive due to the even higher fees, slow and bureaucratic international funds settlement, as well as the many regulatory and legal hurdles involved. The result is illiquid stock markets in relation to the global demand to trade the stock, an inability of global markets to reach fair demand based pricing of stocks, an easily corrupted financial system and an undiscovered global stock trading market. The invention of the Blockchain ledger allows for the efficient reaching of a consensus or distributed consensus, regarding ownership of value and property in a decentralized manner, thus eliminating the need for a centralized authority to enforce ownership status. This allows the establishment of value/property/ownership auditing and trade in a decentralized manner. This decentralization permits trade to occur on a global scale as jurisdictions do not need to co-operate in order to maintain a consensus.

Many systems exist which enable the trade and transfer of assets. The advent of the internet has allowed for the digitalization of assets which can then be traded over the internet where a central authority holds the assets and issues promissory notes by way of contracts. The promissory notes are what are digitally traded or transferred. The central authority is also needed to maintain a consensus on the state of the promissory notes. In other words, to maintain a consensus on which entities the central authority has contractual obligations to and for which assets, the state of transactions and the order book.

Contracts serve to create one or more legal obligations between parties and are enforceable by law. The use of a centralized entity and contractual obligations introduces several issues mainly related to the reliance on the central authority to be trusted by all other parties.

Additionally, because a central authority is providing promissory notes, clearance is needed to facilitate settlement by updating the contractual obligations whenever an exchange of promissory notes occurs between two parties.

Blockchain technology removes the need for a central authority to maintain the consensus on the state of ownership of promissory notes, however it does not remove the issues around the need for contractual obligations and clearance. Blockchain technology is only being used to improve on the efficiency and reduce costs of current trading platforms. There is always a link or written contract tying the digital asset to its real word self, and essentially all platforms are moving toward more and more efficient I.O.U based platforms.

Many other systems exist which accept deposits and issue digital I.O. Us or depository receipts. The digital I.O. Us allow for value to be transmitted more easily. These may be referred to as payment applications (APPs) which use centralized databases. Some examples are PayPal™, national and global banking systems, WeChat™ and AliPay™. It is important to note that these payment APPs require user deposits, and become a trusted 3 rd party and custodian of the user's deposits. On the other hand, this is different to a payment APP such as SnapScan™, which facilitates a payment.

Payment APPs which do not use a centralized database but use the Blockchain ledger, are in existence. Tether is similar to current payment apps, where a user would deposit funds which are then held by Tether™, however the depository receipts are issued on the Blockchain. A token is 'tethered' to an underlying asset or deposited fiat, held in reserve. Each Tether™ token is said to be backed 1 : 1 with its corresponding reserve asset, where Tether™ is a custodian of user deposits. Tether™ tokens are fully redeemable or exchangeable at any time for the underlying fiat currency. The tokens therefore hold their value as a result of a contractual I.O.U promise. For example, a customer can send the tokens to a merchant in exchange for goods and services because the merchant believes that the holding company will hold true to their promise. These systems are permission based where a central authority issues and allows redemption of recipes.

A holding entity receiving an asset held by an asset holder, and issuing a cryptocurrency token with an attribute which allows association with the underlying asset, is known. Tether™ tokens are not valued through market forces determining price by establishing exchange rates between tokens. The Tether™ system does not have a system for exchanging tokens for other tokens within the system. Many centralized systems allow for trade by accepting deposits, for example in US Dollars, and issuing digital I.O. Us and issuing digital contracts, such as share certificates, financial securities, or the likes. They then allow users to trade the digital I.O. Us and digital contracts. After trade, they may facilitate the clearance and settlement of the digital things with the real things. Examples of such systems are stock exchanges and online trading platforms.

There are services in existence which issue the digital contract assets on the Blockchain in the form of tokens with attributes. They then permit the trade of those tokens with I.O.U tokens (e.g. USD) on the Blockchain. In the same way as with the payments APPs, these services will issue fiat depository receipts or I.O. Us on the Blockchain. They also issue 'smart securities' which are financial securities which exist on the Blockchain. They are still a 3 rd party facilitating trade, however, there is a significant reduction in back office administration. The 'smart security' is the asset itself. Symbiont™ has issued the first Smart Securities on the Bitcoin™ Blockchain allowing institutions and investors to issue, manage, trade, clear, settle and transfer a range of financial instruments more efficiently on Blockchain. These are programmable versions of traditional financial securities which are held on the Blockchain.

NASDAQ™ is looking into the use of blockchain technology to reduce administrative processes, speed up clearing and settlement and reduce expenses. Tokens may represent financial contracts and will be traded on a regulated, controlled and centralized Blockchain.

Overstock.com™ is issuing company bonds to private investors over the Blockchain. Digital Asset™ aims to provide a method for settling trade in digital currency and to trade digital and digitalized assets through I.O.U based systems. The focus is on fast settlement and clearing of securities, focused on the use of the blockchain database as a way to increase transparency and reduce costs. DACx crowd funds the purchase of NASDAQ™ and NYSE listed shares. Once enough shares have been crowd funded, DACx will issue depository receipts for the shares on the Blockchain network. DACx uses crowd funding and collects bank deposits which are used to buy listed company shares.

Reference will also be made to relevant prior art in order to better understand the invention.

US20150332395 focuses on the use of cryptocurrencies to improve settlement times, to 'almost instant', in financial markets. This looks similar to 'smart securities' which are called SETL coins. Different institutions or companies can issue SETL coins for their assets. Users can then trade SETL coins with each other and whoever has the SETL coins is entitled to the benefits/enjoyment etc. A token with attributes is used. The attributes being a 'position' and a position in side cryptocurrency (PIC) which is an agreed upon reference used by the peer-to-peer network to refer to, for example a particular security. The position is the quantity of PIC represented by the SETL coin. For example, '20 GOOG SETLcoin' is a single SETL coin representing 20 units of Google™ shares and should have the face value of 20 Google™ shares. A token with attributes is used as a method for improving settlement times. The method of tying the value of the token to some other asset is through issuance by a central authority therefore there is some form of contract. There is a co-ordinator or some component of the system which verifies that a user has sufficient SETL balances to enter into a trade and then proceeds to purchase the asset.

US20160092988 provides a system and method for transferring digital assets amongst a network of distributed users without the need to transfer the assets to an external party, such as an escrow agent. It includes a clearing module and a settlement module, therefore requires clearance and settlement. US20140164251 does not relate to a Blockchain based trading platform. The patent relates to creating digital tokens which can be used for merchant coupons, reward points, air miles and others.

A currently existing exchange, as described above, would typically perform the following functions in order to operate: holding shares and issuing I .O.Us; receiving fiat and issuing I.O.Us; processing an order book; settlement of trades and accounts; redeeming I.O.Us; monitor collateral, enforce margin rules, execute contracts and compliance.

The inventor believes the invention overcomes some of the drawbacks associated with existing trading platforms, systems and methods of trading. The inventor has further identified the need for an improved and more accessible trading platform, system and method of trading.

Summary of the invention

The following definitions may be used to assist in interpreting the specification but not to limit the scope of the invention:

Wallet - a wallet is any form of apparatus which is used to maintain a record of the public and private keys of tokens or any other crypto-currency. A wallet may exist in digital form where it may permit a user to modify the blockchain ledger using the keys recorded on the wallet.

Decentralized - no central authority to enforce a particular action or to maintain a consensus.

Token - unit on a blockchain architecture.

Asset - any form of value, including but not limited to bonds, stocks, gold, futures, options, commodities, coupons. Asset holder - any individual or entity, which may be a legal entity, which may own at least one asset, a fraction thereof or a plurality of assets.

User - a user is any individual or entity that interacts with the system.

Transaction - a transaction is any data message transmitted from a node or from a user connected to a node which causes a modification, update and/or addition to the blockchain ledger or architecture, e.g. a trade order.

Crypto-currency - any unit or token used on the system. A digital or virtual currency that uses cryptography for security.

CCTT drop - the process of distributing a token on the blockchain architecture to a holder of another token on the blockchain architecture.

Distributed ledger - a consensus of replicated, shared, and synchronised digital data, enabling distributed consensus, and including but not limited to a blockchain architecture.

Blockchain architecture - consists of the ledger or database (known as the blockchain ledger), a peer to peer network, a consensus finding mechanism and may include a wallet and other system parameters.

Public and Private keys - these relate to cryptographic systems which make use of keys. The public key refers to a public identifier for a private key. The private key is data which is usually kept private. The private key can be used to digitally sign a transaction and demonstrate that the transaction was signed by the controller of the associated public key. The public key may typically be produced using the private key but not the other way around. According to a first aspect of the invention, there is provided a system for trading, the system comprising; a network including at least one computing device and network nodes;

a digital ledger which establishes the order and state of crypto-currency transactions, crypto-currency market orders and/or crypto-currency market trades, and maintains a record thereof, the digital ledger being connected to the network;

the digital ledger configured to enable a user to transfer data on the network, the data being associated with a crypto-currency, a value of the crypto-currency correlating to a value of an asset held by an asset holder;

the digital ledger further being configured to enable consensus, relating to the data recordable on the digital ledger;

characterised in that a trading platform is generated enabling the user to transact, store, and/or trade a value of the asset using the digital ledger to change the permission rights of the crypto-currency, such that the transactions trading occur in a contract-free manner.

The system further characterised in that no third party clearance or settlement is required when trading using the system.

The system further characterised in that no other forms of clearance, such as bilateral clearance, or settlement are required when trading using the system.

The value of the crypto-currency may become redeemable as an asset.

The value of the crypto-currency may become redeemable as another digital currency.

The user may trade a value of the asset by using a wallet to change the permission rights of the crypto-currency through generating a data message on the system, the data message comprising a transaction which is digitally authorised, wherein at least one unspent output of a previous transaction is spent, and wherein a sum of the outputs is not exceeded by a sum of inputs, and wherein the data message is broadcast to at least one network node for validation by the system.

The system may include atomic exchanges of crypto-currencies between multiple users.

The system may use at least one crypto-currency in the form of a token.

The system may use at least one crypto-currency herein referred to as a Cryptographic, Contract-free, Tracking Token (CCTT).

The digital ledger may include a distributed ledger.

The distributed ledger may establish the order and state of CCTT transactions, CCTT market orders and CCTT market trades and maintain a record thereof.

The distributed ledger may include a blockchain architecture including any one or combination of, a blockchain ledger, a decentralized peer-to-peer network, a decentralized consensus finding mechanism, software which is configured to enable the user to connect with components of the blockchain architecture, and a wallet existing in digital form and configured to enable the storage of public and private keys pairs of the crypto-currency, wherein the wallet permits a user to modify the blockchain ledger using the key pairs recorded on the wallet, thereby changing the permission structures of the public and private keys held by the wallet

The blockchain architecture may use the tokens.

The wallet may be unique for each user.

The software may display human readable information for consumption by the user. The software may be a mobile and/or web application.

The human readable information may include graphs, order book data, market statistics or any other relevant information which the user may wish to consume.

The software may use the blockchain ledger records to display the relevant human readable information to the user.

The software may use data obtained from outside the blockchain architecture to display the relevant human readable information to the user.

The wallet may be a component of the software

The software may permit interaction between the wallet and the software component.

The software may be configured to allow the user to engage the software to perform inputs which result in a transaction on the blockchain architecture.

The inputs may result in an electronic message being transmitted to a network outside of the blockchain architecture.

The user may generate a new CCTT and increase and/or decrease the supply of at least one, a portion of, or a plurality of, CCTT available.

The system may include a token generating engine. The token generating engine may be a CCTT generating engine configured to allow the user to generate a new token and increases and/or decreases the supply of at least one, a portion of, or a plurality of CCTT available.

The CCTT generating engine may be a node on the network. The CCTT generating engine may be a user connected to at least one node on the network.

Adjustments to the software may generate a new CCTT and increase and/or decrease the supply of at least one, a portion of, or a plurality of CCTTs available.

The system may be configured to adjust any attribute of a CCTT so as to generate a new CCTT and increase and/or decrease the supply of at least one, a portion of, or a plurality of CCTTs available. For example, the system may have a single token for USD and a single token for EUR. The amount of USD and EUR within the system may then be manipulated by simply modifying the supply attribute of the token. The supply attribute may be set to any other value.

The system may change the amount of CCTTs held in reserve in order to generate a new CCTT and increase and/or decrease the supply of at least one, a portion of, or a plurality of, CCTT available.

The CCTTs may include any one or any combination of: a specific supply value which may be changed by the CCTT generating engine, wherein the supply value in units of supply may approximate the number of units of an asset held by an asset holder, or the supply value may approximate the number of units of the asset that would be similar in value to another asset held by the asset holder; a naming attribute which may include a human and/or computer readable attribute which permits the user to associate the CCTT with the asset held by the asset holder; a fungibility value which may indicate the number of units a single CCTT unit may be broken down into; a suggested market pairing which attribute may suggest a CCTT to be exchanged against another appropriate CCTT or another crypto-currency within the blockchain ledger or across blockchain ledgers; description meta data which may be a readable attribute permitting the user to obtain information about the CCTT and/or the asset that the CCTT may be associated with;and an expiration wherein the CCTTs may expire after a period of time.

The CCTTs may further include any one or any combination a market fee which may be a fee charged for transacting the CCTT, and voting means which may permit the user to cast votes on items.

The description meta data may include a unit value permitting a single CCTT to be associated with one or more units of the asset held by the asset holder.

The market fee may be a fee charged for transacting the CCTT, wherein the fee may be charged by sending an amount of a transaction volume to a different user or through destroying an amount of the transaction volume.

The market fee may include a minimum and/or maximum fee which may be established as a minimum and maximum number of CCTT units or a portion thereof, to be transferred or destroyed as part of a transaction.

The market fee may be charged by transferring or destroying a CCTT or another crypto- currency other than the one being transacted.

The results of the votes may be influenced by the quantity of CCTTs the user has.

The vote may be type specific, such that certain items may only be voted on by the user if the user controls a specific type of CCTT. The CCTTs may self-destroy in full or in part at a specific time upon expiration, or the CCTTs self-destroy progressively in parts at times specified.

The CCTT may include a whitelisting requirement, wherein the software may be configured to allow specific users, with their associated wallets, to transact a specific CCTT, and a central authority may permit the user to transact a specific CCTT only if the user and the associated wallet is whitelisted. For example, the user may use the software to script such a rule into the blockchain ledger so that the blockchain ledger then carries out the new rules. The user may modify the blockchain ledger to add such rules for specific tokens and how they relate to specific whitelisted or blacklisted users. The user would be limited in their permission to add such rules, for example, the users may only add such rules for tokens they have themselves issued.

The whitelisted wallet may be any wallet that is not designated as blacklisted. The whitelisted wallet may be any wallet that is designated as being whitelisted or not designated as being blacklisted.

The CCTT generating engine may be configured to reinstate some or all permissions and rights to transact the cryptocurrency back to the CCTT generating engine.

The CCTT generating engine may be configured to transfer all CCTTs back to the generating wallet or another wallet.

The CCTT generating engine may be configured to freeze the movement of CCTTs of one or more user.

The CCTT generating engine or a network node or a third party authority may be prompted to approve any of the CCTT transactions. The CCTT generating engine or a network node or a third party authority may prevent any CCTT transactions on the network which cannot be viewed publically by inspecting the ledger.

A plurality of CCTTs with the same attributes may be CCTTs of the same type.

The CCTTs of the same type may be grouped together within the wallet and may be treated as being interchangeable when conducting transactions.

The system may require at least one asset holder.

The asset holder may be any entity holding assets where the entity and/or any assets held by the entity are known to at least one user of the system.

The asset holder may hold assets which may correspond in the number of units to the number of CCTT units, wherein the CCTT units may have a naming attribute permitting association of the CCTT with the asset.

Each different asset held by the holder may be associated with at least one unique CCTT type.

The asset holder may hold assets which are of similar value to assets the naming attributes of the CCT which the token is associated with, wherein the asset holder holds an asset x which has a value substantially the same as an asset y, and the asset holder chooses to hold asset x for a CCTT or asset y for a CCTT. For example, the asset holder may hold US Dollars (USD) 40, which is similar to the value of 1 gram of gold. So for the CCTT 'grams of gold' the asset holder may choose to hold 1 gram of real gold for 1 CCTT on the system, or the user may simply choose to hold USD 40 for 1 CCTT on the system. The asset holder may hold any combination of assets which may be similar in number of units to a number of CCTT units, wherein the CCTTs have a naming attribute permitting association of the CCTT with the asset and assets which may be of similar value to assets the naming attributes of the CCTT which it may be associated with.

The system may use a token trading engine or CCTT trading engine.

The CCTT trading engine may be any user conducting CCTT transactions on the system.

The CCTT trading engine may be a node on the network.

The CCTT generating engine may also be the CCTT trading engine.

The blockchain architecture may include formulas to determine an exchange rate between the CCTT or any other crypto-currency being traded, a method for the system to determine an exchange rate. The blockchain ledger may not be able to determine the current exchange rate from external sources, the blockchain ledger may then use formulas to determine the exchange rate from trade activity that occurs within the system. For example, a threshold of users trade South African Rand (ZAR) 10 for USD 1 , the system then assumes this as the exchange rate.

The blockchain architecture may use an external price feed to determine the exchange rate between the CCTTs or any other crypto-currency being traded.

The exchange rate may be used to determine thresholds of safety for the user of the system who is engaged in an advanced trade, such as a leveraged trade or a short position, wherein the system is configured to use the exchange rate information as a trigger to automatically generate transactions. The automatically generated transactions may be initiated by the blockchain architecture.

The blockchain ledger includes at least one pool account which contains at least one or more CCTT type, a fraction of or plurality of, wherein the pool is funded by at least one user transferring an amount of tokens to the pool account, wherein there is a push transaction to the pool account triggered by the user. The pool account may built in at a blockchain ledger protocol or configured into the core programming, rules, and/or functions of the blockchain ledger.

The pool account may contain one or more CCTT type.

The pool account may be funded by another means of supplying CCTT or any other crypto-currency to the pool such as by modifying the specialized software, or through the CCTT generating engine.

The user may lend from at least one pool account, at least one, or a fraction of or a plurality of CCTTs or any other crypto-currency. This may be a specific type of transaction which is allowed by the blockchain ledger protocol. The transaction will check additional conditions such as the collateral of the user to allow or prevent the transaction from taking place.

The user lending the at least one, or a fraction of or a plurality of CCTTs may be required to return more CCTTs to the pool account than were lent, generating a cost of lending CCTTs from the pool account.

The user may leverages the value of a CCTT available in the pool account by triggering such a transaction using the software, wherein the pool account includes an amount of the CCTT in a transaction the user is engaged in. The user funding the pool may receive an amount of CCTT from the pool account which is greater than or equal to the amount funded to the pool account, generating a reward for lending CCTTs to the pool.

The user may be rewarded for particular activities on the system, wherein the user may receive an amount of CCTT from the pool account or another account, or may have the option of storing or redeeming said CCTT rewarded when desired, alternatively the user may transfer the rewarded CCTT to another user of the system.

The pool account may execute its operations automatically by using the blockchain architecture, with no central controller or third party being party to its operations.

The pool account may execute its operations in response to some trigger within the system when certain conditions or parameters are met, such as a drop or raise in price of a CCTT. The blockchain ledger may calculate an exchange rate which makes certain trade positions high risk. The blockchain ledger may have certain rules which allow for certain triggers, for example the blockchain ledger may calculate a USD to ZAR exchange rate, then execute transactions to cover all positions where a weak ZAR makes the position risky.

The pool account may transfer an amount of CCTTs from a user to the pool account by generating an exchange transaction which causes the user who lent received CCTTs from the pool to exit his or her position automatically, wherein there is an automatic pull transaction of CCTT from the user to the pool account.

Users who lend and receive CCTTs from the pool account may also return CCTTs to the pool account by exiting their position manually, wherein there is a manual push transaction from the user to the pool account.

Users who funded the pool account may withdraw CCTTs from the pool account, wherein there is a pull transaction from the pool account to the user. The blockchain architecture may secure and hold CCTT provided by a user as collateral during a transaction.

Users may exchange at least one, a fraction of or a plurality of CCTTs or any other crypto-currency for at least one, a fraction of or a plurality of CCTTs or any other crypto- currency within the same blockchain ledger.

Users may exchange at least one, a fraction of or a plurality of CCTTs or any other crypto-currency for at least one, a fraction of or a plurality of CCTTs or any other crypto- currency within a different blockchain ledger.

The user may exchange a CCTT or any other crypto-currency for another CCTT or crypto-currency within the same blockchain ledger or in a different blockchain ledger, wherein proceeds of the exchange are received by another user of the system.

A CCTT may be distributed to users who have control of a particular CCTT.

An amount of CCTTs may be distributed to users in proportion to the amount of a particular CCTT a user may have existing control of.

The CCTT generating engine or the CCTT trading engine distribute the CCTTs.

According to a further aspect of the invention, there is provided a method of trading using the system described above, the method comprising; accessing a user interface connected to the system,;

entitling the user access to the value of the crypto-currency; and

transferring data representing the value of the crypto-currency enabling for transacting, storing and/or trading of a value of the crypto-currency. The user interface may include a mobile and/or web application.

According to a further aspect of the invention, there is provided a device for transacting, storing and/or trading, the device comprising; a user interface, connected to a back-end which includes the system as described above;

first payment means for receiving payment from a user;

receipt issuing means for issuing a receipt to the user;

identification means on the receipt for identifying a value of a crypto-currency obtained by the user which correlates to a value of an asset held by the user; a receipt reader for determining an amount to be paid to the user;

second payment means for paying the user; and

wherein the device is configured to enable a value of the asset to be transacted, stored and/or traded by the user.

The crypto-currency obtained by the user may be purchased by the user using cash.

The crypto-currency obtained by the user may be obtained by redeeming a voucher, reward or the like thereof.

The device may be in the form of a vending machine, wherein the user selects the crypto-currency they wish to obtain, payment is prompted by the machine and made by inserting money into the payment means, and wherein a paper receipt is issued by the vending machine.

The paper receipt may include the public and private keys of an account containing the crypto-currency.

The vending machine may connect to a mobile device of a user using near field communication (NFC), radio frequency identification (RFID), Bluetooth, WiFi or the likes thereof, and wherein the user interface may include a mobile or web application (APP) or graphical user interface.

The receipt may be an electronic receipt which includes the public and private keys of an account containing the crypto-currency.

The user may prompt the device to issue the electronic receipt to their mobile device, or any other mobile device, via the APP, email, or the likes thereof.

The user may include a user who paid and/or another individual who holds the issued receipt in their possession.

A method of trading as described above using the device described above.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows a system including blockchain architecture, CCTT generating engine and CCTT trading engine;

Figure 2 shows an asset holder and a blockchain ledger;

Figure 3 shows a simple transfer from a first wallet to a second wallet;

Figure 4 shows an unmatched market order;

Figure 5 shows a matched market order and digital atomic value exchange;

Figure 6 shows a digital cross-chain value exchange;

Figure 7 shows the system including a CCTT pool fund;

Figure 8 shows the system enabling trade on a margin;

Figure 9 shows the system enabling short selling; and

Figure 10 shows the system enable a method of CCTT dropping.

DETAILED DESCRIPTION OF THE INVENTION The invention relates to a system for trading, the system comprising a network, a digital ledger connected to the network, the system being configured to enable a user to transfer data on the network, the data being associated with a crypto-currency, the value of the crypto-currency correlating to a value of an asset held by an asset holder the system further being configured to enable consensus relating to the data recorded on the digital ledger, wherein a trading platform is generated enabling the user to trade a value of the asset, wherein the trading occurs in a contract-free manner, and wherein no third party clearance or settlement is required.

The invention shall be described by way of non-limiting examples as well as by reference to the embodiments shown in Figure 1 to 10. It will be appreciated that the invention is not limited to the embodiments disclosed, but is capable of various rearrangements, combinations, modifications and substitutions without departing from the scope of the invention as set forth.

The invention further relates to a method of trading, the method comprising, accessing a user interface connected to a system as described above, entitling the user access to the value of the crypto-currency, transferring data associated with the crypto-currency enabling for trading of a value of the crypto-currency.

Referring to Figure 1 , a blockchain architecture (100) has a peer-to-peer network (101) of nodes (102 - 105). Some users (102 - 108) form a node (103, 105) while other users are simply connected to at least one node (106 - 108). Each node (102 - 105) attempts to remain connected to at least one other node (102 - 105). The nodes (102 - 105) can be any computing device which maintains a record of a blockchain ledger (109) and communicates with the other nodes (102 - 105) in order to maintain a consensus on the ledger record using a consensus finding mechanism (110) and process transactions (300).

The blockchain ledger (109) refers to a permanent record of time stamped transactions that have taken place. Every node (102 - 105) on the peer-to-peer network stores a full or partial copy of the ledger record. New transactions made by nodes (102 - 105) or by users connected to nodes (106 - 108) are broadcast to the peer to peer network of nodes (102 - 105). The nodes form connections using the internet or another kind of network.

The nodes (102 - 105) reach a consensus, using the consensus finding mechanism, on updated states of the ledger caused by any new transactions which nodes (102 - 105) add to the ledger. The nodes (102 - 105) and users (103, 105 - 108) connected to nodes (102 - 105) run specialized software which enables the node to connect to the network, maintain a record of public and private key pairs, update the ledger, make use of the consensus finding mechanism and enable other features which allow for proper functioning of the blockchain architecture (100).

A token generating engine (105) is a user which is a node on the network or a user simply connected to at least one node (102 - 105) to make new entries into the ledger.

A token trading engine (106) is a user which is a node on the network or a user simply connected to at least one node (102 - 105) to make new entries into the ledger.

Referring to Figure 2, an asset holder (201 - 204) is any entity, which owns at least one asset, a fraction thereof or a plurality of assets (205 - 214). The asset holder does not connect to the peer-to-peer network (101). The asset holder is not a node (102 - 105) on the network nor does it connect to a node (102 - 105).

The asset holder (201 - 204) holds assets (205 - 208) which are similar or greater in number of units to a number of CCTT units (215 - 217), on a blockchain ledger (205), which have a naming attribute allowing association of the CCTT (215 - 217) with the asset (205 - 208). As an example, the asset holder (201 - 202) holds 5 shares of company X (205, 208) which is similar in number of units to the 5 CCTT tokens with the naming attribute X (215). Each different asset (205 - 214) held by the asset holder (201 - 204) is associated with at least one unique CCTT type (215 - 217). A CCTT type (215

- 217) refers to CCTTs with the same attributes.

In an alternative embodiment, the asset holder holds assets (209 - 214) which are similar or of greater value compared to assets the naming attributes of a CCTT are allow for association with. As an example, the asset holder (202) holds government bonds to the value of 1065 units of currency Y (209) which is similar in value to 1067 units of currency Y which is associated with 1067 CCTTs with the naming attribute Y (216). Furthermore, the asset holder can hold any combination of assets (205 - 214) which are similar in value or of greater value compared to assets which the attributes of any number of CCTTs allow association with. It should be noted that the CCTTs on the blockchain ledger are not issued in response to assets held by the asset holder and are not I.O.Us. The CCTTs are not contractually linked or tethered in any way to the assets held by the asset holder and are not redeemable for assets held by the asset holder. The asset holder holds some assets which contain pricing information and the CCTTs on the blockchain ledger assumes any price the market decides on.

Referring to Figure 3, the transfer of CCTT from one wallet, wallet A (301) to another wallet, wallet B (302) is shown. There is a transfer of CCTT from one user to another where different users can own the different wallets (301 - 302). A wallet (301 - 302) is any form of apparatus which is used to maintain a record of the public and private key pairs (303 - 306) of CCTTs. The wallet (301 - 302) can exist in digital form where it permits the user to modify the blockchain ledger using the key pairs (303 - 306) recorded on the wallet. The transfer of CCTTs occurs through the transfer of the right to transfer the rights of the CCTT. Here the rights of the CCTT-ZAR (309 - 310) are being transferred from wallet A (301) to wallet B (302). Wallet A (301) received the CCTT-ZAR (309 - 310) from the outputs of a previous transaction (307 - 308), all CCTTs can in this way be traced back to the CCTT generating engine (105). A transaction (312) thus links a set of unspent outputs (309 - 310) which become the inputs (311) of the new transaction (312), to a new set of unspent outputs (313), held by the recipient wallet B (302), and any change (315) which is returned to wallet A (301), while satisfying the conditions of the transaction (312) and other blockchain rules.

The transaction includes any of the following information:

1 ) an amount of CCTT;

2) who is sending the CCTT by the public key (303) of wallet A (301);

3) who is allowed to receive the rights to the CCTT identified by the public key (305) of wallet B (302), in the case of market orders (400), a recipient does not have to be specified;

4) a signature using wallet A's (301) private key (304);

5) an amount of CCTT, if any, included as a market fee (314); and

6) a transaction name (317) where the name can be used to identify the transaction.

Wallet A (301) must sign the inputs (307 - 308) (which are the unspent outputs of the transaction which provided Wallet A (301) with the CCTTs) with Wallet A's (301) private key (304) which is associated with the Wallet A (301) public key (303) to which the CCTTs were sent. This validates that Wallet A (301) has the authority to transact the CCTTs.

After completion of the transaction and in order for Wallet B (302) to be able to conduct a transaction using the outputs (313) of the above transaction (312), Wallet B (302) must be able to sign the output CCTTs with the private key (306) associated with Wallet B's (302) public key (305) included in the transaction (312) in order to claim the permissions over the CCTTs (313) sent to it. The same applies to Wallet C (316) in the case where a fee (314) is sent to Wallet C (316).

Referring to Figure 4, an order which is not matched and is held on the blockchain until it is cancelled or matched or expires. Wallet A (401) has placed a market order (405) which is a type of a transaction on the blockchain to exchange an amount of the CCTT (404) wallet A (401) has the rights over for an amount of CCTT wallet A (401) does not have the rights over. Once the order transaction (405) is broadcasted the user can no longer trade with the CCTTs used in that trade (405).

The transactional message (405) contains any of the following information:

1 ) an amount of CCTT;

2) who is sending the CCTT (404) by the public key (402) of wallet A (401);

3) a signature using wallet A's private key (403);

4) an amount of CCTT, if any, to be included as a market fee;

5) the other CCTT to be received in exchange for the CCTT to be sent;

6) the exchange rate between the CCTT to be sent and the CCTT to be received; and

7) the transaction name (406) where the name can be used to identify the transaction.

Wallet A (401) must sign the inputs (which are the unspent outputs of the transaction which provided Wallet A (401) with the CCTTs (404)) with Wallet A's private keys (403) which are associated with the Wallet A public key (402) to which the CCTTs (404) were sent. This validates that Wallet A (401) has the authority to transact the CCTTs (404). The order must be matched partially or in full by at least one other order. There is an expiry time limit to the order, in which case the order must be matched within a given time frame. In alternative embodiments, there is no expiry time limit to the order.

There would need to be two transactions occurring for a matched trade to then occur. The transactions occur separately and independently. The blockchain system then matches orders and makes changes to the ledger as a result of a matched order. The user only authorises for something to happen to their tokens and does not interact with any other party. The user only gives permission for certain things to happen their own wallet and the blockchain then acts on that. Only the owner of the tokens can transact with the tokens and the owner can only transact with their own tokens. Exchanges of value have atomicity, no transaction is ever in a partial, incomplete or reaches an invalid state. Nor can an exchange complete one part of the exchange without fulfilling the other part.

Figure 5 shows a digital atomic value exchange (500). This is very useful when the cryptocurrency has the value of real world assets as we have the benefits of cryptocurrency with the benefits of real world assets.

Atomic exchange (507) of at least one CCTT/cryptocurrency with at least one other CCTT/cryptocurrency in a matched order. An atomic exchange (507) consists of one or more market orders (400). In this drawing an aggregation of orders is demonstrated (where for example a single BID (506) is matched by multiple ASKS (504 - 505)). The atomic exchange (507) follows an all-or-nothing rule where the complete exchange either occurs in its entirety or does not occur at all, thus there are no intermediary stages in an atomic exchange (507) and all components of the exchange occur simultaneously. Therefore there is no settlement, as settlement implies delay and there is no delay. It should be clarified that although exchanges occur in their entirety and not in stages, orders can be matched in parts, where the exchange of each part will occur as an atomic exchange as can be observed with wallet B's (502) order transaction (505) and matched order exchange (507).

The network fee (508) and market fee (509) have been fixed to 0.1 of a CCTT for simplicity. Users pay network fees (508) on what they spend and market fees (509) on what they receive. Orders (504 - 506) are matched firstly by the cheapest exchange rate and secondly in the order they were made. Here wallet A (501), wallet B (502) and wallet C (503) have placed market orders (504 - 506) as shown. Wallet A, B and C (501 - 503) are then engaged a single atomic exchange (507) as the blockchain protocol matches the orders (504 - 506). In this case wallet A (501) made its order first, then wallet B (502), then wallet C (503). In this example all orders were made at the same exchange rate between CCTT-ZAR and CCTT-SSL at a rate of 1 : 1 . Wallet A (501) is looking to exchange 1 CCTT-SSL it has rights over for 1 CCTT-ZAR

(504) .

Wallet B (502) is looking to exchange 3CCTT-SSL it has rights over for 3CCTT-ZAR

(505) .

Wallet C (503) is looking to exchange 3 CCTT-ZAR it has rights over for 3CCTT-SSL

(506) .

An atomic exchange occurs between wallet A, B and C (501 - 503) where wallet A

(501) no longer has rights to 1 CCTT-SSL (-0.1 CCTT-SSL from network fee (508), 0.9CCTT-SSL rights now owned by wallet C (503)) and now has rights to 0.8CCTT-ZAR (0.9 CCTT-ZAR received from wallet C (503) - 0.1 CCTT-ZAR destroyed as market fee (509) or sent to fee collecting wallet).

Wallet B (502) no longer has rights to 2.1 of its CCTT-SSL and now has rights to 1.9CCTT-ZAR (-0.1 CCTT-SSL from network fee (508), 2 CCTT-SSL now owned by wallet C (503) and 2 CCTT-ZAR received from wallet C (503) - 0.1 CCTT-ZAR destroyed as market fee (509) or sent to fee collecting wallet).

Wallet C (503) no longer has rights to 3CCTT-ZAR (-0.1 CCTT-ZAR as network fee (508), 0.9 CCTT-ZAR now owned by wallet A (501), 2CCTT-ZAR now owned by wallet B

(502) ). And now has rights to 2.8CCTT-SSL (0.9CCTT-SSL received from wallet A (501) and 2CCTT-SSL received from wallet B (502) - 0.1 CCTT-SSL destroyed as market fee (509) or sent to fee collecting wallet).

Implementations of the system allow for automatic algorithm based cross-chain-value- exchange transactions, where at least two parties exchange cryptocurrencies and/or CCTTs which reside on separate blockchain ledgers. No third party is required to facilitate the exchange or transmit funds, exchanges are conducted peer to peer. Algorithms can be integrated into the wallet software or integrated into the blockchain protocol itself. Referring to Figure 6, digital cross-chain value exchange (600) or atomic cross chain trading permits the exchange of at least two different CCTTs or at least one CCTT and one digital currency on at least two different blockchain ledgers. A user can exchange, buy, sell, swap, trade one, a fraction thereof or a plurality of CCTT or cryptocurrency for one, a fraction thereof or a plurality of another CCTT or cryptocurrency residing on a different blockchain. This is done peer-to-peer and involves only two parties, where no intermediary or third party facilitates the exchange. This exchange is done using a cross-chain exchange protocol, which form part of the blockchain protocol or form part of the specialized wallet software or a combination thereof, where the two transactions on two different blockchains are either both allowed to occur or neither transaction is allowed to occur.

The cross-chain exchange protocol functions in various ways. Figure 6 shows a method of cross-chain exchange which is implemented as part of the trading platform. In alternative embodiments, the method of cross-chain exchange is not implemented as part of the trading platform, and is connected to the trading platform. The method shows an exchange between two parties, both parties have wallets on both blockchain ledgers, ledger A (601) and ledger B (602). The method makes use of a secret number (603) and a hashing algorithm which produces a one way hash of the secret number. A hashing algorithm is used to produce a 'digital fingerprint' or 'hash' of some digital data. It is able to produce the hash of some digital data that can be used to show another party that you are in possession of that data, without revealing the data itself.

In Figure 6, 10CCTT-ZAR are being exchanged for 1 Bitcoin. Each user has their own wallet. In this example illustrated, the end result of the exchange is that Alice's wallet A

(604) transfers the 10CCTT-ZAR from her wallet (604) on ledger A (601) to Bob's wallet

(605) on ledger A (601). Bob transfers 1 Bitcoin from Bob's wallet (606) on ledger B (602) to Alice's wallet (607) on ledger B (602).

Step 1 : Alice creates a secret number (603) and then creates a hash of that number. Step 2: Alice creates a transaction [TX: 1 ] (608) sending 10CCTT-ZAR from Alice's wallet (604) on ledger A (601) to Bob's wallet (605) on Ledger A (601) under conditions (612) that Bob signs [TX:1 ] (608) and the secret number (603) is made public, or Bob and Alice both sign the [TX: 1 ] (608).

Step 3: Alice creates a second transaction [TX:2] (609) sending the 10CCTT-ZAR from [TX:1 ] (608) to herself after a time period (n). Alice signs the transaction and Bob signs the transaction. This step is used to provide a refund fail-safe should the exchange not complete.

Step 4: Alice broadcasts [TX: 1 ] (608) to the peer-to-peer network.

Step 5: Bob creates a transaction [TX:3] (610). He is sending 1 Bitcoin from Bob's wallet (606) on ledger B (602) to Alice's wallet (607) on Ledger B (602) under conditions that Alice signs [TX:3] (610) and the secret number (603) is made public OR Alice and Bob both sign the [TX:3] (610).

Step 6: Bob creates a second transaction [TX:4] (611) sending the 1 Bitcoin from [TX:3] (610) to himself at a time period (n). Bob signs the transaction and Alice signs the transaction. This step is used to provide a refund fail-safe should the exchange not complete.

Step 7: Bob submits (612) [TX:3] (610) to the peer-to-peer network.

Step 8: Alice executes (613) [TX:3] (610) before time (n) runs out, thereby giving up the secret number (603) and making it public.

Step 9: Bob now knows (614) the secret number (603) and can execute [TX: 1 ] (608) before the time expires. Referring to Figure 7, a CCTT pool (700) to provide loans/credit for use in advanced trades shown in Figure 8 and 9.

In an embodiment of the invention, the system and method allows for advanced trading such as leveraged trading and short selling. In order to assist such features the platform allows for at least one CCTT pool (707). The pool (707) exists on the blockchain ledger and its operations are executed automatically by the blockchain protocol with no central actor being party to its operations. A CCTT pool (707) contains at least one CCTT type (CCTTs with the same attributes) and at least one, or a fraction thereof or a plurality of CCTTs of the same type. The CCTT pool (707) is funded by at least one user (701 - 702) sending a CCTT to the fund, a push transaction (710 - 711) from the user (701 - 702) to the pool (707).

The pool (707) stores CCTTs. The user (703) lends at least one, or a fraction thereof or a plurality of CCTTs from the pool (707) in order to engage in advanced trades. A push transaction (713) from the pool (707) to the user (703) where it is required that the user (703) send a request to the pool to lend the CCTTs. In alternative embodiments, the request is automatic. The request is formed as a result of the user (703) creating a transaction. The pool (707) can transfer an amount of CCTTs from a user (704) back to the pool (707) by creating an exchange transaction which causes the lending user (704) to exit her position, a pull transaction (708) from the pool (707) to the user (704). Users (706) who lend CCTTs from the pool (707) can also return CCTTs to the pool (707) by exiting their position manually, which is a push transaction (709) from the user (706) to the pool (707). Users (701 - 702, 705) who funded the pool (707) can withdraw CCTTs from the pool (707), which is a pull transaction (712, 714) from the user (702, 705) to the pool (707).

Referring to Figure 8, the system and method enable trade on a margin (800). The user (801) generates an margin order (802), with given parameters, which makes use of leverage. The order initiates an automatic pool (803) operation (815) to lend an amount of CCTT (804) to the user (801). The lending of CCTTs (809) from the pool (803) by a user (801) is conducted by the pool (803) including an amount of CCTTs (804) as part of a transaction (805) a user (801) can be engaged in. This is a push transaction (713) from the pool (803) to the user (801). In some embodiments, such a transaction (805) can only take place where the pool (803) contains sufficient CCTTs (809) to fund its portion of the transaction (805).

In alternative embodiments, the transaction (805) takes place even if the pool (803) does not contain sufficient CCTTs to fund its portion of the transaction (805).

The CCTT margin (807) provided by the user (801) and the CCTT (804) lent from the pool (803) would normally be of the same type (for example CCTT-ZAR).

The CCTT-ZAR (804) lent from the pool (803) and the CCTT-ZAR margin (807) provided by the user (801) are used in an transaction (805) to purchase an amount of another CCTT (808) or cryptocurrency (e.g. CCTT-SSL) in an atomic exchange (805). The CCTT-SSL (808) purchased in the exchange (805), then the outputs of the transaction (819), is held by the user's wallet (806) with restricted rights where the user (801) can only spend the outputs for the purposes of exiting the leveraged position.

The blockchain architecture of the system is able to secure and hold CCTT as collateral and cover positions. This enables more advanced trading such as leveraged and short positions to be taken by users. For the implementation of advanced trading, such as leveraged and short positions, the blockchain architecture includes as part of its system parameters, algorithms/formulas to determine the exchange rate between the CCTTs being traded, or it uses an external price feed to determine the exchange rate. By way of example, if a user is making a leveraged trade and the margin in relation to the current price of the CCTT being traded falls in value below a certain threshold, the blockchain architecture automatically sells the CCTT to cover the position. If a user is making a short trade and the price of the CCTT being shorted rises in relation to the collateral, above a certain threshold, the blockchain architecture automatically uses the collateral to buy back the shorted asset. Figure 8 shows a margin trade exit position with no margin call. In the event that the exchange rate between the CCTT-SSL (808) being bought against the CCTT-ZAR (804, 807) being sold does not move beyond a threshold of safety, the user (801) exits the position manually, a push transaction (709) from the user (801) to the pool (803). The threshold of safety is an exchange rate determined by an algorithm or formula of the blockchain protocol, or in alternative embodiments through the use of external price feeds. The user will spend the outputs (819) (i.e. CCTT-SSL (819)) from the leveraged trade transaction (805) in a new transaction (810) where the outputs (819) are exchanged for CCTT-ZAR (811) in an atomic exchange (810). An amount of CCTT-ZAR

(812) , which is equal to at least the amount lent from the pool (803), is returned to the pool (803) as part of the transaction (810). Any remaining CCTT-ZAR (817) is sent to the user (801).

In the event that the exchange rate between the CCTT-SSL (808) being bought against the CCTT-ZAR (804, 807) being sold moves beyond a threshold of safety the blockchain protocol can automatically cover the user's (801) position thereby returning the lent funds (804) to the pool (803) and the remainder of the funds (818), if any, to the user (801), a pull transaction (708) from the pool (803) to the user (801). Here the pool (803) detects (816) an exchange rate beyond a threshold of safety and generates an order to exchange the CCTT-SSL (819) held by the user (801) in an atomic exchange

(813) for CCTT-ZAR (814). An amount of CCTT-ZAR (812), which is equal to at least the amount lent from the pool (803), can be returned to the pool (803) as part of the transaction (813). Any remaining CCTT-ZAR (818) will be sent to the user (801). The user (801) can voluntarily add CCTT of the same type as was bought (i.e. CCTT-SSL) to the position in order to maintain a threshold of safety and prevent automatic covering.

Referring to Figure 9, the user (901) generates a short sell order (902), with given parameters, which requires the user (901) to lend CCTTs from the pool (903). A requirement for a valid short order is that sufficient collateral (904) is made available by the user (901). The collateral (904) is provided by the user (901) relinquishing the rights to an amount of CCTT, held by the user's wallet (906), in the form of a collateral operation (905). The collateral is then held by the user's wallet (906) with restricted rights wherein the user can only spend the outputs for the purposes of covering the short position. The CCTT provided by the user (901) as collateral (904) and the CCTT

(907) lent from the pool (903) is of a different type. In this example, the CCTT being lent from the pool is CCTT-SSL (907) and the CCTT used for collateral is CCTT-ZAR (904). The market order (902) made by the user (901) initiates an automatic pool operation

(908) to lend an amount of CCTT (909) to the user (901). The lending of CCTTs (907) from the pool (903) by a user (901) is conducted by the pool (903) including an amount of CCTTs (909) as part of a transaction (902) a user (901) is engaged in, a push transaction (713) from the pool (903) to the user (901). In embodiments of this invention, such a transaction (902) only takes place where the pool (903) contains sufficient CCTTs to fund its portion of the transaction (902). In alternative embodiments, the transaction takes place even if the pool does not contain sufficient CCTTs to fund its portion of the transaction.

The CCTT-SSL lent from the pool (909) are used in a transaction (902) to purchase an amount of another CCTT or cryptocurrency (910) in an atomic exchange (902). The CCTT used as collateral (904) and the CCTT being purchased (910) are of the same type. In alternative embodiments the CCTT used as collateral and the CCTT being purchased are of a different type. The CCTT-ZAR (910) purchased in the exchange (902), now the outputs of the transaction (911), is then held by the user's wallet (906) with restricted rights where the user can only spend the outputs for the purposes of covering the short position.

In the event that the exchange rate between the CCTT-SSL (909) being sold against the CCTT-ZAR (910) being bought does not move beyond a threshold of safety (an exchange rate determined by an algorithm or formula of the blockchain protocol or through the use of external price feeds), the user (901) covers the position manually. In the case where the CCTT used as collateral and the CCTT being bought is of a different type, the exchange rate between the collateral CCTT and the CCTT being sold would also factor into the threshold of safety. The user (901) spends the outputs (911) from the short sell transaction (902) in a new transaction (912) where the outputs (911) are exchanged for CCTT-SSL (913) in an atomic exchange (912). An amount of CCTT-SSL (914), which is equal to at least the amount lent from the pool (903), is returned to the pool (903) as part of the transaction (912), upon completion of which the position is said to be covered. Once covered any remaining outputs (921) of the first transaction (902) are sent to the user (901). The user's (901) rights to their collateral (904) are also returned to the user's wallet (906) by the blockchain protocol.

In the event that the exchange rate between the CCTT-SSL (909) being sold against the CCTT-ZAR (910) being bought moves beyond a threshold of safety the blockchain protocol automatically covers the user's (901) position, thereby returning the lent funds to the pool (903), a pull transaction (708) from the pool (903) to the user (901). In the case where the CCTT used as collateral and the CCTT being bought is of a different type, the exchange rate between the collateral CCTT and the CCTT being sold would also factor into the threshold of safety. Here the pool (903) detects (922) an exchange rate beyond a threshold of safety and generates an order (923) to exchange the CCTT- ZAR (911) held by the user (901) (the outputs (911) from the first transaction (902)) and, if necessary, CCTT-ZAR held by the user (901) as collateral (904), in an atomic exchange (915) for CCTT-SSL (917). An amount of CCTT-SSL (918), which is equal to at least the amount lent from the pool (903), is returned to the pool (903) as part of the transaction (915), upon completion of which the position is said to be covered. Once covered, any remaining collateral (919) is returned to the user's wallet (906) by the blockchain protocol.

The user (901) voluntarily adds CCTT to her collateral amount (904) in order to maintain sufficient collateral and prevent automatic covering.

Referring to Figure 10, implementations of the system enable a method of distributing CCTTs to users who have rights to a particular CCTT, herein after referred to as CCTT- dropping. Any user, including the CCTT generating engine and the CCTT trading engine, can distribute CCTTs in this manner, here the user distributing CCTTs in this manner is represented by wallet A (1001). In embodiments of the present invention, an amount of CCTTs (1002) is distributed via a transaction (1012) to users (1003 - 1006) in proportion to the amount of a particular CCTT (1008 - 1011) a user already has rights to. In Figure 10, wallet A (1001) is distributing 100 CCTT-ZAR (1002) to all users who have rights to CCTT-GLD (1003 - 1006) in proportion to their percentage rights ownership of the CCTT-GLD (1008 - 1011).

The invention enables a user to trade and transact the economic value of an asset in a contract free manner, in the absence of any third party facilitator, without the requirement for clearance or settlement and while maintaining a separation from ownership and economic rights to the asset.

Financial securities, such as listed company shares are held by an asset holder and associated tokens are generated on a blockchain by a token generating engine. Due to the blockchain, it is now possible for there to be a separation between the trader of the tokens, the holder of the shares and the system executing and recording trades.

Tokens generated in the system are connected to the underlying share merely by association and not by a contract or promise. There is a separation between the shareholder and the trading system which permits for increased freedom in trade.

Users decide if they believe the tokens will always have an underlying asset to be associated with. In this way; incentives, market feedback, voluntary user actions, fear and greed, rationality mutual understanding and market forces determine the pricing of the tokens in a free and independent market.

The tokens are called Cryptographic, Contract-free, Tracking Tokens (CCTTs). CCTTs have various attributes and metadata associated with them. Some of these attributes are naming attributes, which are used to identify a particular CCTT or a CCTT type, for example CCTT-ZAR. Users use the various attributes of the CCTTs in order to price them. The naming attribute of the CCTT and its supply value allow for the user to price the CCTT using knowledge of the pricing of the assets held by the holder. The naming attribute and supply value in this way provides a suggested basis for pricing of the CCTT by the user.

The system enables users to price the CCTTs by establishing markets for the CCTTs through creating market order transactions to exchange the CCTTs for other CCTTs or cryptocurrencies at various exchange rates determined by the users.

An example of the system and method in use is, a first company purchases listed company shares. A second company, a software company that does blockchain development, generates CCTTs on the blockchain which it associates with the shares by adding a naming attribute to the CCTTs. Users of the network can then trade the CCTTs against other CCTTs or cryptocurrencies. CCTTs are priced by users such that the face value of a single CCTT unit will assume a price similar to the face value of a single share unit held by the first company. The CCTTs generated do not represent an obligation nor the right for owners of the CCTTs to claim shares. Users who trade the CCTTs are therefore not trading company shares nor lOUs for shares. Users are only trading tokens which represent the economic value of the associated company shares. Users are trading tokens, the value of which is highly correlated to the value of the company shares. In alternative embodiments, users are trading token which do not represent the economic value of the associated company shares.

The CCTTs are not related to the underlying shares save for the name the CCTTs carry and through market forces which incentivise the first company to remain solvent for the CCTTs generated by the second company and/or offer to buy the CCTTs at the market price of its corresponding share. The first company holds the shares and consequently the property and economic rights. There is therefore a separation between the holder of the rights to the asset and by way of incentives, the holder of the value of the asset. No form of financial contract is created and the asset holder functions as a free market participant in 'real world' and blockchain markets, where it buys and sells shares and buys and sells CCTTs. In the preferred embodiment of the invention, the first and second company have no control over CCTT transactions as they are not traded on a centralized server or network operated by an entity or operator. Consequently, the companies do not have any users and only leverage users who have freely joined a permissionless open network. The first and second company do not accept any deposits or make any payments to users. All its assets are its own and it does not act as a custodian of, and does not receive, is not responsible for, assets belonging to users. This enables the CCTTs to be traded within a free market without any regulation and control needed and allows for the economic value of the listed company shares to be traded globally and in an unrestricted manner.

The system makes no promises and creates no contractual obligations nor are any contractual obligations made by any party to any other party. There is no third party actor facilitating transactions and no third party actor is acting on behalf of any user. There is no obligation of any party to enforce the margin or cover any position and no entity is able to enforce the margin. Additionally, no party is held legally liable to perform any action and no performance is legally enforceable, there is no intent to create a legal relationship between any two parties and all parties act in a voluntary manner. Furthermore, CCTTs do not involve any agreement of any kind between any two parties. All modifications to the ledger are signed and executed by a single party only and does not require the signature of more than one party. In alternative embodiments of the invention where third parties are introduced, signature of more than one party is required.

The market prices the CCTTs differently to the real world market price, due to factors such as perceived risk, foreign demand for the share, liquidity and others. The CCTT price will approximately track the price of the associated asset because the only information point for market participants to price the CCTT is the fact that it is associated with a specific asset which has been priced. The result is that the only rational action is to assume that the CCTT will typically track the price of the asset it is associated with, as there is no information indicating that the price of the CCTT would correlate with the price of anything else.

As market liquidity around the token increases, the more accurately the price of the CCTT will track the price of the associated asset. Therefore, if someone attempts to drive the price of a CCTT above the associated price, holders of CCTT of the same type will use this as an opportunity to sell their CCTT at a premium until the market CCTT price is restored. Alternatively, someone could attempt to drive the price of a CCTT below the associated price, users could jump on the opportunity to arbitrate and buy that CCTT type at a discount until the market CCTT price is once again restored.

A user will act in a manner that he expects other users to act in. It is disadvantageous and an expensive exercise to deviate from trading activity that does not confirm the expected behaviour.

The system enables for trade of the value of real world tangible assets securely and privately in a peer-to-peer manner on a blockchain ledger without the need of a third party to act as a trusted agent. The system operates without the need of a third party for the purposes of clearing and settling trades, enforcing trade agreements between parties, acting as an escrow agent, maintaining the order books, hosting platform or conducting credit checks.

The system functions without a market operator or any intermediary actor facilitating transactions or any centralized authority enforcing actions or any middle-man bringing together multiple third parties for the purposes of conducting transactions. No entity is required to hold, or be party to, any funds or CCTT owned by the user.

The system operates without the need for any party to accept and hold any funds belonging to its users. This is because the personal funds of the user do not enter the system. The user can only obtain CCTTs on the system by receiving them as gift or as part of an exchange that is outside of the system.

All CCTTs on the system have their ownerships rights held through the use of public and private key pairs, and whoever knows the key pairs has the rights to the CCTTs held by those key pairs and no one else. The result is that users are always solvent for the trades they are engaged in. No user can enter into an order to buy an CCTT if they do not have rights to the required CCTT to purchase the CCTT. No user of the system can sell a CCTT they do not have the rights over. This has implications for prevention of a user not being able to fulfil their end of a transaction and prevents naked short selling.

High frequency trading (HFT) makes use of computer location in proximity to a centralized exchange as a part of its mechanism and would not be possible using the system described here. This is because a transaction needs to be updated onto the ledger and confirmed by at least one node on the network before a transaction is considered to be validated by the network and by consequence, the system itself. Where only one node is required to validate a transaction, the node validating the transaction can be at any location in the world and the node changes from time to time. This makes very difficult for a user to position themselves in a proximity that is closer than other users for multiple transactions.

Where more than one node is required to validate a transaction, the nodes can be located at different parts of the world and can change from time to time, making it difficult for a user to be in closer proximity to more than one node than other users for multiple transactions.

The system will also make flash orders impossible. Flash orders are a type of trade conducted in centralized exchanges where an order is first presented to a priority group of users who then choose to fill that order, before the order is presented to the remainder of the users. In this embodiment of the invention described, in order for a transaction to be confirmed, it would need to be updated on the public ledger. Once a transaction is updated on the ledger it is viewable to all users and observers who can then choose to fill the order

The system does not create new value but simply allows users to transfer value between each other and from one form to another. No user is therefore in debt to the system. The exchanges are atomic and results in an environment where no user can default on a transaction. Excluding any trading and networking fees, any profit gained by a party is matched by losses of another party.

In the preferred embodiment of the invention, the blockchain architecture is permissionless. Any user can modify the database or the ledger. Any user can use the blockchain architecture to create CCTTs and increase and decrease the supply thereof. Any user can join and modify the blockchain ledger database without requiring the permission from any other entity or user. Any user can also be the trading engine or a CCTT generating engine.

A central authority could regulate the trade of CCTTs or in the preferred embodiment, CCTTs are traded without any control or regulation by a centralized entity.

Any CCTT or cryptocurrency on the system is tradable against any other CCTT or cryptocurrency. The trade between specific pairs of CCTTs can be restricted.

The barriers for entry for a user are reduced by the system and method, to only the most fundamental requirements for an international trading platform, that being a computing device with a connection to the internet and funds to trade. It will significantly reduce costs of trading while providing a better, user friendly service.

In an embodiment of the invention, a device can be used to download an APP on which a user can register an account on the blockchain allowing the user to trade CCTTs in a location independent manner by accessing the trading platform or system via their mobile device, as well as enabling them to manage their account. The present invention allows for the possibility of a user to open and fund an account and exchange value without needing to provide personal or private information.

In an embodiment of the invention, a device in the form of a vending machine is provided and a user can buy the value of financial securities through purchasing CCTTs using cash, such as spare change. A physical receipt wallet can be produced providing the user with access to the public and private keys required to exercise the rights to the CCTTs they purchased. A user can then sell their CCTTs by scanning the receipt they receive and collecting their earnings. These vending machines can be connected to a user's mobile device using Near Field Communication (NFC), Wi-Fi or the likes thereof, wherein a user downloads an APP and registers as a user with an account. This APP also enables a user to trade remotely by accessing the trading platform or system via their mobile device, as well as enabling them to manage their account.

At the same time, or alternatively, the user can connect to the vending machine when in close enough proximity to it, in order to receive an electronic receipt for coins which have been inserted into the vending machine to buy CCTTs. They are able to redeem physical money for the electronic receipt, or redeem money by direct transfer into an account, such as a bank account, amongst other redemption methods and means.

Users can trade the value of assets as speculators in the financial market. A location independent trading platform with reduced fees is generated. Investors can purchase the value and characteristics of annuities, bonds, unit trusts, and the like. Users can store their value in the form of CCTTs in their virtual wallet. The wallet can act as a savings account with no monthly fees. Users can send value to another user using simple transfers, fund the CCTT pool to receive an interest on their value, and use it as a form of low risk investment account.