Request Network Project Update (November 10th, 2017) — first visuals Request Colossus, Q&A session
The Request Network team is committed to create a financial platform with the potential to become the standard for invoices, accounting, auditing, and payments in cryptocurrencies and fiat assets. You can learn more on our website and on our blog.
Over the last two weeks, we were focused on the development of Request Colossus, the first version of our product, and were creating relationships with potential business partners. Those two points are our priority for the weeks to come.
The first visuals of Request Colossus
As announced in the last project update, we are ahead of the roadmap and will deploy the website to create, display, and interact with Request in Q4 2017 instead of Q1 2018 as initially planned.
This website will be open source and entirely on the client side (such as myetherwallet) to act as the foundation for many future projects.
Here’s a sneak peek of the interface:
Create a request
To create a request, the payee selects an account, then enters an amount in ETH and the payer’s ETH address if available. He can add a note (not mandatory).
The request is created and sent within seconds.
This design describes a standard request. The advanced mode will allow you to enter additional information which are mandatory for invoices or other financial flows. We didn’t introduce it yet, Request not only allows you to do your invoicing but we can apply it to manage every financial flow such as salaries, expenses, loans, donations, and more.
Manage your requests
Request allows you to track the payment status in real-time. All parties know whether the request has been accepted, declined, or paid by the payer.
Receive and pay a request
In Colossus, the payer receives the request via a URL (in the next versions, the payer will be able to detect a request automatically). He can decline the request or pay it, partially or fully.
On the visual above, his request contains the additional information that the payee has put, such as his name and address.
Here, Google Inc. is the payer. Once connected with their wallet, they simply have to click on “pay now” to pay.
For the first version of the working product, a Request will be:
- payable only in ETH
- without extensions (such as escrow or late fees)
- created by the payee only
The next versions will include:
- multi-currencies (starting with ERC20 tokens)
- a way for both the payee and the payer to create and send requests
- Offline transactions (ECDSA signed but not broadcasted to optimize speed and cost)
- Identity management
- Manage refunds and additionals (such as tips, discounts…)
- Alerts to detect new requests
We were not using Parity and are unaffected by the bug discovered this week.
For security reasons, we will convert some of our Ethers and diversify our wallets in order to manage expenses and limit the risks.
We give a special attention to our project updates and will often use them to give exclusive news. Be sure to subscribe to our blog or to one of the channels where we communicate these (Telegram, or Twitter).
The Request Foundation needs to be as transparent as possible. We will make sure to keep the community updated. We would like to thank the community for all the submitted questions and especially adm for organizing the Q&A session this week.
We decided to answer the questions in this blog post as the questions were asked via different channels and the project update usually has the best visibility (between 10’000 and 30’000 views thanks to people sharing it)
Feel free to raise your questions about the project and the way we’re leading it during those sessions, or simply keep supporting us the way you are. We really appreciate it.
Request Network AMA (Update on 10/11/2017)
Hiring / current team — How many people are working on Request full time? Have any new people joined? If so, who? What skills do they have? Are you planning on hiring? How can people apply for jobs?
6 people who have been working together for 1 to 5 years are working at Request full-time. Nobody new has joined since the fundraising. We plan to expand our dev team (at least one Full-Stack developer and one Back-end/Solidity developer) in the short term. Every person who joins will be properly assessed as we look for people who are both highly competent and share our values.
See this article from YC on how and when to hire: https://blog.samaltman.com/how-to-hire
Our main scaling strategy will go towards decentralization. We will fund projects which build on the ecosystem.
Learn more about about our scaling strategy here: https://blog.request.network/request-network-project-update-october-27th-2017-1cd981fe131a
ING + YC Partnership breakdown — is there potential for internal partnerships through YC, are you in contact with any? What role do they play? How will they help? How much have they invested? When will public info come from ING’s side about the relationship? Are they actively advising? How often do you meet with both companies? Was Request accepted into YC? Do both companies know about Request?
ING and YC are early backers and advising us frequently. There is no partnership or proof of concept going on at the moment. We discuss often and share the same interest in the space.
YC made us part of an important and strong network of more than 1,000 startups. They also advise us and we are regularly in touch with them.
We entered YC with Moneytis and like many other startups from our batch, we started pivoting there. They focus on teams more than ideas, more info here: https://www.ycombinator.com/howtoapply/.
About ING, we had a meeting this month, will have another one next month. We share common interests and we will see if the executive department of ING is interested in working with Request in the future.
FIAT and the request network — how will it work? What will the flow be like? How will you keep fees competitive? How will credit cards work? In what order will the currencies be added?
Any currency can be added to Request as long as someone can build an oracle which proves that a transaction happened.
Such an oracle can be created through partnerships (i.e. SWIFT/ChainLink, many others will come), with a tokenized version of these currencies or with a mix of both (a bank could participate in the Oracle by moving tokenized currencies but it would be transparent for their customers)
About the fee:
The most costly part of the payment flow in today’s world is to manage the invoice (PayPal will invoice 1.5 to 5% and the credit card processor will receive 0.5% to 1%). We decentralize this part.
Also, by creating an interoperable system, we increase the competition which tends to decrease the fees.
As credit cards can have chargeback and can only be processed by third parties, this is not our main focus but a payment provider such as Stripe or Adyen could plug in Request and manage this part.
Business A creates a request asking Business B to pay 100EUR
Version A: Business A shares a link to this request on the Request website (website to explore Requests that we will release this year).
Business B goes to the website, selects its payment processor and country.
The Request is updated.
Version B: Business B uses a system which screens the blockchain, detects the request and its application (compatible with blockchain) and suggests to pay (immediately or at the due date).
How will proof of stake work in conjunction with the “token burn”?
The burning mechanism is the most important between those two when it comes to the Request project. Proof Of Stake is one of the side effects that could come from the result of the use of a scaling technology such as Plasma.
About the question: Is burning compatible with Staking and would we need to mint new tokens:
In a plasma environment, the proof of stake replaces the ether gas fee. Stakers would be rewarded by fees and not newly minted tokens. As a side note, this is why Ethereum could potentially stop minting new tokens completely one day and work on fees only.
How would the Request Network integrate into current systems? Is there a special software needed? How would it work with businesses that don’t use Request?
Any invoicing software will be able to create the invoice on the blockchain instead of only creating it on their database. They can have a duplicated one on their database if needed.
Accounting software can synchronize and import/export invoices and financial flows with the protocol.
Payment providers can screen the blockchain and detect Requests as an additional feature for their clients.
Auditing companies can start analyzing data of their clients in real time in addition to the other invoices.
And companies who use software which is not connected with Request will be able to use our open source websites.
Through its ICO Request has set the standard of what should be considered ICO best practices. A lot has also been developed to that aim (vesting contract…) Will you be developing this angle further?
We will keep developing what we need and open source as much as we can. (ie the vesting contract).
Our token sale contracts can be reused by anyone and everyone will be able to use directly Request for some part of the sale (presale management…).
We expect marketplaces to develop and help new projects to launch. This is by itself a really big project.
From my experience, a lot of big businesses throw around their weight by purposely paying invoices late, to take advantage of float. What benefits would Request provide to them to encourage them to be a part of the Request Network.
Big businesses do it but they also suffer from it with their own providers, we are fixing the game.
If they pay late within Request, they will get penalized by the reputation, and might also have to pay extra late fees (if this extension is chosen).
What guarantees that the network will be currency agnostic? What Cryptocurrencies will be supported? Is being currency agnostic reliant on 0x for example?
Request can handle any currency as long as it can obtain a proof from an Oracle that the payment was completed.
=> works great with ETH/ERC20
=> works also well with other blockchains using relayers (we still have to deep dive into special blockchains such as Monero, but from a first glance, this seems to be working fine)
=> works with other systems not on the blockchain if they are disincentivized to cheat the system.
We don’t depend on 0x for this part.
What is the status on the oracle question? Is Request Network going to be using a decentralized oracle network like ChainLink or a centralized one like Oraclize? Is there any reason why Request wouldn’t go with decentralized oracles?
Oracle security is really important. At the moment ChainLink decentralized oracles seem like a good solution. We are in regular contact with them.
How is security managed in the Request Network? In the whitepaper it’s stated there’s no opportunity for falsification. However, couldn’t someone make up phony invoices from phony companies for phony purchases, like what currently happens? Huge business don’t have time to verify each purchase is legit, which would still be needed for an audit, or at least a sample used. Also, couldn’t someone hack a user’s side to send phony payments to themselves? There’s no way to refund the money if it’s already withdrawn right away, which the current systems of ACH and credit cards have, which is part of the reason of their fees.
We’ve been working on international transfers for a while, KYC and AML are an important point which could be improved in the FIAT world (and even more in the crypto world at the moment).
Request has decentralized KYC and AML endpoints.
The decentralized KYC is by giving the possibility to plug the requests with identity systems. One day, the administration you work in could push one system. It can work with Civic, with uPort or with EIP 725 and EIP 735 (that we are following very closely).
The decentralized AML endpoint gives the possibility to create Smart Audits algorithms running on the blockchain, analyzing your transactions and detecting irregularities in real time.
How is this part stated in the whitepaper different than accounting software used today: “instead of having double-entry accounts, where the information regarding a purchase appears in the purchase account and in the bank account separately, one can see within the blockchain a purchase account, linked to the supplier, linked to the payment, and linked to the bank account”. Even QuickBooks has a feature where you can drill down and see all this relevant information about a transaction. Accounting software has audit trails where you can see where things get changed, when, by who, etc.
Automatically linking the invoices and the payments without using a third party such as PayPal is still very hard and almost impossible. The reason is the lack of interoperability between the payments / invoicing /accounting / auditing systems. The problem is solved by using a universal database of invoices
Garbage in, garbage out is the old saying. How does Request fix this with the listed transparency of institutions listed in the whitepaper; accountability, integrity, inclusiveness, trust and quality? It seems like everywhere, where money can be spent, would be required to be on the Request Network to achieve these goals.
It’s common for big players to require a specific system for invoicing.
And in the short term, you could imagine a simple “crypto NGO” only accepting donations in cryptocurrencies and financing education in developing countries. Everything could be traceable and that would be a sweet Proof of concept.
Will Request eventually be able to accommodate Point Of Sale transactions at brick-and-mortar stores? If so, how will that work?
Yes, definitely, the experience would be very smooth. We initially planned to talk about it in a later update.
Either an open source POS software or an existing one could interface with the Request Library.
The POS software generates the invoice as a QR code (through an ECDSA signed request not broadcasted)
The client scans the QR code, pays the contract (broadcasting the request and paying it)
The POS software detects the payment and completes the transaction
If you are working on a POS software and would like to work with the Request Protocol, you can email us at firstname.lastname@example.org. We will fund/incentivize the best projects in the future.
Are you planning on filing any patents?
None, or maybe “the idea of using angles between 65 and 80 degrees in consumer electronics.”
How will business to business invoicing work for one business that uses REQ and another that does not use REQ (please see scenarios A & B)
This should be a huge point for the team as you have to assume that the majority of your business clients will not be able to count on other companies using REQ for their invoicing.
Scenario A — a contractor uses Request Network to generate invoices, however, the recipient of the invoice does not use Request Network and is not familiar with the service — this generates extra hassle for the contractor to get paid. Why will the invoice recipient accept being forced to use this strange payment method by the contractor?
Scenario B — a business uses Request Network as an accounting tool for all of its invoices. However, one day the business receives a traditional invoice and not a pay with Request invoice. What happens next? How can the business use Request as its accounting system when some invoices will not come from “pay with Request”.
Short answer: a PayPal invoice can only be paid through PayPal. A Request can be paid using any payment system connected to Request.
Long answer: 2 cases
-for cryptocurrencies, nothing exists yet. Request makes it easier.
-for fiat, if you send a PayPal invoice, it has to be paid via PayPal. It is not interoperable. If you send a Request, it can be paid on Request or any system (a bank app, a wallet, a payment provider…). The same comment goes for Stripe/Venmo and any payment providers.
Short answer: It works smoothly.
Long answer: 2 cases
-Business A is using a centralized accounting software. Business A can import its requests into its accounting software (either via an export/import or because the accounting software is connected to the Request Network)
-Business A is using a decentralized accounting software (the notion itself is quite interesting). Business A can import its invoices inside the blockchain so that the accounting software has all the needed information.
If you are working on an accounting software and would like to work with the Request Protocol, you can email us at email@example.com. We will fund/incentivize some of the best projects in the future.
Could you elaborate further on the “Pay with Request” button, as this has been one of my favorite ideas as an investor so far.
- The roadmap states this would be released Q1 2018, so does that mean there are already companies interested in implementing this feature on their site?
- What kind of user interface would the user experience when using this “Pay with Request” button?
- Could Request offer some kind of promotion to the customer to incentivise using Request to pay (3–5% discount) as the ecommerce site would save money by avoiding Visa/Amex/Paypal fees?
Yes, we have received a lot of interest, especially to accept cryptocurrency payments.
About the UX, the button will open a pop up with the detail of the request where you can pay. Below is a screenshot of what it could look like (initially designed for our standard invoice case but could apply here too)
The e-commerce website can offer this promotion, especially in this case.
Marketing / Request Adoption Questions
What is the plan in terms of marketing Request? When do you plan on marketing the platform? Do you have a plan on how you’ll be marketing?
As an ecosystem creator our role is:
-to create a protocol 10 times better than what exists outside
-onboard businesses through B2B marketing, branding and using consulting companies as a sales channel.
We will also develop products to showcase how the protocol works. These do not target mainstream adoption. They are made for early adopters.
When will you have your first customer using Request on a regular basis? Do you have people wanting to use this network?
We are in touch with many potential customers who are looking forward to having Request on the main net. At the moment, most of them are companies who want to get paid in cryptocurrencies.
What is the plan to get enough businesses and governments and users in the loop for mass adoption? What types of institutions, businesses or entities will you approach first? And when?
Be active in the crypto payment space. Then onboard businesses and partners on Request. Then go to Fiat payments. The answer to this question could be mapped out in a whole document.
Does Request Network plan to use Cosmos/Tendermint in the future? Or, is the network going to work with Ethereum?
We have been talking with Cosmos/Tendermint which could be a potential scaling solution and we love what they are trying to achieve. At the moment, Ethereum brings us interoperability with many other projects and we plan to stay there.
Is there any possibility of Request working with OmiseGo’s decentralized exchange platform to process Crypto to Fiat requests?
If you send money to an OmiseGo compatible system, it’s completely feasible.
What stops the team from not delivering? Monetha made big claims during their ICO too. We all know where it is now, nowhere. I don’t think we’ll be seeing anything of them anymore too. What stops REQ from going the same path?
We want to execute well. We have a fantastic track record of delivery and are used to working together. This is one of the main reasons why YCombinator decided to invite us to their program (according to them). In addition, we don’t see any hurdles on our way of delivering Colossus.
Why was there no vesting period for pre-sales? What were the qualities and what kind of help/favour were you looking for that the applicant would deliver? What was the basis of selecting/rejecting a pre-sale applicant? What have they contributed?
The bonus would not have been sufficient to add a vesting, especially as strategic buyers joined before the token sale which brings additional risks.
We believe there has been some misinformation about this as an attempt to explain the price evolution when some people saw red.
It’s hard to select a good strategic buyer but many helped us with communication, partnerships other pieces of advice and we are happy to have these ones with us.
Can you please provide comment on the current status of Moneytis? Was it a failed project — how come there are no longer any employees working on it? How do you think the current status of Moneytis reflects on your ability to execute and realize the Request Network vision?
This is a pivot. A pivot is healthy in the life of a startup and shows that you can stay focused on what is really needed by the customers. In our case, the real need of people who transferred money internationally was always to pay an invoice (or a request) and we had to solve the problem at the root.
Moneytis had a 20% growth month over month (even this summer when we were not focusing on it, TechCrunch wrote an article about it). What made us do the pivot was that Moneytis had not the same scale of ambition and challenge than Request.
Any plans to join Project Transparency the holdings tracker for ICO’s?
We want to take part in initiatives, and especially if we can use Request to show our transparency. We are our first client of the transparency use case.
Is Request actively pursuing new exchanges? Is there an ETA on new exchanges?
The confidentiality policies we have with exchanges are important to us and we want to respect them. We know how important exchanges are to the Request ecosystem and we will keep paying attention to them for the long-term vision of the project. We won’t comment more on exchanges.
Will you have any merchandise for sale in the future? (T-shirts etc)
The foundation will probably not do it but anyone can. Feel free to make suggestions.
Can we see a picture of your office?