-
Notifications
You must be signed in to change notification settings - Fork 5
Monetisation roadmap
Felipe Sant Ana edited this page Aug 31, 2018
·
2 revisions
Status
- Research.
Motivation
- Tries to leverage existing contracts in the ETH ecosystem, and avoid complicated integrations.
Description:
- In the Lab web app, there's a "Subscribe" button.
- When I click it, I see a modal telling me:
| Current subscribers: 8 | Next cut: 20 |
|---|---|
| At every new milestone, 50% of the amount sent by subscribers is randomly assigned to one of the subscribers in the last batch. | The amount of "tickets" one gets is proportional to the amount paid for the subscription / the total amount paid by all subscribers in the batch. |
| Desciber: Subscribers get an email twice a month w/ "the best 7" (TBD) videos in the site. | |
| Choose subscription price | |
| Send with Metamask |
- Prompt Metamask, send tx.
- Address join contract that tracks subscribers, we log his email.
- Send him the email through mailchimp every month, let the contract do its lottery magic.
- Keep one tab on the site to track stats, like:
| Bacth | Cut | Date Accomp. | Value subscribed | Distributed value |
|---|---|---|---|---|
| 1st batch | 10 subscribers | XX/XX/XXXX | Total value: 1 ETH | Distributed value: 0.5 ETH |
| 2nd batch | 20 subscribers | XX/XX/XXXX | Total value: 1.4 ETH | Distributed value: 0.7 ETH |
| 3rd batch | 40 subscribers | XX/XX/XXXX | Total value: 4.2 ETH | Distributed value: 2.1 ETH |
| 4th batch | 80 subscribers | XX/XX/XXXX | Total value: 12 ETH | Distributed value: 6 ETH |
| 5th batch | 200 subscribers | XX/XX/XXXX | Total value: 21 ETH | Distributed value: 10.5 ETH |
| 6th batch | 400 subscribers | XX/XX/XXXX | Total value: 48 ETH | Distributed value: 24 ETH |
| 7th batch | 800 subscribers | XX/XX/XXXX | Total value: 102 ETH | Distributed value: 51 ETH |
| 8th batch | 1500 subscribers | XX/XX/XXXX | Total value: 208 ETH | Distributed value: 104 ETH |
| 9th batch | 3000 subscribers | ? | Total value (so far): 690 ETH | Distributed value: ? |
Potential Problems:
- No one plays (not enough money in pool; not many people understand, does not pick up and dies) -> but we could kickstart it, and play wise on the numbers for the initial cuts.
- Somebody hacks it ("quadratic voting"-like scheme seems strong agains sybils, though?).
- We should probably add a minimum subscription price (like 0.1eth).
- And a rule like "if we fall to a previous batch, we'll have to cross to the one that was the next one to get "prizes" again.
Status
- Under consideration for a test with Around the Block.
Motivation
- Tries to combine "engagement w/ content" and practicality, once value transfer happens separately from the application, purely on chain. FOMO3d and cryptokitty as inspirations; could even run on YT vids. In the Portal dApp, we can activate an option on upload ("Engagement Games", instead of "Free"), and ask the guy to describe it on "description". Simple.
Description:
- I make a series of episodes. I hide "easter eggs" (purely visual, say) throughout it.
- There's N (precise number may be better) easter eggs. Not public if they are all on episode 3, spread out evenly, all on final episode...
- A contract is deployed and holds some ETH. You can get the ETH in it if you send a very specific tx to it - "proving you found an easter egg in the series".
- Watch each episode for free. If you think you found one easter egg, send a tx to a given contract, specifying in it the hash of the file (the episode), initial + final secondage (hr:min:sec) where the easter egg appears (note it's not just one value, but 2), and the first name of the person appearing on screen during the egg, or the last person to appear before it (entropy to possible solutions: filehash; initialSecondage; finalSecondage; name.
- Get it right: get ETH held by this contract. Get it wrong: your ETH stays in the contract, prize increases for next awardee.
- As a creator, placing these = balancing stimulus for ppl to keep watching VS not piss them off by not giving away anything (also, if you earn a fee on "prizes retrieved", you're interested in people actually retrieving ETH off the contract -> balance between easy and hard to find/claim)
- Creator can earn some (%) of the incomes on pot ala FoMo3D -> we must specify it.
- The funding can go on with more episodes, more engagement, and, potentially, more funding into the contract.
Potential Problems:
- No one plays (not enough money in pool; not many people understand, does not pick up and dies).
- Somebody hacks it (small space of solutions: costless to attack, need something in the orders of hundred millions of variants).
- Somebody wins too quickly (it's too easy to spot the easter eggs!).
- Takes too long to find the eggs, too much hidden, people start to believe they don't exist (we can prove there's a solution to the contract challenge, but not that's related to anything on the content itself).
Status
- Research.
Motivation
- Relatively implementable (a focused month to do it well?). Tests a powerful concept. Doesn't change UI or scope of the UI product, rather adds utility to it (increments the "special search result pages" (our proto-profiles, or proto-channels).
Description:
- Whenever someone searches for a keyword that matches a registered username (e.g. "felipether", or "ETH Global") or a category (e.g. "Opinion Makers", or "Documentaries" - these are still being made by us, manually on DB), the search result page shows a big title for the videos listed below, as if a channel name. The URL ...video/username should also leave to the same search result page (not implemented yet).
- Under this title, we can display a simple, fun one-line (<15 words) description of the category / username. Like, for "Opinion Makers" -> "Stop searching for the right answers. Meet those who make the right questions". (Eventually, one day, "Binance supports free speech and independent thinking.")
- We can start testing this only on the 6 categories made by us.
- Later stage, we add a field on the "Profile" tab, for registered users, under the username, and let them make their own phrase.
- Next to the phrase, on the search result, there's a button allowing anyone to bid on the phrase. The price follows a bonding curve, ETH is locked, and a portion of new ETH locked is distributed to contracts who previously "bought" the space.
- There's technically no need for modals/UI explaining steps of the interaction, on a first implementation, if there's a link to GitHub. Winning bid must carry phrase to be displayed
Potential Problems:
- Security, if working with real ETH.
- UX, still.
- We'd have to adapt code, show the wallet address to loginned users, assume security issues, ask people to fund it w/ real ETH (audacious) and re-enable the feature, to make it work.
Status
- Working on testnet.
Motivation
- Theoretical ease of trying.
Description:
- I open a wallet in the player and tip the creator of the video an amount of tokens (which we implemented) or ETH (which we could).
Potential Problems:
- Security, if working with real ETH.
- UX, still.
- We'd have to adapt code, show the wallet address to loginned users, assume security issues, ask people to fund it w/ real ETH (audacious) and re-enable the feature, to make it work.
Status
- Exploratory research.
Motivation
- Testing the concept of bonding curves for rewarding fans.
Description:
- On our portal web app, an education institution, for example, can sign up as a contributor. Then, decide to submit only videos that are "teasers" of longer-form material. These longer-form material are their courses. Hosted only on their proprietary servers / structure / service providers.
- Paratii can facilitate them selling dynamic-price access tokens to the content they are selling access to, elsewhere. In this case, we could have (1) "the portal as a teasing interface" (not really core need); (2) a templated contract for selling an NFT that can be used for access management, whose price varies on a curve, that distributes earnings to previous buyers, or whatever (this would be the core service).
- Challenge would be bridging (1) and (2). Mos primitive form could be a button alongside videos directing a user to an external environment to learn about prices and, eventually, make a tx to buy access.
- Verifying token ownership / giving out access could be done by the entity (educational institution, in this case) itself, or a trusted third party.
Partners who'd be willing to try out on their systems: Aerolito/Perestroika; Blockchain Academy; Mosaico University (can we just make token + marketplace, leave the "permissions" for the guys to tackle?).
Potential Problems: WIP
Status
- Research. See this paper, which summarises some research.
Motivation
- Generalising curation games to be able to provide aggregation, categorising, recommendation and attention allocations services more cheaply, for apps, than setting up own structure or outsourcing to cheap labor centres in the Phillipines, and to more efficiently employ a network of curators, across platforms.
Description: WIP
Potential Problems: WIP