xGov-116: Subscription Payments

Governance xGov Proposals
,
1

id: 111

title: Subscription Payments

author: krby.algo (@kylebeee)

company_name: Akita

category: dApps

focus_area: Defi

open_source: Yes

amount_requested: 50000

status: Final

Abstract

Subscription payments are a common feature across most industries and are essential to bridging the rest of the world to Algorand. We’re building a first class subscription system & platform that will bring the next generation of recurring payment rails to Algorand. In a multitude of ways, our smart contract design streamlines control, accessibility and management of subscriptions for both businesses and end users on Algorand. With version 1.0 of the contracts already written; Akita is looking to build out the UI interfaces and expand on their functionality (More details below in the Roadmap section). These contracts will serve both businesses on Algorand via Javascript SDKs and the Akita creator subscription platform.

Team

Krby (https://twitter.com/kylebeeeee) has been a full time software engineer for over 7 years and has been spending his evenings building Akita for the better part of the last 2 years following the original dev teams departure. He’s built a number of massive features for the Akita community including a staking platform, discord payment & verification bot (integrated with NFD’s), Yoink Ball (an in person king of the hill game utilizing Freeze & Clawback) and a permissionless Community spec (ARC-53).

Experience with Algorand

For nearly the last 2 years Krby has been spending his evenings building on Algorand. From writing PyTeal smart contracts to building the base components of a longer term vision; a social platform built ontop of Algorand, NFDs, subscriptions & the community page spec. To date he’s delivered an astounding amount of value to the Algorand / Akita community and has been the driving force behind the growth of the Akita platform:

  • The most flexible staking platform on Algorand

  • A discord bot that enables payments, verification, and more

  • Yoink Ball, an in person game of king of the hill utilizing Freeze & Clawback

  • A permissionless community spec that enables NFT and project exploration with some of the best UX on Algorand

  • A shuffle system for Akita Omnigems where the NFTs have no data attached to them before sale

Present Proposal

The features for version 1 include:

  • Automated Recurring payments:

  • any token

  • any interval

  • any amount

  • Merchant Offerings

  • e.g. Offer an Akita Pro subscription for 100 AKTA a month and verify onchain that the user’s subscription is active

  • Address Banning

  • Family Plans ( up to 5 on a single subscription )

We are working to build out the subscription contract triggering service required to make payments seamless & automatic for end users as well as interfaces for end users to subscribe to one another, create offerings, manage subscribers, ban lists and more.

Future Blueprint

Milestone 2: SDKs

Time Taken: 2 months

Amount: 50000

Description:

  • Javascript SDK for building txns to create & interact with the subscription contracts

  • Go SDKs for tracking & triggering payments

Milestone 3: Price Pinning

Time Taken: 1 months

Amount: 50000

Description:

  • Price pinning for subscriptions, we’ll integrate with a price oracle to pay x token in y token value

  • e.g. pay $10 USDC worth of ALGO every month

Milestone 4: Automatic Contract Calls

Time Taken: 3 months

Amount: 50000

Description:

  • subscription contract calls

  • e.g. swap $10 USDC worth of ALGO for AKTA every month via tinyman

Benefits for the community

Subscription contracts have huge convenience features for the community like supporting your favorite NFT creators on a regular basis without having to remember to do so. Royalties often fall short of being sustainable for creators to continue to pursue their passion and build on the Algorand blockchain. These contracts will open up a new avenue for creators, projects & businesses alike to increase sustainability and establish recurring revenue.

Additional information

How it Works:

A user ‘mints’ a subscription either to a ‘Merchant Offering’ or with whatever parameters they’d like (recipients address, token, amount, interval). The subscription acts as an escrow with the intial payment going through immediately. The contract charges a 4% fee with 0.5% going to the account that triggers the payment during a valid payment window. Payments are automated and will be triggered by a scheduling program that watches the chain for valid payment windows. As long as the subscription escrow has the funds to disperse to the merchant the payment can be triggered by anyone ( during the valid window ) and at any time the end user can delete the contract to return whatever funds are escrowed back. We decided to use an escrow system as opposed to delegated logic signatures because it was clear our ecosystem wallets are hesitant to support them due to the risks they create. Over time the escrow design grew on us because it offers more control to the user for little trade off.

Simplified diagram (https://cdn.akita.community/diagrams/subscriptions_simplified.png).

5 Likes
2

In a world where many feel subscription fatigue and there are apps built to help people get rid of subscriptions, can you help me understand the user demand for a subscription model that requires fronting a larger sum of money and yet still involves recurring payments?

As a buyer of such a subscription it would feel to me like this approach combines the downsides of paying yearly and paying monthly.

2 Likes
3

Hey Silent, thanks for your question.

This doesn’t require a larger sum of money upfront, you can pay as little as the subscription amount when you subscribe, it would just mean that you’d need to add more funds to the escrow before the next payment is due or the merchant may lock you out of whatever service you’re paying them for.

As the subscriber you’re in complete control of the funds in the escrow so the amount of runway you want to leave there is up to you and you can get it back at anytime.

Initially the design was just dealing with the constraints that delegated signatures weren’t supported by our ecosystems wallets but the it grew on me over time.

In web2 subscriptions it’s the equivalent of opening your wallet for a vendor and letting them pull the money you owe them, they’re even free to change the price on you. With this system payments must be for the agreed upon amount and since you only give the contract a certain amount of runway at a time you’re far less likely to continue paying for a subscription that you don’t use and don’t value.

With the abstract accounts work i’ve been doing there will be subscription plugins in the future so users will definitely get the option to decide what degree of control they want over the subscription; dedicated escrow or main wallet.

I believe we strongly need easy access for creators to create subscriptions and build recurring revenue for themselves. Most NFT projects are forced to continually release new collections or find other more convoluted paths for monetization.

While subscription fatigue is common, i see huge potential for subscriptions with specific tokens that carry different meaning within their context of usage.

Tldr;

  • self sovereign control over the escrow & payment amount
  • Auto expiring subscriptions so you don’t accidentally pay for services you aren’t using.
  • Single place to manage all subscriptions
  • Different tokens for different kinds of subscriptions
1 Like
4

OK, I didn’t understand that the escrow might get “refilled” by the buyer on a recurring basis to avoid needing to place a larger lump sum in escrow in advance.

If I’m a buyer, how do I manage these refills? I can see that this model gives buyers more control; however, and also gives them the responsibility to manage topping up the escrow. How will this be made painless for buyers?

1 Like
5

Refills can be as easy as sending more of the payment token into the escrow, you’ll also be able to manage it in the akita app.

Im a fan of the additional control but to make it painless we’d need to use abstracted accounts or get wallets to support delegated sigs.

1 Like
6

I think this needs to exist.

sustainability needs to be the number one goal for anything that isn’t being pitched as a public good, and a tool like this would give many creators a very traditional option to make scaling a business possible.

Nice work!

3 Likes
7

This sounds fantastic- am I understanding it right that something like a blockchain Patreon equivalent could be built out using the sdk? As well as automatically gifting discord roles, etc? Or would these sorts of integrations be part of the build itself?

1 Like
8

how does it compare to Subtopia that is already on mainnet developed my MakerX and audited?

2 Likes
9

Hey Rach!

Yes! That is the exact plan for this system, anyone would be able to use the sdk’s for that purpose but separately I’ll be integrating that functionality into the Akita platform

1 Like
10

Hey Lobo,

I’ve spoken a bit with the creator of Subtopia, as i understand it their product is not for recurring payments.

With my contracts an escrow account is created per subscription and funds are dispersed automatically to the merchant at the interval set; whereas Subtopia is a credit based validator. You pay upfront and you can verify on chain how much credit is left for the user.

1 Like
11

One more question Krby, sorry. Would there be an escrow wallet for every single subscription? Or would it be more like a “credit card wallet” that you can sign up to multiple subscriptions from? (I don’t know the coding side of it all, the the latter would be a far more comfortable system in terms of onboarding and use I imagine)

1 Like
12

Right now its one escrow per subscription and it only exists until the subscription is cancelled. The abstracted account version could certainly be setup more like a “credit card wallet”.

1 Like
13

I’m really excited to see how it all develops!

1 Like