Related Projects

SCENARIO shares some design principles with Polymarket and Augur (and with decentralised prediction markets generally) in that these protocols make use of real-world, off-chain occurrences in on-chain or semi-on-chain use-cases. Prediction markets like those listed allow their users (or in some cases, the people behind the platform), to create markets such as will Argentina win the 2026 World Cup?, with other users then able to buy or sell either side of that market’s binary yes/no position at fluctuating prices determined by market activity.

Good examples of current work on prediction markets are found in the Gnosis Conditional Token Framework (CTF) in combination with UMA's Optimistic Oracle (which is discussed in more detail shortly). Gnosis’ conditional tokens represent defined outcomes which, when coupled with the UMA (Universal Market access) optimistic oracle, allow for these conditional outcomes to be resolved and for prediction market payouts to be made – a mechanism upon which Polymarket’s service is built.

Importantly, in the case of SCENARIO, rather than asking users to predict or bet on whether X will occur, the protocol is focused solely on the question: Has X occurred? In this way, SCENARIO deals with a more basic primitive than prediction markets, which instead seek to combine the wisdom of the crowd with market forces to price future events and form predictions about their probabilities. SCENARIO’s focus on a simpler, post-event, yes/no distinction means that it is not burdened by needing to price markets or manage pay-outs that are based on event likelihoods or user wagers.

A further project that shares some common ground with SCENARIO is earni.fi, which allows users to connect their Ethereum public address with their email address in order to receive emails when they have new airdrops to claim. As was noted in Purpose, this type of service is currently centralised, is focused almost completely on airdrops, and does not allow users to create their own bespoke notification requests.

Another notification-focused protocol is Push App. As explained in its white paper, Push App (formerly called EPNS, or ‘Ethereum Push Notification Service’) was the first ever notification protocol for web 3. Push App differs from SCENARIO in several ways, with the most important being that Push is channel-based. Users are encouraged to opt in or subscribe to channels so that they can receive notifications, with these channels needing first to have been created by developers of Push (or other projects) for the purpose of pushing out updates to their users and community members.

In this way, Push App subscriptions operate somewhat like a Discord push notification in instances where a user has joined a Discord channel and opted in for notifications. The ‘Future Features’ section in the protocol’s current white paper does not indicate any plans to allow the application to facilitate bespoke, user-requested notifications, nor does it include any scope for decentralised triggering or verification of notification events.

SCENARIO’s underlying mechanism may have the most common ground with decentralised oracle services such as Chainlink and UMA’s Optimistic Oracle, both of which focus on confirming the occurrence (or nature) of off-chain events in a way that is trustless and highly secure for use in on-chain smart contracts. However, SCENARIO differs from both of these protocols in several ways.

Unlike Chainlink, SCENARIO allows any user to both create and confirm event/oracle parameters permissionlessly and at any time. SCENARIO deals only with one-off ‘trigger-yes’ events (rather than ongoing oracle services such as Chainlink’s price-feeds), and instead of being built with the explicit intention of providing oracle data for a host of other applications, SCENARIO is designed to have a narrower primary focus (notifications) with the potential for these to lead to possible oracle uses in time.

Importantly, SCENARIO’s focus on paid notifications as its key initial use-case means that it has a path to sustainably generate revenue and data outputs without needing to rely on future demand for oracle-style use cases as a revenue driver (though these use-cases may still develop with time). In other words, SCENARIO’s underlying data driver is people’s desire for notifications, rather than people’s desire for data. This is expected to generate a wider range of data types in a more agile and retail-driven manner.

SCENARIO also differs from UMA’s optimistic oracle (OO) in crucial ways. Though the UMA OO model does allow for users (usually developers of other protocols such as prediction markets) to ask for bespoke oracle outputs that are verified by other users, as its name suggests, the UMA OO assumes that its actors are behaving honestly. For this reason, UMA’s OO requires only one actor to mark an event as having occurred, with there then being the possibility of dispute by other ecosystem participants if needed. SCENARIO places a greater emphasis on having high confidence at the verification stage by virtue of allowing for a wider set of verifying participants.

As is the case with Chainlink, notification use-cases do not yet appear to feature in any current or future plans for UMA’s oracle outputs. Further, due to the fact that UMA’s OO is used primarily to power financialised applications for trading, bridging, synthetic assets and prediction markets, almost all of its oracle data requestors are developers and applications rather than retail users. This is another area in which SCENARIO distinguishes itself from other projects; its data requesters and data generators will comprise a varied network of individual actors and retail participants, all of whom will be free to generate idiosyncratic and hugely varying event parameters.

SCENARIO’s front-end user experience will be designed to ensure that it is easy, useful and enjoyable for anyone to act as both an asker and a confirmer, driving more data creation and notification outputs as a result.

Informed by aspects of the above projects, SCENARIO is positioned to fill a market gap and offer a useful new primitive by having a clear focus on being the first fully open and tailorable decentralised notification service.