Hey everyone, Jonathan from Delphi Labs here!
I’m very excited to present the second part of our Private Markets proposal to the community. In this part, as was mentioned in Part I, I will be exploring our proposed Private Markets framework.
If you prefer to watch a video walkthrough of the proposal you can do so on our portal.
Let’s dive in!
–
Introduction
In Part I of this post we covered our proposal for the high level architecture of Perpetual and how the Public Markets would work under this architecture. In this second part we’ll explore how Private Markets fit into this system. As a reminder, for the context of this piece, we refer to Private Markets as perpetuals markets that can be deployed on Perpetual Protocol in a permissionless way, in contrast to Public Markets, which are required to follow a regular governance process to be deployed.
High Level Architecture
The Private Markets architecture consists of 4 main components:
- Private Markets (PrM) DAO: The DAO that sits on top of all Private Markets. Only participants in the PERP DAO (sPERP holders) can join the PrM DAO. PrM DAO participants are entitled to fees generated by Private Markets (we’ll explore how this works more thoroughly in following sections) and act as the third tranche in case of a deficit event. While initially the PrM DAO will hold no governance power over Private Markets (as will be explored below), eventually as the Private Markets architecture matures we expect some governance powers to migrate to the PrM DAO. At first there will be only one PrM DAO as a proof of concept, but as the system matures we envision a multi-DAO architecture with different risk profiles, as will be explored in further detail below.
- Private Markets Insurance Fund: The native insurance fund that covers all Private Markets and will initially serve as the second tranche in case of a deficit event.
- Temporary Insurance Fund: An insurance fund that will be bootstrapped through PERP rewards during the initial stages of the Private Markets while the native insurance fund develops (we’ll explore the specifics in more detail in the following sections).
- Private Market: A perpetuals market created in a permissionless way by any user.
The following figure summarizes the above architecture.
Figure 1. Perpetual Protocol High Level Architecture.
Private Markets DAO
Any sPERP holder will be able to support and participate in the PrM system by staking their sPERP in the PrM DAO. Whenever a user stakes sPERP into the PrM DAO, the user will receive PrM DAO tokens, which represent the user’s share of the DAO. Any user who joins the PrM DAO will receive additional fees from activity facilitated by the Private Markets, while at the same time serving as the third tranche in case of a shortfall event.
For the Private Markets DAO, the PERP DAO will need to decide on a number of important parameters for the system to work as intended. The following is the list of parameters (all of which should be adjustable by governance) and some of our recommendations (see Figure 2):
- Private Markets DAO Cooldown Period: There should be a cooldown period that stakers in the PrM DAO need to wait before being able to withdraw their funds. This cooldown period is necessary to avoid the case where stakers withdraw their funds from the DAO immediately after a deficit takes place, potentially leaving the system at risk. For the system to be robust, funds staked into the DAO need to be a credible source of insurance in case of deficit events. We propose a cooldown period of 1 week.
- Maximum Slashing: Indicates the maximum share of staker funds that is at risk whenever a deficit happens. We propose initially setting the maximum slashing at 30%, same as for the Public Markets.
- Joining Fee: This fee acts as a tax levied on every user joining the PrM DAO that is distributed to all previous stakers in proportion to their PrM token holdings. The objective of this fee is to incentivize early and long-term oriented staking. We suggest that this fee is set at 2.5% initially.
Private Markets Insurance Fund
Ideally, the IF should be able to cover all deficit events by itself, without the system needing to use PrM DAO funds. To this end, the IF should have a target size based on the risk the protocol is taking. To determine this target we suggest following a similar methodology to the one explored in Part I of this post for Public Markets:
- A Target Insurance Ratio is defined. This parameter is measured in the same way as for the Public Markets, where:
Given that we expect the Private Markets to be composed (in aggregate) of riskier assets than the Public Markets, we suggest setting a higher Target Insurance Ratio than for Private Markets. We believe this would give an additional margin of safety to users of Private Markets. Having said that, as is the case with Public Markets, this parameter should be adjustable by governance as the model evolves over time and empiric data can be gathered about its performance.
Based on this target, the fees flow within the Private Markets architecture would be adjusted as follows. If the Insurance Ratio is below the Target, the majority of fees should flow to the IF. Otherwise, fees should be redirected to stakers as that would indicate that the IF is large enough given the current level of risk within Private Markets. The specifics behind the fees flow mechanism will be explored in further detail below.
Temporary Insurance Fund (TIF)
Given that initially the Private Markets Insurance Fund will hold no funds, we suggest creating a Temporary Insurance Fund where any user is able to provide assets that act as the first tranche in case of a protocol deficit in return for rewards in the form of PERP. This mechanism would help bootstrap an insurance fund for Private Markets while the native Private Markets Insurance Fund develops over time. Concretely, we see the Temporary Insurance Fund working as follows:
-
Any user will be able to provide yUSDC to the Temporary Insurance Fund. Assets in this insurance fund serve as the first tranche in case of a shortfall event.
-
There should be a cooldown period that depositors need to wait before being able to withdraw their funds from the TIF. The rationale for this is the same as for stakers in the PrM DAO. We propose this cooldown period to be 1 week.
-
In return for their risk-taking, stakers will continuously receive PERP rewards according to a schedule decided by the DAO. This rewards schedule should be periodically monitored and adjusted when needed in order to:
-
Increase rewards whenever the TIF is undercollateralized.
-
Decrease rewards whenever the TIF is overcollateralized.
To decide whether the TIF is over or undercollateralized, the methodology explored in the previous section should be used. However, given that the TIF is also backing the Private Markets, the Insurance Ratio should be calculated as follows:
If the above ratio deviates considerably from the target defined in the previous section, the DAO should consider adjusting the rewards.
- As the native insurance fund gets built over time via protocol fees, the Temporary Insurance Fund should be gradually wound down. From a rewards perspective, this means that even though over the short term PERP rewards could fluctuate depending on changes in trader activity on the Private Markets, over the long run the trend should be of diminishing PERP rewards.
Private Markets Governance
While we believe in the long run the PrM DAO should have governance power over some of the parameters that regulate Private Markets, initially we think that right should belong to the PERP DAO. The main rationale behind this is that the cost of bootstrapping the TIF will be shared among all PERP holders, not only PrM DAO participants. Eventually, as the Private Markets architecture matures and its native insurance fund gets more robust, some governance functions could be gradually transferred to the PrM DAO.
Private Markets Creation
We developed a simple process to determine which assets would be initially whitelisted for Private Market creation. This is necessary given that not every asset can or should have a perpetuals market. For example, an asset with no oracle or an unreliable oracle cannot have a well functioning perpetuals market by definition. Thus, we use this process to set a minimum set of requirements an asset needs to meet to be whitelisted. We think that this approach will allow for the number of assets listed on Perpetual Protocol to increase considerably while at the same time protecting users as the Private Markets architecture is tested out.
Over time, this whitelisting process could be gradually stripped down to its bare minimum (i.e. whitelisting every asset with a reliable oracle) as the Private Markets model matures. Initially, though, we prefer to be conservative and prioritize user safety. To this end, the conditions for an asset to be whitelisted would be the following:
- Having a Chainlink or Uniswap oracle.
- Having an average 24hr volume traded over the past 90 days higher than $10M.
- Having an audit.
Notice that the above whitelisting process doesn’t imply that the system is permissioned, as any user will be able to create a market for any whitelisted asset in a permissionless manner. Furthermore, the initial whitelisting process should be broad enough such that at launch a significant number of assets are available for Private Market creation.
From a UX perspective, a prospective market creator should be able to browse or search through a list of previously whitelisted assets and create or initialize a market for any of those assets in a few clicks. To this end, it is important that the whitelisting process be done periodically and thoroughly by the PERP DAO or a specialized team assigned to this task. After a market has been initialized, any user will be able to provide liquidity for that market.
Fees Flow
For the Private Markets we propose a similar fees flow mechanism as for the Public Markets (see Figure 2). Specifically, 80% of fees will flow to the IF in USDC whenever the Insurance Ratio is below the Target (otherwise IF fees flow to DAO stakers), 10% will flow to PrM DAO stakers in the form of sPERP and 10% will flow to the PERP DAO in the form of PERP. Notice that the TIF will not be receiving any fees from the Private Markets, as stakers into the TIF will be receiving PERP rewards.
The following figure summarizes the above mechanism.
Figure 2. Private Markets Fees Flow.
Multi-DAO Private Markets
While initially we propose implementing the system with a single PrM DAO that covers all initially whitelisted Private Markets, eventually we envision the architecture evolving into a multi-DAO system where each PrM DAO covers a particular group of markets that fall within a certain risk profile (or that expose certain characteristics). To better understand this, imagine a hypothetical scenario where Private Markets are grouped in 5 risk tranches, 1 being the safest and 5 being the riskiest. Within this system, sPERP holders would have the ability to stake to different tranches according to their risk appetite. This could be applied to the TIF as well, such that TIF depositors could choose the risk level they’re comfortable insuring.
In addition to allowing stakers and TIF depositors to choose the risk level they’re comfortable with, this architecture will allow the DAO to define different parameters for different groups of markets. Parameters such as trading fees, the fee split between LPs and the Protocol and the Target Insurance Ratio could be tailored to specific tranches.
We suggest implementing this multi-DAO architecture in phases. Following the hypothetical scenario above, we would suggest starting with tranche 1, which would be basically the single DAO model described above and gradually add new tranches as the system matures.
Figure 3. Multi-DAO Architecture Example.
Conclusion
Throughout this piece we explored our proposal for the Private Markets implementation within Perpetual Protocol. We expect this architecture to allow Perpetual Protocol to considerably expand its asset offering, with a limited risk exposure to the protocol as a whole. Coupled with the Public Markets architecture explored in Part I of this post, we believe this overall structure will serve as a robust foundation for Perpetual Protocol to grow in the years to come.
We’re very excited to present this to the community and look forward to your feedback regarding this post.