Træde White Paper
Digitised Assets and Decentralized Trading System
Cryptocurrency and digital asset adoption has been held back by their instability. Ordinary people will not use these systems as a common method of exchange if their purchasing power fluctuates wildly. Stability is one of the most important missing characteristics for this area of blockchain technology. Blockchains and smart contracts allow transfers of digital tokens representing virtual currencies securely and verifiably but digital tokens can also be a proof of ownership of real items, commodities or any digitisable asset.
We define a digitised asset as a token that can represent something else, such as another object either physical or virtual and is freely interchangeable with other individual goods or assets of the same type. Digital assets are therefore fungible in that any one digital asset is the same as any other of the same type and holds the same value or represents the same physical object. Digital assets can be used to exchange both real and virtual property and simplify many trade or exchange processes since interchangeability assumes everyone values all items of that type the same. Since the digital assets can be ownership proofs of physical goods a system is needed to verify the goods existence and legally enforce ownership rights in any particular jurisdiction, we refer to such a system as OVA (Origin, Vault, Audit) and for each asset class a transparent, verifiable OVA system is to be put in place.
However, for individual token transactions on many popular blockchains there are high fees, slow transactions and a certain amount of “bloat” that comes from the wide range of use cases being implemented on the blockchain. To enable efficient trading or transfer of assets there is a need to be able to scale the underlying blockchain technology to tens of thousands and more transactions per second. This can be achieved by a combination of technologies including sidechains, state channels, regional partitioning of a blockchain (sharding) and other methods but still coupled to an asset “issuing” main blockchain (mainchain) described below.
Explanatory notes and definitions
Before we can discuss what we are developing and proposing we need some definitions and explanations for those who are unfamiliar with “technical” terminology. They are presented below in relatively straightforward terms.
A sidechain is defined as a separate blockchain coupled to another by a custom protocol or set of rules and generally used to offload computations or transactions from the other “mainchain”. Sidechains can follow different sets of rules from the mainchain, which means they can be enhanced for applications that require extremely high speeds or heavy computing, while still relying on the mainchain for security and authority. The protocol or rule structure can be wide-ranging but often mainly permits the transfer of token ownership.
Sending blockchain transactions requires fees and running smart-contract code is expensive compared to other kinds of computing. State channels is an extension of the “payment channel” concept and make blockchains more efficient by having repeated common transactions off the mainchain.
Imagine a contract that acts like an automatic traffic pass or bridge Etoll electronic tag, you pay money into the tag system (usually $100) which automatically deducts an amount every time you pass an automatic sensor going over a bridge or a tollway. Once the amount is below a threshold an automatic withdrawal from your bank account tops up the payment account. The series of small transactions going back and forth over the bridge are off the “banks” books, only when more money is required does a “bank” transaction take place.
So the steps are 1. User deposits funds on a blockchain smart contract and it is locked via a multiparty signature so that a set of users must agree with each other to update it. 2. The users then exchange transactions off the blockchain using signed certificate “receipts” which can be cashed but are generally held onto until the receiver wants to “bank” the transactions. Each new receipt "overwrites" previous receipts but includes earlier transactions. 3. Lastly, users submit a “final” receipt back to the blockchain, which closes the payment channel and unlocks the funds into each users account (final account balances).
Except for 1 deposit and 3 updating the final funds, an unlimited number of small transactions are off the main blockchain and are high speed and low cost.
The Lightning Network is a "second layer" payment protocol that operates on top of a blockchain. It uses a peer-to-peer system in a network of bidirectional or two way payment (state) channels for making small payments of digital currencies. Since the Network is made up of bi-directional payment channels between two nodes If at any time either party drops the channel, the channel will close and be settled on the blockchain. It is also possible to relay payments between associated peers so people can transfer funds to others not directly connected to them. Generally, to “pass along” a transaction each peer has to have an amount at least as much as the transaction amount itself.
Plasma is a proposed framework for multiple “lightning network” like sidechains relying on enforcement by smart contracts which is scalable to potentially thousands of transactions per second. These smart contracts are incentivized to continue operation autonomously via network transaction fees, which ultimately relies on the underlying blockchain. This structure essentially uses the mainchain as a “central bank” where currency is created and stored and offloads the bulk of transaction processing to the sidechains. The complexities of enforcing consensus and protecting against fraud and double spending in the anonymous linked sidechains is a difficult problem and has held up implementation.
We propose using sidechains along with sharding and state channels in a way that mitigates these problems and provides the same advantages through permission-based sidechains that use known validators to ensure consensus. Reorganisation or “forking” of the blockchain would not be permitted so high throughput can be achieved with current technology and double spending eliminated. Our goal is to implement this model along with the provision to additionally use the Plasma framework when and if it becomes available.
Tokens on Ethereum start with Ether which is used to pay for running the network. Since the code was there for using this token for contracts and transactions why not enable other people to make similar tokens and use them as well. ERC stands for Ethereum Request for Comment, the standard way to ask for improvements in the system. ERC20 is not a technology, software, or piece of code. It is a technical specification. If a token issued by a user’s “smart contract” implements the specification, it is an ERC20 token and can be used in transactions and other smart contracts. The ERC20 protocol standard contains basic functions that any useful token should implement to enable trading. These include transferring tokens, inquiring the balance of tokens at a certain address, and the total supply of tokens. This can be used to create a token exchange system that allows us to quickly add new asset tokens to our platform the moment they are issued, as long as they follow the ERC20 standard. No matter how many different tokens there are, the same system can support trading between Token A and B, A and C, A and Z, Z and M, etc.
Sharding is a type of data partitioning that separates very large databases into smaller, faster, more easily managed parts called data shards. The word shard means a small part of a whole. A blockchain shard can be a partition of data for example by year or dividing all addresses starting with 0x00 into one shard, all addresses starting with 0x01 into another shard etc. Similar to a database partitioning accounts into parts “A to D” then “F to I” etc. It could be regional for example transactions grouped by “Asia” or “Europe”. Each individual blockchain partition is referred to as a blockchain shard. Each shard is held on a separate blockchain instance, to spread the load.
The Origin, Vault, Audit system (OVA) proposed by Træde is similar to the CA (certificate authority) system used by SSL Web certificates. Træde acts as an “Asset Certificate Authority” (ACA) to validate the origin of the assets much like how CA’s now verify web organisations and secure web pages. The OVA certificates are formatted as smart contracts which contain the signatures from the Originator and separate signatures from randomly assigned Vaulter and Auditor entities holding and verifying the asset as well as real time audit proof. Træde ACA will constitute itself with Worlds Best Practice as a verifying authority conducting full due diligence and publishing verification documents on its Træde document blockchain.
Today, your main option to trade tokens is to send them to a centralized exchange or a hosting wallet provider, whom you must trust to secure, not to lose or steal your coins. You can then do all the transactions you like on their books, with their other clients and you never need to touch the issuing blockchain again. But you lose all the benefits of a decentralized value-transfer network.
The Træde platform is developing a Distributed Exchange (DEX) mechanism and open source API for the Træde Wallet (TWallet) holding asset-backed value including support for cryptocurrencies. The TWallet will have the ability to use Træde asset tokens on the decentralized, public Ethereum chain as ERC-20 tokens for maximum liquidity. We believe that this allows for significantly more activity and value in trading, and it will serve as a useful trading avenue for many users of Ethereum. Custom blockchains on the Træde network will hold the general balance of funds per TWallet asset tokens. These blockchains will be able to hold funds across many assets or commodities. However, providing a ledger is not enough for trading and the Træde system allows users to exchange their assets or commodities. To perform exchange, it is necessary to place an order across many different trading pairs in an open market. Træde uses a decentralized orderbook with the trading engine built into the web based or downloadable TWallet, orders are published and matches are performed on known permissioned Validator nodes.
Asset tokens are issued by originators after being validated by Træde ACA and countersigned by the Vaulter and the Auditor. They are “pegged” assets redeemable via the OVA framework for the underlying asset on a one to one basis. See the ova framework further on in this paper.
The Træde network uses its own utility token to pay for the running of the servers, development, code upgrade, maintenance and infrastructure that supports the network. This token is called TRDE. The tokens pay for the system by receiving a share of the fees levied on transactions and trades on the Træde blockchain. Since the underlying transactions and trades are in assets like $, ¥ and € as well as gold and silver or other asset classes holders of TRDE accumulate those same assets and can redeem them from Træde via the OVA framework to pay operating costs and return a profit from their support for the network. Thousands of trades per second between $ to Gold or Gold to Yen or Yen to $ or even just sending $ between account holders in payment for goods or services received on the internet will at even .1% fees soon result in a sizeable store of such assets for TRDE holders. Because we rely on a Proof of stake and known permissioned validators as well as known users there is a “round robin” for validators to earn fees from block rewards and they also earn fees from any transactions they verify as a pool. This provides a steady income stream to compensate for running the network. There is no means for concentration of “miners” as in Proof of work and all Validators, Issuers and holders of TRDE for POS receive fees from the Træde transactions.
Træde foundation will run its own validator nodes to start the network but will admit verified and known others who want to support the system.
Issuers provide liquidity in return for fees from TRDE. An entity that has been validated by the OVA framework can issue assets on the blockchain and will receive TRDE tokens commensurate with the value of the assets posted and their transaction usage as those assets are used in payments, transactions and trades.
For our mainchain and sidechains we use an adapted Linux Foundation system called Hyperledger which is an open source smart-contract permissioned blockchain. Our adaption also provides transaction finality and high transaction throughput with blockchain systems using proof-of-stake on the open source Tendermint or HoneyBadgerBFT consensus engine.
Our Hyperledger adapted blockchain has among other advantages cache optimisation which is intended to allow integration with a SQL layer able to record smart contract events and data into a relational database for analysis and efficiency.
A Sharding and scalability framework with blockchain communication through the TWallet API and exchanges of Merkle audit proofs allows the peer-to-peer network to distribute the load across sidechains and shards.
Træde asset tokens can be customized to enable to following features:
- 1. Træde blockchain has a central mint that can change the number of asset Træde asset tokens in circulation so various national currency tokens ( $ Yen Euro) can be issued once OVA validates the tokens real world asset exists.
- 2. Freezing tokens: if instructed to do so by an authorised regulatory body or in dispute with multiple signatories to a token, tokens can be frozen (not able to be transferred) in a wallet and unfrozen when required.
Træde digitized assets will not adversely affect the underlying Ethereum Mainchain usage and will lower the computational demand on Ethereum mainchain nodes. It will do this by using sidechain network activities and state channels.
The Ethereum and Træde mainchains have mirrored smart contract suites (SCS) and they can issue ERC-20 tokens pegged to Ethereum mainchain tokens like ETH as well as those tokens derived on the Træde sidechain such as GLD (gold), SLV (silver), $ (dollars) and others. Ethereum mainchain users send transactions to one or more smart contract suites (SCS) which “hold” the tokens and operate as a pegged pool of funds. The TWallet transfers a signed “proof of holdings” certificate generated by the Ethereum SCS to a mirrored SCS on the Træde sidechain. The Træde sidechain after validating the signatures for both the Ethereum SCS and the TWallet holder issues ERC-20 tokens pegged to the Ethereum mainchain tokens and reflects the current “held” balance of the users Ethereum mainchain tokens. This allows for any user to supply Ethereum token liquidity to the Træde network which can then be traded in accordance to the Træde sidechain consensus rules “POS”, “Distributed POS”, Tendermint or HoneyBadgerBFT. These pegged tokens can then be used for any liquidity, transaction or trading activity on the Træde sidechain.
No Ethereum token is created or destroyed on the Træde mainchain it is only traded or used in transactions and if an owner wishes to redeem the Ethereum token they send it to the SCS on the Træde mainchain where it originated along with a request to Redeem and a wallet address on the Ethereum mainchain. There they receive a “proof of holdings” certificate from the SCS which the TWallet transfers to the Ethereum Mainchain SCS which validates the signatures and releases the Ether held on the Ethereum mainchain to the user’s mainchain wallet address. It also validates that the new balance of Ethereum tokens on the Træde sidechain has been reduced by the transferred amount. This is an atomic transaction and either succeeds on both chains or fails on both chains via the TWallet confirmations.
Note the terms sidechain and mainchain are relative as both are fully functioning blockchains and which is “main” depends on where the originating token came from. When ETH is transferred Ethereum is the mainchain but when or if GLD or $ are transferred then Træde being the originator is the mainchain. A term like peerchain more accurately reflects the mechanics but we keep the current terminology for ease of use. Our system thus is to peg trading activity in the public Ethereum chain with contract execution input being provided by the Træde chain.
The Træde blockchain network which communicates with each other via the TWallet to allow for trading across virtual token asset classes backed by Ether on the Ethereum mainchain but also real assets verified by the OVA system. Activity on other sidechains or peer chains can connect asynchronously with other chains via certificate proofs delivered by TWallets. The role of the TRDE token is providing computation and enforcement. The token itself acts as utility payment for activity on Træde blockchains. Each Træde blockchain is permissioned and requires known and verified accounts so with validator enforcement we can have a system where consensus rules are optimized for high-throughput transactions. This is similar to full-custodian cryptocurrency wallets such as Coinbase or many centralized exchanges today but the user holds their own keys and tokens in their TWallet. The TRDE token will have value resulting from the known transaction fees derived from the network, with the cost of Validators providing validation to its users and Issuers providing liquidity. This token must have value, to prevent low-cost attacks and is necessary to run the Træde network.
It may be possible to use Plasma once released to allow for delegating validation to third-party plasma chains but the exact mechanism cannot yet be specified until plasma is in alpha or deployed.
The Træde network is designed as a high throughput system and a full proof blockchain without reorganisation is necessary. The system will be able to handle extremely high volumes of transactions and will only do final redemption of ETH over the Ethereum Mainchain. Clearing and settlement of DEX trades occurs over the Træde blockchain and TWallet system. Consensus rules are enforced via this POS Tendermint or HoneyBadgerBFT network. As part of the consensus rules of this network, some Træde validators will also run an Ethereum node to validate ETH in parallel.
Træde Sidechain Mechanism Graphic
The sidechain token transfer mechanism works by way of a hold, peg, issue, redeem sequence. X is an ERC20 token X’ is its “image” on the Træde blockchain, all parameters for both are the same.
Fig 1 Sidechain implementation
We step through the process below :-
- SCS PAIR :- A suite of interoperating smart contracts mirrored on both chains have their own secret public, private key pair.
- HOLD :- When tokens are deposited with the suite a wallet address on the receiving blockchain is also provided and the tokens are held in escrow while an encrypted receipt is produced with the token amount and the receiving address verified by the SCS. The TWallet sends the receipt to the Træde SCS
- ISSUE :- The Træde blockchain SCS verifies the encrypted receipt came from the mirrored SCS. It then “issues” the same amount of image tokens X’ to the Træde blockchain wallet address specified.
- TXNS :- Transactions involving image tokens X’ occur changing ownership, no image tokens created or destroyed anywhere on Træde blockchain.
- TRANSFER :- The owner sends their X’ tokens to the mirrored SCS on Træde blockchain with an address of theirs on the Originating Blockchain. The SCS verifies and produces a redemption receipt.
- REDEEM :- The TWallet transfers that receipt to the SCS on the Originating Blockchain and both SCS perform an atomic transaction where T is released from escrow on the Original blockchain to the address and T’ simultaneously destroyed on the Træde blockchain.
The SCS comprises minimally an Issue contract, Redemption Contract, Hold contract, Validator Contract plus Blockchain Migrate and Shard contracts that are able to communicate with each other about the state of the tokens they have under their control. The Træde network seeks fullnode validation of the public Ethereum blockchain for maximum efficiency and security in trading ETH. The basis of the system is to create contracts on the Ethereum blockchain which locks up and pegs funds dependent upon the condition of the cloned and issued tokens on the Træde chain and vice versa. These funds are now pegged and locked and activity is enforced by the Træde chain. When a redemption order executes, a proof is provided to unlock the funds on the Ethereum or Træde side.
Funds will be settled on Træde and balances updated for continued trading, it is only for final delivery of ETH when the payment occurs on Ethereum other assets are redeemed on their source chains or via OVA for Træde issued asset tokens.
For features such as Ethereum ERC-20 pegging and redemptions we can use signatures based on bilinear pairings, which were added in the Byzantium fork of 2017. For cryptocurrencies, these tokens are non-custodial and instead locked in smart contracts via the SCS.
The blockchain enforces activity on this network using full proof certificates and known Validators. This allows for millisecond clearing and settlement of activity orchestrated on the Træde chain. Reorganisations are not permitted on this network for security and fraud mitigation.
Initial versions of Træde will use aspects of the Tendermint and or HoneyBadgerBFT consensus mechanism.
We believe that there is currently a large market for real stable assets like gold, silver and national currencies using digital blockchain transactions and asset backed tokens and we further present use cases for trading of commodities, currency remittance, payment services and shares.
TWallet and Downloadable Wallet
The wallets enable communication between the Mainchain and Sidechains by acting as the message carrier for a particular wallet owner. Note the smart contracts on either blockchain are the only owners of encrypted signatures used to verify held and issued tokens including Ether. The “hold certificates” and “redeem certificates” signed by the smart contracts are merely transferred via the TWallet user between networks and blockchains.
The Træde platform can also Shard a section of the blockchain that has high volume in order to scale. Thus, if the $ - GLD trading pair was experiencing large volumes it can be split over to another identically structured blockchain but relying on issues and redemption from the original. This allows higher transaction volume while maintaining consistency. The Twallet software identifies which shard to connect to depending on which trading “pair” is being sought by the user.
If more transaction volume is needed peer shards can be maintained that verify with each other and allow even greater scaling .. The wallets can use a number dot protocol to identify the shards similar to the ethernet IP protocol as well as public private keys. We envisage 184.108.40.206 to be the Træde platform and 220.127.116.11 BTC and 18.104.22.168 Ethereum mainnet etc. We would consider an open blockchain committee as a Foundation of interested parties to maintain the lists for everyone’s benefit and avoid duplication or confusion.
The $ - GLD shard might be 22.214.171.124 and its peer shards 126.96.36.199 and 188.8.131.52
A Twallet can split a trade automatically between shards so that a sell order is visible to other Twallets on any Shard transparently.
The platform is developing and aims to use “federations” of blockchains that can connect via shared “blocks” of transactions between blockchains. Transactions between accounts on different blockchains that are the same structure and have the same tokens (say £ in London) and are being used for local payments are bundled, linked to both Blockchains and the block is added to both.
So with this structure transactions in the transaction pool that reference wallet accounts in shards A and B are grouped into one block as is normal but now that block has hash pointers from both previous A and B blocks and the block is appended to both A and B blockchains. Chains C and D don’t need to know about transactions between A and B and so on with all the other blockchains in the federation.
To ensure that blockchains are not malicious or malfunctioning the totals for funds on each blockchain are added and compared with the issuing mainchain every time a block is added to a chain. They must be equal but to ensure there is no potential fraud or double spending “checkpoints” are initiated every 50 blocks where “checkpoint” servers follow all transactions between blockchains back to the last “checkpoint” to confirm no account has behaved fraudulently or tried to spend its funds twice with 2 different blockchains. For 50 blocks we envisage about 1 minute timeframe and so a user wishing to send funds from one of the “federated” London blockchains to say Tokyo would need to wait for a checkpoint (or a maximum 1 minute) for the transaction to complete and be confirmed
The Træde blockchain allows token issuance on the Træde network validated by OVA and pegging such tokens to ERC-20 tokens like Ether or Golem issued on the Ethereum mainchain. This allows for trading any asset class such as gold, silver or national currency and shares. Initial verification handled by the Træde Foundation and audited and verified by known third parties. It can also trade via the Ethereum Plasma system when released. Users will still need to consider the level of “trust” they wish to place in such 3rd party plasma blockchains themselves.
The TWallet connects to required blockchains automatically and can transfer funds to a user’s blockchain address in order to use funds or trade in particular assets with distinct accounts. If a person that a user wishes to transfer assets to has identified an Ethereum account the TWallet can connect to the Ethereum blockchain and make funds available there to transfer to that persons address. Transfer restrictions requiring verification of an owner’s identity from the issuer of the token may be allowed for issued tokens depending upon issuer and vaulting policy. An OVA validator or SCS redemption contract may require Know Your Customer (KYC) or Anti Money Laundering (AML) validation before allowing a redemption. This may be because of local laws or bank regulations for particular assets and regions. This does not apply to tokens which do not flag these restrictions, nor decentralized cryptocurrencies.
Here we show Graphics on crypto trading via sidechains (any chains with ERC20 type Tokens or smart contracts) . Our platform can include coins from other smart contract enabled blockchain platforms, even those with differing consensus methods or blockchain layouts and parameters. Only the coin token is transferred “virtually” to its clone, however to redeem a coin would generally involve returning it to the original blockchain until exchanges were happy to accept cloned coins that they would need to redeem themselves, presumably at a discount as they could then pool coins for a volume redemption.
You could then trade via the DEX the Neo for Ether or $US or Yen or whatever tokens have been transferred across.
If fig XY above the Træde mainnet takes crypto token Neo and Ether as N’ and E’ to enable trading of these and the Ethereum and Neo Mainnets accept clones of $’ ¥’ and €’ which they can now transfer or use in transactions on their network. To redeem the $’ ¥’ and €’ either transfer back to Træde mainnet or settle via a 3rd party like an exchange that accepts $’ ¥’ and €’. Since they can have accounts on the Træde blockchain we feel many exchanges will boost their liquidity by accepting Træde asset tokens as they are redeemable at all times for verified real assets.
A short list of tradable ERC tokens is Neo, Augur, Bancor Network, Civic, Gnosis and Golem. These are perhaps in the top 10 of hundreds of tokens.
To redeem a Træde asset token a user’s TWallet starts a OVA redemption process dependent on each asset type. For national currency it may be as simple as nominating a registered bank account that can accept the currency or for physical gold a registered mailing address (for ounce or less quantities) or secure transfer or delivery via verified 3rd party Logistics operators.
This results in a non-custodial decentralized exchange system where the TWallet may exchange tokens with other TWallet users without trust on a single entity. By pegging Ethereum into a smart contract suite it is possible to clone Ether onto the Træde chain to allow for TWallet token pairs to occur over Ether, creating a liquid market and if crypto trading pairs crosses with ETH, the trading spreads would be much smaller as well as stable. If trading pairs are real assets or national currency then the stability of the system increases to that of a “cash” system and with very low volatility.
TWallet digital asset tokens like GLD (Gold) can be used as a trade crossing with say digital USD (US dollars) however, there would be an incentive to use decentralized tokens for settlement of say GLD due to liquidity or trust advantages related to programmed contracts and anonymity in ETH. By allowing for physical assets to be the backing for TWallet asset tokens, the users can be assured of a known value between TWallet trade activities. Not every payment between two distinct TWallets must be performed using a trade on the decentralized exchange. The users can send tokens to other users of the system at will, perhaps as payment for goods and services or as gifts. Wallets can also hold some reserve balance of tokens for use by micropayments via State channels to or via other Wallets, ready to be used for smaller transfers in frequent small direct transactions. State Channel systems such as Lightning or Raiden Networks allow for payments to occur off the sidechain when TWallets hold balances to facilitate rapid payments. An implementation to allow for such payments across ETH, GLD, or other tokens which can be easily pegged to the Træde chain for TWallet balances can be provided on the Træde sidechain.
Verified Entities using the OVA system issue Gold and Silver assets as tokens and use them on the Træde mainchain or clone them onto the Ethereum mainchain.
A walkthrough of a transfer of Ether to the Træde blockchain and GLD to the Ethereum Blockchain is described below.
- Alice (A) on Ethereum blockchain (BC 1) has 20 ETH and Bobs account has none.
- Alice sends 10 ETH to SCS (BC1) which “hold” them and gives a signed encrypted receipt to Alice’s TWallet which delivers it to SCS (BC2).
- SCS (BC2) issues 10 “cloned” ETH’ to Alice’s wallet address on the Træde blockchain (BC 2)
- Alice uses the DEX functionality available on the Træde blockchain to trade 2 ETH’ for 8 GLD (gold) tokens with Bob.
- Bob sends his 2 ETH’ to the SCS (BC 2) which issues a “release receipt” to Bobs TWallet and burns (destroys) 2 ETH’
- Alice also sends 4 of her gold tokens to a SCS on BC 2 which “holds them and gives Alice a “receipt” that Alice’s TWallet sends to BC 1 which clones and issues 4 GLD’ on the Ethereum chain.
- Now Alice has effectively 4 gold and 10 ether on the Ethereum blockchain and 4 gold and 8 Ether on the Træde blockchain.
- Bob has 2 gold on the Ethereum blockchain and 2 gold still on Træde.
The same process is used for any Asset tokens that need to be transferred to other blockchains.
Trading pools allowing remittance (funds transfer) - Foreign Exchange is possible.
Consider Alice in Europe and Bob in North America, Alice wants to send money to a friend’s bank account in North America but has Euro. Bob in North America wants to send dollars converted to Euro for a holiday he is planning. There may well be thousands of people similar to Alice and Bob wanting to move money for various reasons. They along with Alice and Bob use the Træde platform to put money into their Træde account. It effectively goes into a regional “Pool” of funds. When on the system Alice and Bob “trade” say $1200 for €1000
The money stays in the pools but Alice’s funds in Europe go to Bobs European account and Bobs in North America goes to Alice’s friends nominated bank account there.
These transfers are “local” for banks and therefore inexpensive for users.
Processing of contactless payments of currency or asset tokens using mobile apps and merchant facilities. An app can use the TWallet API to allow a point of sale program on a tablet to receive funds. This can operate from a Mobile phone in QR code mode or “paywave” via software on Tablets and phones.
Here we show a Chi-X type and “over the counter” trading (OTC) of shares via a “nominee” structure or trust. OVA and custodians hold and audit real international shares able to be registered in a new owner’s names.
Our smart contract platform lets people fund projects, companies, and causes or to receive shares from start-up. The system can have smart contracts that release a pooled fund raised by a campaign if it meets its fundraising target by its set date. If not, the smart contract will refund to the supporters the funds they placed into the “escrow” crowdfunding contract. This can be in dollars or yen or any tokenised currency or digitised asset.
The Origin, Vault, Audit system proposed by Træde. They rely on the Public Key Infrastructure type methodology where pairs of keys are used to digitally “sign” an item to “prove” it was authorised by the owner of the keys. Træde Foundation will conduct full due diligence and publishing verification documents on its document blockchain. The Vault operator (i.e. Bank) is also verified by their public / Private signature after verified by the Træde Foundation.
The TWallet (or any wallet provider that uses the API) is able to display the signatures used within any issued tokens and match them to their owners.
The ownership starts with an Originator Entity, a manufacturer or market maker in trade parlance, who provides the physical item to be digitised. But how to minimise the necessary “trust” inherent in buying an item, even fungible ones from someone online. Our proposal is that a system of certificate contracts on a certificate blockchain carry cryptographic signatures of bodies that produce or are original owners of a digitisable asset.
The second entity is the VAULT which for gold would be a physical vaulting provider or for national currencies a bank or financial institution. Again, they are verified by a certificate path and can be vouched for by peers (as for LinkedIn peers). National currencies are freely tradeable and backed by the issuing government so as long as it exists in an account in a bank the originators trustworthiness as an issuer is less required. As long as the vaulting bank is not criminal or negligent (Barclays etc). A Vault entity would sign that they received the asset from the originator and are the current custodian of said asset.
The Audit tab on the displayed certificate links to a Dapp that among other technologies uses Bank API’s with “read only” access accounts nominated by Vault providers and match the funds in the account with totals on blockchain. The audit system is to be as automated as possible, it can be as involved as a 3rd party auditing company or one of several independent auditors who are randomly selected for each audit. Or as automatic as a Xero like audit page that allows a person to verify an account holds a certain amount of national currency among which is yours. Many api’s are currently available that allow 3rd party “read only access” to bank accounts. The “audit software” need only total up all the client account national currency on the blockchain and confirm the total matches a specified bank account amount presumably in a holding “pooled” trust account.
For Gold and Silver physical vaulting cameras that don’t display security relevant features can move between rows of gold or silver and record the numbers and amounts from digital scales as well as having a “ticker total” of holdings. Accurate weight information can be streamed or displayed on a screen within view of the “webcam”. These internet based and automated methods would supplement traditional auditing processes. Audit entities again sign and produce an audit report that is available either on a web page or through the blockchain. We envisage it as being tied to the token itself embedded as a hash in the token metadata. Træde would, for its initial gold offering publish an audit of held gold in both allocated or unallocated pools every 24 hours confirming amounts secured in a vault is equal to amounts of GLD issued and pseudonymously detailing the account holdings.
At the center of the OVA system lie certificate log entries. A certificate log is a blockchain that maintains a record of certificates.
They’re obviously append-only, certificates can only be added to a log; certificates can’t be deleted, modified, or retroactively inserted into a log. Second they’re cryptographically assured with “signatures” of verifiable parties and third they contain a mechanism for continuous auditing via DApp or TWallet software that matches totals on the blockchain with totals in respective “vaults”. Lastly they’re publicly auditable anyone can query a blockchain log entry and verify that an ACA certificate contract has been legitimately appended to the log.
There needs to be enough log nodes so that log node failures, attacks or a nodes temporary outage is not a problem and queries to logs are not bottlenecked. So, more than 100 but much less than 1000 worldwide. A further refinement is that it may be possible and useful for the certificate entries to be registered as a unique type of “transaction” on the main blockchains of the Træde platform.
Each certificate is essentially a OVA record for an issuance of a digital asset. As an example, a market maker releases 1000 Canadian gold maple coins. A verified, ownership, vaulting and audited proof is digitised by a log DApp and signed by the owner, vaulter and auditor into an issued certificate contract (the ACA possibly being the Canadian mint and Træde foundation as a root Authority) those gold coins can now be traded and they are traceable via the OVA system and the certificate log entries in the blockchain. They are also different from other gold maple coins being traded on the system due to the “trust” that is assigned to the issuer. The Canadian mint would have a higher level of trust by the general public than a small coin dealer operating from their shopfront. The coins from both issuers however have independent 3rd party Vault and Audit entities to verify their assets are real and available assigned randomly by the ACA not the issuer.
Note that Any wallet that implements the Træde OVA API can validate an issued ERC20 asset token.
A more interesting and possibly common scenario is an issuer releasing say $100,000 digitised US dollars onto the blockchain. The Issuer is a valid legal company verified by a root ACA and has been assigned a smart contract certificate for US dollars up to a certain amount and issued up to a certain date. They digitise the $100,000 in order to earn TRDE tokens and receive fees from the use of their $100,000 in transactions payments and trade. They “vault” the $100,000 US dollars in a 3rd party ACA nominated Bank account legally assigned with rights of withdrawal to verified owners of the token they are issuing. The bank verifies it has “vaulted” the money in a suitable account and signs the certificate as the “vaulter”. An auditor is put in place that also has read access to the Bank API and can query the banks public facing servers. The Auditor signs the certificate and the digitised asset token is now issued on the blockchain to a nominated account. This allows a wallet with the Træde API to get the certificate information off a token and open an Audit Dapp where the account in question is viewed and its total displayed via the Banks API. The Dapp then totals the value of tokens available on the blockchain, both circulating and on “Hold” and compares the two which should be equal. If a user redeems tokens for an amount of $US then after the OVA redemption process say $100 is transferred from the Audited account to the new holder’s bank account (minus bank fees) and $100 worth of that user’s tokens are simultaneously “burned” and destroyed. The new value of funds both at the “vault” and circulating as tokens is now $999,900 which again matches. The use of 3rd party vaulters and auditors (not chosen by the Issuer) increases the level of “trust” and the history and legal status of the issuer is available on the certificate log blockchain as public information. Anyone has the ability to verify the bank account “vault” of the assets behind Issued tokens. The real time auditability of the holding account via a bank API and associated Dapp allows the system to have a higher level of “trust” than other proposed solutions for trading digitised assets.
Transaction fees are native to the Træde chain. The validators and Issuers earn fees from promoting and validating the activity of the blockchain. Transaction and interchange fees are used to pay for activity on this network, stop spam attacks or high frequency trading and to incentivise honest activity.
Pegging, Issuance, OVA and transactions have a cost, those who provide these services on behalf of others on the network will charge fees which will be well known and transparent. A user will be able to see the fees before initiating a trade or transaction and more than one issuer or validator can set fees for transactions or trades which the wallet can filter for “most trusted”, “most used” or “cheapest”. In this way a free market of transactions between peers on the network is available so that the best price for a service can be obtained.
New TRDE tokens are also minted to holders of TRDE and Validators who have TRDE bonded as POS or Issuers who provide a “market” to the network either in commodities, currencies or equities. All of these activities earn a set amount of TRDE generated along with the fees at a fixed rate dependant on the volume of transactions they are supporting. This provides an incentive to provide network and development infrastructure to support a global network of millions of transactions per minute over a community freely able to trade and transact in any digitizable commodity including national currencies.
There are 3 main organizations or groups involved with the Træde platform.
- 1. The Træde Foundation, a not for profit foundation for the promotion and development of the Træde platform and system as well as the open source OVA framework. This group may launch an ICO for the TRDE token depending on some of the legal opinions presented.
- 2. The Træde GROUP a registered company under the laws of the British Virgin Islands that is charged with initiating many of the core financial use cases outlined in this whitepaper either independently or via partnerships and joint ventures. This includes obtaining appropriate regulatory approval in all jurisdictions where such operations are envisaged. There are joint ventures with companies like Hypertrader, Incub8te and others which will be provisioning the “ready for market” use cases and are ready and able to use the system as stage 1 entrants.
- 3. The Træde ACA Asset Certificate Authority which will be a top-level asset certifying authority as empowered and assisted by the Træde Foundation. It will collect fees for supplying certificates and use them for due diligence and operating expenses in certifying organisations and issuers.
Blockchain systems should have a constitution and a governance system. Bitcoin relies on the Bitcoin Foundation and miners to agree on upgrades, but this is a slow process and sometimes fails ending in a hard fork and 2 “coins”. Because there was no mechanism for making quick decisions or any prior social or real contract in place Ethereum split into Mainstream and Classic after hard-forking to address the infamous DAO attack.
The Træde Foundation has a human readable constitution that details what can be done, by whom, under various conditions of both malicious acts or unintended situations affecting the system and platform with all stakeholder’s interests represented. It also has a “coded” constitution that governs the technical blockchain functions.
Technically Validators, Issuers and stakeholders on the Træde system can vote on proposals that can change pre-set parameters of the system automatically (such as TRDE usage limits for running the network), coordinate upgrades, as well as vote on proposed amendments to the human-readable constitution that govern the policies of the Træde Foundation and thus the blockchain. The human language constitution of the Træde Foundation allows for consistency among the stakeholders on issues such as legalities, improvements, theft, bugs and other operational matters allowing for quicker and cleaner resolution. Each sidechain attached to the Træde mainchain can also have their own constitution and governance mechanism as a subset of the Træde general one. The Træde constitution and code enforces no roll-backs, except for bugs of the Træde mainchain but a sidechain or shard might have a different roll-back mechanism approved when it was set up that complements the Træde system.
The Træde network is an open network and can be inspected and verified publicly without an account, but it is necessary to be permissioned both to avoid the “wait” times for trading issued tokens on the blockchain and for AML and KYC enforcement due to the nature of holding physical assets and national currencies in regional jurisdictions. This however also mitigates against the use of fraud or stolen tokens since users will need to have an account, can be identified and would be subject to normal due legal process. We are currently optimizing for performance and speed but Træde is a pseudonymous network natively with AML KYC constructions for tokens issued on physical assets.
Implementation of the Træde blockchain, Twallet and infrastructure is ultimately the responsibility of the Træde Foundation team, the advisors not part of the Træde team only provide technical guidelines for the architecture.
Træde provides an opportunity for national currency tokens to interchange across a decentralized network, along with cross compatibility with cryptocurrencies, shares and commodity assets.
To build this decentralized trading network requires not just a blockchain suited for payments and trading of issued tokens, but also a decentralized exchange which supports trading activities.
Twallet includes user-owned keys and allows selection of different blockchains depending on a user’s intended use and financial requirements.
Thanks go to Abhishek Satpathy and Kris Crnomarkovic for technical assistance, editing and proofreading.
- “Enabling Blockchain Innovations with Pegged Sidechains”, by Adam Back
- “Lightning Network”
- “The Honey Badger of BFT Protocols” by Andrew Miller University of Illinois
- “Hyperledger Architecture”