Storehouse and Wheat

Sif's flowing golden hair symbolizes the endless fields of wheat, embodying a vision of post-scarcity abundance where nature's generosity sustains all.

Why Storehouse and Wheat

Storehouse and Wheat is an extension of the LPD monetary policy that induces a substantial permanent burn on Rowan tokens.

Problem Statement:

• Premise: For a fixed liquid market cap and an increasing circulating supply, the value of each token decreases alongside inflation. Deflationary burn mechanisms can induce the opposite effect, increasing the value of each token that isn't burned assuming a fixed liquid market cap
• Problem: Traditional burn models induce minimal deflation. For example, Ethereum's EIP 1559 led to a supply change of -0.07% for Ether between June 2023 and June 2024. BNBChain's burn mechanisms led to a supply change of -25% for BNB between Oct 2017 and June 2024
• Solution: Storehouse and Wheat takes Rowan out of circulation and increases Rowan's purchasing power in a manner similar to LPD but permanently burns a percentage of the total Rowan taken out, allowing it to go hyper-deflationary and burn up to 90% of circulating supply in 1-2 years or more, depending on what monetary policies are used and when.

How Does Storehouse and Wheat Work?

Variable Definitions

Chain State

The chain state is the set of information from the consensus protocol. This is exogenous to the model of the liquidity pool in that blocks are validated without feedback loop that prevents the operation of the protocol. The variables specified below are the state of the chain necessary to be read by the Storehouse and Wheat monetary policy.

Governance Decision

The governance decision is a policy input message that broadcaqrsts a specified \(r_{gov}\) for a specified length of time \(l_{policy}\), with a computable \(r_{final}\) as the intentional end-state of the policy at the end of its effective life at \(h_f\).

Assumption: epoch_length is a governance design, where there is the need for the consensus protocol to execute an epoch module.

final_compounded_rate is a metric of gov_rate and policy_length_in_epochs

Liquidity Pool Module State

Receives Storehouse and Wheat policy through governance decision, updating its parameters for \(r_{gov}\) and \(l_{policy}\). Combining this policy with the production of blocks from the protocol, allows for the computation of \(r_{block}\) and \(r_{running}\).

Additional Details on these Variables:

The total duration of a policy is the span of blocks between \(h_S\) and \(h_F\)

The duration of the policy can be divided into epochs which are sections of blocks of equal length. An obvious option for epochs would be one epoch per day. Of course, this would need to be measured against an average block duration as not all blocks have equal duration. For example, if blocks were approximately 5 seconds long then an epoch would be 17280 blocks, but because the blocks were not exactly 5 seconds long the epochs would not be exactly 1 day long.

The epochs are a user experience affordance to put governance reasoning about the effects of Storehouse and Wheat in intuitive units.

Use \(r_{gov}\) to Derive \(r_{block}\)

Let \(r_{gov}\) be the per-epoch rate increase voted in by governance. Each epoch, the purchasing power of Rowan (treated as the \(y\) token in Variable Definitions above) should increase by this percentage.

Let the final compounded rate, \({r_{final}}\), be defined as follows:
\[{r_{final}} = (1 + r_{gov}) ^ {l_{policy}} - 1\]
Rowan should increase by this percentage between \(h\) and \(h_F\) (ie. across all epochs).

Now we compute \(r_{block}\), which is the incremental increase on a per block basis (to reach \(final\_compounded\_rate\)):
\[r_{block} = (1 + r_{gov}) ^ {l_{policy}/({h_F-h_S})} - 1\]
\(r_{block}\) function derivation can be found in Appendix 1 at the end of this document

From this point onward we only focus on blocks.

Given a block rate calculated at the initial governance decision, there is no further role for the epoch rate or to keep track of epochs. The block rate is not recalculated again after the initial goverance decision.

Use \(r_{block}\) to Derive \(r_{running}\)

Let \(r_{running}\) be the running rate that is compounded over time (at any particular block). Similarly

\[r_{running} = (1+r_{block})^i-1\]
where
\[ i = h - h_S \]

Note: \(r_{running}\) in Storehouse and Wheat is an interesting stat but is not necessary for calculations in this feature

Computational and Financial Effect of Storehouse and Wheat

On a per-block basis, Storehouse and Wheat removes \(r_{block}\) Rowan from all LP positions and places it in a separate Storehouse address. Consider the image below:

For each Rowan token removed and placed in the storehouse, the feature distributes one Wheat token to each pooler.

Calculating the Burn Amount

For each subsequent block h:

1. Calculate the value of the added Rowan (\(V_{R_h}\)) by multiplying the amount of Rowan added in that block (\(R_h\)) with the current Rowan price (\(P_{Rh}\)):
   \(V_{R_h}\) = \(R_h\) * \(P_{Rh}\)
2. Update the running average price (\(P_{R_{avg}h}\)) using a weighted average formula:

\[P_{R_{avg}} = (P_{R_{avg}{h-1}} * S_{h - 1} + V_{R_h}) / (R_h+S_{h - 1})\]

Example below:
Block 1: \(S_0 = 0\), \(R_1 = 10\), \(P_{R1}\) = $10, \(P_{R_{avg}}\) = $10
Block 2: \(S_1 = 10\), \(R_2\) = 10, \(P_{R2}\) = $12, \(P_{R_{avg}}\) = $11
Block 3: \(S_2 = 20\), \(R_3\) = 10, \(P_{R3}\) = $15, \(P_{R_{avg}}\) = $12.33

Calculate the Burn Amount:

Take the current price of Rowan at the end of the policy period (\(P_{h_f}\)) and subtract the final average price of Rowan added to the storehouse \(P_{R_{avg}}\) and divide by the final price again. This returns a percentage of Rowan in the storehouse that can be burned. For example, if the price of Rowan at the end is $15 and the average price of Rowan added to the storehouse is $12.33, then you can burn ($15-$12.33) / $15 = 17.8% of all Rowan in the storehouse (with the rest being distributed back at auction).

Sifchain Storehouse & Wheat: Dual Auction Mechanism

To optimize Rowan distribution and Wheat value, the Storehouse employs a dual auction system that switches between two mechanisms based on the Rowan-Wheat price ratio:

Highest-Bidder Auction:

• Trigger: Activated when the Rowan-Wheat price ratio (\(P_R\) / \(P_W\)) is below a pre-defined threshold (\(RW\_delta\)).

Process:

• Bidders submit a single bid in Wheat, representing the amount they are willing to pay for the entire lot of Rowan in the Storehouse.
• The highest bidder wins the entire lot of Rowan.
• The Wheat used for the winning bid is burned.
• All other bidders retain their Wheat.

Lottery-Based Auction:

• Trigger: Activated when the Rowan-Wheat price ratio (\(P_R\) / \(P_W\)) is above \(RW\_delta\).

Process:

• Bidders submit a single bid in Wheat, representing their entry into a lottery.
• Each Wheat bid acts as a "lottery ticket."
• Any bidder can win, regardless of bid size, but the probability of winning is proportional to the amount of Wheat bid.
• All Wheat submitted in the lottery is burned.

About \(RW\_delta\) Threshold

Governance Parameter: The \(RW\_delta\) threshold represents the critical Rowan-Wheat price ratio that determines which auction mechanism is activated.
Value Setting: The specific value of \(RW\_delta\) requires careful analysis and consideration of market dynamics, desired price stability, and community input.

Example:

Let's say \(RW\_delta\) is set to 0.05 (meaning Rowan must be worth at least 5% more than Wheat for the Lottery-Based Auction to be activated).

Scenario 1: (\(P_R\) / \(P_W\)) = 0.06 (Rowan is 6% more valuable than Wheat): The Lottery-Based Auction is triggered.
Scenario 2: (\(P_R\) / \(P_W\)) = 0.03 (Rowan is 3% more valuable than Wheat): The Highest-Bidder Auction is triggered.

Motivations:

Flexibility: Adapts to changing market conditions and token valuations.
Wheat Price Support: The Lottery-Based Auction can potentially boost Wheat demand and mitigate price decline when its value is low.
Efficient Allocation: The Highest-Bidder Auction ensures the most efficient allocation of Rowan when Wheat is valued highly.

Extending DLP to Manage Wheat Sale

Summary:
Currently, DLP (DEX Liquidity Protection) only manages the sale rate of Rowan. We propose extending DLP to also manage the sale rate of Wheat, bundling the sale of both assets to protect the liquidity of non-Rowan assets on Sifchain.

Motivation:

• Protecting Non-Rowan Liquidity: DLP is designed to ensure sufficient liquidity remains available for users to buy Rowan. However, excessive sales of Wheat could drain non-Rowan liquidity, impacting DEX usability for other assets.
• Preventing Panic Sales: Bundling Wheat and Rowan sales during potential panic selling events prevents a cascade effect where the sale of one asset triggers the sale of the other, exacerbating the situation.
• Maintaining Market Stability: By managing the sales rate of both Wheat and Rowan, DLP helps stabilize the DEX during periods of volatility, ensuring a healthy and balanced ecosystem.

Proposed Solution:

• Bundled Sales Threshold: Introduce a new governance parameter for the maximum percentage of the total USD value of Wheat and Rowan that can be sold within an epoch (typically a day).
• Dynamic Adjustment: Similar to the existing DLP mechanism, the daily threshold for bundled sales is dynamically adjusted based on the USD value of Wheat and Rowan sold.
• Circuit Breaker Action: If a combined sale of Wheat and Rowan exceeds the current daily threshold, the swap is rejected.
• Individual Asset Thresholds: Alternatively, we could introduce separate daily thresholds for Wheat and Rowan, providing more granular control over individual asset sales.

Implementation:

• Extend Existing DLP Logic: The existing DLP mechanism can be extended to include Wheat sales within the bundled threshold calculation.
• Oracle Integration: An oracle will be required to provide real-time USD values for both Wheat and Rowan.
• User Interface Updates: The user interface should clearly display the current bundled sales threshold and any potential restrictions on selling Wheat or Rowan.

Benefits:

• Enhanced Liquidity Protection: Protects the liquidity of all assets on the DEX, not just Rowan.
• Improved Market Stability: Helps to prevent cascading sell-offs and maintain a more balanced trading environment.
• Increased User Confidence: Provides a more stable and predictable trading experience for all participants.

Challenges:

• Parameter Optimization: Carefully determining the bundled sales threshold and potential individual thresholds requires analysis and community input.
• User Experience: Implementing bundled sales restrictions may require adjustments to user interfaces and trading workflows.
• Potential for Manipulation: Large holders could try to manipulate the system by timing their trades strategically.

Conclusion:
Extending DLP to manage the sale rate of Wheat, bundled with Rowan, offers a significant step towards a more robust and resilient DEX ecosystem. By ensuring sufficient liquidity for all assets, DLP helps maintain market stability and promotes confidence for all participants. Careful implementation, community engagement, and continuous monitoring are crucial to maximize the benefits of this enhanced DLP feature.

Implementation Detail

If Storehouse and Wheat is too computational to run every block, it can be optimized. For example, it can be run every n blocks on all pools or once every block on only a subset of pools such that after n blocks all pools have been adjusted.