ApeWorX LTD
What’s this? Yet another streaming payments system?
Yes, but we swear there’s a good reason we built and open sourced a new one!
When building cHaOSneT we realized that we had a decision to make: did we want to go the Web 2.0 way and use traditional login and payment processing, or did we want to go full Crypto-native and try to build something new?
https://mirror.xyz/apeworx.eth/mIKYEt54RgNs7R12Np1vEyp8z5HuBKBdCjCWqrnNfe8
Of course, we decided to do the latter, but this meant researching Crypto-native login and payment solutions. Login was easy, we used Sign-in with Ethereum, but in researching streaming payments platforms we had some problems. All the options we researched either didn’t have the right UX for this use case, were upgradeable (which is poor for automated services as it could cause an outage… among other things), or were otherwise not making updates to the protocol anymore. So… we needed to build our own!
ApePay is designed from the ground up for the needs of automated service provisioning performed off-chain, such as the types of services we are building at ApeWorX for our users. We needed a minimal payment protocol that was flexible enough to meet our needs, and yet safe for users by allowing them to withdraw at any time to stop using our services. An upgradeable protocol was immediately off-limits. Maybe it would have been useful but it’s just not safe, and we also wanted to open source this protocol, so allowing what might seem like a minor upgrade to the contracts could risk completely wrecking our infrastructure. Immutable protocols are the way to go for robust, scalable infrastructure since their behaviors won’t change on a whim.
That’s great, but here are some of the actual benefits of ApePay’s architecture:
It’s extremely scalable!
it unlocks smart contract workflows for users
It can re-purposed for multiple different products
We also added support for Permit2, and wrote it in gas-efficient Vyper v0.3.9!
But let’s dive a little deeper…
Since ApePay is a decentralized application, and not just another centralized payment service, downtime is effectively eliminated. We don’t have to host servers, or make relationships with credit card companies in 195 different global jurisdictions. Everything is just crypto, streamed at a defined rate, until it either runs out or is cancelled by the stream creator (or us).
Reliability makes it possible for us to build our product infrastructure around this protocol, and that’s exactly what we’re doing by leveraging the upcoming Silverback platform for managing the off-chain integrations behind each of our products. When you open an ApePay stream, our infrastructure will automatically detect this action, and then parse the stream to provide the services that you paid for, as transparently and quickly as possible.
What about spam? Chargebacks? Compliance?
Since each ApePay StreamManager contract is it’s own self-sovereign hub, the owner has complete control over how they handle streams and under what conditions users are allowed to set them up in the first place. By using an optimistic architecture - basically that you trust the hub owner enough to open a stream with them - we can eliminate a lot of the complexity of negotiating on-chain when errors do happen. Made a payment by mistake? Close the stream (after a pre-defined warm-up period design to protect against DDoS attacks against the infrastructure). The service was down? The owner can just credit you with more time than the stream specifies off-chain. Only want to allow certain users during a limited beta? Add validators contract to deny users who shouldn’t be allowed or don’t meet specific conditions.
All of these features are executed completely on-chain, and we can rely on this behavior to negotiate off-chain using the assumptions of the protocol. Very human, and easy to use!
This was a cool one for us to realize, imagine this: what if you allowed a service user to be a smart contract that pays for it’s own usage? As an example, let’s say you are building an arbitrage bot that runs on the (upcoming) Silverback platform. You create a contract used to hold the assets at rest, and have that contract manage it’s own payment stream used to pay for running the bot directly from the profits! This is really cool, because you don’t have to worry about setting up those recurring payments, or what happens if your payment processor goes down, since it’s a decentralized application that’s always running the subscription as long as you want it to. What’s more, you can have the bot shut itself down if it’s no longer working profitably.
This is the future we’re asking for!
If we were gonna design our own payments protocol, we wanted to make sure it was flexible enough to support all our future products. Since ApePay is a very simple but very configurable system, we were confident that it can grow and scale to support whatever future products we (and the community!) might build with it. And by open sourcing it to our community, it’ll be interesting to see how others might evolve and adapt the rules of the protocol to create even more interesting use cases.
It’ll be especially interesting to see how ApePay will allow centrally viewing and managing payment streams across our product suite, and potentially from multiple service providers, all from a convenient dashboard (coming soon™)
ApePay is being open-sourced under this repository, and maintained by ApeWorX. We accept feedback, contributions and feature requests, and will be integrating it with our cHaOSneT product shortly. For now, there is no public deployment, but will be coming shortly, and of course anyone can deploy their own for testing purposes.
https://github.com/ApeWorX/ApePay
If you want to be one of the first to try out cHaOSneT just sign up to our Mirror email notifications to be given front row access for when we launch the Beta! Just sign up above and you’re in!
#PrepareForcHaOS
- ApeWorX
For the latest on all things Ape follow us on: apeworx.io | Discord | Twitter | Bluesky
Over 200 subscribers
