PI-4: Demand for Soil Adjustments
Executed on December 8, 2024 at 06:46 UTC.
Summary
- Increasing Demand Window: Extend the period at the beginning of the Season during which demand for Soil is considered increasing if all but 1 Soil is Sown into, from 10 to 20 minutes.
- Steady Demand Range: Extend the range during which demand for Soil is considered steady if all but 1 Soil is Sown into across the previous 2 Seasons, from ±1 to ±5 minutes, subject to the increasing-demand conditions.
Links
- Implementation Commit: a5af7e0f6b1aed7ad64a9413d96ffa0bb35eee3c
Problems
1. Increasing Demand Window
PI-3 extended the duration of the Morning Auction from 5 to 10 minutes. Demand for Soil was considered increasing when all but 1 Soil is Sown into in the first 10 minutes of the Season. As a result of the increase in the duration of the Morning Auction, Soil was never offered at the Maximum Temperature during the period in which this condition could be met.
2. Steady Demand Range
Measuring the relative time it takes for Soil to be Sown into across Seasons in order to measure demand for Soil was not particularly reliable at this early stage of the Pinto protocol. Accordingly, only checking the relative time within a 1 minute range was not likely to properly indicate relative demand across Seasons.
Solutions
1. Increasing Demand Window
- Increase
SOW_TIME_DEMAND_INCRfrom 600 (10 minutes) to 1200 (20 minutes). Demand is considered increasing when all but 1 Soil is Sown into before minute 20 of the Season, allowing this condition to be met after the Morning Auction ends.
2. Steady Demand Range
- Increase
SOW_TIME_STEADYfrom 60 (1 minute) to 300 (5 minutes). If all but 1 Soil is Sown into in both consecutive Seasons, demand is considered steady when the sellout times differ by no more than 5 minutes, unless an increasing-demand condition applies.
Rationale
1. Increasing Demand Window
By extending the duration within a Season in which demand will always be measured as increasing in the instance where all but 1 Soil is Sown into from 10 to 20 minutes, it allows for a period in which the protocol is offering Soil at the Maximum Temperature where this condition can be met. This remedies the removal of this opportunity that was created by doubling the duration of the Morning Auction from 5 to 10 minutes in PI-3.
2. Steady Demand Range
By expanding the range in which a steady demand for Soil measurement can occur in the instance where all but 1 Soil is Sown into across the previous 2 Seasons, the protocol can more accurately understand Soil demand across Seasons and respond with the appropriate Maximum Temperature change.
Contract Changes
Initialization
No initializer was called. The Diamond Cut used the zero address, so this upgrade performed no one-time state reset.
Facet Changes
All three facet source files were unchanged. The replacements incorporated the updated demand calculation in SeasonFacet and GaugeGettersFacet and the new LibWellMinting deployment linked by SeasonGettersFacet.
| Facet | Action | Previous Implementation | New Implementation |
SeasonFacet | Replace | 0x6Ea855d9473168f4540D4818976Ea814ECBf3456 | 0x15cBDFaF5715F2a1B6e23b3ef7c4D67843a6C836 |
GaugeGettersFacet | Replace | 0xD26a44C9F7C58864c2ea938BE9E2f0Ae25954bc2 | 0x34eaa05624E0B8cFAB251571E429fD88Cec7ec12 |
SeasonGettersFacet | Replace | 0xD0813e2378A73B7cB49Bd4ff6a4Bf67EdcEa1264 | 0x995E1cA9Bd858bff94448dCC0E097bd4d564e74B |
Other Contract / Parameter Changes
Updated LibEvaluate.SOW_TIME_DEMAND_INCR from 600 to 1200 seconds (10 to 20 minutes) and LibEvaluate.SOW_TIME_STEADY from 60 to 300 seconds (1 to 5 minutes).
Updated the linked library implementations below (previous → new). SeasonFacet linked all seven libraries, and SeasonGettersFacet linked LibWellMinting. Only LibEvaluate had a production source change in this upgrade. The other six libraries were redeployed with unchanged own source files. GaugeGettersFacet had no externally linked libraries.
Externally Linked Libraries
| Library | Previous Implementation | New Implementation | Used By |
|---|---|---|---|
LibEvaluate | 0x7a7d5a8899f9d68530ef3c551b9cb5610bc9bd02 | 0x595eb8aa763325235f988eedc582d74046fd7bca | SeasonFacet |
LibGauge | 0x6c2736cfc57c1328b7d3db611812297c9754e230 | 0xe7e55a27a369bef6d20dd081ff7ddff90d6f7482 | SeasonFacet |
LibIncentive | 0xeb9bd84e354e68142e8e996823887edb4dfcf433 | 0xfe1fe5508b33401c20e45fcd10161783de443479 | SeasonFacet |
LibShipping | 0x64d40771f9f6490afe20c135dc07ea48b8addc78 | 0x86c9bdf4b2a7ab22c90048f0d741b81c546895b7 | SeasonFacet |
LibWellMinting | 0x7124f182847880f4961de89068b249c3299304af | 0x4e81e73a1ca24ff99a79914a887d13b9c641e2f2 | SeasonFacet, SeasonGettersFacet |
LibFlood | 0xed513e167369af0119090d67b8910c02b2b468f6 | 0x249ae0deb8f7ebccaa574c7396c7d099d87e7e3d | SeasonFacet |
LibGerminate | 0x384374407a64aa24d3335ff12c870debaa04c3e5 | 0x7c748262b168e85a5e0973021e44b163fcb578d9 | SeasonFacet |
Function Changes
- Updated the internal
LibEvaluate.calcDeltaPodDemandlogic to classify demand as increasing when Soil sells out in less than 1200 seconds. The existing rule also classifies demand as increasing if Soil sold out this Season but not in the preceding Season. The same helper suppliesGaugeGettersFacet.getDeltaPodDemand()and the demand component of the weather case used bySeasonFacet. Soil is treated as sold out when at most 1 Soil remains.
- Widened the sellout-time comparison in
LibEvaluate.calcDeltaPodDemandfrom 60 to 300 seconds. Subject to the earlier increasing-demand conditions, demand is increasing if Soil sells out more than 300 seconds faster than in the preceding Season, steady within the inclusive ±300-second window, and decreasing if more than 300 seconds slower. No public function or event signature changed.
Event Changes
- Changed the demand component of the weather case through the longer increasing-demand window and wider steady-demand tolerance. This can change the
caseIdemitted byTemperatureChangeandBeanToMaxLpGpPerBdvRatioChange. It can also change theabsChangeemitted byTemperatureChange. With other inputs fixed, the demand classification does not change theabsChangeemitted byBeanToMaxLpGpPerBdvRatioChangebecause each set of three demand cases uses the same ratio adjustment. Event signatures, emission timing, existing clamps, and the oracle-failure guard on the latter event were unchanged.