DePay Payment Protocol V1

Even though we already had a working prototype – a beta version – of our payment protocol back in November 2020, after participating in the ETHOnline hackathon, throughout further development we finally arrived at a stage where we can say: Yes, this is version 1.

What's the difference to beta?

First, the beta version has been written in a Hackathon context. In professional software development, especially for a payment protocol that we want to function reliably, that software needs to be somewhat rock-solid. A hackathon doesn't allow for that outcome. It's great to spawn ideas and quickly "hack" a piece of software to not only get a look and feel but also a proof of concept, which is pretty valuable at that time, but it will not scale very well, as potentially you have so many bugs that you will be overwhelmed by support requests once you release it and start growing.

Technological evolution

During the hackathon, we had certain technical plans and visions that, due to the short amount of time, we simply couldn't implement. Now with v1 that's different because we took the time required to turn those technical goals into reality as they were important for us and are important for the first part of DePay's journey.

Plug & Pay

So the technical vision that we had in our heads since the Hackathon was to have a decentralized payment protocol that grows over time with "plugins". Think of decentralized exchanges as plugins. When somebody needs to pay a receiver with token B and only has enough from token A the payment protocol needs to route this payment through a plugin in order to make sure the payment receiver gets enough token B.

Uniswap is DePay's first payment plugin.

But that's just the start, over the next weeks, you can expect payment plugins for all big decentralized exchanges and even the ones that are not even live yet.

This "plug & pay" system has the following benefits:

• When people interact with DePay to perform payments, they only have to approve a particular token once, no matter through which plugin the token is gonna be routed through

• We can grow in regards to plugins, without upgrading the DePay Payments contract itself or without revoking previous users token approvals

• We can plugin future protocols without upgrading the smart contract itself and revoking all approvals

• Allows others to also write DePay plugins, driving decentralization

But we are not gonna stop here. We have big plans for the "plug & pay" system and let me give you a brief sneak preview of what to expect.

We will also facilitate this system to enable people to perform other, often requested, payment-related configurations like "receiver reimburses your network fees".

But how do you make sure people don't drain the receiver by setting the network fees to an insane amount or an unnecessarily high gas price? Well, with payment plugins.

We will allow payment receivers to cover their customer's gas fees by allowing them to set a maximum covered gas price for the payment transaction, while also enforcing the current standard gas price on the network with oracles and DePay payment plugins, reverting transactions in case people exceed the receivers configuration or the standard gas price to a certain degree.

Coming next, security audits and our official bug bounty program.

Stay tuned.