ppTranche

New system design that allows a) liquidation-free and capital-efficient synthetic assets b) markets where people can speculate and hedge variable yields.

Comment 1

Inspiration

We search for a general and simple module that compartmentalizes volatility for any asset/underlying pair that has an oracle. Such a module would exhibit the versatility that allows the construction of a wide array of functionalities, such as the creation of capital-efficient synthetic instruments(think off-chain bonds!), risk tranching, liquidation-free credit lines, 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 while liquidation incentives are unnecessary and 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. Instead of inefficient and discounted liquidations, lenders would earn yield until their bids(of asset denominated in underlying) are filled.

  2. 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 staking rewards that are variable by nature.

The canonical stable coin trilemma can be generalized to the trilemma of on-chain synthetic assets. While this trilemma can't be ignored, we aim to create a system closer to its efficient frontier in the axis of being backed by censorship-resistant collateral and increased scalability,

How it works

For any given asset/underlying pair that realizes volatility(and with an existing oracle), a tranche instance can be 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. When the price of junior denominated in underlying falls to a certain level, the system can remain solvent by a) devaluing senior tokens b) minting more junior tokens, and c) allowing senior holders to redeem these newly minted junior tokens.

Some example user flows:

  1. A user can mint a senior and earn fixed, protected returns by simply a) splitting the asset to senior + junior token and b) swapping the remaining junior to the senior token in an AMM (which has senior/junior liquidity).

  2. A user can mint a junior and gain leveraged exposure on asset/underlying by a) splitting the asset to senior + junior token and b) swapping the remaining senior to the junior token in the same AMM.

  3. A user can provide asset as liquidity in the junior/senior AMM to gain trading fees.

  4. When the senior token is programmed to realize 0 volatility with respect to its asset/underlying price(e.g a stablecoin for underlying), a user can borrow with asset as collateral by a) splitting the asset to senior + junior token and b) thereby receiving the senior token amount as her credit, while the junior token absorbs all volatility.

Example products:
For synthetic asset generation, an example asset could be stNEAR, and an example underlying CPI(consumer price index) or trad-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 stNEAR/CPI, and vice versa. These counterparties are sourced from AMM liquidity providers, who earn fees and can hedge excess beta from external exchanges. Since the yield for CPI/USD can be covered by the Near staking reward, the leveraged long token would be an interest-free leveraged position for Near/USD, and CPI or bond minters would essentially be able to earn L1 staking rewards on their USD without being exposed to the market. The system remains solvent by requiring these CPI holders to purchase stNEAR when Near/USD goes below a certain price(hence the cash-secured put analogy). Similarly, the system can scale by requiring the leverage Near/USD holders to sell to CPI when Near/USD goes above a certain price. Note that minting this CPI can simply be abstracted as a process of selling stNEAR to CPI (instead of collateralized borrowing), and CPI minters are forced to buy Near rather than sell at low prices. No value is leaked to liquidators.

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

How we built it

We built with Aurora. Here is the address of the factory contract deployed on the testnet: 0xE6537Ee620FFa188a183D98BB76f9862053d0Cb8

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. For the demo, we used oracles from Flux Protocol for reading asset prices on the aurora testnet.

Challenges we ran into

  1. Exploring the design space of AMMs for swapping senior<->junior pairs. Each design 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. Since the AMM is path-independent, Lp rewards are more predictable.

Cons: Pool value lost to arbitraguers. Also, there is no direct path of arbitrage since the system only accepts senior+junior pairs for redemption to stay solvent, so have to implement a new promise-based arbitrage mechanism.

Suited for: junior/senior pairs where oracles are not reliable and price of junior/senior exhibits high predictability and/or mean reversion(such as variable yield rates).

  1. Aligning interests of different parties Finding the right balance of incentives for liquidity providers, tranche traders, and arbitrageurs is a difficult problem. For example, in the case where the senior token is a CPI, it's supply would scale with the amount of counterparties that would leverage long. In an liquidity sentive AMM, this counterparty can be arbitraguers incentivized via spreads that can hedge in external markets, but in naive oracle AMMs, the net 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(one that we've implemented) would 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. This is analogous to increasing or decreasing interest rates on CDP positions.

  2. Finding and removing attack surfaces Some well-documented attack surfaces that the system is susceptible to are 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 ppTranche

-perhaps better incentives for balancing AMM pool reserves and protecting LPs -integrating robust oracles and implementing various oracle-based defense mechanisms -finding and removing other various plausible attacks -better and easier user experience and interface -more extensive testing

Mathematical/system design/mechanisms details are outlined in the whitepaper link

Built With

Share this project:

Updates