Managing Renewals

So you can create a subscription, deposit and withdraw funds, and renew/expire. But...

1. Who invokes renewals?

2. How do they find which subscriptions to renew?

Who invokes renewals?

The answer to this is simple, but will make more sense with context provided by the second question. And remember, anyone can call the renew instruction on the program.

Two groups of people are incentivized to enforce Buoyant's renewal mechanism: products using subscriptions, and public markets.

Products that use subscriptions rely on the renewal mechanism for the functionality of their product and their source of revenue, so product builders can enforce renewals themselves.

Upon renewal, a small portion of the amount being transferred is paid to the caller, and on expiry rent is withdrawn from the subscription metadata account and the deposit vault. This incentivizes anyone in the general public to enforce renewals as it's passive income with a low barrier for entry.

How do they find which subscriptions to renew?

Short answer: by the power of PDAs on Solana.

If you don't know what PDAs are, briefly, they're accounts without private keys that allow for a hashmap lookup of addresses/storage and enable programs to sign instructions. Read more about them here, here, or here.

Because of the PDA scheme of subscription metadata accounts, the only information you need to find a particular subscription's address is the payee, amount, duration, and its index.

Each time a new subscription is initialized, a count is incremented. This count is stored in a separate account with a similar seed scheme. The newly initialized account's index is just the count at the time, so the first subscription of that type has index 0, the second has index 1, and so on.

PDA seed schemes are outlined here:

pageBuilding on Buoyant

With all this information, you're able to find not just one but all subscriptions of this type, and trigger renewals for all of them. The builders of a product will have chosen the necessary parameters to identify a subscription type and therefore will be able to easily find the accounts to renew.

But what if you aren't the one building the product? Or if you are building the product, what if you don't want the reliability of your subscription renewals to be centralized to your own crank?

Subscription Registry

People who want to run renewals for subscriptions for other products need some place to find subscriptions to renew. Products that want public markets to enforce their renewals need a place to publish their subscription parameters. Solution: an on-chain subscription registry.

As a part of the Buoyant protocol, the program will include a function to add your subscription type to an on-chain subscription registry. The registry acts as an append-only list of subscription types. As a product, you can simply call this instruction to add your subscription type, and as a renewal maintainer you now have easy access to subscriptions to renew.