Reliquary — The new chef in town?

There is this belief, or maybe even inner hope, that big projects or visions are always beautifully planned and executed. Followed through no matter what, anything else would be madness right? Pure chaos!

I’d argue that this is an illusion and any project blindly following an initial vision will at best end up in something that smart people out there working with neural networks would call a local minima. It describes a common scenario that occurs when searching for an optimal solution for a problem. After an initial implementation, we might end up with a solution which looks pretty darn good (resembled as a minimum of errors) and if we move away from it, the result gets worse. We’re tempted to assume that this is the best we can do, but if you change it enough to make it over the hump, you could find an even better result.

When training neural networks this is often done by adding some noise in the form of randomness. Or as my prof liked to say, you have to shake the system. I find this a beautiful image which I also try to apply to solutions I build or even life itself. Maybe you think your life is pretty good as it is, but sometimes you gotta shake it a bit with some random decisions and eventually you might find a better life without knowing that there was one in the first place.

People actually working with neural networks are probably rolling their eyes about my childish comparison and naive explanation but thats ok, I still like it. It helps me to keep an open mind and look for solutions that I don’t even know exist yet!

But why are we talking about this in such great length? I thought this blog was about something called Reliquary from those legendary guys called the Byte Masons!

Well, you might remember some months ago, a proposal was passed to implement vote locking for fBEETS. So what happened to it? The convex based contract was already audited and ready to go right? The truth is, it always felt like a somewhat local minimum to us. So the fact that I was gone for a while on parental leave, the V2 release and the general shift in market conditions gave us some time to reflect and look out for other solutions. While keeping our eyes and ears open, we heard about Reliquary from the Byte Masons. Something about staking with maturity levels (tranches) bound to NFT’s that could be sold on a secondary market. This obviously caught our attention, so we decided to have a closer look, and figured we might as well share our findings with anyone interested.

An evolution of the Masterchef

Reliquary can be seen as an evolution of the Masterchef contract. It’s very similar in many ways but adds more flexibility and some additional layers. Similar to the Masterchef, we have a reward token which is distributed to pools based on allocation points. Users stake tokens (usually liquidity pool tokens) in pools to get rewards based on their share. So far, nothing out of the ordinary. Let’s look into how emissions are calculated and distributed to pools.

Token emissions are a very hot topic and an important factor when investing in a token. With the Masterchef, its always a bit of a hassle to make sure you follow the emission curve. It’s a static value which has to be updated at the right point in time. Reliquary helps us to stay on track. The emission rate is extracted into a separate contract which can implement any desired strategy. We could have a contract which automatically adjusts the emission based on a predefined curve making any manual interaction obsolete. This contract is upgradable, so if the emission curve needs adjustment, this can be done. Beautiful, get rid of those manual tasks! Let the robots do what they do best and leave me alone with this nonsense.

Now that we know where the emission rate originates, let’s see how we calculate the emission for a specific time period.

Where the distribution for a pool is based on its allocation points in relation to the total allocation points

As an example, if we reward 10 BEETS per second and we want to distribute our emissions evenly to pool A and pool B, we just add those 2 pools with the same allocations points (given we have no other pools configured). So if we give both pools 10 allocations points and wait 60 seconds, the emissions for pool A would be:

Both pool A & B get 30 BEETS for the 60 seconds passed. Now in the classic masterchef, those 30 BEETS are distributed based on the share of a users position relative to the total tokens deposited in a pool.

This is where Reliquary adds some additional layer with maturity levels (tranches). For each pool, we can define different maturity levels and weight the rewards for each level with allocation points. The maturity of a user’s position is calculated from the entry timestamp and the current block timestamp

Maturity always translates to a level which is defined by a minimum maturity. So we progress up in levels when we stay long enough to meet the minimum maturity requirement. Let’s look at an example pool:

For level 1, you have to be in the pool for 0 seconds, for level 2 86400 seconds (1 day) and so on. Each level has allocation points defined which impact the reward distribution to users. Additionally, each level has the combined total balance of all users that are currently in this level. With this, we can now calculate the rewards for a user. So let’s see some more math!

Ok, take it easy with the formulas! I know, but stay with me, I’ll explain! First we have the token emissions dedicated for pool A which we already calculated before. Now instead of just using the fraction of the user share of the total balance like the Masterchef does, we take the levels into account. For this, we multiply the staked balance of user X in pool A with the allocation of his maturity level and divide it by the sum of the total balance for each level multiplied by its allocation points.

Not much easier in text form after all. So let’s do a step by step example.

If a user has a balance of 1000 with a maturity of level 2 (20 allocation points), this would result in a weighted balance of 20'000.

Now we divide that against the total weighted balance

With the token emissions from our sample before of 30 BEETS, this leaves us with

Now this looks easier I’d say! But how would it look if we would have been in maturity level 4?

Double the rewards! Great stuff.

Ok you almost got me there, but this looks pretty similar to some locking contracts where you get more rewards the longer you lock. So why not just do this with locking where user can also early withdraw? Would be kinda the same result right? Wrong! And here we come to the next major difference to the Masterchef. Staked positions are not bound to a wallet address but rather to an NFT. This enables transfer of staked positions and opens the possibility of a secondary market. And with maturity levels, you can see why it could be interesting to buy staked positions. We could end up with substantially more rewards for the same amount of tokens invested.

Interestingly, the concept of maturity levels (tranches) can be easily extended beyond just reward tokens. Imagine a scenario where a user’s voting power is directly tied to the maturity of their positions. We end up with a system that is the reverse of vote escrow (ve), where voting power is not dictated by how long you are willing to lock your tokens for, but instead how long you’ve been a participant in a protocol. Outside of voting power and reward tokens, any number of game mechanics can be built on top of the maturity of a user’s position.

Pretty cool right? But what happens to my precious level when I deposit more tokens to an already matured position? Remember that the maturity is defined by the current block time minus your entry timestamp. A naive approach would be to just reset the entry timestamp to the deposit time, meaning you have to start from scratch. But that would not be worthy for the Masons! Instead they add the weighted maturity to your entry time

This means if the weight is 1 we end up with what we described above, the new entry point is the current block time.

Now we obviously want to know how the weight is calculated since it has a big impact on our entry point and therefore our maturity. It’s pretty much what we would expect, the relation of the deposit to the already staked balance.

With this you end up with a graph which looks roughly like this

Let’s make an example:

• entry timestamp: 1663156800
• current balance: 1000
• deposit timestamp: 1663243200 ( 1 day later) => maturity 86400
• deposit amount: 500
• maturity at deposit: 86400 => level 2

To recap, we calculate our new entry timestamp with

with our numbers from the example, this results in

which leaves us with a new maturity of

If we check against the maturity requirements for our pool levels, we see that we dropped down to level 1. Sad, but at least we don’t start at 0 maturity.

Now the Byte Masons wouldn’t be the Byte Masons if they didn’t build some utility around it. We can mint infinite amounts of NFTs to deposit to, merge them together or shift deposits from one NFT to the other while still maintaining the correct maturity. So in our example above, we could have been smart and minted our deposit to a new NFT so the maturity level of our existing position isn’t reduced. Once our initial NFT has matured enough so it can handle the new deposit without dropping a level, we could merge them again. I didn’t do the math but it would probably end up with more rewards. I leave that to the true degens out there to figure out!

With this being said, I think we have covered the core of what Reliquary has to offer. It feels like they added some really useful layers to the classic Masterchef, allowing you to create an incentivise to stick around with the possibility to exit if you chose so. Together with the possibility to leverage maturity for voting and other mechanics I’m definitely intrigued!