---
# System prepended metadata

title: (OUTDATED) TempleDAO - Thoughts On Runway

---

# (OUTDATED) TempleDAO - Thoughts On Runway

**THIS ARTICLE IS OUTDATED.** Temple's mechanics have been completely revamped, and the information in this article no longer applies.

**Edit:** I no longer believe that the issue I describe in this post is critical to the longevity of the protocol. But I still think it is something to be aware of. 

In my [last post](https://hackmd.io/@bull4361/r1aUCsCwY), I talked a bit about runway, but I had more thoughts and details to share.

What I want to discuss here is the fact that the runway effectively has an upper bound. This means that at a certain point, the runway will basically stop increasing no matter how much more FRAX is sacrificed. 

But before we can understand why, we need to understand how the runway is calculated. 

### Calculating The Runway
Like I mentioned in the last post, the runway is dependent on 3 variables:
- The EPY (daily yield), denoted by $r$
- The amount of TEMPLE staked, denoted by $S$
- The amount of TEMPLE in the staking rewards pool, denoted by  $P$

All it really takes to determine the runway is to calculate how long it will take to distribute the entire rewards pool to stakers given the current EPY. 

First we need to calculate how much TEMPLE is in the rewards pool. The amount of TEMPLE owned by the protocol is 

$$\textrm{Total Supply} - \textrm{Circulating Supply}$$

With current numbers this works out to 

$$247,889,574 - 60,398,387 = 187,491,187$$

We also know that 35% of each harvest goes to the staking rewards pool. And since the 20% for boosting IV wasn't minted, that means that the staking rewards pool makes up $35\% / 0.8 = 43.75\%$ of the protocol-owned TEMPLE.

So the staking rewards pool is 

$$P = 187,491,187 \cdot 0.4375 \\ P = 82,027,394$$

Note that this is just an approximation and technically not correct. 

We then calculate the percent-increase in TEMPLE amount stakers would get if the entire rewards pool was distributed to them. We'll call this value $g$, for gainz. 

$$ g = \frac{S+P}{S}$$

So if the current staked supply is 60,398,387 (virtually the entire circulating supply is staked right now), and the staking rewards pool has 82,027,394, then

$$ g = \frac{60,398,387+82,027,394}{60,398,387} \\
   g = \frac{142,425,781}{60,398,387} \\ 
   g = 2.358
$$

Put simply, if you staked one TEMPLE, by the time the entire rewards pool is distributed, you'd have 2.358 TEMPLE. **The amount of TEMPLE you hold would grow by 135.8%**

So now we know by what percent the staked supply would grow if the entire staking rewards pool was distributed, and we know the EPY (0.7%). So we need to find the number of days, $t$, such that:

$$1.007^t = 2.358$$

Rearranging this, we get:

$$t = \log_{1.007}(2.358) \\ 
  t = 122.9$$
  
And we round this down to 122 because we care about the number days the protocol can afford to distribute the full EPY.

As one formula, the calculation looks like this:

$$ t = \log_{r}\left(\frac{S+P}{S}\right) $$


I want to point out a relevant property of this formula: for constant $r$, what determines $t$ is the ratio of $P$ to $S$. This is important for the next section. 

Now that we understand how the runway is calculated, we can dig into why it has an upper bound.


### The Upper Bound

Let's turn back time to epoch 0, right when the Fire Ritual started. Before any staking rewards were ever given out.

As we know, whenever FRAX is sacrificed, 1/6th (16.66%) of the FRAX is used to mint TEMPLE that is immediately given to the user and added to the staked supply, 35% * 0.8333 = 29.166% is added to the staking rewards pool. 

At this point, if we were to calculate $g$, it would be

$$ g = \frac{29.1\overline{6}\% + 16.\overline{6}\%}{16.\overline{6}\%}  \\ 
g = 2.75$$

Then

$$ t = \log_{1.007}(2.75) \\
t = 145.02$$

Giving us a runway of 145 days. 

As sacrifices slow down and staking rewards begin to be distributed, TEMPLE is moved from the staking rewards pool to the staked supply. 

This has the effect of reducing the staking rewards pool to staked supply ratio, thereby reducing the runway (as expected).

Now what would happen if there was suddenly a huge surge in FRAX sacrifices? Say, for argument's sake, $1B FRAX sacrificed within a day?

We'd expect the runway to shoot up a ton (at least logarithmically) as well, right? But that's not what happens. 

Since 29.166% of the new FRAX sacrifices goes to the staking rewards pool, and 16.66% is added to the circulating supply (again, $g=2.75$), the sacrifice simply cannot push the current $g$ value higher than 2.75, no matter how large it is. 

This puts an upper bound on the supply that cannot be broken with FRAX sacrifices alone.

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

The truth is that this upper bound *can* actually be broken, and that's because FRAX sacrifices aren't the only source of revenue for the TempleDAO treasury. Revenue sources like an arbitrage bot, management fees from automated investment strategies, etc. would increase the size of the staking rewards pool without also increasing the size of the staked supply, which would push the gainz factor higher than 2.75 (increasing the runway).

A bunch of people unstaking their Temple would increase the upper bound.

"If that's true, then what's the big deal?", you might be asking. "If the runway only has an upper bound under a very specific set of assumptions, who cares?"

Despite this upper bound being somewhat unlikely to technically exist in practice, I think it says  something very important about the mechanics of TEMPLE. 

**This hypothetical upper bound implies diminishing value capture by the protocol.**

### Diminishing Value Capture

Before I expand on this, I want to point out two things:
1. We shouldn't have to rely on people unstaking in order to increase the runway. You'd expect a runway increase to correspond to treasury growth. Why would a significant number of people want to unstake while the treasury is still growing? 
2. Although Temple will soon have additional sources of revenue, the core mechanics should be sound regardless. It's likely that, at least in the beginning, the vast majority of treasury growth will continue to come from sacrifices and not other revenue sources, and so we want to be able to direct much of this growth towards increasing the runway, among other things. 

With that out of the way, let me explain what I mean by diminishing value capture.

If at some point, additional FRAX sacrifices, no matter how large, barely increase the runway or don't increase it at all, then the only way current holders benefit from these sacrifices is that they slightly increase the intrinsic value.

The entire appeal of Temple is that it basically converts what would have been volatile price action into long term yield, by putting a ceiling on price and generating revenue for the treasury whenever the price hits that ceiling. 

It's supposed to grow the runway a ton during exponential surges in demand, so that it can afford to distribute yield for a long time during periods of very low demand (i.e., bear markets).

But if there's a hard limit to how much FRAX sacrifices can increase the runway, this just isn't possible. 

In my opinion, this is a serious issue that *will* hurt the longevity of the protocol if it isn't fixed ASAP.


### Potential Solutions
All of this complaining would be no good if I didn't at least try to provide some potential solutions to this problem, so here they are: 

#### Dynamic EPY

This doesn't solve the problem of increasing runway beyond the upper bound, but it does solve the problem of ensuring existing holders consistently get new yield from new sacrifices. Basically, the closer the runway gets to the upper bound, the higher the EPY rises in order to bring it back down again faster, so that new FRAX sacrifices can continue to give existing holders more yield. 

I'm not a huge fan of this solution for a couple of reasons (doesn't actually increase runway beyond upper bound, intentionally reduces runway faster), but I thought I'd include it anyway. Maybe it will inspire someone to come up with something better. 

#### Price premium on top of the 3-6x IV
This mechanism would work as follows: as long as the runway is well below the current upper bound, the OTC price would remain at 6x IV. But as the runway approaches the current upper bound, the OTC price would increase slightly beyond 6x IV, and this entire premium would go right into the staking rewards pool. 

The 6x IV + premium wouldn't get rid of the upper bound, but it would increase it to a higher one. Then once this new upper bound is close to being hit, the premium would increase again.

If demand suddenly dries up, this premium would slowly decrease at about the same rate the runway is decreasing.

I'm partial to this idea, as it would actually sustainably increase the runway. The main downside I can think of is that the OTC price would go up and down rather than be up only. 


<hr>

Both of these mechanisms need to more rigorously fleshed out (for example, exactly how much should the premium be at any given point based on the runway?)

If you have any other ideas, please post them in the product channel and tag me! I'd love to hear and discuss them.

Thanks for reading! 
Twitter: [@bllu404](https://twitter.com/bllu404)




