$1b Ribbon Theta Vault

Ribbon has grown the adoption of on-chain option markets almost entirely by themselves, using the assumption that **set-and-forget** strategies which rely on sustainable yield (theta) will capture more users than the prospect of active participation in these option markets.

**Perpetual-izing** time-based option strategies has made the Theta vaults a competitive place for capital, even when compared against massive apy (misleading...) yield farms.

This ethos and strategy is certainly the best way to grow adoption of crypto structured products, so how can we make it even better?

## Build Vaults for More Tokens and Scale TVL using RMM protocol

Right now, Ribbon matches vault depositors to call option buyers. Therefore:

**More Deposits = More Problems**

The vault can only support the capacity of buyers, so as vault deposits grow, it gets more difficult to maximize utilization unless buyer capacity grows with it.

A **$1b Ribbon Theta Vault** is possible using **Primitive RMM** pools.

This is because of a fundamental property of RMM pools, the same with any AMM:

**More Deposits = More Yield**

As the pool grows in size the arbitrage opportunities grow along with it, meaning the fee income to keep the pool rebalanced also grows.

The sell options to buyer model is also limited by buyer's capacity for different tokens! RMM protocol makes Theta Vaults for any token possible since pools can be created for any token pair.

**Theta Vaults** built using **RMM** can scale to massive TVL and more markets, all while relying on decentralized architecture.

# Proposing Theta Vault on Primitive RMM Pools

A Theta Vault that deposits to selected RMM-01 pools will give Ribbon users access to **higher yields** and structured products for **more tokens**.

Here is how in three steps.

## 1. Replace Process, Scale TVL

Right now, the process for Ribbon's Theta Vault strategy is **3 steps**.

![](https://i.imgur.com/slcEC5l.png)

#### Note: old diagram, but same process that is now decentralized through auctions

### Replace process by depositing to RMM

Using Primitive's RMM protocol, a constant function market maker, this can be **reduced** to **1 step**:

1. Theta Vault mints RMM-01 LP tokens
   a. The manager selects an RMM LPT to mint based on the parameters strike price, expiry, implied volatility, and swap fee.
   b. Vault uses deposited funds to allocate liquidity into the Primitive RMM pool
   c. Vault holds onto RMM LP tokens

The net result of this process is that the Vaults should **receive swap fees over time, expected to be equal to the option premium**. This will mean the Vault's balance will expand over time as swap fees of RMM are generated and compounded into the LP token.

### How does it work?

RMM protocol is a two-token [Constant Function Market Maker](https://web.stanford.edu/\~guillean/papers/constant_function_amms.pdf). This means the two tokens of the pool can be swapped, generating trading fees for liquidity providers. Therefore, Ribbon Theta Vault depositors would be the liquidity providers.

**More liquidity in RMM = More Trading Fees**

As a pool's liquidity grows, large trades have lower price impact, therefore capturing more trading flow and thus trading fees.

### Where does theta come from in this CFMM?

The trading function of RMM is designed to **capture theta through swap fees**. Read the whitepaper to learn more: [whitepaper](https://github.com/primitivefinance/rmm-research).

## 2. Optimize Parameter Selection

Theta vaults follow the strategy of selling one-week call options that are deep out of the money (OTM). Here is a concrete example for a prospective RMM pool as a place to put Theta vault deposits:

![Example](https://images.mirror-media.xyz/publication-images/AKP5LgJ3V_120dXMuXFpn.png?height=79&width=311)

The current price of ETH is about **$4000**. With these parameters, this particular RMM LPT is currently valued at \~0.913 ETH \* 4000 + 275 = $3,927. In one week (expiration), there are two di

https://mirror.xyz/XUtGuUBPkh0UIHNVd1XglC79gtjJeUPwBGha64aePww

Tokenless AMM

###### tags: `alex-blog`

As the year ends, I spend my weekends writing long romantic letters to my accountant explaining the process of minting an NFT, [fractionalizing](https://fractional.art/) it into a million tokens, and market making it across multiple AMMs.

One of the more nuanced interactions is how liquidity providing is treated from a tax perspective, and how it impacts a trader's profit.

All regimes may treat it differently, but notably in the U.S. and Germany, adding and removing liquidity is equivalent to buying and selling a token. The implications are far reaching, as they directly impact the overall return of liquidity positions on AMMs.

Sparked by a tweet from [Gabriel Shapiro](!%5B%5D(https://i.imgur.com/4iTXnzW.png)), I am going to explain how a *tokenless* AMM could be built using [Primitive](https://primitive.finance).

![great](https://i.imgur.com/CTtWFPr.png)

### Quick Note

There will be two instances that moves tokens, depositing and withdrawing, creating taxable events. Ideally, these two instances will be spread out long enough to not incur short-term capital gains tax (if in the U.S.), with lots of return optimizing activity between (that does not touch tokens).

## From the perspective of the tokenless AMM smart contract

### Step 1: Accept deposits of one token.

The "pure" smart contract will need to take deposits from a user, denominated in ideally a single token like USDC or ETH. This balance will then be used in an *ethereal* sense, i.e. it will only be converted back to the token on withdrawal.

### Step 2: Deposit into the Primitive Engine contract’s internal balances

Each token pair has its own Primitive Engine smart contract deployed, which AMM pools can then be created for. Tokens for that pair can be deposited in advance, crediting an internal account to be used for any future actions, i.e. adding liquidity or swapping. This can be done atomically as well, so a user's initial deposit is combined with this internal balance deposit.

### Step 3: Manage liquidity positions entirely using internal balances

The user can choose how they want to update their position: remove from one pool, add it to another, or zap into a new one. It would be possible to do this without ever moving tokens if its pools in the same pair! The state changes, not the tokens.

If it were pools from different pairs, the "pure" smart contract would swap tokens into a common denominator asset, like USDC, then deposit into the internal balance of the other pair. From there, the internal balances can be used to do the same actions.

### Step 4: Extend features to use other composable protocols

One clear example would be getting leverage on internal balances. Originally explored in this smart contract repository: [v1-cross-margin-spec](https://github.com/primitivefinance/v1-cross-margin-spec), using internal balances as collateral to gain access to more internal balances is something in reach! There are many levels of complexity for this, but a cool idea is to net out collateral requirements using active liquidity positions.

### Step 5: Extend features to other ecosystems

Another example is adding collateral to a Maker vault, and rather than minting Dai, it mints a Primitive internal balance of Dai, making it available to be provided as liquidity. This would allow the collateral to be monetized through AMM swap fees, without ever touching the Dai directly.

### Open Question

Does this actually avoid some of the tax pitfalls of LP tokens? What else can be improved at the smart contract level to mitigate tax obligations?

### Conclusion

It's extremely exciting to explore yield optimizing strategies. The ideas outlined here don't exist yet! To implement it, I recommend you read the [Primitive introduction post on mirror](https://mirror.xyz/mirror.primitive.eth/l5F1BLMhfmcm_B1R2w-by003_oiAz2-Ir_Jj_rCvGCs).

tags: alex-blog

tags: `alex-blog`