ETH Global Prague 2025 hackathon project
SubsCrypt is an innovative platform that leverages EIP-7702 and Vlayer ZK-proofs to create an on-chain private subscription payment marketplace.
Name morphological analysis:
- Subs: Short for “Subscription”, highlighting recurring payments.
- Crypt: From the Greek “kryptós”, meaning “hidden” or “secret”, emphasizing user privacy.
In most Web2 SaaS applications, users' emails are used as the service consumer profiles, allowing users to authenticate themselves in web apps and consume the specific service. In the case of paid services, payments should be routed through a conventional payment gateway (PayPal, Stripe...) to which the identity of the user must be disclosed (email, payment information, service consumed, price paid) to a third-party payment gateway. The advantage is that for subscription payments, the user should only set up the payment method once, and the service provider will periodically pull the funds throw the payment gateway from the user's payment methods automatically without requiring any user interaction. We can now mimic that flow efficiently by implementing delegate logic to EOAs thanks to the EIP-7702 introduced in the Ethereum Pectra upgrade.
Hidden Email as a Service Consumer Identity
Using Vlayer Email Proof, we can authenticate a user's email off-chain within the service provider application and have it verified and bound to a specific "payment" EOA controlled by the user (service consumer) without needing to disclose any user data to third-party payment applications. In this schema, the email address is only shared with the service provider. Additionally, the user can authenticate and trigger actions in the wallet by sending simple emails, abstracting any key management on their part.
The "payment" EOA can be created solely for the subscription payment purpose and can be funded using privacy-preserving funding systems to guarantee that the service consumer account remains completely anonymous. To bind this "payment" EOA to the email of the user a commitment of the email (hash + salt) is stored on chain in order to allow the consumer provider in the future to proof through his email that he is the owner of that specific "payment" EOA (Email authentication in the delegated EOA).
We can leverage EIP-7702 to enable non-interactive payments, meaning that only an initial signature from the "payment" EOA private key is required to set up the subscription. This signature will be used to sign the authorization tuple that is submitted on-chain by the service provider backend to delegate the smart contracts which allow the service provider to periodically pull funds from the EOA, mimicking conventional Web2 subscription systems. The signature will be sent through email to bind the "payment" EOA to a specific email address. After the delegation, the private key of the "payment" EOA can be destroyed without the risk of losing the EOA funds since recovery logic with email authentication is implemented in its code thanks to the delegation. This flow allows one to completely abstract private key management from the users.
Since once the EIP-7702 delegation is activated we can control de implementation code of the EOA programatically there is not need for the user to hold the private key of the EOA, as we can implement email authentication mechanism to allow the user to recover the funds from the address.
The service provider can pull the funds whenever he wants since we implement a stream payment that accrues the paid amount per unit of time. Ideally, the service provider will periodically pull funds from the payment EOA. The periodicity and the price per unit of time are properties of each specific service provided and are completely customizable.
In order to incentivize the execution of the payments semi-automatically, a fee auction is implemented to incentivize anyone to pay for the gas of payment triggering transactions, obtaining a fee percentage in exchange.
We leverage 1 Inch Unoswap swaps so users can pay in their preferred currency and the services providers got payed with their specified currency. The swap executes atomically in a same pulling transaction, converting the funds.
- Service providers can announce their services by submitting a transaction to
SubsCryptMarketplace.registerServicespecifying all the properties of the service throughServiceOfferstruct. This can be easily done through the service provider admin dashboard.
struct ServiceOffer {
address serviceProvider;
address paymentRecipient;
address paymentAsset;
uint256 assetChainId;
uint256 servicePrice; // in wei/seconds
uint256 paymentInterval; // seconds
}- Users can visualize all offered services from different services providers in the same aggregated frontend.
- If an user is interested in a specific service, he can start the subscription initialization through cling a simple button in the frontend.
- Transparently to the user a "payment" EOA private key is randomly generated and is used to sign a delegation to the
SubsCryptSmartAccountDelegateimplementation. - At the end of the button click handler action, an email window opens, indicating to the user that they need to send an email to the service provider with the delegation payload. The email is automatically generated following a template; the user only has to send it.
- The email is received in the service provider inbox and is automatically processed by an email automation build with n8n.
- From the email content following data is parsed:
- The service id that the user wants to subscribe to.
- The email sender.
- The email receiver.
- The EIP-7702 authorization tuple.
- The service provider backend submits an Ethereum v4 transaction to the blockchain with the given authorization tuple, effectively setting up the SubsCryptSmartAccountDelegate to the "payment" EOA.
- The email's
.emlfile content is submitted to our custom prover and all private inputs constrains are checked. As output we obtain the address of the "payment" EOA and a hidden commitment of the user email. - The proof is then passed on-chain to the verifier contract along with the public outputs.
- If the verification succeeds the verifier contract itself will call the access controlled
SubsCryptMarketplace.initializeAccountto initialize the state of the EOA. The wallet is now ready to be funded.
-
The users knows the address of the wallet and is its his duty to add funds to it in order to trigger the first payment of the subscription. Privacy preserving funding methods can be used to completely anonymize the payments of the subscription.
-
After each period of
paymentIntervalthe bots will be incentivized to trigger the payment transactions mimicking an automatic execution of the payments. The payments can be triggered selectively in batches through calling theSubsCryptMarketplace.batchExecutePayments.
SubsCryptSmartAccountDelegate.sol: This contract manages the delegated smart account, enabling controlled fund withdrawals based on periodic payment intervals.SubsCryptMarketplace.sol: This contract facilitates the marketplace operations by handling service registration, account initialization, and automated batch payment executions.
A dedicated dashboard where service providers can efficiently manage and monitor their offered services.
This microservice handles email automation reception and executes the Vlayer prover and verifier logic calls to trigger subscription initialization.
This interface aggregates all marketplace services and provides an intuitive subscription flow for users to easily enroll with their chosen service providers.
Custom implementations of the email prover and verifier contracts, enabling on-chain validation of email proofs.
Prover inputs:
Prover outputs:
- Hash of the email to initialize the account
Email format:
- __AUTHORIZATION__<Authorization Tuple>__AUTHORIZATION__
- __SALT__<Salt to add randomness to the email>__SALT__
authorization tuple: [chain_id, address, nonce, y_parity, r, s]