EXP-0003: Application Subscriptions

Table of Contents

• Application Subscriptions are needed for the next generation of crypto products.
• Live Demo
  • 1. Initialize an Account
  • 2. Mint some experimental tokens
  • 3. Start a Subscription
• I like this! How does this work?
• Conclusion
• Links

Application Subscriptions are needed for the next generation of crypto products.

There are many use cases where a user would want to allow a third party to perform actions on their behalf:

• Subscriptions to content (e.g. paid newsletters, subscribing to the New Yorker, etc.)
• DeFi actions (e.g. yield rebalancing, dollar cost averaging, and payment streaming)
• AI agents & Telegram bots (e.g. copytrading, memecoin trading, and complex DeFi strategies)
• NFT drops sniping (e.g. automated minting for time-sensitive drops)
• Improved UX through server-executed recurring transactions without constant user interaction

Building products around these use-cases is challenging because Ethereum wallets don’t natively support any features around delegation of actions with tight policies to ensure security. As a workaround, many products will use centralized services, which may compromise the security of the user’s funds.

In this experiment, we show how Porto, our next-generation Ethereum account SDK empowers, developers to build such products, by delegating actions to a server with smart contract-enforced policies to ensure security.

Click through the live demo below, or check out the end-to-end example repository to learn more.

Live Demo

In this demo, we will create an account, delegate access to it to a server (in our case, a Cloudflare Worker), and schedule a recurring transaction to be executed on-chain. This demo generalizes to any client-server setup and all of the above use-cases.

We provide everything step-by-step so you can follow along. In production, you can collapse all of these steps into a single button / function call.

You can click the “Raw Response” button in each step to see what the API responses looks like.

1. Initialize an Account.

If this is your first time seeing an Ithaca experiment, click “Register” to create a new account, else click “Sign In” to sign into an existing account you’ve previously created.

Make sure to try out EXP-0001 and EXP-0002!

2. Mint some experimental tokens.

Now that you have an account, it’s time to mint some tokens for the purpose of this experiment. The tokens are valueless and are only used to demonstrate the delegation of on-chain actions.

Click “Mint 100 EXP” below!

3. Start a Subscription.

Now that you have an account and tokens, we will start a subscription, which is composed of 3 steps abstracted into a single step:

1. Request a key from the server. This is an off-chain action and costs $0.
2. Grant permissions to the server. This adds the above generated server key to the account. This is an onchain action and costs few cents in production.
3. Start a subscription. This is an onchain action and costs few cents in production.

Security Note: For this demo, the server does not encrypt the private key before storage. This approach is not recommended for production environments.

To reset the demo and start again, clear your browser’s local storage and refresh the page, or use a private/incognito window.

We are aware that this demo does not show to the user what they are signing over or what permissions they are giving to the session key. We have exciting updates for addressing the blind signing problem, which are work in progress. You can preview them at playground.porto.sh, and we will have more to share soon.

Congratulations! You’ve just created a subscription using Porto!

I like this! How does this work?

We present below a high-level overview of the delegation process.

Using Porto, the delegation process follows these steps:

1. The user initializes an account, either creating a new one or signing into an existing one.
2. The user requests a unique key from the server, which will be used for server-delegated actions.
3. The server generates a random P256 key pair, encrypts the private key with the public key for secure storage, and returns the public key to the user.
4. The user uses the public key to authorize the server by calling experimental_grantPermissions with specific permissions and limits.
5. The user sends a delegation request (a scheduled transaction) to the server, along with any required transaction parameters and a schedule.
6. The server securely stores the request information and executes the transaction at the specified time.

We have designed experimental_grantPermissions as an alternative to the draft ERC-7715: Grant Permissions API specification, with a more scoped API. We also leverage ERC-7836: Wallet Call Preparation API to prepare and send transactions on behalf of the user.

type Request = {
  method: 'experimental_grantPermissions',
  params: [{
    // .. snip

    // Permissions to grant.
    permissions: {
      // Call permissions.
      calls: {
        // Function signature or 4-byte selector.
        signature?: string
        // Authorized target address.
        to?: `0x${string}`
      }[],
      
      // Spend permissions.
      spend: {
        // Spending limit (in wei) per period.
        limit: `0x${string}`,
        // Period of the spend limit.
        period: 'minute' | 'hour' | 'day' | 'week' | 'month' | 'year'
        // ERC20 token to set the limit on. 
        // If not provided, the limit will be set on the native token (e.g. ETH).
        token?: `0x${string}`
      }[]
      // ERC-1271 verification permissions.
      signatureVerification?: {
        // Authorized contract addresses that can call the
        // account's ERC-1271 `isValidSignature` function.
        addresses: readonly `0x${string}`[]
      },
    },
  }]
}

The experimental_grantPermissions call provides an API for granular control over delegated actions via permission rules. Consumers of the experimental_grantPermissions call are required to specify at least one spend limit and at least one scoped call.

We are very excited by how powerful yet simple this API is, and plan to contribute concepts from this implementation
back into the standardization process.

Conclusion

We think that Application Subscriptions is a missing piece in enabling the next generation of crypto applications across DeFi, consumer applications, and frontier explorations with new interfaces.

This experiment demonstrates a simple application of delegating permissions to a server, showcasing how a user can authorize a server to execute transactions on their behalf with specific limitations.

If you liked this experiment, you can fork our end-to-end example repository as a starting point and build your own applications such as:

• Automating payments for content subscriptions.
• DeFi yield rebalancing and dollar cost averaging bots.
• Integrating with AI Agent frameworks.
• Secure Telegram bots.
• NFT minting bots.

We are hiring excellent engineers to help us build the next generation of crypto applications at Ithaca. If you build something cool, reach out to join@ithaca.xyz to tell us about it!

Links

• Porto
• Client/Server Demo Playground
• End-to-end Example GitHub Repository