Increasing the Oracle Rewards Pool

This proposal puts forward my idea for replenishing the oracle rewards pool for staking rewards. It is a further discussion and refinement from my prior proposal "Vision for LUNC".


The purpose of this proposal is to replenish the Oracle pool to limit the decline of staking rewards, improving the attractiveness of the LUNC chain and good long term staking rewards.

The problem:

The oracle pool is being drained at a rate of around 300 million LUNC per day (source LUNCPenguins). The total oracle pool is declining and thus rewards are declining every day. The current rate is about 22.2% per annum (including LUNC+USTC rewards). This is basically a gifted LUNC version of anchor protocol, which attracted many to LUNA. We should value the oracle pool and preserve it, which will draw more to the chain. This will continue to decline and the rate will drop unless we take action to stop or slow its decline.

How to solve the problem:

The problem is an approximate 300M LUNC drop each day. We need to find as much funding as possible to make 300M LUNC per day or at least part of this, to slow the oracle pool decline.

How can we find such funding:

Aside from outside funding, USTC proposals which are long term and are unlikely to be successful in the short term for a variety of reasons including possible legal ones, we need to look to on-chain funding to meet our immediate and ongoing needs. This would need to come from gas fees and transaction costs from tax.

What is my specific proposal:

My proposal to fund the oracle rewards pool has been refined from earlier, and is this:

1. Assuming dapps are partially tax exempt from the burn tax if the recent proposal from dfunk passes (not yet in voting).

2. Pass a parameter proposal to raise the burn tax back to 1.2%.

3. Pass a text proposal to code a split of the burn tax 80% burn 20% to community pool. No seniorage, no minting. The split is direct from the tax itself using the new burn tax anthandler. The code for this is being worked on by the L1 team already (with Ed's prior 50/50% proposal). This should be changeable by parameterisation if we need to adjust the rates. An 80/20% split values burns and our funding needs.

4. Pass by text proposal a CAP mechanism on the community pool of 2 billion LUNC (currently worth 342k USD). This can be changed if needed by parameterisation, lowered or raised.

5. Pass a text proposal (or included with #4) that all funds that exceed the CAP on the community pool flow directly to the oracle rewards pool. My previous proposal said 50/50% burn/oracle, but the daily shortfall in the oracle pool is so big we need 100% of the overflow to oracle pool.

Effects of these changes:

1. Burn tax will increase to 0.96%. This is 4.8x our current burn rate of 0.2% of approximately 50 million per day to = 240M burned per day (subject to volume). When we had the 1.2% burn tax for 3 weeks burns above 200M per day were normal.

2. Community pool funding from tax is 0.24%. This would be an approximate 60M per day to the community pool (1.8 billion LUNC per month).

3. Once the 2 billion community pool CAP is reached, 60M per day would flow directly to the oracle rewards pool. The figure of 60M per day is based on a 80/20% split of 1.2% tax at current volumes. If volume increased like during a bull market for LUNC 3x it could be up to 180M per day, or higher if volume was higher. On-chain volume spikes during LUNC bull runs we have seen it before. If volume increases even more burns would occur and even more funding to the oracle pool once the community pool CAP is reached.

4. The community pool is filled first with priority for development up to the CAP, leaving enough for shorter term development (it replenishes very fast if there is any spend from the pool), then overflow to the oracle pool.


1. More burns.

2. Faster funding of community pool than just gas fees (present situation).

3. CAP on community pool allows us an automated flow to oracle pool without requiring regular governance spending votes, so we avoid unneeded headaches.

4. Faster funding for oracle pool than just gas fees.

5. Reduces oversupply to community pool (not yet a problem but could be later).

6. Funding to community pool is prioritised, then oracle pool.

7. Burns at 80% of 1.2% (0.96%) are still 4.8x higher than the current burn tax rate of 0.2%.

8. If dapps are partially tax exempted their function won't be harshly impacted by the tax raise (if dfunk's proposal passes, not yet in voting).

9. We can push CEX to do off-chain tax on transactions again, as we are increasing the burn rate and they are encouraged to do so also, especially Binance (which is only at 0.1%).

10. We can get back the burn momentum we lost after the loss of the 1.2% after 3 weeks and the minting fiasco.


1. Higher on-chain transaction costs.

2. Possible lower on-chain volumes due to 1.2% tax. This is arguable, as reducing the 1.2% tax did not lead to the promised volume gains. Also over time the tax will become normalised.

3. CAP on community pool of currently 2 billion LUNC ($342k at current price) is not enough for a huge project. One quarter (3 months) of L1 funding is 900M LUNC. In my proposal we can replenish 900M LUNC in approximately 2 weeks. There are presently no viable big spending projects for LUNC. If they appear we can raise the CAP higher than 2 billion. Also as the price rises 2 billion LUNC will be worth a lot more (3x LUNC price is $1.02M and 10x is $3.42M).

Additional measure which can be taken:

Further increase gas fees if appropriate as they partially go to the oracle rewards pool.

Summary: we need to fund the oracle pool. Staking LUNC is a huge draw to the LUNC chain. We were blessed with the large oracle pool which is continually declining. The longer we can preserve it, and find solutions to fund it, the more will be attracted to buy LUNC and stake on-chain due to the passive income it provides. This will increase transaction volume to the chain as more stakers = more people withdrawing rewards daily, swapping USTC to LUNC, and sending to CEX to spend. Also more LUNC staked reduces circulating supply and can lead to increased price.

Better funding for oracle pool leads to longer the rewards will be good, and better passive income from staking. For example a person staking 100M LUNC has a return of approximately 61k LUNC per day (if USTC also converted to LUNC). This is worth $10.4 USD. As the LUNC price rises say 3x to $0.000513 this would be $31.3 per day or $219 per week. LUNC at 10x ($0.00171) would be $104 per day or $728 per week. I gave this example to show that as LUNC goes up in price our staking rates will become even more attractive for people to stake their LUNC or buy LUNC to stake, so it's good to preserve the reward rates as long as possible.

We have a built-in awesome utility of staking rewards which should be a priority to preserve. It's like the LUNC gold mine, and we shouldn't let it deplete quickly and go to nothing.


Increase burn tax to 1.2%, code send 20% to community pool (no mint, no seniorage), CAP community pool to 2 billion LUNC, overflow goes to oracle pool rewards funding. So we have more burns, more community pool funding, more oracle pool funding, but higher transaction costs. I believe it's worth it.

Also if you have other ideas how we can fund the oracle rewards pool please post below. If you are technically minded and can analyse the data please provide insight here regarding the following:

1. Is further increase of gas fees viable?

2. Volume analysis of the 1.2% when it was in effect for 3 weeks to determine more accurate 80/20% split amounts.

3. Any other relevant data analysis for the oracle pool aside from the very simple LUNC Penguins, as it doesn't provide much data (value of oracle pool each day).

I would appreciate your thoughts and ideas how we can fund the oracle rewards pool. That is the point of this thread, how to fund the oracle pool, and to consider my proposal. I believe it should be a big priority for LUNC, but is not being focused on as much as it should. If you agree with my plan or suggest changes, or have your own ideas, you can provide that below. This is a proposal for discussion. Thank you.

First, we need burn oracle ustc.