Verse Protocol Data Room

Prediction markets let you make bets on whether or not a particular world-state will come into being. "Verse" or "Verse Protocol" is a novel financial primitive that lets you trade on second, third, or higher-order consequences of those world-states in an isolated alternate timeline where that world-state has already happened.

What is Multiverse Finance?

Verse is the practical implementation of a concept originally sketched out by Dave White of Paradigm. You can read his original proposal here, but I'll also summarize it briefly here.

The kernel of inspiration for Multiverse Finance is the idea that pure Arrow-Debreu securities (contracts which pay out 1 dollar given 1 world-state and zero in all others, such as a "YES" bet on Polymarket) are awkward financial instruments. White gives the example of using those "YES" tokens as collateral for a loan of ETH: since the price of these contracts can near-instantly drop to zero, your collateral could become worthless faster than you could be liquidated… but what if that ETH that you were loaned became worthless at the same time? If the conditionality applied across your financial strategy, then there wouldn't be any problems.

This is the key intuition for understanding Multiverse Finance. When you take a bet on a platform like Polymarket, you are effectively buying "yesUSDC". It is problematic to have that conditional USDC interact with non-conditional assets. Multiverse Finance proposes that your "yesUSDC" should only ever interact with "yesETH" or "yesGOOG" or "yesGOLD". The protocols those assets interact with are yesSwap, yesLoans, yesInsurance, et cetera — and this is the novel mechanic unlocked. Not just singular conditional assets, but whole conditional financial worlds. White calls these worlds "Verses" and that is where this project gets its name.

Before outlining some of the possibilities and implications of Verse as a financial primitive, a quick high-level explanation of how the protocol is actually implemented. This is where we depart from the abstract purity of White's original sketch and get into the grit of actually implementing it.

Consider the following diagram:

Diagram 1

At its core, Verse is about creating partitions. We define a "partition" as some axis along which you can divide the set of all possible future world-states in any given verse (note that the "real world" is a verse like any other in this conception). Each partition has a set of possible outcomes, and these are the "verses". In order to be valid, this set of outcomes must be disjoint (their resolution conditions must not overlap) and their union must be equivalent to the complete set of possible outcomes in the parent verse.

In practice, each partition is a wrapper contract. You deposit some USDC (for example) into the condition A partition, and it gives you some "Yes A USDC" and "No A USDC". These wrapped assets "live inside" of their verses, and are redeemable for the original asset if any only if the condition for that verse is met. White calls this pushing down an asset.

This is pretty interesting on its own, but the real magic of Verse is that it permits sub-partitions. In the same way you can establish a partition of the real world, you can establish a partition off an already partitioned verse! In the diagram you can see how by declaring a sub-partition for "Condition B" off of the two possible verses created by the "Condition A" we now have verses that account for every possible configuration of the outcomes for these conditions. Imagine nesting this a few layers deeper, or using partitions with combinatorial outcomes (this just means there are more than two possible resolution conditions, such as candidates in an election), and you start to see how powerful this can be.

As the resolution conditions are met, the tree will be "pruned" since it is no longer possible for verses or their child verses to ever become real. If the resolution condition for "Yes A" is met and consequently "No A" is pruned, then it also prunes all of the child verses in partitions coming off that verse.

The last important thing to understand is that each verse comes loaded with its own set of DeFi primitives that are contained to the verse. Conditional assets only ever interact with other assets that are in the same verse (and consequently have the same set of conditions). Note that this kind of strong quarantine is not necessarily going to hold true in perpetuity, as is discussed in the strategy section of this document. Some of the most interesting possible directions from the protocol are downstream of selectively breaking this quarantine, but it has to be done carefully to avoid compromising the entire point of the project.

Unlike a prediction market, where you simply make flat directional bets on the first order outcomes of a particular world-state ("Will X happen? Who will win Y?"), Verse allows you to make bets on the higher-order outcomes of these world-states. If you believe that X happening means that the price of some asset will rise, you can make that trade in the YES verse, and do nothing at all (or take the opposite trade) in the NO verse.

For a more poetic gloss on the product itself: Verse lets you trade with information from the future, since in the environment where you're making your trades, the specified set of resolution conditions are guaranteed to happen. If they don't, then the branch gets pruned… it's like it never happened.

Implementing Multiverse Finance: Hypermap and the Verse Namespace

One of the key challenges identified in White's original sketch is the need for an onchain data structure called a "multiverse map" that keeps track of all the conditional verses, their resolution conditions, and facilitates the flow of assets through them. Conveniently, I've been working with a robust and production-ready onchain primitive called Hypermap for the past year and half in my tenure as Head of Product at Hyperware. You can read more about Hypermap in the Hyperware whitepaper (specifically sections 2 and 7), but in short:

Hypermap is an onchain hierarchical namespace, designed to solve the PKI (public key infrastructure) problem that naturally comes up when working on a project with p2p networking like Hyperware. It also attempted to generalize this pattern: networking keys are not the only thing that could be useful in a p2p environment. This design requirement put in place before I joined the team is very fortunate to me now, as it led to a number of features that make Hypermap useful for implementing Verse.

Hypermap "entries" are standard ERC-721 NFTs that can have onchain metadata attached to them (either mutable or immutable), can mint "sub-entries" underneath them, and each entry has a ERC-6551 token bound account (TBA) associated with it. These TBAs, which are analogous to the increasingly popular "smart accounts" found elsewhere, can have custom account implementations which allow them to be used for any kind of onchain action. This feature specifically is what makes Hypermap ideal to implement Verse.

To illustrate how Hypermap allows for a practical implementation of Multiverse Finance, I'll reproduce the diagram earlier, but now specifically as a reflection of the onchain implementation. Here I'm using the example from White's blogpost of one condition to do with the outcome of an election, and another to do with a recession:

Diagram 2

The ".verse" is the root entry of the Verse protocol namespace. In Hypermap parlance, this is a "top level zone" or TLZ. This sets the rules for the entire namespace underneath it. For Verse specifically, you can think of the TLZ as representing the real world.

Underneath ".verse" you can mint entries that represent partitions, such as "election.verse". This namespace entry uses the PartitionTBA account implementation, which makes it a wrapper contract for ingesting assets and then minting wrapped versions of them to each outcome verse. The outcome verses are automatically minted upon initializing a PartitionTBA based on whatever input parameters are desirable (thus far I've only implemented yes and no outcomes, but there's no technical obstacle to allowing combinatorial outcomes), and so we end up with two more entries: "yes.election.verse" and "no.election.verse" that use the VerseTBA account implementation.

Because each entry has a wallet of its own, it can do things like own or mint dedicated instances of DeFi protocols on a per-verse basis, or manage the redemption of the conditional tokens, or keep track of wallet whitelisting, or any other thing that might prove pertinent. Naturally, VerseTBA also allows for a sub-entry to be minted with the PartitionTBA underneath it (creating something like "recession.yes.election.verse"). This is how we can manage infinite sub-partitions and create the rich "multiverse" environment.

Each "PartitionTBA" contract has a function that allows you to declare a "winning" verse (the verse whose outcome became real for a given partition), which then allows you to call the redeem function: if you hold an wrapped version of an asset pertaining to a specific verse, you can redeem it for the underlying (note that this doesn't necessarily mean you were the one who originally sent it into the partition).

There are some more protocol-level considerations that require some experimentation, but the main idea that needed derisking is "you can effectively use Hypermap as an expressive multiverse map", which has already already been done.

Video Demo

Go To Market and Long-Term Strategy

Long-term, I view Verse as belonging to the family of protocols that take themselves very seriously, without all the token shenanigans that plague this industry. Large firms, financial or otherwise, will use Verse for hedging, to position themselves optimally ahead of time, and to otherwise exploit interesting possible trades that can be made if you have some angle on a particular outcome. Not particularly decentralized, and resembling more of a traditional exchange or trading venue business. I expect that soon the United States will have passed the much-anticipated "market structure bill" and with it there will be a viable path towards the tokenization of major US equities and commodities. These kinds of assets, simple but unimpeachable twins of their real-world counterparts, are what I'm most interested in getting wrapped into Verse.

However, this precludes certain design decisions that might be seen as standard for an onchain/protocol project. It's difficult to imagine that some form of KYC wouldn't be required, or that you could have a venue where serious assets are traded under the purview of token governance. This restriction is unfortunate, because launching a token (or even just hinting at launching a token) is such a powerful accelerant for early-stage companies operating in this space. So I won't rule it out. In any case, this decision is heavily contingent on a developing regulatory landscape, and it doesn't change my immediate plans.

The goal is that within 90 days we can begin a rapid release cycle, giving the public access to a series of timely handpicked Verse namespace trees (which is to say, a set of partitions) with resolutions 4 to 6 weeks out. Once those get resolved, we'll kick off a new set. Each cycle will present a new series of verses and some new features for the protocol as we explore what works best, discarding some things and keeping others. The target audience here will be "crypto early adopter" types, who are motivated by a points program and enjoy trading the kinds of vaporous crypto-assets that we'd have no qualms about wrapping into the protocol. They will be trading real money.

Specifically, we want to be experimenting with mechanics that break some of the "purity" of the protocol. Applications (or just interfaces) that allow for cross-verse interaction, the ability to sell off a single asset + resolution path pair "early", the early-exit mechanism proposed by White, privileging the dollar as unit of account to allow liquidity providers to go directly to a high-activity verses, et cetera.

The purpose of this staggered release strategy is to get to a point where we know what works best across the board: what primitives are necessary for market makers, what quarantine-breaking features tend to be problematic, which are exciting. What kind of UI makes sense for navigating the multiverse map. After a few rounds of testing and hopefully getting people excited, I'll be able to make a more firm decision about how to proceed as we cut a proper, more "permanent" release.

Contact