All questions and answers from the Request AMA held on Friday the 4th of October — 2019.
Last week the complete team participated in the public AMA, directly answering all the questions asked by the Request community in a two-hour time period. As a lot of valuable information has been shared in this session, we’ve categorized the questions & answers below. This should make finding & making references to the information provided easier.
Marketing communications
Question: I believe adoption will come through a strong community. Creating an ecosystem from which even more new partnerships and integrations can emerge on their own is the right way to go in my opinion. Request’s treasury can help with meetup and conference costs, in order to allow volunteers from around the world organize meetups. Is this something you’re considering?
Answer: Indeed, we totally agree. Once we find a solid adoption base, hosting events will be key to exchange ideas, receive feedback, know each other and give visibility to the project. We first focus on the product because it still lacks core features (ETH, ERC20 payment detection and encryption). With these core features, gathering early adopters in events will be easier and more powerful. Regarding community members pitching Request during conferences, we did not think about that. Thank you for the nice idea! The volunteers can get in touch with us directly by sending any of the team members a direct message or send in their idea through the contact form. The success of such an action would rely on the right person going to the right conference with the right pitch.
Question: What is the current status of the Request Hub?
Answer: The Request Hub is still active and it’s a great space we use to talk with developers (Gilded etc) — it’s also advertised on the website in several places such as our developer page.
We are still accepting applications for the Request fund. You can apply for the fund here.
Question: Could we please move back to regularly scheduled project updates, by that I mean short blogs than just Reddit posts. How about commissioning a member of the community to flesh out an article from bullet points?
Answer: The original feedback from the community was that the bi-weekly updates frequently didn’t have enough substance, they have been replaced by minor bi-weekly roadmap updates instead.
Larger updates, for example, Mainnet V2, Request for Payments are still announced in the form of a larger, more substantial blog posts.
We will always review how we provide updates and how they can be improved. In the future, if blog posts are a better medium we will make that our primary method of communication again.
Question: Another AMA mentioned lack of confidence in Request v1 (which I find strange, but maybe something was lost in translation), and great confidence in Request v2 (which is great, and exactly what we expect of a second iteration after the many learnings we all went through): given this great confidence in v2, and the fact that the company has about $9m worth of treasury in ETH at the time of writing, I believe marketing through relevant channels to reach developers and companies that ought to use Request would be highly beneficial to product development and visibility. Is it planned?
Answer: We have built V2 to bring encryption features and to make it more scalable & adaptable. V2 is not developed because of any lack of confidence. Requests for Payments are still based on V1, and it works very solid. You might be right that this was lost in translation, our apologies for this misunderstanding.
With regards to marketing: adoption won’t come by itself with a website, a blog, or a Reddit community. We contribute to business development activities to learn more about the crypto-businesses’ needs and spend a significant amount of time participating in electronic invoicing events and discussions. Not only does it bring visibility to our vision and project, but we also discover a lot of additional use cases. For example:
here and here.
When the V2 core features are available through the API, we will put more effort into getting the project in the spotlights :)
Question: Marketability and brand recognition is very important for a project like this in my opinion. Have you considered naming Request Network’s sub-projects using something more googleable/searchable?
There is potential to use a keyword like “ReqPay”, but unfortunately, something with this name already exists.
Answer: Thank you for the suggestion; we have not considered changing or adopting “ReqPay”.
We agree that having a recognitional brand name is essential. Being found when using more general search terms is, especially in the stage where we are less know, very beneficial. A recent example is the launch of the Request Academy. The Request Academy content is written with keyword research in mind to improve SEO rankings. The content is related to the creation of invoices, e-invoices, payment requests, cryptocurrencies, and more. Initiatives like this will contribute to introducing Request to a broader audience.
Organisation
Question: One of the private AMAs talked about the team, and that growing it took time at first, and now allows things to go much faster. Could you share a list of all team members (or only their positions if not willing to share names), their experience before Request, what they’re working on now at Request, and what they’ll be contributing to in the future? I’d like to understand what the team looks like right now (size and skills) and how it’s shaped to work on everything that’s planned.
Answer: At Request, we’re currently a team of 15, 8 of us being developers.
We’re split into 3 different teams. We have one team taking care of learnings and experiments, one team developing our main products (protocol and API) and one team taking care of partnerships and community.
Question: Why have you failed previously (Moneytis, Req V1) and what have you learned from these failures? What makes you confident that you’ll be successful going forward?
Answer: The Moneytis project wanted to make the remittance transfer market more transparent and more accessible to anyone. We were trying to tackle a symptom instead of the root issue that’s why we pivoted. We learned a lot during our Moneytis journey about the market and the users to build a better solution. Users wanted an easy way to pay their bills wherever their money is. To make it short, the money was not in the middle but the invoices were. That’s how we started Request.
The first version of Request allowed users to pay more than 400K USD in one year and is still used (including by ourselves). However, its limitation will be a barrier to adoption. We decided to develop a new version for several reasons:
- Tackle the scalability issue, since Ethereum v2 is not ready
- Allow encryption to enforce the privacy of our users (this is one of the most important features to get adoption)
- Being less dependent on Ethereum. Even if we strongly trust the development team behind Ethereum, we cannot take the risk to be too dependent on another project.
Note that what we call Request v1 will probably become “Smart requests”. This will allow users to enjoy the upside of the v1 (invoicing and payment in one flow, trustless payment rules enforcement though a smart contract..) into the v2.
Payment detection
Question: Romaric has said previously (July 15th) that the challenges of detecting ERC-20 payments haven’t yet been investigated. The recent update has said the investigation phase has now finished and implementation is going to happen. To me this is worrying as a roadblock for V1 was the challenges in implementing Bitcoin. What are the changes that will allow BTC to be accepted versus ERC-20?
Answer: A major difference between V1 and V2 is payment detection.
V1 is tightly coupled to Ethereum, which makes it easy to detect ETH and ERC20 but difficult to detect other blockchains payments.
V2 is using the blockchain as proof for the payment request interactions, for example, creation and acceptance. However, this can not be used for payments, except for declarative payments.
Instead, the client will connect to the payment network (BTC, etc) to retrieve the payment status. This creates some UX challenge but makes the network much more powerful.
Question: Have you thought about integrating XMR as a payment option?
Answer: We haven’t looked into it, currently we’re focussing on transparently accessible currencies like BTC, ETH and ERC20, as well as fiat.
The choice of tokens we integrate is driven by usage and demand from our users and Monero is currently not planned.
If you have a use case for XMR and Request let us know by getting in touch with us through the Request Hub.
Product
Question: Would you reconsider a mobile app since it’s been a huge expectation since day one OR are you still waiting for Pomelo Pay? If the answer is yes to the latter, would you care to explain why you chose this team and their progress on this project?
Answer: PomeloPay is a great use case for Request.
There are already some great mobile wallet solutions, it doesn’t make sense at this stage of Request to create our own mobile wallet. There are many standards available to make payments via mobile wallets which we can support in our apps.
Right now, our effort is better spent on making the network more usable, increasing usage, exploring potential use-cases and exploring industries to find product-market fit.
Question: Have you thought more about the possibility of having a Request account linked to an email, a pseudo or a phone to make payments easily instead of having to copy/paste an address?
Answer: We’re currently experimenting with several possible solutions to remove the barriers for novice users. This includes not having to deal with keys and using email addresses as identifiers. We believe in making request accessible for everyone, including people who don’t know about public/private keys, ethereum addresses, or blockchain in general.
One of the solutions we’re experimenting with is accounts. This allows users to not worry about the complicated blockchain concepts and will allow builders that are willing to support it to build faster.
Of course, this is an optional part of the Request experience. The Request Protocol is open for other types of identities in the future.
Question: Can you give us either an estimate or a goal/target for the usage of the network from its various “fronts” i.e the usage on Request to Pay, versus Xero, versus with Gilded, etc?
Answer: Honestly, estimates for these are nearly impossible. We are creating a variety of usages to test adoption hypothesis, and we’ll improve the ones that show good results.
Question: What is your plan to take advantage of Gilded working with QuickBooks? This seems like an enormous opportunity.
Answer: Request integration to as many invoicing software as possible is a clear target for us. We have a similar vision with Gilded, with different first steps: ours is more focused on invoices creation and import.
Ideally, we will be working on several different integrations, while Gilded and others will create some more. In parallel, we have initiated a Xero integration proof of concept a few months ago. We put the project on hold while working on Request for Payment. Meanwhile, we focused on some missing technical pieces, both from the Protocol and API, that will enable it to go live. We intend to release this integration as a code example for other integrations to come.
Question: I constantly see merchants asking about how to accept crypto on /r/cc and just generally everywhere. The answer is always BitPay or some other source. When will you start actively tackling these cases and making connections in order to deliver to these merchants and start spreading requests advantages by word of mouth in the merchant community?
Answer: We’re currently focusing on building the framework that will allow other people to build these kinds of applications more easily.
We also believe that a product based on Request has the potential to replace Bitpay. Providing a more decentralised approach and leading to better interoperability and cheaper cost. We tried a proof of concept and we are still missing some pieces in the current version of Request. Specifically encryption and cost-effective requests. Both upgrades will be included in the next releases. As online payment is an entire project, we will welcome independent teams who would like to tackle the issue using Request while we focus on the core system of Request.
Strategic Partnerships
Question: The fact that WeCan is involved with Libra is very interesting. Can you tell us about what led you to Invest In WeCan; how you heard of them, why, your hopes with this investment, etc?
Answer: To answer the first question: We know WeCan Group founders since 2012. They are people we trust. Well connected with governments, universities and blockchain projects. The investment we made was part of Request Fund. The goal is about Request development and sharing connections.
Question: Is Request still talking to governments, and what is Request offering to them that they are/might be interested in?
Answer: Yes, we are still actively talking to institutions. From Ministries of economics to EU level representatives. Request is perceived as an interoperability layer between ongoing national E-invoicing initiatives like in Italy. Providing a space where Companies and Institutions can share both invoicing and payment information has been identified as a unique opportunity to combat tax fraud and reduce VAT Gap.
This report explains the E-invoicing industry, market size and initiatives in the Invoicing world.
However, this is a long and ongoing process. Decisions at a national level usually take months to years as it relates to EU regulatory frameworks, ISO standards, invoicing standards, accounting norms and more.
Question: Is Request somehow involved in this?
Answer: We’re involved with WeCan Group as an investor
Question: Would you care to tell and describe the different startups and companies you have invested in?
Answer: The status is the same as the last AMA:
The Request Fund has made 2 investments and given a few grants. There are NDAs in order to disclose more info only once the team has reached specific milestones. The blog article we originally planned after answering questions in our last AMA is currently not on our agenda anymore. The goal is to maximize the efficiency of mutual communication.
Only Gilded completed the milestones, that is why we often refer to them. You should check their product, it is solid with nice UX and features: https://get.gilded.finance/
Question: Could you please tell us the result of the e-invoice conference at Vienna from September 29 to October 2, the results obtained and how it affects the future of Request?
Answer: The Vienna Exchange Summit was the first opportunity for Request to pitch in front of a qualified target audience composed of:
- B2B, BTG and BTC E-invoicing professionals, tax authorities and EU commission representatives.
- Payment industry professionals such as banks and card networks. Our presentation generated a lot of interesting questions, enthusiasm and discussions within the conference over the 2 days.
This is great for the future of Request as we are now recognized as a legitimate player in the ecosystem we target. Also, the conferences brought us a lot of exposure. We can now say that this audience knows Request and recognizes us as a knowledgeable partner. This will facilitate the next discussions with prominent actors in the industry.
The next steps are to initiate exploration phases with some of these actors to validate and fine-tune our value proposition towards them.
Tokenomics
Question: Tokenomics: the burn mechanism, which will burn REQ tokens proportionally to how much the network is used, is the only thing that currently gives the token utility value (that I know of):
What companies/projects are you aware of that will be using Request v2, or already are? Has Gilded moved to v2? I know v1 processed $250k worth of payments, how is v2 doing so far?
I’m not for creating artificial ways to increase market value (which often fail anyway), but if you have new token mechanics planned, I’d be curious to hear about them!
Finally, could you list all the token vesting schedules currently in place?
Answer: The API, although centralized, is the easiest way to onboard on Request, so that’s where we want to make an effort for adoption. Currently, the API is missing small features compared to the decentralized protocol in order to be used, we’re working on adding these features. An example of such feature is changing the state of a request.
Currently, no project outside of Request is using v2. Internally, we have the API on v2 and will be migrating app.request.network.
We consider ideas today that we could implement later, that may have an impact on token utility, like staking and governance. A technical benefit to staking will be to reduce spam.
There are multiple vesting contracts in place for team members at Request and not every team member receives vesting and the same amount. The definition of vesting at Request is that a smart contract is continuously paying a percentage of the full vesting amount until 100%. A team member receives vesting over either 2 or 4 years since the start of the employment contract. All vesting for team members can be tracked on this smart contract: https://etherscan.io/address/0x45e6ff0885ebf5d616e460d14855455d92d6cc04
Question: My second suggestion is to provide some sort of staking, to add both to the usability of the token and also tackle a market that is currently very centralized; Escrow. Currently when I’m buying from eBay or aliexpress or similar big sites, I have to use a centralized Escrow service that is usually provided by the site itself.
Similarly, the REQ token could be used as staked collateral by a node to provide Escrow for the holding of funds between a buyer and a seller or a service provider. Price swings in token value could be offset by the Request Foundation themselves holding a percentage of their vested tokens (~300mil REQ — not all of it, obviously) just for the purpose of covering escrow value swings. This service could probably be hedged by running a MakerDAO contract against REQ price drops that feedback to the Escrow contract.
What forms of staking have you considered using REQ for so far, and has the Request Foundation considered providing usability for staking escrow services using REQ tokens?
Answer: Our current vision of Request is to document payments. We don’t plan to provide an escrow service at the moment. However, we encourage people to build escrow services on top of Request!
We are considering staking on the node as a means to reduce spam, you can find more details in this thread.
