LSD is a new protocol for buying and selling real yield. Our previous post explained why real yield will be the next trend to bring DeFi and web3 into the mainstream.

In this post, we’re going to talk about how our protocol works, and specifically get into details on the central primitive of LSD: transferable yield slices.

Prior art and requirements

Transferrable yield slices are a yield derivative that underlies the LSD protocol. Before getting into details of how they work, let’s mention the prior art, and go over the requirements we had for yield slices.

LSD is not the first protocol to deal with yield derivatives. Some previous projects in this area include Pendle, Element, and Timeless. We’re not going to discuss the specifics of how LSD differs from them in this post (we’ll talk about that in a later post), but we want to explain the requirements that we had when designing LSD. We started with the end user experience, and developed the protocol to meet those needs. None of the existing yield protocols meet all the requirements below.

A real yield protocol must have the following properties:

• Enable yield exposure without equity exposure. This is the fundamental goal of any real yield protocol: allow the separation of yield exposure from equity exposure.

• Allow a finite amount of yield to be sold. Yield sellers need the ability to sell a limited amount of their future yield, not an infinite stream of future yield. This is necessary to distinguish our yield token from equity. Otherwise, the yield token effectively becomes priced like an equity token, since equity tokens are priced at the net present value of all future yield.

• No fixed terms. A one-size-fits-all approach doesn’t work. Some yield sellers may want a one month term, while others may be comfortable with a year or more. No matter what term you pick in your protocol, you’re going to make someone unhappy. The only term that works is if everyone picks their own term.

• Work with mixed tokens. Unlike inflation yield, real yield is paid out in a token that is different from the protocol’s governance token, typically an L1 token like ETH, or in USDC. The yield is generated by the governance tokens. A real yield protocol needs to work with this distinction.

• Handle variable yield rates. Unlike inflation yield, which is hardcoded in a smart contract, real yield is always variable, since it is based on protocol revenue. One day might generate 1.5 ETH per token, while the next day might drop to 0.9 ETH per token, or rise to 3.4 ETH. A real yield protocol needs to expect this variation.

With these requirements in mind, we developed the core primitive of LSD: transferable yield slices.

Transferable yield slices

A transferable yield slice is a new DeFi primitive that meets the above requirements. Each yield slice has the following properties:

• An ID to reference the specific slice.

• An amount of yield promised to be paid to the owner of that slice.

• A number of generating tokens locked into the slice, which are producing the yield.

• A beneficiary to receive the generated yield.

• A claimant that will receive the locked generating tokens, once all the promised yield is repaid.

A yield slice is a promise to pay a certain amount of yield, generated by some locked tokens. The promised yield goes to the beneficiary of the yield slice. Once the promise is fulfilled, the generator tokens are unlocked and returned to the claimant.

Lets emphasize some important points about yield slices.

Yield slices are non-fungible. Yield slice 1 is different from yield slice 2 and yield slice 3, and so on. Specifically, they are different because the ratio of yield promised to generating tokens is different. Consider, as an example, a yield slice which locks 5000 LOOKS tokens, and promises to pay 10 ETH in yield from the underlying. This yield slice is not the same as one which locks 200 LOOKS tokens, and promises to pay 40 ETH in yield. The first yield slice has more generating tokens, and has made a smaller promise. It will repay its promise faster.

Yield slices can be transferred between accounts, either in part or in whole. When you transfer a yield slice, two things happen. First, the receiving account gets an increase in the yield it is promised. Second, the receiving account gets an increase in the number of generating tokens backing its slice.

An example will help illustrate this. Suppose you start with the following two yield slice:

Slice ID                     1
Yield promised               10 ETH
Generator tokens attributed  5000 LOOKS
Beneficiary                  0xAlice

Slice ID                     2
Yield promised               40 ETH
Generator tokens attributed  1000 LOOKS
Beneficiary                  0xBob

Note that we have omitted the claimant account information in the above examples.

In the example, account 0xAlice transfers half of her slice to 0xBob using the following contract method:

transferYieldSliceBenefits(fromSliceId: 1, toSliceId: 2, amount: 5) 

After this transfer, our accounting looks like this:

Slice ID                     1
Yield promised               5 ETH
Generator tokens attributed  2500 LOOKS
Beneficiary                  0xAlice

Slice ID                     2
Yield promised               45 ETH
Generator tokens attributed  2500 LOOKS
Beneficiary                  0xBob

Notice that the first yield slice has halved the amount of yield it promises, and also halved the amount of generator tokens attributed to paying that yield. Meanwhile, the second yield slice has received the transfer and therefore seen an increase in both dimensions.

In the above example, note that transferring the yield generated does not impact how the claimants can recover their locked tokens. Claimants are the initial sellers of a yield slice, and they can recover their locked tokens once those tokens generate the promised yield. Even if the beneficiary changes, and parts of the slice are moved around, the claimant is credited for the yield generated by his initial lockup.

Risks and rewards of yield slices

Like any financial instrument, yield slices have risks and rewards for buyers and sellers.

Let's look at the buyers first. If you buy a yield slice, you are paying some upfront tokens in exchange for more of that token in the future. For this example, let's assume we are dealing with yield paid out in ETH, and let’s suppose a buyer paid 1.0 ETH for the next 1.2 ETH of yield from an allocation of tokens. This buyer has looked at the historical data, and if everything stays the same, he will generate a nice 20% APR return on this purchase.

In this transaction, the buyer gets two benefits. First, he is able to access yield without full equity risk. If you recall, this was the first goal of our yield protocol: separate yield risk from full equity risk. His second benefit is the APR he is receiving. However, the buyer also takes on some risk. Suppose the underlying protocol starts losing users. The revenue it generates will go down, and the APR goes down as well. If it takes eighteen months to repay the 1.2 ETH, the buyer's APR drops to around 13%.

Next, let’s look at the sellers. If you sell a real yield slice, you are receiving some upfront ETH in exchange for paying back more ETH in the future. We can use the same example as above: you, the seller, receive 1.0 ETH today, and you promise to give the buyer the next 1.2 ETH generated by your protocol tokens.

As the seller, you get two benefits as well, which are the inverse of the buyer's benefits. First, you get some upfront cash which you can spend today. Second, you can maintain your equity exposure over the long run. Together, this means you can get liquidity without selling your stake in the token.

The sell side is not without risk either, however. After you sell future yield, your tokens are locked until they generate the promised yield. If the yield on the protocol token drops, the lockup time is longer than you expected.

Use cases for yield slices

The primary use case for buying yield slices is to get yield exposure without equity exposure. An equity’s price is the net present value of all its future yield. It is hard to predict future yield into infinity, and as a result equity price have high volatility, both on the upside as well as the downside. Investors who do not want that risk can buy a yield slice from the same protocol instead: it is easier to predict the yield over the next 1 year than the next infinity years. As a result, the yield slice will have a more predictable price, and therefore appeal to a different risk/reward profile.

On the flipside, there are two main use cases for selling yield slices. The first is sales by investors in a protocol. An investor in a protocol holds some of its tokens, but is not involved in the day to day operation of the protocol. An investor may want to sell a yield slice if he wants some upfront liquidity without having to wait a year for the yield to be generated. If an investor is confident he will hold a token long term, he can sell some of it future yield for cash today. He can use this cash for consumption, or he can double down his investment in the original token.

Another use case for selling yield slices is by the protocol operators themselves. Protocol operators hold large amounts of their own token in treasury. It is hard to sell large quantities of a protocol token without moving the price. Additionally, a protocol selling its own token is a negative signal to the market, and could reinforce the price dip caused by a large volume sale. Finally, protocol operators are naturally long on their own token, so they are disinclined to sell it.

Selling a yield slice solves all these problems: the protocol operators can get upfront cash for development and marketing, without affecting the token price.

We hope this post has made it clear how yield slices work, and why they are useful. In a later post, we’ll get into the technical implementation of yield slices in LSD. If you want to get more updates on yield slices, follow us on Twitter and join our Discord.

LSD is a new protocol for buying and selling real yield. Our previous post explained why real yield will be the next trend to bring DeFi and web3 into the mainstream.

In this post, we’re going to talk about how our protocol works, and specifically get into details on the central primitive of LSD: transferable yield slices.

Prior art and requirements

Transferrable yield slices are a yield derivative that underlies the LSD protocol. Before getting into details of how they work, let’s mention the prior art, and go over the requirements we had for yield slices.

LSD is not the first protocol to deal with yield derivatives. Some previous projects in this area include Pendle, Element, and Timeless. We’re not going to discuss the specifics of how LSD differs from them in this post (we’ll talk about that in a later post), but we want to explain the requirements that we had when designing LSD. We started with the end user experience, and developed the protocol to meet those needs. None of the existing yield protocols meet all the requirements below.

A real yield protocol must have the following properties:

• Enable yield exposure without equity exposure. This is the fundamental goal of any real yield protocol: allow the separation of yield exposure from equity exposure.

• Allow a finite amount of yield to be sold. Yield sellers need the ability to sell a limited amount of their future yield, not an infinite stream of future yield. This is necessary to distinguish our yield token from equity. Otherwise, the yield token effectively becomes priced like an equity token, since equity tokens are priced at the net present value of all future yield.

• No fixed terms. A one-size-fits-all approach doesn’t work. Some yield sellers may want a one month term, while others may be comfortable with a year or more. No matter what term you pick in your protocol, you’re going to make someone unhappy. The only term that works is if everyone picks their own term.

• Work with mixed tokens. Unlike inflation yield, real yield is paid out in a token that is different from the protocol’s governance token, typically an L1 token like ETH, or in USDC. The yield is generated by the governance tokens. A real yield protocol needs to work with this distinction.

• Handle variable yield rates. Unlike inflation yield, which is hardcoded in a smart contract, real yield is always variable, since it is based on protocol revenue. One day might generate 1.5 ETH per token, while the next day might drop to 0.9 ETH per token, or rise to 3.4 ETH. A real yield protocol needs to expect this variation.

With these requirements in mind, we developed the core primitive of LSD: transferable yield slices.

Transferable yield slices

A transferable yield slice is a new DeFi primitive that meets the above requirements. Each yield slice has the following properties:

• An ID to reference the specific slice.

• An amount of yield promised to be paid to the owner of that slice.

• A number of generating tokens locked into the slice, which are producing the yield.

• A beneficiary to receive the generated yield.

• A claimant that will receive the locked generating tokens, once all the promised yield is repaid.

A yield slice is a promise to pay a certain amount of yield, generated by some locked tokens. The promised yield goes to the beneficiary of the yield slice. Once the promise is fulfilled, the generator tokens are unlocked and returned to the claimant.

Lets emphasize some important points about yield slices.

Yield slices are non-fungible. Yield slice 1 is different from yield slice 2 and yield slice 3, and so on. Specifically, they are different because the ratio of yield promised to generating tokens is different. Consider, as an example, a yield slice which locks 5000 LOOKS tokens, and promises to pay 10 ETH in yield from the underlying. This yield slice is not the same as one which locks 200 LOOKS tokens, and promises to pay 40 ETH in yield. The first yield slice has more generating tokens, and has made a smaller promise. It will repay its promise faster.

Yield slices can be transferred between accounts, either in part or in whole. When you transfer a yield slice, two things happen. First, the receiving account gets an increase in the yield it is promised. Second, the receiving account gets an increase in the number of generating tokens backing its slice.

An example will help illustrate this. Suppose you start with the following two yield slice:

Slice ID                     1
Yield promised               10 ETH
Generator tokens attributed  5000 LOOKS
Beneficiary                  0xAlice

Slice ID                     2
Yield promised               40 ETH
Generator tokens attributed  1000 LOOKS
Beneficiary                  0xBob

Note that we have omitted the claimant account information in the above examples.

In the example, account 0xAlice transfers half of her slice to 0xBob using the following contract method:

transferYieldSliceBenefits(fromSliceId: 1, toSliceId: 2, amount: 5) 

After this transfer, our accounting looks like this:

Slice ID                     1
Yield promised               5 ETH
Generator tokens attributed  2500 LOOKS
Beneficiary                  0xAlice

Slice ID                     2
Yield promised               45 ETH
Generator tokens attributed  2500 LOOKS
Beneficiary                  0xBob

Notice that the first yield slice has halved the amount of yield it promises, and also halved the amount of generator tokens attributed to paying that yield. Meanwhile, the second yield slice has received the transfer and therefore seen an increase in both dimensions.

In the above example, note that transferring the yield generated does not impact how the claimants can recover their locked tokens. Claimants are the initial sellers of a yield slice, and they can recover their locked tokens once those tokens generate the promised yield. Even if the beneficiary changes, and parts of the slice are moved around, the claimant is credited for the yield generated by his initial lockup.

Risks and rewards of yield slices

Like any financial instrument, yield slices have risks and rewards for buyers and sellers.

Let's look at the buyers first. If you buy a yield slice, you are paying some upfront tokens in exchange for more of that token in the future. For this example, let's assume we are dealing with yield paid out in ETH, and let’s suppose a buyer paid 1.0 ETH for the next 1.2 ETH of yield from an allocation of tokens. This buyer has looked at the historical data, and if everything stays the same, he will generate a nice 20% APR return on this purchase.

In this transaction, the buyer gets two benefits. First, he is able to access yield without full equity risk. If you recall, this was the first goal of our yield protocol: separate yield risk from full equity risk. His second benefit is the APR he is receiving. However, the buyer also takes on some risk. Suppose the underlying protocol starts losing users. The revenue it generates will go down, and the APR goes down as well. If it takes eighteen months to repay the 1.2 ETH, the buyer's APR drops to around 13%.

Next, let’s look at the sellers. If you sell a real yield slice, you are receiving some upfront ETH in exchange for paying back more ETH in the future. We can use the same example as above: you, the seller, receive 1.0 ETH today, and you promise to give the buyer the next 1.2 ETH generated by your protocol tokens.

As the seller, you get two benefits as well, which are the inverse of the buyer's benefits. First, you get some upfront cash which you can spend today. Second, you can maintain your equity exposure over the long run. Together, this means you can get liquidity without selling your stake in the token.

The sell side is not without risk either, however. After you sell future yield, your tokens are locked until they generate the promised yield. If the yield on the protocol token drops, the lockup time is longer than you expected.

Use cases for yield slices

The primary use case for buying yield slices is to get yield exposure without equity exposure. An equity’s price is the net present value of all its future yield. It is hard to predict future yield into infinity, and as a result equity price have high volatility, both on the upside as well as the downside. Investors who do not want that risk can buy a yield slice from the same protocol instead: it is easier to predict the yield over the next 1 year than the next infinity years. As a result, the yield slice will have a more predictable price, and therefore appeal to a different risk/reward profile.

On the flipside, there are two main use cases for selling yield slices. The first is sales by investors in a protocol. An investor in a protocol holds some of its tokens, but is not involved in the day to day operation of the protocol. An investor may want to sell a yield slice if he wants some upfront liquidity without having to wait a year for the yield to be generated. If an investor is confident he will hold a token long term, he can sell some of it future yield for cash today. He can use this cash for consumption, or he can double down his investment in the original token.

Another use case for selling yield slices is by the protocol operators themselves. Protocol operators hold large amounts of their own token in treasury. It is hard to sell large quantities of a protocol token without moving the price. Additionally, a protocol selling its own token is a negative signal to the market, and could reinforce the price dip caused by a large volume sale. Finally, protocol operators are naturally long on their own token, so they are disinclined to sell it.

Selling a yield slice solves all these problems: the protocol operators can get upfront cash for development and marketing, without affecting the token price.

We hope this post has made it clear how yield slices work, and why they are useful. In a later post, we’ll get into the technical implementation of yield slices in LSD. If you want to get more updates on yield slices, follow us on Twitter and join our Discord.