Joystream / Joystream/joystream

Design subscriptions pallet

Open
#4,099 3 comments 0 reactions 0 assignees View on GitHub
post-mainnet question runtime
Dominant language
Rust
Stars
1.4k
Forks
116
PR merge metrics
No merged PRs in 30d

Description

# Background

Subscriptions are a key monetization primitive for creators, and it's power comes from the ability to generate revenue streams with greater levels of predictability than per content (ads, transactional) monetization, and also doing price discrimination. I have looked around a bit, and I actually not found anyone who have designed on-chain subscriptions in a scaleable way, without introducing trust in off-chain entities.

# Challenge

Propose a design for an on-chain subscriptions pallet which

- scales in the number of publishers.
- scales in the number of subscribers.
- scales in the number of subscriptions.
- scales in the number of subscriptions per publisher.
- allows multiple (active) subscriptions per subscriber, but does not need to scale, but also nice if possible.
- allows each publisher to set a custom $JOY price per period, but period length can be universal.
- allows each publisher to update $JOY period price going forward.
- allows efficient verification, both off and on-chain, of whether a given subscription is currently active/valid.
- allows both publisher and subscriber to act (on-chain) rarely, or at least only have to act subject to well known time limits, while remaining safe,. The ideal UX for everyone is the way normal web2/banking subscriptions work, but that is unlikely to be perfectly feasible.
- $JOY platform fee on value captured by publisher.

The key here is that the runtime cannot iterate over any of these sets, as they need to be unbounded. Payments are in the native asset ($JOY), so assume it can be minted and burned. A first best approach would not introduce any new complex cryptography, and not any trusted off-chain actors. Its probably a good idea to do a deeper review of what other people have tried, just to make sure I did not miss anything obvious.

_Note: probably worth applying for W3F grant if a good design is prepared._

# Resources

- https://eips.ethereum.org/EIPS/eip-1337
- https://docs.superfluid.finance/superfluid/v
- https://unlock-protocol.com/

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.