No Money, Mo’ Problems?

12 min readDec 16, 2022

Introduction

As 2022 comes to a close, I would like to share some thoughts on where we are, and where I think we can go in the new year. First and foremost, I think we are in a much more independent, stable position than we were a few months ago. Previously, I felt like we were clawing back from a cliff’s edge, and any gust of wind could have taken us over. Now, I feel the ground beneath us, and it is solid… yeah, our pockets may still be empty and we are still broke, but the tides are changing. Recent proposals directly bring more funds into the community pool, while others have the goal of bringing value back to the chain. And of course we have the Oracle pool. An unexpected windfall from the depeg market swaps that turned out to be a life saver for the recovery.

But don’t we have a problem? Isn’t time running out on the Oracle pool distribution? Well, kind of …but maybe not.

Let’s begin by looking at how delegators and validators earn rewards.

At this moment, we are literally earning 99% of all of the staking rewards from the Oracle distribution, 1% from gas fees, and 0% from inflation. Let’s now dig into the mechanics behind each of these variables (Oracle, Gas, and Inflation) and see that we may have actually have mo’ money and options than we realize.

Oracle Pool

The urgency in innovation, development, and progress is inherent in this field. The open source nature of development enables verification of correctness of code and forces developers to innovate to remain competitive. That is what attracted me to this technology, and why I continue developing in this space. For the Oracle pool, a different sense of urgency has spurred discussion and development; however, the situation of the Oracle pool may not be as dire as we think. One common statement that I hear in the LUNC community is that the chain will die once the funds in the oracle pool run out, and that this will run out in the next 2 years. This idea comes from the parameters of the Oracle shown here.

# Oracle Distribution Algorithm
# totalPeriodRewards = RewardPool x (votePeriod / rewardDistributionWindow)
votePeriod = 5                       ## Every 5 blocks, distribute oracle rewards
rewardDistributionWindow = 9400000   ## 9.4M blocks, or 652 days (~1.7 years)
r = votePeriod/rewardDistributionWindow
numVotesPerDay = 14400/votePeriod

The main parameter to pay attention to is the rewardDistributionWindow. This states that the percent Oracle distribution every voting period should be calculated over a span of ~1.7 years. Thus, if there were a constant/linear distribution out of the pool, it would deplete in that amount of time. The rewards computed over the votePeriod is,

where dist_t1 is the first time step, pool is the size of the Oracle pool, and r, is the percent distribution calculated by,

Basically, every 5 blocks (~every 30 seconds), 0.000531% of the Oracle is dispersed. Now, the thing to realize is, the distribution is not constant. The size of the pool continues to decrease every voting period. Thus, the distribution at the next time step is computing a dispersion of 0.000531% of a smaller pool size. The distribution 5 blocks later (at t=2) will be a decreased pool effected by the previous distribution at time, t=1….

or more precisely by substitution and some algebra,

And we can continue this expansion to the next time step, t=3.

And if we simplify this,

Distribute out the pool variable,

And one more time to t=4 to recognize the pattern.

Dig deep into your memories now…. you might recognize the pattern of coefficients from high school math. It is the pattern of Pascal’s triangle, (1,-2,1) (1,-3,3,-1), with an alternating series… whose coefficients can be solved in the general case of t=n by the Binomial theorem.

This expansion of the sum of binomial coefficients is equivalent to the closed form solution of a more simple polynomial expression,

All this to say, we can compute the amount of the distribution from the Oracle pool at any timestep/point in time in the future, denoted by n.

Let’s make this concrete and put some hard numbers in. As of December 13, we have about 272B LUNC and 935M USTC in the Oracle pool. For the moment, we are ignoring all the other dust (other minuscule stables). If you want to see the current state of the oracle pool, you can look here https://finder.terra.money/classic/address/terra1jgp27m8fykex4e4jtt0l7ze8q528ux2lh4zh0f

# Starting point, Dec 13,2022
lunc = 272764796913         ## 272 B lunc, around $45M USD
ust = 935235498             ## 935 M ustc, around $23M USD
staked = 894076663267       ## 894 B lunc
totalSupply = 6872832823412 ## 6.87 T lunc

If we plot the above distribution over the period of 10 years, this is the graph that we see. There is a pretty steep drop early on in the first year and a tapering off as time goes on. In fact, the reward algorithm asymptotically approaches zero (meaning the Oracle pool will never run out), and continues on well past the 2 year mark.

If you would like to verify this solution, please see the code used to compute this distribution.

# Solve binomial equation and the analytical solution

def solveReward(t,r):
    sum1 = 0
    for i in range(t+1):
        sum1 = sum1 + ((-1)**(i))*comb(t,i)*Decimal((r**(i+1)))
    return sum1

def solveRewardAna(t,r):
    return r*(1-r)**t

# Verification of Distribution via 3 methods, numerical, binomial expansion, and closed form

r = votePeriod/rewardDistributionWindow
n = 1000
binom = lunc*solveReward(n,r)
analytic = lunc*solveRewardAna(n,r)

print(totalLuncRewards[n])    # Numerical solution
print(binom)                  # Binomial expansion
print(analytic)               # Analytic closed form solution

145010.50414723594
145010.5041472357588397052805
145010.50414724177

The distribution of LUNC from the Oracle pool today is around 145k total across all validators every ~30 seconds. One year from now, it will drop to 82k every ~30 seconds. If we keep going to 2 years, 3 years, 5 years, 10 years, it is 47k, 27k, 8.8k, and 541, respectively.

Ok, but what does this mean in terms of staking rewards and returns? Is this enough to keep yield percentages competitive? For the purposes of these calculations, we need to assume that several factors stay the same including amount staked, swap price of LUNC/USTC, no increase in the Oracle pool amount, and no compounding.

# Assuming everything stays the same (amount staked, no increase oracle, no compound, swap LUNC UST rate, etc.)

oneYear = int(numVotesPerDay * 365)
oneYearLunc = sum(totalLuncRewards[0:oneYear])
oneYearUst = sum(totalUstRewards[0:oneYear])

###  Swap Rates
pLunc = 0.000165
pUst = 0.025
swapRate = pUst/pLunc

oneYearStake = oneYearLunc/staked
oneYearStakeUst = (oneYearLunc + (oneYearUst*swapRate))/staked
print(oneYearStake)
print(oneYearStakeUst)

0.13066713800791213
0.1985492125845048

Given the amount distributed across all the stake (894B), one could expect Oracle pool yields in the first year (2023–2024) to be 13.06% just LUNC, but if the swapped USTC is included, the returns are 19.85%. Auto compounding could slightly improve the yields. There are other yield percentages floating out there and I believe they may not be taking the decreasing pool size into account. For example, if we assume constant pool size, the reported yield would be 17.04% LUNC only, and 25.90% with LUNC+swapped USTC, but these may be too high in reality.

In the year 2024–2025, we can expect approximately 7.47% LUNC returns, and in 2025–2026 the rates fall to 4.27% LUNC returns again given a diminishing Oracle pool and all other factors stay the same. (USTC swaps are not included because they would be incredibly difficult to predict this far out). As long as we can distribute the delegations more evenly across the active validator set, this signals that there is no doomsday Oracle depletion event that will happen two years from now.

Gas Fees

So yields stay fairly competitive years out, but definitely loose their attractiveness as time goes on. We can combat this by addressing the other variables in the total staking returns. One solution is by tackling the gas fees on transactions.

We are currently averaging about 2.09 transactions (non-oracle votes) per block over the past week. Before the depeg in April 2022, the blockchain was averaging somewhere between 40–50 transactions per block, see the data here. The history of the chart indicates that they are also not counting oracle transactions. This gives us the sense that a 20x–25x in the number of transactions would be the upper bound one could expect.

Further data scrapped data from the chain over the past week shows about 567,000 in LUNC fees collected, with a gas multiplier of 5.665. This computes to approximately 3.2M LUNC is collected in gas fees per week, where half is being sent to staking rewards, and half is being sent to the community pool. Interestingly, the computation of the gas fee distribution does not match the actual amount going to the community pool. It seems like the estimate is nearly 13x too low. If you look at the feeCollectorModule, it receives much more than the actual gas fees in additional deposits from smart contracts such as TerraSwap, and also there are validators (such as Luna Station 88) that also send part of their rewards to the community pool.

Thus, the calculations that follow are essentially a lower bound and in actuality the returns could be much greater. Right now our gas fees are one of the lowest of any blockchain; this is a byproduct of the hyperinflation of LUNC. Raising the gas fee to something more in line with other major chains (Luna v2, Juno, LTC, etc) could help combat the depleting Oracle pool. In fact, fees are so low, we could 60x our gas fees and still remain under a penny (~$0.009) for a basic send transaction.

Analyzing our current volume, approximately every penny of gas fees would provide a 0.47% bump in APR (it is actually 0.94%, but remember half of this goes to the community pool). Given that pre-crash, the volume was 20–25x larger than it is now, I think a reasonable target goal would be a modest 5x in volume by the end of next year, especially after technological parity with Luna v2. Basically, what the data shows is that if we are able to 5x the number of transactions, and the community decides to raise gas fees to 0.009 per transaction, the staking yield after the first year would be 16% as opposed to 13% from the Oracle distribution alone, with 50% going to the community pool. If the pool is sufficiently capitalized via seigniorage, we could divert all gas fees to staking rewards leading to a 19% LUNC yield in the next year.

Inflation

Finally, the last term in the staking rewards computation is inflation. Inflation is at 0% right now and provides no contribution to current staking rewards. This means that there is no percent minting every block as one sees in Luna v2 (annual inflation is set to 7%). This zero percent inflation aids the burn narrative, but is an option that the community can revisit in the future. For example, if staking rewards become too low, or if on-boarding utility becomes more important than the burn narrative, a modest inflation could be put in place so that chain becomes more attractive to build upon, rather than further taxing users and projects to shoulder the cost burden.

Capitalization Plan — L1 Development

At this time, many people are directly addressing capitalizing the Oracle pool, which is necessary and extremely important; however, one of the main purposes of this article is to highlight that we can also focus on the gas fees, inflation, and decentralization of voting power to incentivize delegation and attract high quality validators. We can also counteract the diminishing rewards by focusing on increasing the number of transactions processed every block, and attracting utility.

And… probably the best way to raise transactions and attract utility is to achieve technological parity with Luna v2 and the broader cosmos ecosystem. Here I would like to outline where we currently are in terms of Layer 1 status, and offer some steps necessary for parity.

Summary of Present State

This is a summary of the current state of the chain with regard to the L1 status. These items what was left of the old chain, as well as some of the improvements made to the L1 layer since the depeg. Many core upgrades are necessary w/ particular attention needed to support the various parties affected by the upgrades.

SDK v0.44.5-patch + lunc patches to support oracle
Tendermint v0.34.14 + Oracle patches
Enormous, inestimable archival node size (>8tb I guess)
Numerous known previous unknown state transitions with breaking changes
Contract security updates
Special SDK type updates
Unknown if a new archive node can be produced
Wasmd v0.16.6
Oracle feeder sha256 fix
Upgraded docker tooling
ICS Patch
Re-opened IBC channels
ABS Keeper (beta)
TC Constitution (beta)

Summary of required L1 changes to be completed

SDK v0.45.11 (+) with lunc patches to support oracle
Tendermint v0.34.21 (ideally 0.37) with Oracle patches (note priority tx change in tendermint)
Cosmwasm v1.0.0 (+)
LocalTerra replacement for Classic
Assess and develop cosmos sdk upgrade handlers (version mapping UpgradeHandlers)
Create and document upgrade procedure (software upgrade gov proposal)
Assess and report effect on L2 wasm contracts in 0.16.6
Assess and report new genesis creation (currently cannot spawn new genesis with json file > 4GB)
Incubator whitelist feature for on-chain tax exemption (ideally governance proposal)

Summary of upgrade process

Upgrade chain w/ above L1 updates (either bump or new genesis)
Coordinate w/ validators, coordinate w/ CEXs
Utilize software upgrade proposal (if possible, or at least build it to use moving forward)
Identify and contact L2 smart contracts on chain
Provide migration instructions/documentation to L2 dApps

Additional L1 Support and Maintenance requirements

Create IBC channel to Luna v2
Assess LCD/FCD compatibility with v0.45.1 (+) (Note mantlemint may not work)
Provide community/public access to LCD and FCD endpoints (encourage people to run their own nodes)
Provide public genesis.json and updated addrbook.json
Establish and maintain relay between LUNC chain and LUNA chain

Special Note on TFL’s Interchain Wallet

In order for LUNC to be compatible with the new TFL Interchain wallet, all of the above needs to happen plus an upgrade bech32 prefix from “terra” to “terrac”. Unfortunately, this is a very complicated, breaking L1 solution that is unlikely to happen within the next few months (or years).

That being said, TFL will investigate and try to solve the problem at the wallet level, instead of relying on the change at the blockchain level. Since TFL’s software is all open source, I would propose that the Classic chain also direct some development resources towards forking Interchain wallet, developing our own solution to the bech32 problem at the wallet level, and presenting multiple solutions to TFL. We could take an active approach to interoperability instead of passively waiting for external support.

As for timeline, the short answer is that it “depends” on a lot of things. However, what I can say is, figuring out how/when/and who can get this done is the number one priority of the Terra Grants Foundation program that I am currently running, and we are working to make this a reality.

Happy holidays!