RTrade Technologies Ltd mega-development update! In this blog post you will find information on our token (RTC), TEMPORAL, and our new hiring process!
RTCoin
Details for the infrastructure of our token, RTCoin (RTC) have been finalized! We are pleased to deem RTC an mmPOS (merge-mined Proof of Stake) as it allows token minting via the staking of RTC in a smart contract, and through mining with the Ethereum mainnet. All token minting is handled entirely through smart contracts, without any reliance on RTrade. Following sections will detail all the intricacies of our token.
If you are looking for a much more technical breakdown, including gas usage, testing, and more instead of a summary click here
Supply Distribution click for more information
- Initial/Total Supply: 61.6Million
- Max Supply: uncapped
- POS Coin Generation: 10%
- Merged Mining Coin Generation: Theoretical max of 3.15% (see later section for explanation of why it is a theoretical max)
| Allocation Categories | Allocation Percentage |
|---|---|
| Advisors/Partnership Incentives | 5% |
| Founders/Early Contributors | 10% |
| Company | 15% |
| Community Purchase | 70% |
Proof Of Stake click here for contract code
The staking system features per-block coin generation, allowing the user to mint coins every single block directly to their Ethereum address. After a period of 2103840 blocks, and after 31557600 seconds have passed, the initial stake can be withdrawn to the users wallet. Withdrawing the initial stake does not prevent people from minting coins that have not yet been minted. Once the total amount of coins for a given stake has been minted, no additional coins can be minted.
Coin minting doesn't have to be done every block, you can do it as often (so long as a block has passed since the last minting transaction). You technically don't even have to mint more than once! To do this, you would simply trigger a minting transaction after 2103840 blocks have passed since your first mint.
In order to prevent malicious transactions disabling the staking system, preventing users from minting their tokens, the only way to change the staking contract which the RTC contract uses, is for there to be no active on-going stakes. In the event that people are actively staking, new stakes will be disabled on the smart contract. After that, all current stakes must expire.
Merged Mining click here for contract code
The merged mining contract is an experimental smart contract, allowing anyone who mines a block on the Ethereum mainnet to receive freshly minted RTC tokens, with the provided limitation that block information (block number, and coinbase) have been submitted to the smart contract. The act of submitting block information is incentivized, awarding the submitter 0.5RTC. The block miner who redeems the reward, is awarded 0.3RTC. Both rewards are redeemed the moment block information is submitted, and the moment block rewards are claimed.
The current system has a theoretical max supply increase of 3.15%, if all block information and all rewards are claimed in a year. We call this a theoretical max increase, as it is unlikely all blocks will have their information submitted, and also unlikely that all submitted blocks will have their rewards claimed.
The merged mining contract setup is less restrictive, and can be swapped out at any moment for a new merged mining contract, due to its experimental nature. Future iterations will avoid the incentivized block information submission, and instead, use merkle proofs and block header validations which ultimately will be much more efficient process in terms of gas usage, and performance.
Audits
Before deployment of the contracts to production (Ethereum mainnet) a fully contract audit will be performed. We are currently in discussions with auditors to find the right fit for us.
TEMPORAL click here for code repository
TEMPORAL development has been continuing at a brisk pace, and there have been numerous advancements since our last developer update. This includes additional features, contract writing, objective refinement, and hiring processes!
Core Code Base Updates
We are pleased to announce that the feature set for the first release of TEMPORAL has been frozen! This means that no new features are going out before our first release, and instead bringing existing futures up to scratch in terms of performance, bug fixing, ease of use, and more. The first release of TEMPORAL will provide support for the public IPFS network, as well as any private IPFS network for which you give us the connection details, or for which you create through our infrastructure and we host it for you!
The latest feature to have been included is email notifications, combined with logging. The combination of these two features allows us to extremely reduce the amount of user involvement, and efficiency of interaction with TEMPORAL.
What does all this technical jibberish mean? Well, it means that users can perform "hit and run" actions with TEMPORAL, where you give us the data you want inserted and leave it at that! So long as the calls to our API complete and you don't disconnect your internet before they can complete, our backend will intelligently handle all technical processes needed to inject your content into the system. Any failures that previously would've ground everything to a halt, will trigger an email to the configured email address for your account, and to RTrade as well.
By doing this, we can more diligently handle failures, and the user will be informed of any failures that occur. This means that if you trigger an API action and receive no failure email then you have the satisfaction of knowing your API call completed successfully. Any actions which don't result in immediate user consumable data (such as uploading a file to IPFS, which first requires the file to be injected into IPFS before a content hash is known) will result in the appropriate information being emailed to your account, and inserted into the database.
Along with these updates, our testing efforts have been started, rolling out tests for TEMPORAL features! You'll notice that recently released features also have their tests! This is incredibly important as it allows for a more speedy and efficient design process, allowing us to notice bugs faster! This is something that will be increased as time goes on, adding in tests sooner rather than later.
Smart Contracts click here for all TEMPORAL contracts
The smart contracts used to facilitate payments is nearly complete! We have two types of payments that can be made with TEMPORAL:
Per Action Payments only require the user submitting payment transactions whenever they store data into the system, and only apply when using the frontend web interface, or frontend API routes. Whenever an action is requested using these API calls, our backend generations a signed message providing you with the signature parts, and necessary information for the smart contract to validate the signed message and payment. When using the web interface which requires a web3 provider, typically through metamask, you don't witnessany of this technical jumbo, and instead it is handled all automatically. Once the transaction has been processed, our backend will pick it up (or you can trigger our backend to start the data ingestion). This process is entirely hands off, except for when using the frontend API routes directly.
The payment channel method is still in development, however just like payment channels, it allows the user to commit RTC or ETH to a smart contract. Each time the user interacts with the frontend web interface, or frontend API routes you will generate a signed message, giving this to us. We will validate the data, and confirm that the smart contract transaction will succeed. We used the total balance of the payment channel to determine whether or not the user has enough funds. If the user has enough funds, then they may proceed with the data ingestion. This is intended for frequent TEMPORAL users, and will allow a virtually seamless interaction with TEMPORAL, meaning that you don't have to wait for payment transactions to be processed. You simply give us the signature data and proceed with your API interaction as usual. Although this imposes some delay, nowhere near the minutes sometimes hours to process transaction, it allows for applications to be built quite easily with TEMPORAL.
What if you don't want to deal with any of those delays? EASY! Simply send us a message and we can set up special access for your account implementation an easy to use payment solution that is the right fit for your application.
As with the RTC contracts, all payment contracts will be audited before deployment to the Ethereum mainnet
Releases
Our first beta release for TEMPORAL is slated for August 2018. The beta release will include full IPFS integration, and give users a chance to interact, and store data on the real IPFS public network, and any configured private networks, while also allowing IPNS usage. The payment processing will be an opt-in feature, and use smart contracts deployed onto the Rinkeby testnet; you will be given all required testnet RTC and ETH. While we try to keep data uploaded during the beta phase on TEMPORAL after the beta is completed, this isn't a guarantee.
Once the beta is released, work on the next feature set for TEMPORAL will begin, which is STORJ integration. Initially it was going to be SWARM, however SWARM isn't quite ready yet, and there is a huge likelihood that there will be breaking changes before SWARM is fully implemented. As such, SWARM integration has no real user base, and RTrade has evaluated this to mean that development efforts are better spent elsewhere, on feature that will lead to real uses, such as STORJ.
Depending on how long STORJ integration takes to complete, if SWARM is ready to be utilized it will be implemented, however if SWARM isn't quite ready SIA will be the next feature set.
Decentralized Mobile Justice (official name TBD)
With our eyes on the future, and never ceasing to explore opportunities, RTrade has settled on a new project to pursue towards the completion of TEMPORAL, which for now is being deemed Decentralized Mobile Justice, or DMJ for short (name TBD). DMJ can be considered a spin-off/upgrade to ACLU's Mobile Justice. DMJ will leverage TEMPORAL's extreme distributed storage ability to solve issues with centralized data storage present with Mobile Justice, and it's centralized spin-offs, while also leveraging livepeer for distributed video streaming and video relay. Smart contracts will be utilized to facilitate typical application features such as user profile, data listing, reputation, and more.
RTrade Hiring click here for opportunities
RTrade is hiring! Following is a brief summary of the positions we are hiring for!
- Software Engineering Backend:
- Golang (desirable, will be required)
- Python (desirable)
- Unix/Linux Systems Administration skills (desirable)
- Familiarity with go-ethereum
- Familiarity with Blockchains (desirable, will be required to gain some familiarity within your time with us)
- Software Engineer Frontend
- JavaScript (required)
- HTML/CSS (required)
- Experience with web3js (desirable/required to learn)
- NodeJS (desirable/required to learn)
- Redux, React, Vue (1 of these, or other popular framework)
*DevOps and/or Systems Administrator with some or all of the following skillset:
- Containers:
- LXC/LXD
- Kubernetes
- Docker
- System Orchestration/Config Management:
- Ansible
- Puppet
- Salt
- Chef
- Misc:
- Terraform
- Consul/Vault (Hashicorp open source version)
- BASH Scripting expertise is a must
- Linux/Unix Systems Administration Skills is a must
- Mobile Application Developer (Android + iOS)
- Hardware Engineers
- Project Management
- Product & Design
- Marketing / PR
- Business Management
- Graphics/Web Design
- Community support