ppTranche

We created a general module that splits the volatility of any assets with oracles, which allows us to create novel defi products such as capital-efficient synths and yield markets.

Comment

Inspiration

We search for a general module that compartmentalizes volatility for any asset/underlying pair that has an oracle. Such a module exhibits versatility and allows the construction of a wide array of functionalities, such as creation of capital-efficient synthetic instruments(think off-chain bonds!), risk tranching, or markets for yield.

1.Existing synthetic instruments backed by censorship-resistant(crypto) collateral are usually debt-based. The prevailing systems necessitate over-collateralization, which does not scale in accordance with its demand. Also, these mechanisms require external liquidators to babysit system solvency which is empirically proven to fail during times of high market volatility. In addition, liquidation incentivization in the form of premiums serves to be an unnecessary, undesired value transfer from synths minters to miners/validators. We address these problems by formulating the synth-minting process as equivalent to merely swapping the asset to a cash-secured put of a given asset/underlying pair.

  1. Given the current context of the rise of consensus tokens' staking derivatives, the market would demand a product that allows participants to easily find a counterparty to speculate, hedge/lock-in, leverage, and amplify the yields generated from these variable staking rewards. Moreover, our system can leverage the composability of ERC4626s to enable these tranching functionalities for any yield-bearing instruments.

What it does

For any given asset/underlying pair that realizes volatility(and with an existing oracle), a tranche instance can be permissionlessly created such that the system takes in an asset and splits it into a junior and senior token. Based on oracle feeds, these senior/junior tokens are continuously priced such that the senior token represents a share of a fixed rate of returns for asset/underlying while the junior token represents a pro-rata share of the remaining assets after all seniors have redeemed. A user can mint a senior(junior) by simply a) splitting the asset to senior + junior token and b) swapping the remaining junior(senior) to the senior(junior) token in an AMM(that has a senior/junior liquidity pool)

Interesting examples:
For synthetic asset generation, an example asset could be stETH, and an example underlying CPI(consumer price index) or tradi-fi bonds denominated in USD. In this instance, for every senior (synthetic CPI or bonds) minted, the system requires a counterparty that mints juniors (leverage long token) for stETH/CPI. Since the yield for CPI/USD can be covered by the ETH staking reward, the leveraged long token would be a interest free leveraged position for ETH/USD, and CPI or bond minters would essentially be able to earn L1 staking rewards on their USD without being exposed to ETH beta. The system remains solvent by requiring these CPI holders to purchase stETH when ETH/USD goes below a certain price(hence the cash-secured put analogy). Similarly, the system can scale by requiring the leverage ETH/USD holders to sell to CPI when ETH/USD goes above a certain price. Note that minting this CPI or leverage ETH long token can simply be abstracted as a process of selling stETH to CPI/leverage ETH long(instead of collateralized borrowing), and CPI minters are forced to buy ETH rather than sell at low prices. No value is leaked as liquidation incentives.

For yield asset tranching, an example asset would be stETH, and the example underlying ETH. In this instance, for every senior(fixed rate) stETH/ETH minted, the system requires a counterparty that mints a junior(leveraged/variable rate) stETH/ETH. An example usage flow is illustrated for each of these agents, a) A stETH holder can amplify her yield by splitting her stETH and providing liquidity into this senior stETH/ junior stETH pool and collecting fees. b) A stETH holder who wants fixed, protected returns can mint a senior stETH token c) A stETH holder who wants leveraged rates can mint a junior stETH d) A stETH holder who speculates the variable rates of stETH to rise can repeat the following process: mint junior stETH, use it as collateral to borrow senior stETH, and sell it to junior stETH. Vice versa for speculating rates decrease.

How we built it

The system requires price feeds for asset/underlying pairs. If no direct oracle exists for a given pair, it can be inferred by oracles for asset/middle_ground and underlying/middle_ground. As such, the system would rely on high quality off chain data if the underlying does not exist on chain.

Challenges we ran into

1.Exploring the design space of AMMs for swapping senior<->junior pairs. Each designs has its trade-offs, and is suited for different asset/underlying. We implemented two types of trading modules: a) Purely oracle based AMMs Pros: No pool value lost to arbitraguers. Ease of implementation. Cons: Assumes accurate/reliable oracles with low latency. Low predictability of LP rewards. When price of junior/senior is predictable(such as always mean reverting), liquidity pool can be drained by traders. Suited for: junior/senior pairs where oracles are reliable and price of junior/senior is not predictable.

b) Liquidity sensitive AMMs This resembles a UniV3 AMM, so the process of providing liquidity and collecting fees would be familiar to Defi users. Pros: Does not rely on oracles. Cons: Pool value lost to arbitraguers. Since the AMM is path independent, Lp rewards are more predictable. Suited for: junior/senior pairs where oracles are not reliable and price of junior/senior exhibits high mean reversion(such as variable yield rates).

  1. Alligining interests of different parties Finding the right balance of incentives for liquidity providers, tranche traders, and arbitrageurs is a difficult and an ongoing problem. For example, in the case where the senior tokens is a CPI, it's supply would scale with the amount of willing counterparties that would leverage long. In an liquidity sentive AMM, this counterparty can be arbitraguers incentivized that can hedge in external markets, but in naive oracle AMMs, the demand for leverage needs to be organic, which might not be sufficient in certain market regimes. One solution to this problem is allowing some slippage to incur from the CPI minters, where value captured by the pool from this slippage can be used to incentivize arbitrageurs to take the opposite side(analogous to a funding rate mechanism). Another might be adjusting the price of junior/senior such that it subsidizes restoring to a balanced pool reserve ratio, and penalizes a trade that does not.

  2. Finding and removing attack surfaces Some well documented attack surfaces that the system is subseptible to would be oracle manipulations and frontrunning. However, there exists various defense mechanisms for these attacks which can be built upon.

Accomplishments that we're proud of

Building a working prototype that guarantees solvency from first principles.

What we learned

Details and nuances when building financial products(in the context of blockchains).

What's next for Untitled

-incentives for balancing AMM pool reserves -oracle hacks defense -IL loss scales when junior price is low and leverage is high, and fix too much leverage when junior price is low -sufficient counterparty for leverage longs when arbitrage is not an incentive -finding and removing other various plausible attacks -better user experience and interface

Built With

Share this project:

Updates