Request – Version 2.0 Mainnet Released

Today we are beyond excited to announce we have launched v2.0 of the Request Protocol on the Ethereum mainnet! V2.0 acts as the fundamental infrastructure of Request moving forward.

Learn everything you need to know about the redesigned Request Protocol, what’s included and changed since the beta in the article below!

First – why did Request need a new version of the protocol?

V2 of the Request Protocol is the second major iteration on the protocol. While working on the first version of the Request protocol, market insights made us realize that important features needed to be integrated into Request technology for the protocol to be adopted by industry professionals. The release of v2 and further development of this new version addresses these requirements, such as the need for high scalability and data privacy options. V2 was originally introduced in October of last year. The initial release, v2.0-alpha, was shipped in February for internal testing, followed up by v2.0-beta in June for external beta testing.

What does the Request protocol allow me to do?

The Request protocol enables companies to create, exchange and process invoices and requests for payment through a global network.

By connecting transaction receipts (invoices for B2B, purchase receipts for B2C and transaction receipts for C2C) together with information flows from the payment industry, Request opens a wide range of new automation possibilities in corporate finance, particularly in invoicing, payments, tax collection, accounting and bookkeeping activities.

Request is the blockchain backbone of Supply Chain Finance, where buyers and sellers share trusted information which is immutable and time-stamped for accounting purposes. Based on set permissions, financing institutions may be granted access at some stages of the transaction lifecycle in order to provide short-term credit options. This optimizes working capital and increases business efficiency for both the buyer and the seller

The blockchain-based technology behind the Request protocol finally represents an opportunity for organizations to join a new paradigm, process transactions using digital asset (tokenized assets, cryptocurrencies) and benefit from smart contract possibilities to automate business relationships, enabling electronic invoices to become “smart objects“.

Are you an early adopter, true innovator or just curious about investigating efficiency gains having your business empowered by Request? Please feel free to reach out to us.

Announcing v2.0 mainnet

After positive feedback from our external testing period, v2.0 is ready to be deployed to mainnet. The contract can be found here:

RequestHashStorage : Stores the hashes

RequestOpenHashSubmitter: Declares data hashes and collects the fees

We always aim to receive additional feedback and answer all implementation questions on the Request Hub and will continue to expand the documentation. Now that v2.0 is released on mainnet, we will frequently release new features to expand the functionality of the protocol.

What is included in the v2.0 release

V2 is a complete redesign of the Request Protocol. The initial release, v2.0, is the core foundation of this redesign and the start of a scalable, secure and privacy compliant way of creating and sharing invoices on a global network powered by blockchain technology.

Below are the features you can expect to find in the v2.0 mainnet release:

Invoice storage on IPFS with proof on Ethereum

Create, retrieve, update (accept, cancel, change amount) requests for payment

Content data: the standards for the data of the Request Protocol

BTC payment detection, allowing invoices to update their payment due when paid in bitcoin.

Declarative requests: create a request in any currency without automatic payment detection

Request node: Web server that accepts transactions and saves them on IPFS while broadcasting a proof on Ethereum. The node aims to simplify using the Request storage layer.

Request Client js: A web and node.js library to connect to Request nodes, meant to simplify the use of the protocol.

With v2.0 now operating on mainnet, a minimum fee of 0.10 USD will be needed per network update, for up to 10kB (approximate size of a request) and 0.03 USD will be asked per additional 10kB.

Feedback and changes since v2.0-Beta

We received positive feedback from the builders that have tried v2.0 during the testnet beta phase and did not report any bugs.

We have however received useful feedback regarding documentation improvements and feature requests. These have been prioritized and will be worked on next.

Although no major feature has been added, some changes have been made since the testnet beta:

Dedicated IPFS network: We’ve set up an IPFS network dedicated to Request usage. IPFS calls this feature a private network. A private IPFS network is a collection of IPFS nodes that share the same secret key; in our case, this key is public so that anybody can join our dedicated network. It allows Request to have tightly connected IPFS nodes with faster synchronization, resulting in a faster and more reliable Request network.

We’ve set up an IPFS network dedicated to Request usage. IPFS calls this feature a private network. A private IPFS network is a collection of IPFS nodes that share the same secret key; in our case, this key is public so that anybody can join our dedicated network. It allows Request to have tightly connected IPFS nodes with faster synchronization, resulting in a faster and more reliable Request network. Testing: We’ve created 16k transactions with a 99.97% success rate.

We’ve created 16k transactions with a 99.97% success rate. More logging on the node: The Request node now has detailed log output

The Request node now has detailed log output More bitcoin providers: We now rely on 4 bitcoin providers (instead of 1 before) to read the Bitcoin blockchain to detect payments. This increases the decentralization and resilience of the data.

We now rely on 4 bitcoin providers (instead of 1 before) to read the Bitcoin blockchain to detect payments. This increases the decentralization and resilience of the data. Compute the requestId before creation: The requestId is generated deterministically, not at the creation. This makes it possible to generate the request’s ID before its creation. A builder needed this feature for their use case

The requestId is generated deterministically, not at the creation. This makes it possible to generate the request’s ID before its creation. A builder needed this feature for their use case Minor improvements and fixes that can be found in the changelog of each package on the github repo.

What is worked on next:

Now that v2.0 is on mainnet, we will focus on implementing:

Privacy through encryption: Adding encryption to Request makes the content in a payment request, such as payer/payee and amount due, only accessible to stakeholders that have access to decryption keys.

Increase network scalability by batching requests: Grouping requests on Ethereum will lead to increased throughput of the protocol and decreases fees.

Support for more currencies: integrating ERC20 & ETH payment detection

What happens to v1 of the protocol?

The v1 smart contracts stay on Ethereum and will remain usable. The v1 library stays on npm and will be minimally maintained.

We will not deprecate V1 until request batching, ETH payment detection and ERC20 payment detection are implemented and operational on v2.0 mainnet.

How to get started:

Visit the new Documentation page here.

Check out Request Node and deploy a node in local

Check out request-client.js and especially test/index.html and start using v2.0!

If you need help, come find us on the Request Hub

How to contribute and how to report a bug

Submit an issue to discuss your idea or bug

Have a look at the contribution guidelines

Get in touch on the Request hub