The problem sub2 protocol solves

As single payments and checkout processes with ERC-20 tokens have become more popular and user-friendly, the potential for on-chain subscription payments remains a largely untapped field. On-chain recurring payments is a hard problem because the EVM does not natively support time-based automation. Current solutions either require companies to use the user's private key for transactions or rely on the recipient to process their payments. Token streams require locking up tokens and do not fit the current business subscription model. These approaches are flawed, hindering the adoption of on-chain subscriptions.
Introducing sub2, a permissionless, immutable and autonomous protocol for creating and managing on-chain subscriptions. Sub2 solves the automation problem by opening the role of payment processing to anyone. The processing fee which would normally go to a company now goes to whoever processes the specific payment creating a financial incentive to do so. Using an open reverse Dutch auction model to pick the processor on each payment, sub2 simultaneously ensures fairness and the lowest possible fee for the user. Only on L2s like Base and with the recent lowering of fees as the result of EIP-4844, subscription payments can now be processed with sub2 more than ten times cheaper than traditional payment processors.
Sub2 acts as a foundational protocol allowing anyone to build on top of it, which can be anything from creating payment apps to making content on social media exclusive to subscribers. The sub2-sdk, a TypeScript/JavaScript development kit, together with extensive documentation makes it easy to interact with the protocol. The web interface sub2protocol.com simplifies creating and managing subscriptions, providing users with an all-in-one solution. It also serves as a popup 1-click checkout window that can be integrated by third parties such as merchants.

Challenges we ran into

The major challenge with creating this protocol was making sure that the logic is sound and that it is completely secure. As a foundational protocol handling economic activity, any bug or exploitable logic in the smart contracts can have severe consequences for the user. Therefore we emphasised extensive testing in Foundry including unit testing and fuzzing of the core functionality. We are of the strong opinion that such a protocol has to be audited before being deployed to mainnet. Thus, sub2 is currently launched on Base Sepolia until the contracts have been audited.

One of the hardest technical challenges was creating the ability for any third party to sponsor the processing fee of subscriptions. We wanted a model where the sponsor doesn't need to perform any on-chain actions while ensuring that only subscriptions meeting the sponsor's specific criteria are eligible for a sponsorship. We ended up solving the problem using an EIP-712 signature scheme. This way, the sponsor can sign a permit with the exact specifications of the subscription they want to sponsor. The signature can be made off-chain and when used in creating a subscription, a reversion happens if the input arguments do not match the signed criteria.

Another challenge was designing a data structure making it gas efficient to store and interact with subscriptions while also making querying information efficient. Specifically, it should be efficient to query all outgoing subscriptions from a sender, all ingoing subscriptions to a recipient and the data structure should be partitionable to facilitate parallel payment processing. We found a good solution using a central array which is double indexed from both the sender and recipient’s perspective. Furthermore, the array slots are reusable making the memory fingerprint on Base proportional to the number of active subscriptions instead of the total number of subscriptions ever created.