Vyper Bytes #2: An overview of Vyper Core

Gm Snakes 🐍

In today’s edition of Vyper Bytes we present an overview of the architecture design of our primitive, Vyper Core.

Vyper Core and Application Layers

If you’ve been with us for a while you may have heard different terms thrown around, including Vyper Vaults, Vyper Core, and more recently Vyper OTC. We realize that can be a bit confusing so first we’re going to clarify how they relate to each other.

First of all a reminder from our previous article:

Vyper Core is the first ever primitive allowing anyone to create, trade, settle on-chain derivatives. It allows complete flexibility over the choice of collateral, the source of pricing data, and even the payoff

So Vyper Core is about derivatives, cool. But how?

In essence, Vyper Core provides a flexible infrastructure allowing people to create their own derivatives products. With “derivatives products” we don’t mean only things like perps, options, and so on, but more generally protocols or products that derive part of their functioning from external data. Within this broad definition, most of DeFi is about derivatives, even if we are not used to thinking about them in this way.

As a programmable layer, Vyper Core is supposed to be interacted with through other layers (smart contracts), which we call Application Layers. Each Application Layer provides additional functionalities that are specific to a given use case, while still leveraging the full power of Vyper Core. In this context, both Vyper Vaults and Vyper OTC are Application Layers, powered by the same infrastructure, Vyper Core.

You may wonder, why the need of separate smart contracts? Isn’t that complicating things needlessly?

The reason it’s very simple: composability.

Using a common base infrastructure greatly improves efficiency and code re-usability, and with the right architecture choices it can prove invaluable for developers. Indeed while developing Vyper Core we had two main classes of users in mind: direct users (using Application Layers that we or others develop), and developers (who build innovative solutions on top of Vyper).

While it’s self-evident that direct users will use an app if they find it useful, it may not be obvious why a dev should want to spend time to learn how to use Vyper Core rather than developing something from scratch.

Let’s take the example of Alice who wants to develop a fixed-rate product built on top of a lending protocol like Solend. Focusing just on the smart-contract work (in reality you have other stuff too, a front-end at a minimum), she needs to understand how Solend works, how to manage the fixed rate feature, how to structure accounts, positions and cTokens, deposit of collateral, and so on. For a full fledged-out protocol, it’s not uncommon that the time-to-market goes well into several months.

Alternatively, Alice could use Vyper Core and access a functioning smart contract layer which provides out-of-the-box collateral management, oracles integration, and a flexible payoff specification module. On top of that she could rely on the integration support of the Vyper Core team, which include first-class devs and derivatives specialists. With all this, without exaggerating, the time to market could be cut from months to just a week!

The increase in dev efficiency is something that it’s important to us, as it allows people to experiment more and simply try more stuff. If it costs you months and months to develop something, you will think long and hard before doing it. While that’s generally a good thing to do, it also means that sometimes some cool stuff is left behind, stifling DeFi innovation.

We believe that every protocol developing their full smart-contract derivatives infra from scratch is an incredible waste of time. Imagine if every time a dev starts a new project they needed to code first their own operating system or IDE. It’s simply not sustainable. Vyper is a first step in tackling this issue, and while it will definitely have limitations, we believe it paves the way in the right direction

A modular architecture

We are now ready to give a high-level overview of how Vyper Core is structured. Let’s start by giving a quick look at the vyper-core repo:

As you can see, vype-core is only one (central) part of the primitive, which leverages two key additional types of module: rate and reedem logic. Let’s have a look at each of them.

Vyper Core

Within the primitive, Vyper Core takes care of a key part: collateral management, including the minting and redemption of what we call position IOUs, representing a depositor’s position.

If you think about it, most derivatives involve two sides: lender vs borrower, long vs short, and so on. Vyper Core works by taking collateral deposits for each of the two sides and minting position IOUs. When collateral needs to be released, the value of the position IOUs are updated and the deposited collateral is redistributed and released accordingly.

To properly re-assess the new value of the position IOUs, two additional parts are needed. One that evaluates what external data has changed, and by how much. And another that takes those values (in most cases prices) and computes the actual position IOU value in terms of the collateral deposited. These are the rate and redeem logic modules.

These modules are other smart contracts which communicate through a common interface with Vyper Core. Importantly, as long as they respect the interface, anybody can write one and plug it in Vyper Core! Every time the Vyper Core smart contract is initialized, you can specify which modules you will use, thus giving you all the flexibility you may need.

Module: Rate

The Rate module exists to provide Vyper Core with external data. In most cases that means an oracle, and indeed we already built out a rate-switchboard and rate-pyth modules, which wrap the oracles in the right interface for Vyper Core. That will likely be enough for most situations, but for other cases other possibilities are also available (e.g. reading on-chain accounts). Again as long as it respects the common interface, anything is allowed.

Since sometimes you need more that a single value to calculate the payoff, the Rate module currently supports up to 10 different return values.

Module: Redeem Logic

This module is where the magic happens! Based on the data provided by the Rate module, the Redeem Logic module tells Vyper Core how much the position IOUs are worth.

Again there is a common interface to be consistent with, but no other restrictions. So you want an option? Simply write in the module max(0, S-K) and you’re done (it’s not that simple, but you get the idea). This is the key of our flexible infra, given that you can put here pretty much anything you want.

In the screenshot of our repo you can see we already published a few, and writing one can take very little time. Going back to our dev Alice, writing a fixed rate Redeem Logic can easily take less than a day. Each redeem logic can also support additional parameters that can be configured separately, such as strikes, caps, splits, etc.

Limitations

We wouldn’t be fair if we also didn’t briefly mention where the magic of Vyper Core (currently) ends. We’re still in the early stages of Vyper so clearly there are some trade-offs to do. A few of them are a result of design choices, to allow the primitive to remain flexible, while others are dev time constraints. A few of them are:

• Single collateral type. Currently Vyper Core accepts only one type of collateral per initialization. That means you can’t have one side deposit USDC and the other SOL. At the same time, collateral can be any SPL token like SOL, USDC, LP tokens, and even a (single) NFT.
• Time. Vyper Core is not “time aware” so any type of expiration, funding periods, or epochs needs to be implemented at the Application Layer level
• Upfront collateral. Vyper Core accepts collateral at the beginning of the initialization. While repeated deposits and withdrawals are possible, the logic of how to manage that (or whether to allow it or not) is left to the Application Layers. For example, Vyper Vaults implements this for multi-epoch trades, while Vyper OTC doesn’t allow further deposits after the trade is started, and allows a single withdrawal after expiry.

Moreover, Vyper Core has no concept of “position health”, or “margining”. We will leave to another article the rationale and implications of this point.

All together these components constitute the Vyper Core primitive, which we envision to become a key component of future DeFi derivatives protocols. If you’re a DeFi user and can’t wait to use Vyper, stay tuned for more announcements soon! If you’re a dev and are as excited as we are, get in touch and let’s build together 🐍