Request Network project update (December 8th, 2017) — Financial flows management, Colossus release date, roadmap update
The Request protocol aims to formalize financial flows on the blockchain by setting the standard for payments, invoicing, accounting, and auditing in cryptocurrencies, so that crypto-enthusiasts can invoice, get paid, and get their salary in crypto.
You can learn more on our website and on our blog.
What we were up to in the last two weeks:
- Designing and integrating the different financial flows within Request
- JS Library design and development
- MVP Colossus development
- Burning contract and Core refinement
Release of Request Colossus
First of all, we’re more than happy to announce that Request Colossus is about to be ready anytime now. We will release the first version of Request working with Ethereum on testnet within the next two weeks, before the next project update.
Financial flows management — Request types
In our last project update, we showed the state diagram of a Request Core and explained that the model we’re building is not only for invoices, but for every financial flow — a salary, a loan, an expense, a bonus, a donation.
Request Core is the same for each type of request. What changes is the format of the metadata and extensions that will meet the accounting and tax purposes. The Request Foundation will develop and support several schemes, however, these formats are open and anyone is welcome to create and maintain them.
Here is how Request Core works for each request type and what it looks like:
We already described the standard request in the last project update. So let’s begin with the invoice request.
The invoice request
In the invoice request, we integrate all the mandatory information needed for an invoice (details about the seller and the buyer, a unique reference number, the invoice date, information on goods sent or services delivered, tax details, currency, total amount charged, payment terms). The information will then be stored as metadata for accounting and tax purposes.
Case 1: The payee (the seller) creates the request and sends it to the buyer.
The payer (the buyer) declines the request or validates and pays it. He can do multiple payments until the amount of the request is totally paid.
At any time, the seller can give a ‘discount’ or a ‘credit note’ in case an already paid request has to be cancelled for some reason. He then issues a refund. If the request is not paid yet, the seller can cancel it. If he/she wants to pay more, the buyer can include an additional amount such as a ‘tip’.
Case 2: The payer (the buyer) creates the request. No validation is required by the seller.
The same functionalities apply as above.
The salary request
About the salary, we need to keep a record of the employee’s and employer’s identity, the basic salary, the additions (overtime, bonuses), the deductions (taxes and social charges), the net salary, the salary period, the payment date and payment mode.
The payer (the employer) creates the request. No validation is required by the payee (the employee). The employer can then add an additional amount such as a bonus.
The loan request
The loan request represents an advantage comparing to how a loan is managed today. Today, several payments are done with no connections between them. Here, we only need one request to be linked to all the financial flows of a loan (the principal, the principal repayments, and interest).
The payee (the lender) creates a request with the amount of the loan interest. The payer (the borrower) declines or accepts it. Then the lender issues a refund to the borrower corresponding to the loan principal.
Then the borrower has to pay both the interest and the principal repayments of the loan.
This works for the most common loan types (fixed-rate loans). For variable rates, an extension will be needed.
The crowdfunding request
Request gives an easy way to start a crowdfunding (or an ICO) in a standard, easy, and secure way and we expect several projects to connect with the protocol.
Even if a crowdfunding request is very similar to a standard request, we will create a specific support for these ones as they can sometimes be paid by thousands of people. It will impact the metadata and the display.
Examples of advanced payment conditions that can be developed for a crowdsale:
-Whitelist of payers’ address
-Max amount
-Soft cap or reimbursement
-Does not allow payments after a specific date or before one
-Send a specific amount of tokens when a payment is received
-Individual cap
Roadmap Update
We updated and refined our roadmap below (in green is what we do sooner, in red is what we shift to 2018).
What will be done sooner than expected:
-Deploy the website to create/visualize and interact with requests => Q4 2017 instead of Q1 2018
-Add request management of accounting concepts such as refunds, credit notes, and purchase orders => Q4 2017 instead of Q1 2018
(we’ll release more technical papers on this topic soon)
Also, in order to provide a fully decentralized system, we will release a JS library instead of a centralized API. The library will be released soon and will let everyone develop on top of Request.
What we shift to 2018:
-Proof of Concept: Request Core working with a Bitcoin Oracle => we’ll do it in Q1 2018 at the same time as Request Core working with ERC20 tokens.
Partnerships
ING support
We will remove the ING Ventures logo from our website. After a discussion with their legal department, they asked us to communicate that they solely backed Moneytis but were not involved with Request since they can’t be associated with a project that did an ICO.
Vesting Contract: Bug bounty program
Security is our top priority at the moment. We have been committed to it and will continue to be.
We are pleased to announce that our code for the vesting contract has been audited by Clement Lesaege, CTO at Kleros. Now that the audit has been completed, we are launching a bug bounty program. The bounty concerns only the smart contract of the ERC20Vesting.
The code is available here (commit: fb6dafc).
Critical vulnerabilities will be awarded with up to $10,000, while major bugs will be awarded with up to $5,000 in REQ tokens.
The rules of our bug bounty program are the same that applied to the Ethereum protocol and you can find more details on the rules on our previous post.
The bug bounty program starts now, and we encourage you to report the bugs as an issue on the Github repository. You can also email security@request.network. Anonymous submissions are welcome as well.
Community
Congrats! The social media community of the Request Protocol is growing. Twitter’s followers are more than 8,000 now and Reddit’s followers are more than 5,000! Thank you.
The number of token holders has also increased by 15% with 13,845 REQ holders over the last two weeks.
Also we have 2,000 people on our new Telegram channel and we invite you to join here.
That’s it for this bi-weekly. The next bi-weekly will be published on the 22nd of December. In the meantime, see you soon for the Request Colossus Testnet launch!
Stay tuned with the latest news by subscribing to our blog, Reddit, Telegram, and Twitter.
