Primitive’s focus is to build innovative products oriented around Automated Market Makers (AMMs) and their evolving role in decentralized finance (DeFi). These tools improve the experience of using AMMs and enable users to leverage this new class of financial instruments effectively.

Making AMMs More Accessible

AMMs are a type of decentralized exchange that enables anyone to participate as a market maker. Market making on AMMs allows users to extract revenue from transaction fees on orders that flow through the exchange. AMMs are essential to the DeFi ecosystem and allow anyone to bootstrap financial markets without participation from professional market-making firms.

Primitive will use our Series A funding to build products that make discovering popular AMM liquidity pools and strategies easier, powered by a new protocol and suite of DeFi development tools. For those curious but unfamiliar with AMMs, Primitive offers educational materials that empower users to broaden their understanding of DeFi.

“Over the past two years, we have realized that we can broaden DeFi’s adoption by focusing on user experience and creating easy-to-use tools for new and veteran crypto users alike,” said Angel, Founder and Chief Executive Officer of Primitive.

“Primitive offers advanced financial products and market-making strategies while retaining the elegance and simplicity of automated liquidity provision,” said Alex Evans at Bain Capital Crypto. “We are excited to work with the excellent Primitive team as they broaden access to powerful crypto-native financial instruments.”

Primitive is Hiring

Today, the Primitive team is led by Angel, Zach Thielemann and Matt Czernik. The team includes twelve skilled individuals with unique expertise in smart contracts, mathematics, cryptography and design to identify demands in the market and build simple products that meet those demands. The company is currently expanding its NYC-based and globally remote teams. To learn more and apply, visit https://jobs.primitive.xyz.

Learn More

Primitive builds powerful infrastructure and innovative products in DeFi. Our team is committed to supporting the next generation of crypto users through education and simplified interfaces, and our research and development are driven by intention and integrity. Join the Primitive community on Discord and Twitter, and learn more about Primitive at https://primitive.xyz/.

Liquidity providers (LPs) can use the Primitive RMM-01 protocol to create portfolios that express directional views with respect to asset prices. Setting an out of the money (OTM) strike implies an expectation of positive market movement while setting an in the money (ITM) strike implies expectation of negative market movement. Implied volatility (IV) and time to maturity parameters describe the dynamic behavior of concentrated liquidity. 

The key insight is that the directional view that LPs derive from their parameter selections can be used to provide dynamic concentrated liquidity adapted to market conditions. In contrast, Uniswap LPs cannot specify a market direction due to the symmetric behavior of the pricing function. While RMM-01 pools have dynamic concentrated liquidity based on the initial Black-Scholes parameter selection, Uniswap V3 concentrated liquidity is static and does not adjust to changing market conditions.

This article analyzes the performance for a recent ETH/USDC pool created on July 5, 2022 and expired July 10, 2022. Pool profitability hinges on setting parameters that accurately describe the direction and behavior of the market. The efficacy of dynamically concentrated liquidity distributions are analyzed by the statistical kernel density estimate (KDE) tool. Code can be found in this jupyter notebook, and can be easily modified to analyze any other RMM-01 pool.

Pool Parameters

The parameters set by a recently expired ETH/USDC pool were defined as:

Strike price: 1255 USDC

Implied volatility: 77%

Time to maturity: 5 days

Initial reported price: 1107 USDC

By selecting a 1255 USDC strike price, which is higher than the initial reported price, we can discern that the liquidity was provided to this pool with the expectation of a positive price movement.  Setting the IV and time to maturity parameters tell the Black-Scholes equation how much volatility should be priced in and what the underlying volatility of the pool composition will be. Ideally, a pool composition that oscillates around a 50/50 split is the best outcome and is the most effective if liquidity can be dynamically concentrated around this split. 

Directional LP Performance

We compared performance to a static portfolio equal to the composition of pooled assets at creation. While the static portfolio appreciated 12.249%, the RMM-01 replicating portfolio appreciated 12.596%, outperforming the static portfolio by over .3% as shown in the below chart. Unlike Uniswap pools, there is no impermanent loss from the upside gains of specifying an accurate liquidity direction on RMM-01.

We calculated realized volatility based on the ETH reported price in the chart below. The first half of the pool duration had an average volatility of 79% and swap volume of 541,472 USDC. In the second half, average volatility fell to 18% while swap volume increased to 783,097 USDC. Realized volatility followed IV more closely in the first half compared to the second half.

There were a total of 44 swaps routed through the pool that accounted for a total swap volume of 1,324,570 USDC. Total swap fees collected were 6,224 USDC and 5.8594 ETH for a total value of 13,548 USDC. Swaps on this pool represent 36% of all time swap volume and 12.6% of total swaps across all RMM-01 pools. Comparing volume with IV, more swap volume occurred when realized volatility was lower than IV. This means that the liquidity depth from the concentrated liquidity was thicker at the end of the pool than at the beginning because it facilitated more swap volume with less realized volatility, but less dynamic because the IV parameter didn’t accurately describe realized volatility.

The chart below shows how the replicating portfolio composition shifted from the original 690 ETH and 79,623 USDC to 756 ETH and 41.83 USDC. Although the pool composition shifted almost entirely to ETH, since the payoff function is being replicated by Black-Scholes, the riskiness of the different pool compositions remains the same.

As the reported price converged towards the strike price, the replicating portfolio composition approached a 50/50 split. However, the reported price ultimately did not end above the strike price, so the replicating portfolio composition shifted towards nearly 100% ETH. If the reported price had ended above the strike price, the replicating portfolio composition would have shifted towards 100% USDC.

Analysis of Dynamically Concentrated Liquidity Distributions

To measure dynamically concentrated liquidity, we use a KDE to estimate various liquidity distributions and illustrate how liquidity dynamically concentrates over time. By observing the peaks in the chart below, we can see that liquidity was most concentrated when the pool was composed of 15% USDC and 80% ETH. There was not a large overlap where ETH/USDC reserves oscillated around 50/50. This implies liquidity could have been better dynamically concentrated.

Creating another KDE on the swap distributions, we can see that swapping USDC to ETH had a very tight range compared to swapping ETH to USDC. If the terminal-reported price ended above the strike price, the portfolio composition would have become more USDC heavy, allowing a larger dynamic range for the USDC liquidity to be deployed. 

The liquidity efficiency measures the percent of the portfolio reserve used for market making. ETH to USDC swaps saw levels of usage around 5% of USDC reserves. USDC to ETH had a much larger usage, around 10-20% of ETH reserves. This means that liquidity was more dynamically concentrated around ETH reserves.

Conclusion

In conclusion, we visually analyzed how this RMM-01 pool behaved. We saw how RMM-01 pools could be used for directional LPing and analyzed the results of having dynamically concentrated liquidity distributions. This pool was initialized with parameters that roughly predicted the direction of the market. However, the implied volatility parameter caused looser concentrated liquidity ranges, decreasing the efficacy of the dynamically concentrated liquidity. Further research will explore optimization of the IV parameter behavior on liquidity depth and the effect dynamically concentrated liquidity has on concentrated liquidity bounds in general.

On the RMM-01 protocol, nearly 80% of users were identified as suspects in Sybil attacks. In response, Primitive developed a straightforward method for detecting and filtering these users. While Primitive uses this tool to remove noise that Sybil attacks impose on user data, other DeFi protocols can expand the open-source code to suit a large array of their own needs.

What is a Sybil attack?

DeFi protocols commonly use airdrops as a method to launch tokens. This method rewards early users of the protocol by "airdropping," or giving, the users free tokens. Sybil attacks can be initiated to exploit airdrops in DeFi protocols.

The term "Sybil attack" originates from the main character in "Sybil" by Flora Rheta Schreiber. The book details a case study of a young girl who is thought to have Dissociative Identity Disorder. It was later revealed that the entire story was a ruse and Shirley Mason, the woman who inspired the character of Sybil, fabricated the different identities. In a Sybil attack, an entity generates a large quantity of pseudo-anonymous identities, akin to Sybil's multiple personalities in the book, to obtain a large influence over a network.

A common example of a Sybil attack is when a user, in anticipation of an airdrop, generates a large number of addresses, then deposits and removes tiny amounts of value from a DeFi protocol. This is referred to as "airdrop farming," and is often facilitated algorithmically. Protocol developers look down upon airdrop farming because their goal is to reward engaged and authentic users; not bots.

Sybil attacks on the RMM-01 protocol

Upon launching the RMM-01 protocol, the Primitive team set up a monitoring infrastructure to notify us when users add and remove liquidity. As the Total Value Locked (TVL) grew, we noticed a large quantity of the notifications were for very small amounts of liquidity that were almost immediately removed after they were added. The large volume of small transactions indicated that Liquidity Providers (LPs) were Sybil-ing the protocol in anticipation of an airdrop.

The noise from the Sybil attacks made it difficult to analyze the authentic user activity on the RMM-01 protocol. We realized the need to filter accounts that orchestrated Sybil attacks so that we could gain a more accurate understanding of the value that users derived from the protocol. After the accounts associated with Sybil attacks were filtered out, our data better reflected the activity of our unique users.

The script that we built in response to Sybil attacks serves as a tool for more accurately quantifying authentic users. At Primitive, we use the information derived from this process to better inform data-driven decisions and improve the RMM-01 protocol experience for our users. The script is fairly agnostic, so it can benefit other DeFi protocols in the same ways that it does RMM-01, or it can be extended to fit a wide array of needs for protocol developers.

Open-source method to filter Sybil attackers

In response to Sybil attacks on the RMM-01 protocol, the Primitive team has identified a straightforward methodology for compiling lists of addresses associated with Sybil attacks. Once this list is generated, the associated addresses can be blacklisted and disregarded.

The methodology and the corresponding detection scripts are open-source and can be found here. This approach is ideal because anyone can use a small script on relevant contracts for their benefit. The script is configured by entering your ETHERSCAN_API key and CONTRACT_TO_LOOK_AT in a .env file.

The script queries a contract's transactions using the Etherscan API and compiles a list of addresses that interacted with the configured contract. Then, the script filters out transactions where no value was exchanged (such as token approvals). After this, the cost of the transaction is checked by multiplying the user's cumulativeGasUsed by gasPrice. If the cost of the transaction is greater than the value of the transaction, the script adds this address to an array of Sybil suspects.

Future work

There are many ways to make this script more robust. One approach is to query all transactions from the Sybil suspects and check if they are a collection of deposits with the same value. This is a clear indication that the Sybil suspect's address is farming airdrops.

*Disclaimer: Primitive does not have a token or plans to release a token.

Written by 0xJepsen

As the Primitive team prepares to launch the new, fully audited RMM Protocol smart contracts, we want to remind all of Primitive's early users to revoke any outstanding approvals for those vulnerable contracts made between December 2020 and February 2021. Those contracts are non-upgradeable, which means the only action possible must come from the user.

Users who interacted with the Alpha Primitive V1 protocol between December 01, 2020 - February 22, 2021 should revoke all approvals immediately for these contracts (1) and (2).

This is a fairly common vulnerability which makes it even more important for every user to be aware of proper approval management. Approvals should be exact instead of infinite, or revoked after users are finished with using a protocol.

Here are some valuable resources to learn more about the approval related vulnerabilities:

• https://primitivefinance.medium.com/postmortem-on-the-primitive-finance-whitehack-of-february-21st-2021-17446c0f3122

• https://dydx.exchange/blog/deposit-proxy-post-mortem

• https://medium.com/zapper-protocol/post-mortem-sushiswap-uniswap-v2-zap-out-exploit-84e5d34603f0

• https://etherscan.io/tokenapprovalchecker

• https://v1.primitive.finance/reset

What addresses are vulnerable?

We made a public Dune query that is available here, which displays the vulnerable addresses.

We've identified 11 active infinite approvals for either WETH or DAI. We have confirmed three of these vulnerable addresses have received our messages and will take action to revoke approvals. Three of the remaining addresses are inactive, with no transactions after interacting with the Primitive V1 Protocol and no tokens or ether. This leaves five addresses, two of which hold more than $1K worth of value. All of these 11 addresses have been contacted by the security.primitive.eth account through Etherscan's blockscan chat feature.

While no tokens are at risk now, if WETH or DAI are transferred to these addresses with the approvals, they immediately become at risk.

These vulnerable addresses made the approvals over a year ago, and while we have brought the list down from 100 to just 8 through continuous monitoring and contact attempts, these 8 open approvals can still put a significant amount of funds at risk if WETH or DAI are transferred to them.

Going forward

These contracts deployed in 2020 and early 2021 were experimental and in an alpha stage. The Primitive team has learned from this incident, which is why all smart contracts are audited at least twice by professional 3rd party security firms.

Infinite token approvals are permanent until they are revoked. DeFi moves very quickly, with new projects launching daily. Token approvals can quickly be forgotten about and linger—in this case for over a year. After using a new protocol, we highly recommend revoking approvals to keep your tokens safe.

Contact us

These are the dedicated security channels for contacting Primitive:

• Send a message on Etherscan's blockscan chat to security.primitive.eth

• Email security@primitive.finance

• Send a message to the Primitive Twitter account: https://twitter.com/PrimitiveFi

Highlight of the Week!

• Primitive's first discord and spaces town hall had over 250 listening to the team discuss the RMM Primer and Soulbound NFT. The twitter space was recorded here and the discord call audio will be uploaded soon (it's pinned in the discord).

Primitive Team

• RMM Primer was published on Tuesday, the first in a series of educational manuals for using the protocol. Read it here.

• Soulbound NFT concept was published on github. The initial implementation by Alex is the starting point for developing this novel mechanism.

• Trail of Bits began the review of the fixes on the rmm-core smart contracts.

• Product team integrated support for native Ether into the app.

From the Community

• 0xMin wrote a tweet thread mentioning Primitive is a way to improve the liquidity of options in DeFi.

• 0xPerp wrote a notes summary of Primitive's first town hall!

• L wrote an interesting tweet thread on replicating vanilla call options using RMMs + Squeeth.

Next week - February 13

• Soulbound NFT Updates.

• Launch is on the horizon 🚢.

How to Get on Primitive Weekly

• Connect us with an artist to make nice art for these weekly posts - or all the posts we have!

• Write a tweet thread mentioning the @primitivefi twitter handle.

• Write an article that mentions Primitive or RMM protocol.

• Open issues or pull requests on the open source repositories that fix typos, bugs, or to suggest features.

• Join the team part or full time and make contributions.

Primitive Replicating Market Maker ("RMM") is a supply source for tokens and option derivatives*. Existing as a free, unchangeable, and unowned protocol, RMM is the purest form of decentralized infrastructure.

Anyone has the freedom to provide capital to the RMM pools and earn fees, providing a service of filling the other side of token trades, and eventually option trades. There are no gatekeepers, no pausing (i.e. circuit breakers), and markets run 24/7.

By the end of this primer, you will have a better understanding of using the protocol to hedge risk or take advantage of time-based strategies as a market participant. There are concrete example scenarios to help you grasp the different nuances present in the protocol.

Read more to learn about the primitive behind the magic.

*Replicated option derivative payoffs, not option contracts. "In layman’s terms, replication is four fives for a twenty: they behave exactly the same (they’re each worth twenty dollars), but they look completely different (one is four pieces of paper, the other is one piece of paper)". There are no promises the payoffs will be received.

Decentralized Exchanges are Liquidity Sources

This primer assumes a basic knowledge about decentralized exchanges, token trading, and popular protocols like Uniswap, Curve, and Balancer. Token trading is the most fundamental backbone to decentralized finance - enabling more markets like lending and derivatives.

Dex Volume 2019 - 2022

Without knowing anything about these protocols in the chart, it goes far to know that the majority of them rely on the same "idea", and together they make up almost all of the token trading activity on Ethereum.

This section is a brief overview on how these dexes work and how they can be used for token and option trading.

How to Make a Decentralized Exchange

Trading curves of different protocols

Constant Function Market Maker ("CFMM") based decentralized exchanges (e.g. Uniswap, Curve, Balancer) facilitate the lion's share of on-chain token trading volumes. The success of CFMMs as spot markets can be attributed to several crucial properties that they all share: ability to support any token pairs, high degree of capital efficiency, predictable behavior, and a relatively straightforward user experience. At a high level, CFMMs facilitate trades between two counterparties, "traders" (users that swap one token for another) and "liquidity providers" (users that make their tokens available for trades to earn fees).

Constant Function Market Maker Trading

Trading in a Primitive RMM Pool

Buyers

Traders are users that own one token (e.g. ETH) and demand another (e.g. USDC). Traders swap assets on a CFMM by sending transactions specifying some amount of tokens for other tokens, less a small fee. The average price a trader pays is dependent on both the ratio and amount of tokens in the pool prior to the swap (e.g. 100ETH/100,000USDC), the trade size (smaller swaps beget a better average price), and the trading function (we'll get to this later).

Suppliers

On the other side of this trade are the liquidity providers. Liquidity providers add two tokens to a liquidity pool contract. This liquidity contract accepts transactions swapping from token A to token B and token B to token A. Whenever traders execute swaps from either direction, liquidity providers collect fees proportionally based on their provided tokens compared to the total tokens in the pool.

Market Making

From a high level, tokens are made available by market participants to be the other side of trades for users who want to swap their tokens. The tokens available are implictly priced by a rule, called the trading function, which comes from basic math. This technology works exceptionally well on networks like Ethereum because it automates the process of supplying tokens to the other side of trades; a reason they are often called Automated Market Makers ("AMMs").

How to Earn a Return using CFMMs

Payoff of Liquidity in CFMMs

Liquidity Providers

In this section we will dig a bit deeper into what it means to provide liquidity to a CFMM, as well as how/when you might want to do so.

Price of the Asset over time

The final payoff of a liquidity position on a CFMM is determined by the trading function and the asset's price path. Price path is taking into account the prices that the asset has reached over a time period. There are unique price paths along which providing liquidity to a CFMM can be advantageous or disadvantageous. Say, for example, your portfolio (a liquidity position) has 1 ETH and 0 USDC. If the price of ETH doubles, your portfolio value will also double.

Impermanent, or Divergence, Loss

In the case of the ETH 2x price path, if you had provided liquidity to a CFMM that demands an equal weighted (50% ETH, 50% USDC) portfolio, you would have suffered what's known colloquially as "Impermanent Loss" (opportunity cost) by not capturing the full increase in ETH's price because the portfolio was not 100% exposed to it. This phenomenon occurs because as the price of one asset in a CFMM pool increases, LPs are effectively buying the cheaper asset (in this case USDC) on the way up. You would've profited in the end, but you would've missed out on that sweet sweet 2x.

Status Quo Strategy

So when does providing liquidity to a CFMM work to your advantage? The strategy name for adding liquidity to a CFMM which maintains a constant portfolio weight of an amount of assets is "mean reversion". A mean reversion strategy wants the prices of the token pair in a liquidity pool to be correlated in the medium run. In the ETH 2x case described earlier, in order to obtain the optimal terminal payoff the price of ETH would have to drop 50% to that at which you had initially added liquidity (hence the name, impermanent loss).

In summary

Providing liquidity to a CFMM creates a portfolio that is implicitly long a mean reversion strategy where price variation works in your favor so long as the prices of the assets revert to that which it was originally.

Options

What is a call option?

Long Call Option

Buying Calls

Before getting back to CFMMs, let's walk through a brief primer on call options. A call option gives the right to purchase an asset for a pre-determined price up until an expiration date. These properties of an agreed upon price and expiration date give the call option itself its own value, beyond the underlying asset. To own a call option in traditional markets, it is purchased from another party on an options exchange.

Short Call Option + Asset - Covered Call

Supplying Calls

The party selling (shorting) a call option is liable to sell their assets if the option buyer chooses to exercise, (buy the asset for the strike price). In traditional exchanges, most of these assets do not need to be put up as collateral because the terms of the option contract are legally enforceable. However, in DeFi, there is no way to enforce the delivery of the underlying assets, unless they are already deposited. It's for this reason that call options in DeFi are collateralized, and this combined position of selling a call option + depositing the collateral is a covered call option.

Covered Call Options and CFMMs

Earlier in this article we discussed how CFMM liquidity maps onto a unique payoff structure (mean reversion). Likewise, covered call options offer their own distinct payoff structure.

Covered call strategies and mean reversion are similar in that they both offer what's called a "concave payoff". To summarize, a concave payoff is a payoff that has a discrete central barrier at which returns are maximized (see above graph).

In the case of a call option, that barrier is located at the strike price (K). That is to say, the max payoff for a party selling a call option is obtained if the price of the underlying is equal to exactly K at expiry. Similarly, the max payoff of a CFMM liquidity provider is obtained if the price of the underlying token reverts to its initial price.

The important difference between these two strategies is rooted in the fact that covered calls allow you to take a directional view on future price. Choosing a strike price greater than the market price of an asset implies a directionally bullish opinion on the asset price.

RMM is a Covered Call CFMM

The Curve

RMM curves value pool assets based on price, volatility, and time. It is these properties which make RMM a new primitive.

The Payoff

Change in Implied Volatility - All else constant

Price of swapping on different IV Curves

RMM curves with different implied volatilities will have different costs when swapping. Trading in a higher IV curve will lead to a higher price of the asset being purchased, while trading in a lower IV curve is the opposite. This will affect the external arbitrageurs who only rebalance pools when it is profitable to do so - there must be a larger profit opportunity in higher IV pools to warrant a rebalance. This has the consequence of affecting the fees that will be generating, as less rebalancing means less fees.

Change in Time until Expiry - All else constant

Price of swapping as pool gets closer to expiry

If only time changed, the curve also experiences "Liquidity Compression" until trades can be executed at a fixed cost equal to the strike price. This compression is sometimes described as "concentration around the strike price", as the price of the asset is constant and equal to the strike price as expiration.

RMM Curve Changes over Time

Time until expiry affects expected fees

The distance between the curves with a lot of time until expiry and zero time until expiry is equal to the total fees expected to be earned by the liquidity provider. This does depend on the implied volatility and swap fee of the curve, as these parameters impact the probability of capturing the expected fees.

RMM Liquidity

Primitive RMMs benefit from the same properties present in other CFMMs, but with the distinct advantage of being able to express more nuanced opinions about future price.

These are some of the additonal benefits you can see from using RMM in lieu of other CFMMs:

1. Liquidity providers choose the point at which impermanent loss begins (K).

2. Liquidity providers can directly bet on volatility (σ), earning more or less fees depending on the accuracy of the bet.

3. Liquidity providers earn theta over time, i.e. fees generated as pools get closer to expiration (τ).

Choose a price strategy

With RMM you're not limited to mean reversion strategies. Instead, you can deploy a position that expresses a directional view on the future price of a token. Doing so requires thoughtful strike price (K) and expiry (τ) selection. For example, if the price of ETH is 3000 USDC, but you believe that one month from now that price will be 4000 USDC, you can express that view by providing liquidity to an RMM that expires in one month (τ = 1 month) with a strike price of 4000 USDC/ETH (K = 4000 USDC). This position has the highest expected return if the price of ETH reaches a terminal value of 4000 USDC at expiry. The caveat to this is that if you're incorrect about the price path, for example if ETH goes to 2000 USDC in that same timespan, you are exposed to greater impermanent loss and will likely make less fees relative to a comparable xy=k position (how about hedging with another RMM?).

Choose a volatility strategy

How about that volatility (σ) thing? In general, a volatility near the market IV (just check the chain) for a given pair should serve as a good proxy for volatility selection. Volatility in an RMM prescribes the degree of liquidity concentration around the strike price. If the strike price of the curve is set to 4000 USDC, a 100% position will have less concentrated liquidity at 4000 USDC versus a 90% one. That means the 100% position would likely earn less fees than the 90% one, should the terminal price at expiry land at 4000 USDC. The tradeoff here comes in the form of greater impermanent loss for lower volatility positions.

RMM Liquidity Tokens

Every liquidity token minted from depositing into a CFMM has a payoff. For RMM, the liquidity token payoff is a covered call.

The method to convert this payoff into the trading function is explained in the Replicating Market Makers paper. Primitive's RMM protocol is an implementation of this.

Ways to use

Provide Liquidity

• Each RMM is a two token pool which accepts deposits and mints RMM liquidity tokens. These liquidity tokens are a new DeFi primitive designed to replicate the payoff of a covered call by capturing theta decay through trading fees.

Swap

• Every pool is composed of two tokens which can be exchanged for one another at any time up until the expiration date of the pool. Trading fees are earned by the liquidity providers on a continuous pro-rata basis and are re-invested into the pool.

DeFi Protocols

• The RMM liquidity tokens are instantly redeemable at any time for their underlying assets. This makes it a highly composable instrument that can be used as a collateral asset for borrowing. Adoption for CFMM LP tokens has grown immensely in 2021, which are now supported across some of the top protocols like Tribe and Aave.

As a Market Making Vault

• Liquidity in RMMs must be rebalanced based on time, volatility, and price. Along with that, the pool's trading fee is also a parameter than can be chosen by a pool creator. Vault strategies can be built around time preferences or volatility preferences, giving end users easy access to a huge source of sustainable yield: theta.

As a Structured Product Vault

• Structured products maintain a portfolio of assets or derivatives which follow a strategy on behalf of depositors. RMM liquidity tokens can be used as a tool to hedge out risk (e.g. underlying asset price risk) or tap into specific exposures, like theta.

As a Large Yield Optimizing Vault

• One of the hurdles for yield optimizing vaults is as they scale into TVL of $ billions, there are not many sources which can sustain strong returns. The theta from options comes with risk, but it also is sourced directly from the volatility of the underlying asset. Vaults which utilize option strategies can earn outsized yields in high volatility environments.

Comparisons

Compared to Uniswap xy=k curve:

• Impermanent loss only occurs after the strike price, making liquidity provision directional.

• RMM curves concentrate liquidity over time vs. Uniswap V3's fixed concentrated liquidity.

• Trading fees are designed to be dependent on time and volatility, while Uniswap's fees are dependent on volatility.

Compared to Covered Call Options in DeFi:

• No reliance on oracles reduces risk and easily supports long-tail assets.

• No need for a direct counter-party to generate theta/fees.

• Instantly redeemable for underlying and quote asset vs. covered calls which is a position that needs to be closed in an exchange.

• Highly composable and a better collateral asset because of redeemability.

Liquidity Provision in Practice

Covered calls are inherently directional bets which are best to take advantage of in high volatility environments. It is ideal to provide liquidity when the underlying asset's volatility is high, and the expected price of the asset will not exceed the strike price by expiration.

Choosing your strategy

Each RMM Pool is a "theta curve" with the following set of parameters:

• Strike price: Each liquidity token is composed of strike price amount of quote tokens if the price of the underlying asset is greater than this strike price. When the pool expires, the underlying asset can be bought or sold for this strike price amount. This will incentivize the re-balancing of the pool such that the each liquidity pool token is worth strike price of the quote asset.

• Implied Volatility: The expected volatility of the underlying asset over the time period until the expiration date. Higher implied volatility will make trades have higher price impact (cost), and lower implied volatility will make trades have lower price impact. If realized volatility of the asset is less than the chosen implied volatility, there is a lower chance that liquidity providers get their expected theta (trading fees).

• Maturity: The expiration date at which no more trading in the pool can occur, and thus no more trading fees can be generated. Liquidity providers can withdraw their liquidity at any time, before or after.

• Gamma: Used to compute the trading fee of the pool. For example, if a pool's trading fee is 1%, its gamma will be 99%. Each swap must pay the trading fee to the liquidity providers, which gets automatically re-invested into the pool.

Example #1 - Choosing a Far Strike Price

On January 10, 2022, Alice notices the volatility of YFI has increased sharply since announcing their new tokenomics plan. The coin trades at $32,000 right now, and Alice believes it won't exceed $100,000 by March. Alice also believes it can double in value to $64,000 by then. She wants to take advantage of the volatility and price movement, so she provides liquidity to an RMM that expires March 11, 2022, with a strike price of $100,000 and implied volatility of 150%.

The amount of value in stable units (e.g. $) of liquidity that Alice must provide is calculated using the Portfolio Value formula:

Depositing Tokens

To summarize the initial position on January 10:

• Current Price: $32,000

• Strike Price: $100,000

• Maturity: March 11, 2022

• Time until expiry: ~3 Months

• Implied Volatility: 150%

• Value of Alice's deposit V(S) in $: (0.8737 + $2909) = $30,868

• Value of Alice's deposit V(S) in YFI: (0.8737 + $2909/$32000) = 0.964

Derived information:

• Call price with those parameters is C: ~$1,132

Notice how the value of the covered call is just the current price less the premium. E.g. S - C = V(S), $32,000 - $1,132 = $30,868.

Capital Efficiency

Therefore, liquidity is being efficiently used to "back" these tokens that have the payoff of a covered call. When compared to covered calls issued on other option protocols, full collateralization is required, sometimes even locked, to mint the call tokens. Going further, these LP tokens are instantly redeemable for their underlying assets at any time, which makes it a strong collateral asset. Using the LP token as a collateral asset to leverage a position is capital efficiency increase that RMM is capable of supporting - but that is left to a future primer.

On or After Expiration

Let's say assumptions proved right for Alice, and three months later YFI is trading at $77,000 with implied volatility over the period being effectively realized. The most important assumption here is the choice of implied volatility (IV). If the realized volatility of the underlying asset diverges from the choice of IV, its possible the replication is not as precise. In that scenario, Alice would have been better off moving their liquidity a lower IV curve. But, because RV was close to IV, the replication was very precise and Alice got the expected payoff. This is a critical choice that is being made when liquidity is provided.

Exiting Position at Expiry

The pool has eclipsed its expiration timestamp, and Alice decides to exit her position. Assuming the pool had sufficient liquidity to attract traders and arbitrageurs, the trading fees and final swaps should cause the pool to be 100% composed of YFI.

This is because the underlying assets in an expired RMM pool can be bought or sold for the strike price. This will incentivize traders/arbitrageurs to purchase all the underlying assets from the pool if the price of asset (e.g. on another dex) is more than the strike price. In the opposite scenario, traders/arbitrageurs will sell as much underlying assets to the pool until the pool only has underlying assets in the if there exists a reference price of the asset that is less than the strike price.

Withdrawing Tokens

March 11, 2022: Alice removes liquidity when YFI is $77,000 and realized volatility over that period was 155%.

• YFI Price: $77,000 (~2.4x increase).

• Realized volatility >= Implied volatility, therefore high probability that the LP token in practice has this payoff.

• Liquidity token composition: 0.00% in $, 100.00% in YFI

• Value of Alice's deposit V(S) in $: $77,000 (~2.5x increase, $77,000 / $30,868).

• Value of Alice's deposit V(S) in YFI: 1 (+3.73% increase in YFI, 1 / 0.964 ).

Alice took the risk of redeeming $100,000 if YFI's price was above that by expiration date. In exchange, she is rewarded with the 3.73% gain in YFI. This extra return denominated in the asset also led to an overall higher return when denominated in a stable coin. Notice that YFI's price increased by 240% and Alice's position increased by 250%, 10% more.

Example #2

Alice loves using RMMs, she made a strong risk-adjusted return and felt confident in the security of the protocol.

She continues to believe that in 3 months YFI will not be above $100,000, so she decides to enter in a new position.

Depositing Tokens

March 20, 2022: Alice provides liquidity when YFI is $80,000

• Current Price: $80,000

• Strike Price: $100,000

• Maturity: June 21, 2022

• Time until expiry: ~3 Months

• Implied Volatility: 150%

• Value of Alice's deposit V(S) in $: (0.469 YFI + $25062) = $62,582

• Value of Alice's deposit V(S) in YFI: (0.469 + $25062/$80000) = 0.782

Derived information:

• Call price with those parameters is C: ~$17,418

On or After Expiration

Unfortunately, this time Alice was wrong. Its June 21, 2022 and YFI is trading at $135,000. What happened to her deposit?

Withdrawing Tokens

June 21, 2022: Alice removes liquidity when YFI is $135,000 and the realized volatility over that period was around 150%.

• YFI Price: $135,000 (~1.6875x increase).

• RV >= IV, high chance replication success if sufficient liquidity in pool during lifetime.

• Liquidity token composition: 100.00% in $, 0.00% in YFI

• Value of Alice's deposit V(S) in $: $100,000 (~1.5979x in $, $100,000 / $62,582).

• Value of Alice's deposit V(S) in YFI: 0.7407 (-5.3% decrease in YFI, 0.7407 / 0.782).

While Alice did get a good return in $, if she wanted to earn a return denominated in YFI she would have been better off to hold all of her deposit in YFI. The actual price of YFI was more than the strike price of the pool, $35,000 more, which incentivized arbitrageurs to buy all the YFI from the pool at a price of $100,000. The pool is then 100% composed of $, which liquidity providers like Alice eventually withdraw.

So, what was the tradeoff that Alice took?

• Trading lower probability of potential gains (YFI price increase above $100k) for higher probability of profits (trading fees).

In the opposite scenario, If YFI's price was below $100,000 at the maturity:

• Alice withdraws 1 YFI, earning a 28% (!!!!) return on YFI. Note: High return because of IV parameter curve being high, and realized volatility was close to it.

And what was the belief/purpose of providing liquidity to RMM?

• Not confident in YFI being above $100,000 in 3 months.

• Wanted to capture trading fees, i.e. theta decay, generated from YFI's volatility.

• Wanted to earn a return denominated in YFI.

RMM Strategies

Choose Impermanent Loss Price Point

In short term bearish environments, like a prospective FOMC meeting, prices are dampened and volatility is heightened. This is an optimal time period to take advantage of RMM. By providing liquidity, the exposure to the underlying asset will be maintained assuming the strike price is high enough, and higher volatility will warrant higher fees (if the liquidity is there).

In comparison to a CFMM like Uniswap, any price change in the underlying asset which does not revert to the initial entry price will miss out on potential gains (opportunity cost) from the asset, while RMM pools will only miss gains on the asset if the pool expires "in the money"; when the market price of the asset is above the strike price of the pool.

On the other hand, this opportunity cost in Uniswap would be in the LPs benefit in the scenario the underlying price fell off a cliff. In that scenario, the RMM LPs will be left holding 100% the underlying asset, which could potentially go to zero.

This directionality is not available in any AMM curves because those curves are not aware of time or strike prices.

Hedge Options with RMM

Hedging options is called a dynamic hedge because it is a position which counters another position's greek exposures. Greeks are planned to be explained in a future option primer, but for now they can be thought of as symbols to represent the change in the option's value depending on price, volatility, or time. For example, if an option changes value because of time (theta), the dynamic hedge will also change by the same magnitude from the same change in time.

An option's value is derived in part from the underlying asset's price. The greek symbol delta is used as a quantitative metric for how much value the option's value changes when the underlying asset's price changes. Going further, the greek symbol gamma is the metric for how much the delta changes when the underlying asset price changes. Gamma exists for options because if the underlying asset price gets closer or further away from the strike price, there is more/less probability the asset price will be above the strike. If the option is not above the strike by its maturity date, then it's worthless. Therefore, delta is sometimes used as a proxy for the probability of being in the money. Gamma is one of the primary reasons options are such a popular instrument, because purchasing gamma (buying the call option) is cheaper (but has the same returns) as purchasing delta (buying the asset).

Call options have a positive gamma, which means a hedge cannot only be in the underlying asset (which has no gamma), it must be a negative gamma position. Uniswap liquidity tokens have negative gamma, but it's not a straightforward hedge for a call option because it does not match its gamma.

RMM liquidity tokens replicate a covered call payoff, which means its close to a perfect hedge (almost) for calls. Along with that, it's negative gamma so it can be used to hedge other gamma positive positions.

Why hedge a call option with a short call option? A rough example of an opportunity is if call options on another protocol are underpriced, they can be purchased and then hedged with an RMM liquidity position, capturing the difference in premiums.

RMM Risks

While these are the expected results of providing liquidity to RMM, its entirely possible that no fees are generated at all. However, in that case it would mean the pool's liquidity is not rebalanced. This might end up in the LP's favor anyway. For example, if no trading occurred in the pool Alice deposited to, and thus no fees were generated, the initial deposit would be the same. At that point, she'd be withdrawing some YFI along with the $, rather than only $.

A no trading fees scenario occur for several reasons:

• Realized volatility is lower than the curve's implied volatility, increasing the arbitrage profit window and reducing the amount of trading fees generated.

• Liquidity in Alice's pool is too small for many trades to happen.

• Liquidity in Alice's pool does not create enough profitable opportunities for arbitrageurs to trade the pool.

• The pool is not known well/integrated into a dex aggregator/known by arbitrageurs/searchers.

Oracle Risks

None.

Smart Contract Risks

Have the smart contracts for RMM been audited?

Yes. RMM protocol contracts have been audited by five security firms, making it one of the most audited set of smart contracts in DeFi (if not the most):

• Trail of Bits - 8 weeks

• ChainSecurity - 8 weeks

• ABDK - 4 weeks

• Dedaub - 4 weeks

• Sherlock - continuous

While these audits give high confidence in the protocol's security, the smart contracts still have the possibility of containing bugs. Along with the audits, Primitive has a $1,000,000 bug bounty on Immunefi, and $10,000,000 of coverage by Sherlock.

Conclusion

Primitive RMM is a highly composable primitive for DeFi that will bring more liquidity to on-chain options. Liquidity tokens can be used as a collateral asset in lending and derivative protocols, increasing the capital efficiency and usage of the underlying tokens.

RMM protocol fixes the poor liquidity environment for on-chain options and it's going live in a couple of weeks. You in?

Resources

Visit the website here: primitive.finance

Follow Primitive on twitter.

Frequently answered questions: FAQ.

Community Discord: Discord.

Secret highlight of the week, here’s a keccak256 hash of the description:

Primitive Team

• Interface release candidate is prepared, with UI/UX updated to latest design framework.

• Trail of Bits team’s last week of review for rmm-core and rmm-manager.

• Final changes and fixes have been merged to rmm-core and rmm-manager smart contracts.

• Clement built a custom alert discord bot to monitor rmm protocol transactions!

From the Community

• Quiet from the community this week.

Next week - January 30

• Mainnet launch.

How to Get on Primitive Weekly

• Connect us with an artist to make nice art for these weekly posts - or all the posts we have!

• Write an educational tweet thread mentioning the @primitivefi twitter handle.

• Write an educational article that mentions Primitive or RMM protocol.

• Open issues or pull requests on the open source repositories that fix typos, bugs, or to suggest features.

• Join the team part or full time and make contributions

Most impactful highlight of the week is Verumlotus's implementation of a Theta Vault built on Primitive. It is based on Ribbon Finance's Theta Vaults, and manages liquidity in Primitive RMM pools on behalf of depositors.

Primitive Team

• UI/UX/Interface team migrated the app's components to a new framework connected to our new design system mocked.

• Trail of Bits team (Natalie and Simone) continued work on end-to-end echidna tests for rmm-core.

• Clément started working on a proof-of-concept contract for an "Auto Pool".

From the Community

• 0xEmperor mentioned Primitive in a mirror post in which they break down the paper "Improved Price Oracles: Constant Function Market Makers".

Next week - January 23

• App Release Candidate #1 will be deployed, with the new UI.

How to Get on Primitive Weekly

• Connect us with an artist to make nice art for these weekly posts - or all the posts we have!

• Write an educational tweet thread mentioning the @primitivefi twitter handle.

• Write an educational article that mentions Primitive or RMM protocol.

• Open issues or pull requests on the open source repositories that fix typos, bugs, or to suggest features.

• Join the team part or full time and make contributions

Beta 5 is now live at app.primitive.finance.

New Features

• Alchemy: Using Alchemy as our default web3 provider, connecting a wallet is no longer necessary to view top pools.

• Create Pools: Creating new pools using the Add Liquidity page is now enabled and functional.

• Disable Permit: Introduced a new user setting that enables users to choose between permit and approve when using permit-enabled tokens.

Bug Fixes

• General stability improvements from integrating the newly released rmm-ethers package.

• 2-3x loading time improvements across the interface.

• Removing liquidity is now fully functional, no more crashing.

• Transaction notification log is now working.

• Transaction processing speed improved.

• Pools accessible without injected provider connection due to Alchemy provider.

Future Improvements

• Design Refresh: We are currently preparing a complete design overhaul. The UX of the interface will not change much, but this new design system is a 10x improvement aesthetically.

• Wallet Improvements: Next up on the priority list is adding additional wallet types, such as Wallet Connect, and improving the UX for changing networks and connecting wallets.

• Protocol Onboarding: RMM-01 is a complicated protocol, and while we love answering questions in the discord, we are building a more comprehensive onboarding process into the RMM Interface.

• Improved Transaction History: A history of transactions populated via rmm-ethers will be available to view the name of the transaction and status.

User Feedback

To make bug reports or feature requests, please visit primitive.canny.io.

Overall highlight for the week is definitely Clément's gas comparison tool called Marmite.

Primitive Team

Along with that, it's been a productive week:

• Estelle discovered a novel way to rebalance between RMM pools to minimize losses. Paper is in the works.

• Alex😇 finished a beta version of the rmm-ethers package, a transaction helper for interacting with rmm protocol.

• Zach, Rj, John, and Kinrezc shipped an app update which is summarized by Zach here.

• Royce finished the first draft of Mocked a web3 focused design system, and began using it in the new Primitive UI skin.

• John made progress on building the actual components based on the design system using stiches by Radix ui.

• Alex😇 updated the rmm-core contract tests to be 50% faster and work with ganache.

From the Community

We'd also love to show case some of the community efforts towards Primitive - along with this we plan to announce more details about our bounty program.

• whoisndu wrote a substack article in which they dove into order books, AMMs, and derivatives in DeFi. Along with that whoisndu gave an excellent overview of Primitive RMM protocol.

• 0xYoann wrote an overview of Primitive on mirror. Yoann discusses constant function market makers and on-chain derivatives, it's a great primer for anyone interested any of those topics!

• (Past month) transmissions11 got their gas optimization changes merged into the rmm-core contracts!

Next week - January 16

• ********* Primer. (🤫)

• App update called "Beta 6" with a re-skinned UI.

• Bounty program (not bug bounty, we already have that!).

How to Get on Primitive Weekly

• Connect us with an artist to make nice art for these weekly posts - or all the posts we have!

• Write a tweet thread mentioning the @primitivefi twitter handle.

• Write an article that mentions Primitive or RMM protocol.

• Open issues or pull requests on the open source repositories that fix typos, bugs, or to suggest features.

• Join the team part or full time and make contributions

"You can cook good Solidity recipes with marmite."

• Clément Lakhal, Chief of Protocol at Primitive

Overview

Around Christmas last year, transmissions11 offered us one of the best gifts a team of Solidity developers could ever dream of: pull requests full of gas optimizations!

This kind of spawned in us a desire to gas golf our contracts even deeper, but we quickly realized that we didn’t have a proper tool to help us test different Solidity implementations and compare the gas costs.

So after sending our smart-contracts to a final audit (performed by Trail Of Bits team), we decided that it was time to build this new tool!

What’s the soup?

Marmite allows you to write different implementations of some Solidity code directly in your contracts, and then obtain a gas cost comparison among them.

These declarations are done using the tags @start<Implementation-name> and @end:

Note: Implementations are meant to be used during the process of gas optimization and should not be kept in final contracts.

Once you’ve done that, the next step is simply to run the golf:contract command:

If you have a more complex setup (with multiple contracts deployed) or a specific environment, you can write a script using the Marmite context function:

After that, you can use the golf:script task to execute the script:

Conclusion

Marmite offers a simple and flexible way to compare gas costs directly in your contracts, and in case you were wondering: it supports any Solidity versions!

If you want to try it out, check out the README on GitHub for the installation and usage instructions.

Happy gas golfing!

Marmite on GitHub

Primitive Discord

We are excited to open source the RMM SDK, a developer tool that makes it easier to build on top of the RMM protocol.

Interacting with any web3 protocol comes with hurdles: parsing on-chain data, modeling smart contract state, and displaying information in a clear way. This developer kit exposes several "entities", which are models of the smart contracts, and "managers" to help construct transactions (but not execute them!). Use the SDK to easily tap into the RMM protocol, derive useful information for users, and safely build transactions for them.

The Primitive team is using the SDK to build an innovative liquidity product on top of RMMs, and now anyone can do that with it being open source. The RMM protocol is designed to be maximally composable through its oracle-less, dependency minimized architecture. These are some of the straightforward use cases for the app layer of RMMs:

• Structured Products

• Vault Strategies

• Swapping

Tools like this will be used to increase adoption of these unique liquidity tokens for everyone using Primitive, from liquidity staking to volatility harvesting vaults. This SDK remains narrowly focused on the main smart contracts, while being powerful enough to build several products from it.

Discord

We have an open server with specific channels for discussing products:

Join here

For Developers

Comprehensive documentation of the sdk is here.

Entities

These products all need to tap into a property of the Primitive pool's underlying math, whether that is calculating amounts for swaps, or computing the deterministic pool ids that are dependent on curve parameters. There are three typescript classes which are used as models to make this easily accessible:

• Engine entity

• Calibration entity

• Pool entity

Engine Entity

The Engine entity is utilized to deterministically compute the address for pairs, the smart contract called "Primitive Engine". It needs the Primitive Factory address and the two token addresses to be instantiated, that's it!

Calibration Entity

Calibration extends the Engine, enabling a pool id to be deterministically computed based on the parameters:

• strike price (in wei)

• implied volatility (sigma)

• maturity (expiry date)

• gamma (100% - swap fee %)

These two entities are designed to be stateless, i.e. they are not instantiated with on-chain data, only the parameters, token addresses, and Primitive Factory address.

Pool Entity

The Pool goes further with extending the Calibration, but it can also be instantiated from on-chain data. This pool models the entire state of a pool: its reserves, invariant, and calibration parameters. Along with it, the model exposes useful functions to derive information for users, e.g. amount much liquidity they receive for when providing an amount of tokens.

Simulating Pools

A simulated pool model can be instantiated using fromReferencePrice. The user must pass in a referencePrice of the asset to infer what the reserves would be. This can be useful to determine the arguments for creating pools or allocating liquidity to a new pool based on its parameters, rather than on-chain state.

Creating Pools

If a user were to create a new pool, they should be asked for a reference price, which can then be used to instantiate the pool's theoretical reserves. From this, the optimal amounts of liquidity to add can be computed, and then the transaction could be constructed.

Creating the Pool Entity

An easy way to build the Pool entity is available through the peripheral contracts. The Primitive Manager smart contract has a function uri which accepts a poolId as an argument. Calling this will return some encoded json data, which can be decoded and then passed directly to the Pool entity's from method, returning a Pool entity that's "synced" to the same block as the uri call.

This is the optimal way to instantiate the pools, as a bundle of uri calls can be batched in a multicall.

Managers

Along with the entities are "managers". These expose easy functions to encode function selectors and arguments to build a transaction's calldata.

Periphery Manager

This class is designed to match the Primitive Manager smart contract's public functions. Primitive Manager inherits a Multicall contract, making it possible to bundle several transactions to the Primitive Manager in a single transaction.

Multicall Example

For example, a "zap" is a way to provide liquidity to a two-or-more token pool with only one token. How it works: some of the tokens are first swapped to the token of the other side(s) of the pool, and then all the tokens are provided as liquidity. With multicall, its possible to do this without an on-chain function!

It takes two steps:

• Given an amount of $ value to provide, denominated in one token, compute amount of liquidity tokens that could be minted (i.e. $ to provide / $ value per liquidity token)

• Given an amount of LP tokens, compute how much of each side of the pool is required

• Compute the amount needed to swap to get the other side of the pool

• Add the swap transaction to an array of calldata

• Push the allocate liquidity calldata to the same array

• Wrap the calldata in a multicall!

There are nuances here, but that's the general idea.

Encoding function data

Each of the static methods on the PeripheryManager expose an easy way to build ready-to-send transaction payloads to the on-chain PrimitiveManager contract. Mix and match these methods to build all kinds of useful functions!

Here are some ideas:

• Roll positions (update a liquidity position from one expiration to another)

• Single-asset liquidity provision (zaps)

• Distribute liquidity across curves at different implied volatilities

• Tokenless AMM

Factory Manager

The factory contract only has a single function deploy. This manager has a static method to encode this function selector with two token addresses, which will deploy a new PrimitiveEngine contract.

Dependencies

This SDK relies on an ethers.js wrapper: web3-units.

Along with that, it uses the Uniswap Token Entity from their sdk-core package.

Primitive pools have a trading function, which the Pool entity computes using the typescript implementation in rmm-math.

Helpful links

Use the RMM SDK now!

Community

Go tell your friends about the oracle-free derivative protocol launching soon with concentrated and fungible liquidity.

To meet the rest of us, join the discord:

Primitive discord

Published on Mirror

mirror.primitive.eth

Published on Primitive Blog

blog

Learn More

Visit the website

primitive.finance

Visit the docs

primitive documentation

Follow Primitive on twitter

primitivefi

One week ago, the Primitive app for RMM protocol on rinkeby was shared in the Primitive discord and since then has done over 12,000 transactions!

Over 2,500 users hold RMM liquidity positions across six different test pools. In addition to that, the discord has almost 3,000 members along with more than 60 feature requests and 60 bug reports for the app.

What is RMM protocol?

The Replicating Market Maker ("RMM") protocol was built for a reason: to build novel liquidity products from innovative financial vehicles.

Any user of RMM has access to derivative payoffs without reliance on oracle systems or counterparties.

What's next?

Mainnet will be in January. The team is following a strict quality process to get to mainnet.

This version of the app helped narrow down the remaining issues that broke the interface. Significant upgrades are being developed in parallel to the fixes to ensure the app is an extremely reliable interface for RMM protocol.

The next scheduled upgrades to the app:

• Beta 3: Current

• Beta 4: 1-week expiry pools, 1 chosen feature request, bug fixes and performance updates

• Beta 5: 1 chosen feature request, better and faster data

• Beta 6: Style updates + final bug fixes, 1 chosen feature request

• Release Candidate 1: Final release before mainnet

• Release Candidate x: If any bugs found in a release candidate, fixed here

• Mainnet: With a reliable interface, tested contracts, and exceptional UX mainnet can be launched!

Pipeline

Along with the app, these are some interesting products the team is exploring:

• Tokenized Theta (an up-only token)

• Vanilla options (long call and long put options)

• Binary options

Each of these simply interacts with the RMM-01 liquidity token in a different way, it's the ultimate DeFi lego.

The smart contract team is working on contracts that will improve adoption for the liquidity token, including an LP staking contract.

Adoption

The team is focused on writing better documentation, building reliable tooling, and following best security practices in preparation mainnet launch. These upgrades, scheduled by end of year, will make it easier to build on the RMM protocol:

• Docs overhaul with better and more concrete examples

• User guides to understand risks, rewards, and how to best use the protocol and its products

• Private discord for the teams who want to build on RMM-01

Closing thoughts

Each of these items will improve every user's experience on mainnet launch. The goal all along:

A reliable interface that can work in a decentralized setting, simple examples to understand building on RMM, and basic user guides to make the learning process easier.

Helpful links

Use the testnet now!

Community

Go tell your friends about the oracle-free derivative protocol launching soon with concentrated and fungible liquidity.

To meet the rest of us, join the Primitive discord.

Published on Mirror

Read this post on mirror: mirror.primitive.eth.

Published on Primitive

Read this on the Primitive blog: blog.

Learn More

Visit the website: primitive.finance. Visit the docs: primitive documentation. Follow Primitive on twitter: primitivefi.

View the bug bounty details on Immunefi.

Primitive directly handles a $250k portion of this bug bounty, while Sherlock has committed the remaining $750k. Being under the umbrella of Sherlock Protocol has improved the protocol security by tenfold through direct smart contract review, coverage, and incentivizing bugs to be reported rather than exploited.

The smart contracts have a scheduled audit starting in January with Trail of Bits. These audit weeks will cover the RMM contracts (which have already been audited). This final review will give us full confidence in the security of the protocol, cementing its status as an immutable and anti-fragile system, as all low-level primitives should.

The smart contracts are planned to be launched before this audit is finished, therefore caution should be exercised when interacting with the protocol at all times. The protocol should be considered as an alpha version.

Testnet

The testnet is live and the app is scheduled to be available to users during this week, if not today. There will be a separate blog post to give a brief overview of the testnet and the goals of having it.

Discord

The testnet will first be made available to the users in our discord, you can join here: Primitive discord.

Published on Primitive

Read this on the Primitive blog: blog.

Learn More

Visit the website: primitive.finance. Visit the docs: primitive documentation. Follow Primitive on twitter: primitivefi.

Primitive is purchasing $10m of coverage for its users through Sherlock Protocol. This entitles all users to claim a portion of USDC from the pool in the case of an adverse event.

This coverage also comes with the benefits of increased security:

• $1m bug bounty incentivizes against black hat attacks

• A future avenue of scaling coverage on Primitive products

• Continuous audit capacity on smart contracts

Since this is all handled on behalf of users, if any funds are lost users will simply gain access to a claim USDC button.

The unique model of purchasing coverage through Sherlock has an important feature: coverage pricing that moves with code complexity. As Primitive launches new products that may be more complex, the Sherlock team will be best positioned to make better pricing decisions. This ultimately leads to more coverage for the end user because more can be purchased at a better price.

Sherlock has already proved themselves to be invaluable through the security expertise of their Watsons, and we couldn't be more excited to offer coverage for all of our users.

Visit Sherlock

Learn more on the Sherlock website: sherlock.xyz

Community

Go tell your friends about the oracle-free derivative protocol launching this month with concentrated and fungible liquidity.

To meet the rest of us, join the Primitive discord.

Published on Primitive

Read this on the Primitive blog: blog.

Learn More

Visit the website: primitive.finance. Visit the docs: primitive documentation. Follow Primitive on twitter: primitivefi.

Good documentation for a DeFi protocol is absolutely mandatory, but writing it can be sometimes cumbersome. Here comes Dodoc: a super simple Hardhat plugin allowing you to generate documentation for your smart contracts with no hassle!

Overview

A couple of weeks ago while wrapping up the contracts of our brand new Replicating Market Marker, we decided to have a look at the current solutions to generate and host our contracts documentation.

Finding how and where to host the docs was not a big deal, and among many different choices, our front-end team decided to go with Docusaurus and to use Markdown-based files.

The last thing to do was to find a way to automatically generate the Markdown documentation, based on the NatSpec of our Solidity contracts, and pass that to Docusaurus.

But after some research, we started to scratch our heads since we found out that the only available plugin was Hardhat Docgen, which was generating a whole static website. Not exactly what we wanted!

So we decided to have some fun and write a brand new tool from scratch: Dodoc was born!

Features

Zero-configuration required

Just install Dodoc package, import it in your Hardhat config file and you're good to go! Documentation will be generated on the next compilation in the docs folder of your repository.

Compatible with latest Solidity versions

Even the latest Solidity versions (0.8.x+) are supported, this means that you can even write documentation for your custom revert errors!

Extendibility

Default output is generating Markdown files, although custom templates can be created using Squirrelly! This means that literally any format can be supported.

Conclusion

While working on Dodoc, our goal was to make a very simple tool that would also be flexible enough to allow anyone to reuse and extend it. So we did it!

Finally, the last thing to do is to share a live example, so here is the new Primitive documentation, generated using Dodoc:

Let's try out and check out the installation instructions in the README on Github. Trust me, it's super simple!

Feel free to open any issues on Github and join us on Discord to share your thoughts and give some feedback! Happy hacking! :)

• Dodoc on GitHub

• Primitive documentation

• Primitive Discord

Published on Primitive

Read this on the Primitive blog: blog.

Learn More

Visit the website: primitive.finance.

Follow Primitive on twitter: primitivefi.

Building this protocol was a collaborative effort that could have not been done without the help of Alex Evans, Guillermo Angeris, Tarun Chitra, and Experience.

Introducing Primitive

Today, we are ecstatic to introduce the Replicating Market Maker ("RMM-01"), a spot exchange and derivative protocol.

While derivatives in traditional finance are massive, DeFi derivatives have yet to grow to a comparative scale. This is in part because they are bottle-necked by their dependence on oracle systems and high collateralization requirements.

Oracles are one of the largest sources of smart contract vulnerabilities and perhaps the largest centralization vector, so we sought out an architecture that excluded them.

Primitive is an oracle-free solution to scalable and efficient on-chain derivatives, reflecting our belief that the future of decentralized finance should not depend on expensive (and often brittle) oracles.

The protocol is slated to launch December 2021 on Ethereum L1 mainnet, Arbitrum L2, and Optimism L2.

The features on launch include:

• Concentrated fungible liquidity

• Liquidity pool tokens that replicate covered call options

The protocol can be used for:

• Earning swap fees as a liquidity provider

• Swapping between tokens of underlying pools

• Building structured products using the composable liquidity pool tokens

• Creating liquidity pools for any token pair

Out of the box, Primitive is the base infrastructure for an oracle-free DeFi and the future of on-chain derivatives.

Read on to learn about "derivative tokens" and how the pools concentrate liquidity as an AMM.

Derivative Tokens

Every liquidity provider to the popular automated market makers ("AMMs") has, implicitly or explicitly, held an underlying derivative: the liquidity pool token ("LPT").

Primitive is not an AMM that trades derivatives, the LPT is the derivative. This specific niche of derivative market has seen some early growth, but has yet to reach the spotlight. For example, there are a few protocols that leverage the LPT as a derivative: Onboarding Uniswap V2 LPTs, Aave AMM Markets Released, Balancer as a portfolio manager, and the idea of "Pool 2", Yield Farmer's Guide.

Primitive leans into this market as an AMM whose primary use-case is having financially useful LPTs. This makes the protocol different when compared to other AMMs, which have arbitrary LPTs that are not the most straightforward to value.

Using RMM liquidity pool tokens, virtually any derivative payoff can be offered or created. For example, in a decentralized lending market like Fuse, these LPTs can be shorted, expanding the possible derivative payoff range to call and put options, and therefore nearly any derivative payoff one could imagine. Structured product and liquidity strategy protocols, like Ribbon and Charm, can use a basket of LPTs to make novel products for any token on any EVM chain. Binary options can be created by selling the rights to one side of the LPT, as researched in Replicating Monotonic Payoffs. A basket of these binary options can be used to replicate an unlimited number of instruments!

Spot Exchange

All of the liquidity which backs these LPT derivatives is productively used as a spot exchange for tokens, just like any other AMM. Better yet, concentrated liquidity curves make these swap rates competitive within the DEX ecosystem, which captures more trading flow and generates fees for liquidity providers.

Liquidity providers are exposed to the price risk of the underlying assets and are not neutral. While the swap fees compensate for the risk, being an LP on Primitive is almost the same as market making covered call options. With this complexity, positions will be optimally managed in a more active way and ideally delegated from most users to vault products like Yearn and Charm.

Tokenization

Liquidity within the RMM is not tokenized itself, enabling higher level smart contracts to make the decision on their own. This allows any token standard to be used: ERC-20, ERC-721, ERC-1155, etc.

Primitive's Manager contract uses the ERC-1155 standard to tokenize liquidity. This comes with several important features:

• All metadata of the liquidity pool token is aggregated into a single location, the token URI

• Each token id matches the pool id

• Multiple LPTs can be batch transferred, enabling more efficient structured products

• Reduces on-chain state bloat by using one smart contract for all pool tokens, rather than one per pool

• On-chain image constructed from the metadata, for easy viewing in any wallet!

Cheap Liquidity Management

The core smart contracts can hold internal balances, allowing liquidity to be moved in and out of pools without paying the gas cost of transferring tokens. These token transfer costs are usually 1/3 of the total gas cost for providing liquidity to AMMs. Now liquidity can be moved in and out of pools (for the same pair) with much lower friction.

TWAP Oracles - Spot and Implied Volatility

The state of reserves for these pools are valuable on-chain resources which can be weaponized into TWAP oracles. This is done by utilizing the cumulative reserves of a pool and viewing it over a select time range.

While this oracle would be for spot prices, a TWAP oracle for volatility can also be created using the cumulative liquidity of a pool. Mapping the most liquid pools to their respective volatility curves gives incredible insight into the implied volatility of the token pair.

Although ideally, oracles wouldn't be needed in an RMM world.

Audits and Bug Bounty

Several professional smart contract security firms were engaged to review the core and peripheral contracts of the Protocol:

• ChainSecurity audit over 8 audit weeks

• ABDK audit over 4 audit weeks

• Dedaub audit over 4 audit weeks

• Sherlock continuous review since August

While we believe such a range of serious audits is the absolute minimum safety measure in the DeFi, the complexity of the protocol and the ecosystem means that a completely bug free codebase can't ever be guaranteed.

As such, an open bug bounty of $250,000 is offered through Immunefi to anyone who finds a critical bug within the smart contracts.

Launch Details

The Primitive Protocol will be deployed to testnet during the week of December 7, 2021, allowing anyone to use the protocol in advance of the launch.

• View the Primitive RMM Core repository for the source code of the AMM.

• The Primitive Manager repository has the smart contracts which users will be interacting with.

• Visit the Primitive Examples repository to check out some of the early ideas for products on top of the protocol.

• Use the RMM Simulator developed by Experience to model LPT payoffs.

For launch to go smoothly, we will focus during the remainder of December on these priorities:

• Testing and review of the protocol's smart contracts

• Supporting integrations with other products and protocols

• Interface design and functionality finalized

• An analytics site to explore the Primitive pool ecosystem

• Further documentation, tools, and examples to support the ecosystems growth

Community

Go tell your friends about the oracle-free derivative protocol launching this month with concentrated and fungible liquidity.

To meet the rest of us, join the Primitive discord.

Published on Mirror

Read this post on mirror: mirror.primitive.eth.

Published on Primitive

Read this on the Primitive blog: blog.

Learn More

Visit the website: primitive.finance. Visit the docs: primitive documentation. Follow Primitive on twitter: primitivefi.