diff --git a/public/pi/0/index.html b/public/pi/0/index.html new file mode 100644 index 000000000..b3ff9ad7c --- /dev/null +++ b/public/pi/0/index.html @@ -0,0 +1,798 @@ +PI-0: Fix the PINTO:USDC Multi Flow Pump and Update Multi Flow Pump Cap Parameters

PI-0: Fix the PINTO:USDC Multi Flow Pump and Update Multi Flow Pump Cap Parameters

Executed on November 20, 2024 at 01:31 UTC.

Summary

  1. Multi Flow Pump Bug: Fix a bug in the Multi Flow Pump that caused the Pump to return incorrect data for the PINTO:USDC liquidity pool.
  1. Pump Parameters: Update the Wells on the Minting Whitelist to use a new Multi Flow Pump with more forgiving LP token supply and exchange rate change caps of 25% per block (2-second cap interval) in order to allow the Flood to return the price to the value target in instances of greater volatility.
  1. Deposit Metadata: Update the Metadata Facet to return the correct metadata.

Links

Problems

1. Multi Flow Pump Bug

The implementation of the Multi Flow Pump resulted in the tryCalcLpTokenSupply helper returning MAX_UINT256_SQRT (the integer square root of uint256.max) when the Newtonian estimation in Stable2’s calcLpTokenSupply failed to converge at high prices, causing the function to revert. Using this failure value in LP token supply capping produced incorrect reserve data and excessive minting.

2. Pump Parameters

During the Flood, the Well reserves hit the LP token supply and exchange rate caps. Because it took ~2 Seasons for the Pump values to catch up to the Pinto price, the protocol would mint more than it should’ve during the Flood.

3. Deposit Metadata

The ERC-1155 Deposit token was erroneously named "Beanstalk Silo Deposits".

Solutions

1. Multi Flow Pump Bug

Upgrade the _capLpTokenSupply function in Multi Flow Pump to skip LP token supply capping if calculating the LP token supply from either the previous or current reserves fails, while continuing to apply exchange-rate capping to the current reserves.

2. Pump Parameters

Upgrade the whitelisted Wells to a new Multi Flow Pump with more forgiving LP token supply and exchange rate change caps of 25% per block (previously set to approximately 0.493862% and 0.083160%, respectively), enabling the Flood to return the Pinto price to its value target in the instance of greater upside price volatility.

3. Deposit Metadata

Update the Metadata Facet to rename the ERC-1155 Deposit token from "Beanstalk Silo Deposits" to "Pinto Silo Deposits" and update its description and trait labels to use Pinto terminology.

Rationale

1. Multi Flow Pump Bug

The Stable2 Well Function uses Newtonian estimations to perform complex calculations on-chain in an efficient fashion. The further away from the value target, the greater the chance that the Newtonian estimation fails to converge, in which case the function reverts. In the instance of a reversion, it is better for the _capLpTokenSupply function in Multi Flow Pump to skip LP token supply capping when either calculation fails because MAX_UINT256_SQRT is an extremely high value which can lead to the protocol overminting Pinto. The Pump continues using the current reserve values, subject to exchange-rate capping.

2. Pump Parameters

The initial caps were designed to mitigate inter-block MEV on Ethereum, where control of consecutive blocks can enable oracle manipulation. On Base, there is no MEV performed by the sequencer, and so the risk of setting the parameters capping changes too high is almost non-existent. The Multi Flow Pump’s initial conservative caps limited how quickly its reserve values could respond to market changes. During a Flood with significant upward price volatility, this lag reduced the effectiveness of the Flood in returning the Pinto price to its value target. The higher caps allow the Pump to respond more quickly while retaining limits on changes in LP token supply and exchange rates.

3. Deposit Metadata

The Deposit token metadata should identify Pinto so that wallets and interfaces display the correct protocol name.

Contract Changes

Initialization

InitZeroWell.init(WellData[]) was called on the following contract to upgrade the whitelisted Wells to the new Pump configuration and reset their oracle snapshots:

Facet Changes

FacetActionPrevious ImplementationNew Implementation
MetadataFacetReplace0xbC9bbe5226e92970272Db91a7168786528D83f8c0xf6506176A027ed4d5CdBaB23d9DFcdEC2B35b2A8

Other Contract / Parameter Changes

New Multi Flow Pump: 0xBA51AAaA66DaB6c236B356ad713f759c206DcB93. The whitelisted Wells use this Pump with LP token supply and exchange rate change caps of 25% per 2-second cap interval (previously approximately 0.493862% and 0.083160%, respectively).

Function Changes

Event Changes

+

\ No newline at end of file diff --git a/public/pi/1/index.html b/public/pi/1/index.html new file mode 100644 index 000000000..a21d583e8 --- /dev/null +++ b/public/pi/1/index.html @@ -0,0 +1,797 @@ +PI-1: Convert Newly Earned Pinto and Misc. Bug Fixes

PI-1: Convert Newly Earned Pinto and Misc. Bug Fixes

Executed on November 27, 2024 at 05:52 UTC.

Summary

  1. Germination of Earned Pinto: Eliminate the Germination Period for Earned Pinto, enabling Pinto → LP Converts immediately after a Farmer Plants their Earned Pinto.
  1. Re-germination of Converted Deposits: Eliminate a bug where Converts can erroneously cause a Deposit to Germinate again.
  1. Minimum Crop Ratio During Rain: Add a distinct Minimum Crop Ratio while the system is Raining.
  1. Initial Soil Supply: Add initialSoil to expose the remaining Soil supply before Morning Auction scaling.
  1. Event and Rain Data Fixes: Correct the number of Pinto emitted by the Sow event and startRain’s emitted Crop Ratio change.
  1. Plenty Claim Return Values: Return the number of tokens claimed as Plenty from claimPlenty and the token addresses and numbers of tokens claimed from claimAllPlenty.

Links

Problems

1. Germination of Earned Pinto

Earned Pinto Deposits should be able to be used in a Pinto → LP Convert immediately upon distribution (i.e., they should not Germinate). However, when a Farmer Planted their Earned Pinto, they were not able to Convert their new Pinto Deposit to an LP token Deposit until 2 Seasons elapsed. This inability to Convert immediately after Planting was a significant inefficiency with respect to peg maintenance because users that just Planted their Earned Pinto needed to wait until the Germination Period ended and then return to the Farm to Convert their Pinto for peg maintenance.

2. Re-germination of Converted Deposits

When a Farmer Converted a Pinto Deposit that had recently finished Germinating to an LP token Deposit (or vice versa), the output Deposit became Germinating again. In this case the then Germinating Deposit lost its Stalk, and instead was issued Germinating Stalk (i.e., a claim on Stalk after the Germination Period ends). Germinating Stalk is ineligible for mints or Flood rewards. Thus, a user was disincentivized to Convert during times of large mints and Floods because they would lose 2 Seasons of mints and eliminate their share of subsequent Flood distributions during the current Rain associated with the Converted Deposits.

3. Minimum Crop Ratio During Rain

When the system is Raining, the minimum Crop Ratio should be lowered to increase the incentive to Convert from Deposited Pinto to the Deposited LP token with the most Seeds.

4. Initial Soil Supply

There was no on-chain function that returned the remaining Soil supply before Morning Auction scaling, so the UI had to make excessive RPC calls to reconstruct it.

5. Event and Rain Data Fixes

The Sow event emitted an incorrect number of Pinto, and startRain did not correctly emit the change in BeanToMaxLpGpPerBdvRatio, resulting in incorrect data in the subgraph.

6. Plenty Claim Return Values

The claimPlenty and claimAllPlenty functions did not return sufficient data to easily compose transactions together in the UI.

Solutions

1. Germination of Earned Pinto

Update the plant function to issue a non-Germinating Pinto Deposit crediting it with the Grown Stalk it would have earned at the previous Season's Seeds per PDV for Pinto, plus an additional 1 micro Seed.

2. Re-germination of Converted Deposits

Update the convert function to issue a non-Germinating token Deposit for Pinto ↔ LP Converts if the value being Converted was not Germinating. If the resulting Deposit would otherwise have a Germinating Stem, top up Grown Stalk to the non-Germinating minimum based on the previous Season's Seeds per PDV of the output token, plus an additional 1 micro Seed.

3. Minimum Crop Ratio During Rain

Add rainingMinBeanMaxLpGpPerBdvRatio to the EvaluationParameters struct in storage and initialize the value to 33333333333333333333 (approximately 33.33%), and update getBeanToMaxLpGpPerBdvRatioScaled to use rainingMinBeanMaxLpGpPerBdvRatio instead of minBeanMaxLpGpPerBdvRatio when the system is Raining.

4. Initial Soil Supply

Add the initialSoil function, which returns s.sys.soil.

5. Event and Rain Data Fixes

Update the Sow event to properly emit the number of Pinto that were used to Sow, rather than the number of Soil deducted from s.sys.soil.

Update the startRain function in LibFlood.sol to properly emit the change in BeanToMaxLpGpPerBdvRatio.

6. Plenty Claim Return Values

Update the claimPlenty function to return the number of tokens claimed. Update claimAllPlenty to return the token addresses and numbers of tokens claimed.

Rationale

1. Germination of Earned Pinto

There is no reason to enforce a Germination Period for newly Planted Earned Pinto Deposits. The Germination Period prevents a specific manipulation. Without it, a user could Deposit value in the Silo to receive Stalk, call the gm (which triggers the Sunrise), and then immediately withdraw the Deposit plus the yield from that Sunrise, all without holding exposure to the price of Pinto. Earned Pinto already accrued from a Deposit that completed Germination, so exempting it does not enable the manipulation described above.

The inability to Convert newly Planted Pinto to Deposited LP tokens is a significant inefficiency with respect to peg maintenance because it creates a lag between when Farmers Plant their Pinto and when they can Convert them. This lag may delay the effect of mint distributions on peg maintenance with respect to the value that stays in the protocol (i.e., wasn’t sold) by at least one Season, because delayed Converts can delay the peg recovery and lead to more Pinto being minted.

2. Re-germination of Converted Deposits

Once value that was Deposited in the Silo has completed its Germination Period, there is no reason to make it Germinate again upon a Convert because the value will have already been in the Silo for a sufficient period of time, ensuring that it is not taking advantage of a Pinto mint without holding exposure to the Pinto price.

The ability to Convert a non-Germinating Pinto Deposit into a Germinating LP token Deposit creates a disincentive to Convert, which can lead to excess mints because holders that would otherwise have Converted do not.

3. Minimum Crop Ratio During Rain

When it's Raining, Pinto should be very aggressive in incentivizing Converts from Pinto Deposits to LP token Deposits. During a Flood, the protocol should be minimizing how much it mints because when the Flood ends it will almost certainly experience heavy outflows. Accordingly, lowering the Crop Ratio to an exceptionally low value – below the Minimum Crop Ratio – will create a stronger incentive for Depositors to Convert their Deposited Pinto to LP token Deposits and minimize excessive minting.

4. Initial Soil Supply

Exposing the remaining unscaled Soil directly lets the UI read the protocol’s current value without reconstructing it through multiple RPC calls.

5. Event and Rain Data Fixes

Emitting the Pinto actually Sown and emitting the Crop Ratio change allows the subgraph and UI to process the protocol’s state changes accurately.

6. Plenty Claim Return Values

Returning the claimed token addresses and numbers of tokens lets the UI use claim results when composing subsequent actions in the same transaction.

Contract Changes

Initialization

InitPI1.init() was called at 0x4cbD1A8ff8E3dcE759dC9049417DeeBC3Ac24ddA to initialize rainingMinBeanMaxLpGpPerBdvRatio to 33333333333333333333 (approximately 33.33%).

Facet Changes

FacetActionPrevious ImplementationNew Implementation
ClaimFacetReplace0x85495A065bEc462d76Fbfa1E344C06f64308Af910xEa0Aad388e2dF06F90A218cA2eDa199294fBAaDB
ApprovalFacetReplace0x77e228C03277e38FcfF8FC21106afDc22389e85c0x540e776e8F0eaC5dFA82110b827CB6ceA6705669
ConvertFacetReplace0x0FAf9BBDDD27647bA9972672aee4E638B364E2490x379D2d7FF9907F127f1226a9024BCF0789619734
ConvertGettersFacetReplace0xF0f2e61939DE4daf29d894B466b51798C5c54A1d0xfE55E1e7f3FdAef6b1E6E3d6D53f84a374151817
SiloFacetReplace0x8A42a986DDB3612437f8445bB199FDb14714fa420x3235540bb01Ef11e4208a9B99c2F2Dd9860E721a
SiloGettersFacetReplace + Add selectors0x12b94E41697AC173d619CecCcAAd1C2C21A2a66C0x039Ec53Bb37F8fe240798E3591d9439C68e72B7b
PipelineConvertFacetReplace0x032CAe4820C7379B1419Af64a3e2a4Ce4861Ab0a0x9d108e7f673C773Ac196bDE4bEBC6758088D2e59
SeasonFacetReplace0x03fbe88B58FceA841A749FF2e93E4e56D2f42C060x269C8386bE50C176f03355c7C7925356fdEF9F84
GaugeGettersFacetReplace0xABcBa236f57a807084F7884B3eEdD25C077595Ba0xD26a44C9F7C58864c2ea938BE9E2f0Ae25954bc2
FieldFacetReplace + Add selector0x34d5239E92720773C2E7a5A93Db8587a3af6Bb040x6430F859a3b8825D25382Ebc7941fCD719635797

Other Contract / Parameter Changes

Introduced a separate minimum Crop Ratio during Rain of approximately 33.33%, using rainingMinBeanMaxLpGpPerBdvRatio. Outside Rain, getBeanToMaxLpGpPerBdvRatioScaled continues to use minBeanMaxLpGpPerBdvRatio. Previously, the 50% minimum also applied during Rain. The minimum remains 50% outside Rain. Ratios use 18 decimal places per percentage point (100e18 = 100%).

Externally linked library deployments changed as follows (previous → new). These address changes do not by themselves imply changes to each library’s behavior.

LibraryPrevious ImplementationNew ImplementationUsed By
LibSilo0x6a634f53d185298ad84a51e2c6fac8b5256d01650x351ca256f86c10b01f2640f22ca379cf1e74d8e2ClaimFacet, ConvertFacet, SiloFacet, PipelineConvertFacet
LibTokenSilo0xa565840bc1a3d3b24fb36c02472aa495259477b60xbbe1d3e7bb0b50d1999f631674efd5446881612aClaimFacet, ConvertFacet, SiloFacet, PipelineConvertFacet
LibConvert0xad4a3b66c5e672acc952d9f4b728b4c845f8cb7a0x3dedd64cfbf6db642cf6a22ce747fdfb9f17b570ConvertFacet
LibPipelineConvert0x9b0943584aa2bd99cefd82004dfe859d369e43260x4917dcbafc47b57b9ec004424a44ccdc5834d054ConvertFacet, PipelineConvertFacet
LibEvaluate0x34ebbb2b16cf20964b6819cef921dd10599f117c0x7f1770fa1b43abdbe8095295ecae37c00d4ba7f8SeasonFacet
LibGauge0xc3ccf1a9cff074fd572c9ab7d55486ef003fd4270xcd376159cfa7ff6c60a3b6d55e2ce75cec515669SeasonFacet
LibIncentive0x7b160137d1298e3b71285ea6a260cb2248176d820x86da3aba20454a441eceae9d5b960564abd0cba1SeasonFacet
LibShipping0x1fa93c17cfe8a33d9a195e904031e262325915710x2b6a87195446b28c404cd5d78351998a1e8b31f9SeasonFacet
LibWellMinting0x4910f9a342c79ea50a4395477cfdb11f36a010ad0x78e2a41721b97f33e13a383d15726b1ac96c2a19SeasonFacet
LibFlood0x2174762d93abebd7c4317104c26b6961d6cb3f100xd668ecc7df030202ee50f9c465db7f7da7581a48SeasonFacet
LibGerminate0x74f409bf422e33bc34d909a1233516307adb6daa0x06cc9fb93b3cefa5dc6bb5f418c7358cd3ea0a85SeasonFacet

ApprovalFacet, ConvertGettersFacet, SiloGettersFacet, GaugeGettersFacet, and FieldFacet have no externally linked libraries.

Function Changes

Event Changes

\ No newline at end of file diff --git a/public/pi/10/index.html b/public/pi/10/index.html new file mode 100644 index 000000000..6402a6e35 --- /dev/null +++ b/public/pi/10/index.html @@ -0,0 +1,797 @@ +PI-10: Fix Cultivation Gauge and Revise Parameters

PI-10: Fix Cultivation Gauge and Revise Parameters

Executed on June 19, 2025 at 03:57 UTC.

Summary

  1. Cultivation System: Upgrade the Cultivation System to handle two edge cases.
  1. Soil Sold Out Threshold: Upgrade the mechanism that determines if Soil sells out to be more manipulation resistant.
  1. Convert Down Penalty: Update the Convert Down Penalty Gauge to issue the penalty as a function of instead of .
  1. Batch Plot Transfers: Restore batch Plot transfers with correct allowance checks.
  1. Plot Listing Payments: Prevent Plot Listings from being filled with zero Pinto and correct the rounding boundary.

Links

Problems

1. Cultivation System

With the introduction of Tractor support for Sowing, there was an inefficiency discovered in how the Cultivation System worked.

In particular, the Cultivation Factor decreased when Soil did not sell out. In instances where there was a Tractor Requisition to Sow at the Maximum Temperature in a Season in which Soil sold out, and there were no Tractor Requisitions to Sow at lower Temperatures, the Cultivation Factor got "stuck" oscillating at the level it was prior to the Tractor Requisition being filled (typically the minimum Cultivation Factor). The result was that the available Soil never increased, even if there was demand to Sow in excess of the available Soil. In practice this had resulted in the Field never offering enough Soil to meaningfully affect the state of the system.

Additionally, there was no Steady case in which the Cultivation Factor stayed the same, which could lead to suboptimal numbers of Soil being issued in the instance where there was a consistent amount of demand for Soil across multiple Seasons.

2. Soil Sold Out Threshold

The threshold at which the protocol considered Soil to be sold out was not manipulation resistant.

3. Convert Down Penalty

The Convert Down Penalty was insufficiently aggressive in instances where the L2SR was Reasonably Low.

4. Batch Plot Transfers

A bug in the protocol allowed a malicious actor to bypass the approval process and transfer another user's Plots without their permission. The vulnerable functionality was removed in an Emergency PI leaving users unable to transfer multiple Plots in a gas efficient way.

5. Plot Listing Payments

A bug in the protocol allowed small Plot Listings (podAmount <= 1e6) with a certain Pod price to be purchased without Pinto.

Solutions

1. Cultivation System

Introduce a new threshold in which the protocol considers Soil mostly sold out.

Set the "Mostly Sold Out" threshold as a function of the Soil issued at the start of the Season, , and the Sold Out threshold (see below):

.

Introduce the Cultivation Temperature, which is set at the previous Season’s Maximum Temperature when Soil is Sold Out or Mostly Sold Out, and demand for Soil is steady or increasing.

Update the Cultivation Factor Gauge to increase, stay the same, or decrease based on the following logic: increase when Sold Out. Remain unchanged when Mostly Sold Out, or when demand is decreasing and the previous Season’s Maximum Temperature is below the Cultivation Temperature. Decrease otherwise. The Cultivation Factor remains between 1% and 100%.

2. Soil Sold Out Threshold

Update the "Sold Out" threshold to be a function of Soil issued at the start of the Season, , as:

3. Convert Down Penalty

Update the Convert Down Penalty such that the penalty is a function of , rather than . Here, denotes the previous Season’s L2SR, the lower bound (12%) replaces the optimal bound (40%), is the rolling counter after its current update, and is its cap of 12. The counter increases by 1 when time-weighted deltaB is positive and decreases by 1 otherwise, bounded between 0 and 12. At zero L2SR, the prior penalty ratio is retained instead of using this formula. The penalty is waived when the Pinto price in the conversion Well exceeds the Excessively High Price threshold. A minimum number of Grown Stalk is retained to keep the converted Deposit from germinating.

4. Batch Plot Transfers

Reintroduce the transferPlots function to properly decrement the allowance of a sender when sending another Farmer's Plot(s).

5. Plot Listing Payments

Update the fillPodListing function to revert when a user attempts to fill a Listing with 0 Pinto. Tighten the remaining-Pod rounding comparison to prevent an entire additional payment unit from being rounded away.

Rationale

1. Cultivation System

The Cultivation Factor getting stuck such that it never increases effectively cripples the efficacy of the Field. By tracking the Cultivation Temperature the protocol is able to prevent itself from getting stuck and reenables the Field to meaningfully contribute to peg maintenance.

Introducing a Steady case to the Cultivation Factor changes means that the protocol can more granularly adjust the number of available Soil, leading to even more efficient Soil issuance.

2. Soil Sold Out Threshold

Prior to this upgrade Soil was considered Sold Out if at most one Soil was not sold. Because the number was so low, there was the potential for manipulation that could prevent the protocol from logging Soil being Sold Out by someone Sowing all but just over 1 Soil.

When initial Soil is at least 50, less than 5 Soil remaining qualifies as Sold Out. With low gas costs, a Farmer with demand is likely to Sow the remaining Soil. When initial Soil is at least 500, the threshold is capped at 50 Soil. The cap was chosen to leave enough value that a Farmer with demand is expected to find Sowing worthwhile, while avoiding a threshold that grows indefinitely with Soil issuance.

3. Convert Down Penalty

By changing the Convert Down Penalty to be 100% when the counter is zero, the Pinto price in the conversion Well does not exceed the Excessively High Price threshold, and the L2SR is at least the Excessively Low L2SR threshold instead of the Optimal L2SR threshold, the protocol will have at least one Season where the penalty will be 100% in more instances when the Pinto price crosses the value target. This should cause TWA∆P > 0 and a mint to occur, which in instances where the L2SR is not Excessively Low would generally be healthy for the protocol. A 100% penalty does not burn all Grown Stalk. The minimum retained Grown Stalk keeps the converted Deposit from germinating.

4. Batch Plot Transfers

Correct allowance accounting restores batch transfers while requiring a delegated sender to have sufficient approval for the total number of Pods transferred.

5. Plot Listing Payments

Requiring a positive payment prevents a zero-Pinto fill. The stricter rounding boundary prevents an entire additional payment unit from being rounded away.

Contract Changes

Initialization

Executed InitPI10.init() at 0xcc7578d84785c30a45306c8afc75955ba1767709. Extended the Cultivation Gauge data from four to six uint256 values, preserving its existing adjustment and factor bounds and initializing cultivationTemp and prevSeasonTemp to zero. The stored Cultivation Factor and Convert Down Penalty value were unchanged by initialization. The new stored initialSoil field was not populated by the initializer. Both new threshold getters returned zero at the execution block, before the next Sunrise stored the new Season’s initial Soil.

Facet Changes

Replaced four facets and added five selectors: two Soil threshold getters, two Gauge-result getters, and the restored transferPlots function. Other selectors in these facets were replaced without implying that every function changed.

FacetActionPrevious ImplementationNew Implementation
GaugeFacetAdd / Replace0x42575b2f01d18cf3ed670c9fe82ee90332739d030x046c76aee5d109fba8708ee58a50d76eea1f98dc
SeasonFacetReplace0x5545a4ab5cd3f6e7db0883e73ea4805f6e1270a90x9c74f623d22c4132211c9a8c605de7d2cda01700
FieldFacetAdd / Replace0x0b5888a4c6fb90d26fb4d5f782d45c9e86dcc9740x36e4dd6f2be854962174c3e398cd0e11d49e404c
MarketplaceFacetAdd / Replace0x1f4504295c5bd57cdbd8caf4df9ab13381cb0ad40x5aeb7c0a256b167bae026056d32818539b1734b4

Other Contract / Parameter Changes

SeasonFacet linked the libraries listed below. GaugeFacet, FieldFacet and MarketplaceFacet have no externally linked libraries. LibEvaluate changed demand classification. LibWeather is a new external dependency containing the Temperature logic and the previous-Season Temperature update. The other six libraries have new deployment addresses but unchanged own-source files. Shared compiled dependencies may still differ.

LibraryPrevious ImplementationNew ImplementationUsed By
LibEvaluate0x311877f9ffbaf12b905df3e1f8c3b5f3c5527bd40x1687f3eccced54e4ea4d98ffa13e2108954501e5SeasonFacet
LibGauge0x28d436b9bbbe755dea4db747483f693d718479840xfa27f1b255a02a929a7a4e668066ce76cadcc09cSeasonFacet
LibIncentive0x09240a6c83350caaf110d9de6e23a659625d54760xb3f71bf8362cbaafebb99e1e5fac02c85e1ecfccSeasonFacet
LibShipping0x3e3442a75ed4dd47e64e4522da625701049d64770x166ab367e077e65f1a4f273f05d8c25a3c3ea398SeasonFacet
LibWellMinting0x6dd836e7fe603bd73532bf6b5cbb188b7fcc7fa90xd76d2011647f57071cca0d182f0d524abeaee84eSeasonFacet
LibFlood0xff823fbb0ae114b8e41c0529c7d87702cc5d06a80x20a9aeac56fee169dec4d8a5c454e818b55fa8afSeasonFacet
LibGerminate0x74f0910564523a9a9a0b4db23505f653af20548c0xaedabcc13a7c44d612cb3776b6a2f3a81fd3d932SeasonFacet
LibWeatherN/A — new dependency0x82e2cfe47cf2ddd23755f81abb1349bdd96b5bfeSeasonFacet

Changed the fixed 1 Soil sellout threshold to min(50 Soil, 10% of initial Soil), and added a Mostly Sold Out threshold equal to the sold-out threshold plus 20% of the remaining initial Soil. Integer calculations round down in 6-decimal Soil units. Changed the Convert Down Penalty scaling denominator from the optimal (40%) to the lower L2SR bound (12%). Added an L2SR input cap at the lower bound, while retaining the final 100% penalty cap. The counter rate of 1 per Season and cap of 12 were unchanged.

Function Changes

Event Changes

\ No newline at end of file diff --git a/public/pi/11/index.html b/public/pi/11/index.html new file mode 100644 index 000000000..57a516c4b --- /dev/null +++ b/public/pi/11/index.html @@ -0,0 +1,797 @@ +PI-11: Update Convert Down Penalty Gauge and Dewhitelist Pools

PI-11: Update Convert Down Penalty Gauge and Dewhitelist Pools

Executed on July 31, 2025 at 15:34 UTC.

Summary

  1. Convert Down Penalty Gauge V1.1: Update the Convert Down Penalty such that the Convert Down Penalty ratio is 100% during positive-TWAΔP Seasons while a minimum number of Pinto has not yet been minted.
  1. Pro-Rata Convert Down Penalty: Fix the application of the Convert Down Penalty in instances where the penalty should apply to only a portion of the Deposits Converted.
  1. Dewhitelist Pools: Dewhitelist the PINTO:WSOL and PINTO:WETH pools from the Deposit Whitelist.
  1. Optimal Deposited PDV: Set the optimal percentage of Deposited PDV of PINTO:cbETH, PINTO:cbBTC and PINTO:USDC to 33.333333% each.

Links

Problems

1. Convert Down Penalty Gauge V1.1

The Dynamic Convert Down Penalty had not resulted in the protocol spending significant time above its value target.

2. Pro-Rata Convert Down Penalty

If a Pinto -> LP Convert started with a price above the Excessively High Price threshold and resulted in a price below the Excessively High Price threshold, the protocol applied the penalty to all of the value Converted instead of only the portion below the threshold.

3. Dewhitelist Pools

Whitelisted LP tokens that contain an asset without liquidity on Base that is external to the Well were unable to be Converted into other LP tokens on the Deposit Whitelist without incurring large slippage costs, creating friction for Farmers to optimize their Seeds. There was no external liquidity on Base for WSOL.

Fragmenting the ETH exposure of the protocol across two pools leads to greater slippage when interacting with the pools than if the liquidity were concentrated in a single pool.

4. Optimal Deposited PDV

The removal of the two assets from the Deposit Whitelist required resetting the optimal distribution for the remaining tokens.

Solutions

1. Convert Down Penalty Gauge V1.1

Every Season, update the Convert Down Penalty Minting Threshold based on TWAΔP. Each Season with TWAΔP < 0 adds current supply × to the main threshold while unlocked, or to a running threshold while locked. The running threshold replaces the main threshold only when it exceeds it, then resets. Above-target Seasons reset the running threshold. Reaching the minting threshold clears the main threshold and tracked mints. At zero TWAΔP these thresholds remain unchanged.

For TWAΔP < 0, add to the main threshold if unlocked, or to the running threshold if locked.

If the running threshold exceeds the main threshold, replace the main threshold with it, reset the running threshold to zero and unlock the threshold. Tracked mints are not reset by this replacement.

Where:

2. Pro-Rata Convert Down Penalty

3. Dewhitelist Pools

4. Optimal Deposited PDV

Rationale

1. Convert Down Penalty Gauge V1.1

The Dynamic Convert Down Penalty started to decrease after the first Season in which the protocol logged a TWA∆P > 0. Particularly after longer periods where the protocol has failed to log a TWA∆P > 0, the protocol should highly discourage Pinto -> LP Converts until either the protocol mints some number of Pinto or the price is significantly above the value target.

By increasing the number of Pinto minted required before the penalty can decrease the longer TWAΔP remains negative the protocol aims to ensure that it mints a healthy number of Pinto before Pinto -> LP Converts return the price to its value target, where longer extended periods below the value target justify more minting once it returns to the value target. Once the minting threshold is cleared, subsequent positive-TWAΔP Seasons increase the Blight Factor so the protocol can gradually decrease the penalty until it reaches a level at which the protocol is able to oscillate across its value target.

2. Pro-Rata Convert Down Penalty

Applying the penalty only to the portion below the penalty price avoids penalizing the part of a Convert that maintains the price above that threshold.

3. Dewhitelist Pools

There was no WSOL or SOL on Base other than in the PINTO:WSOL Well. The result was that any LP -> LP Converts to and from the pool experienced a very high amount of slippage. This resulted in a loss of value for Convertors and the protocol, and created a high degree of friction for the Seed Gauge System to work effectively.

By reducing the number of pools with ETH exposure and concentrating the exposure in cbETH, the protocol minimizes the slippage experienced by Convertors and traders in the system and increases the amount of yield received on its liquidity. The downside is that all remaining paired assets carry censorship risk from Circle/Coinbase.

4. Optimal Deposited PDV

Setting the optimal ratios of the remaining pools to be approximately 1/3 each is a reasonable distribution of liquidity, with approximately 2/3 of the target Deposited PDV exposed to the crypto market and 1/3 exposed to stablecoins.

Contract Changes

Initialization

Executed InitPI11.init() at 0x35c229daa5e9028672137854b6342b57e058fb00. Reset the Convert Down Penalty ratio and rolling counter to 0. Initialized the locked minting threshold to 15,007,159.669041 Pinto, tracked mints and running threshold to 0, and the supply scalar to 0.000416666666666667 per negative-TWAΔP Season. Retained the counter rate of 1 and cap of 12. Set the independent penalty price to $1.005, dewhitelisted PINTO:WSOL and PINTO:WETH, and set the three remaining optimal Deposited PDV percentages to 33.333333% each.

Facet Changes

FacetActionPrevious ImplementationNew Implementation
ConvertFacetReplace0xdfa197784879926e2358a7c71c6a0bd487f919fd0x9e090554525af3e39b7191bcefaed4a594bfdf24
ConvertGettersFacetReplace0xe0b8fca80b1a7060fea44c6f823b221ec9d7217c0xc2eddd1cfb0ac4aab93a6aaedc097b8ccc114710
PipelineConvertFacetReplace0xc54cd71bfa5d0fe05d887eabbec4dbbc94cf74ba0x68206dab632667e293589078800a9a7ccca39b63
GaugeFacetReplace0x046c76aee5d109fba8708ee58a50d76eea1f98dc0xb054a1348d2a9fd5ba1eaa51ef1aee2d6ad402ed
ApprovalFacetReplace0xa7c95ed70be8f91f8d8af91de193710fa7ab32bb0x463edf62ff627351518dcf0ac015c1e98562412f
SeasonFacetReplace0x9c74f623d22c4132211c9a8c605de7d2cda017000x0c5aa699e1979493e172d114193ee75c6a5afb39
ClaimFacetReplace0xd38c3e61bf08734cd808aca15c944389968612e00x8bbcc20eaf03191f1970ed5d93567ab76034f44d
SiloGettersFacetReplace0xadfd7fbe59ca2624cec1b04f9bc65c7f90efed360x954fba56a8356e7439f41a39579c7be59791d92f
GaugeGettersFacetReplace0x0f97cb8bb44d3d7a0afaeac24bbfe152215e3c5a0x889d0183c752b89e8d6cd62870b4f8eb70d10893
OracleFacetReplace0x7256fad9eb704173afe2185d1a44edf826ff6c860x5d8e457dd58f443237e105c2f27dc2c75133976c
SeasonGettersFacetReplace0xebaa2c95efc7f1cef1a57dfb5fe05f8935d7390e0x47246b05945031432f30becbf602d2d7dc6fece0

The cut replaced 179 selectors, removed downPenalizedGrownStalk(address,uint256,uint256) (0x527ec6ba), and added its four-argument replacement and getMaxAmountInAtRate(address,address,uint256). The seven supporting facets were redeployed without changes to their own source files. Replacement alone does not imply every getter changed.

Other Contract / Parameter Changes

The following externally linked libraries were redeployed. Only LibConvert and LibPipelineConvert changed their own source files relative to their previous deployments. Other library source files were unchanged, although some compiled dependencies changed.

LibraryPrevious ImplementationNew ImplementationUsed By
LibConvert0x71e8ab0a025c0b96d64c34759880e6ba2ba0baa00x98b7efa3ceb5076a59aa54256657114dba4401a1ConvertFacet
LibPipelineConvert0xa4a2d1e394faac3e60297a55cdceeb38c0b6ca180xdd7f09a5c4ea7d742a6a2916509e968faffd22a5ConvertFacet, PipelineConvertFacet
LibSilo0xefa4e6492966228a7af3d5d9045bd9c9e5dc72bf0xb8d171d90bbcd178b594b69b7c3f510775eeaf46ConvertFacet, PipelineConvertFacet, ClaimFacet
LibTokenSilo0xf2a0e7fb0e9b1189b14274418e4ac78ae449b4ed0x8013c1b3d6d63741c6fefb05b4106f330cf18118ConvertFacet, PipelineConvertFacet, ClaimFacet
LibEvaluate0x1687f3eccced54e4ea4d98ffa13e2108954501e50xe3de9e4f8cfd5f52522e2a6ace70787c880dbf89SeasonFacet
LibGauge0xfa27f1b255a02a929a7a4e668066ce76cadcc09c0x72a5e9f867dda828473b19f1f9e5c2f0d72b99b2SeasonFacet
LibIncentive0xb3f71bf8362cbaafebb99e1e5fac02c85e1ecfcc0x20ad7475af48004993a9b0da582155b0c15c6fbaSeasonFacet
LibShipping0x166ab367e077e65f1a4f273f05d8c25a3c3ea3980x3d71794eb70bea52681b8bce8e9c7af33fbdbad1SeasonFacet
LibWellMintingSeasonFacet: 0xd76d2011647f57071cca0d182f0d524abeaee84e; SeasonGettersFacet: 0x6dd836e7fe603bd73532bf6b5cbb188b7fcc7fa90x795381dfec56fda5a423080f6d7b446c3172974cSeasonFacet, SeasonGettersFacet
LibFlood0x20a9aeac56fee169dec4d8a5c454e818b55fa8af0xaba142b51d6684e5471537379cead55afe2f1202SeasonFacet
LibGerminate0xaedabcc13a7c44d612cb3776b6a2f3a81fd3d9320x46a29a054861fa5eba24ed262c4215cc3e2365f1SeasonFacet
LibWeather0x82e2cfe47cf2ddd23755f81abb1349bdd96b5bfe0x9f0e6b3e54a91d677e30ce180dbe193cc65c388dSeasonFacet

The old penalty used the $1.025 Excessively High Price threshold. PI-11 used a separate $1.005 convertDownPenaltyRate without changing the existing evaluation parameters. The new minting-threshold fields had no prior equivalents. Dewhitelisting set Gauge Points and optimal Deposited PDV percentages to 0, set stalkEarnedPerSeason to the minimum raw value of 1, and preserved isSoppable for previous Flood claims. Optimal Deposited PDV changed from 12.5% to 33.333333% for PINTO:cbETH, from 25% to 33.333333% each for PINTO:cbBTC and PINTO:USDC, from 12.5% to 0 for PINTO:WETH, and from 25% to 0 for PINTO:WSOL. The three remaining raw percentages sum to 99.999999%, with normalization in the Seed Gauge calculation.

Function Changes

Event Changes

\ No newline at end of file diff --git a/public/pi/12/index.html b/public/pi/12/index.html new file mode 100644 index 000000000..3555396f9 --- /dev/null +++ b/public/pi/12/index.html @@ -0,0 +1,797 @@ +PI-12: Decrease Excessively Low L2SR Threshold

PI-12: Decrease Excessively Low L2SR Threshold

Executed on September 8, 2025 at 08:48 UTC.

Summary

Decrease the Excessively Low L2SR Threshold from 12% to 5% in order to incentivize Converts Up.

Links

Problem

The Pinto price was below the value target, which was largely attributed to downward price volatility in the crypto market. During this time, there had been minimal value Withdrawn from the protocol, indicating that even if there were Converts that increased the price to the value target, it was unlikely to decrease the amount of liquidity in the protocol.

Given this information, it was likely suboptimal for the protocol to so heavily disincentivize Upward Converts.

The Excessively Low L2SR Threshold () enables the protocol to prioritize preserving liquidity during periods of excessively low liquidity. Accordingly, when this threshold is met (i.e., the liquidity level is below the threshold), the protocol decreases the Crop Scalar () by up to 50 percentage points per Season toward its zero floor, moving toward a state in which value held in the LP token with the highest Seed rate is rewarded with the highest relative number of Seeds permitted by the lower bound of the Crop Ratio.

With the Convert Down Penalty adjusted in PI-11, during positive-TWAΔP Seasons while mints tracked toward the active threshold remain below it, there is a 100% Mown Stalk Penalty (subject to the non-Germinating minimum) on the portion of a Pinto-to-LP Convert below $1.005 (the then-current Convert Penalty price). The combination of the low Crop Ratio and additional friction to Convert Down had created conditions where there was an extremely high disincentive to Convert Up.

Solution

Decreasing to 5% moves the L2SR of 8.5% from the excessively low range into the reasonably low range. In the newly reclassified L2SR range, the Crop Scalar increases by up to 1 percentage point per Season when the TWAΔP is nonpositive, Pod Rate is at least 15%, and required liquidity oracles succeed. A higher Crop Scalar raises the Crop Ratio, increasing Pinto’s Seed rate relative to the LP token with the highest Seed rate. This reduces the Seed advantage of holding LP tokens and can make Converting LP to Pinto (Converting Up) more attractive.

Rationale

While the ideal solution would be to design a system that dynamically adjusts the L2SR thresholds as a function of the historical lookback of value Withdrawn from the protocol, implementing a multi-Season lookback to support such a peg maintenance feature is a major development undertaking. A lower friction, short term solution is to lower from 12% to 5%.

Contract Changes

Other Contract / Parameter Changes

Updated s.sys.evaluationParameters.lpToSupplyRatioLowerBound from 0.12e18 (12%) to 0.05e18 (5%). All other EvaluationParameters fields were unchanged. The threshold is expressed with 18-decimal precision and the excessively low classification uses a strict less-than comparison. L2SR values from 5% inclusive to 12% exclusive therefore move from excessively low to reasonably low. The call did not reset the Crop Scalar or change the Crop Ratio bounds. It also left the Convert Down Penalty Gauge value and data unchanged at execution.

Function Changes

Event Changes

\ No newline at end of file diff --git a/public/pi/13/index.html b/public/pi/13/index.html new file mode 100644 index 000000000..deeb1114d --- /dev/null +++ b/public/pi/13/index.html @@ -0,0 +1,800 @@ +PI-13: Dynamic Convert Up Bonus + Optimizations

PI-13: Dynamic Convert Up Bonus + Optimizations

Executed on October 23, 2025 at 01:13 UTC.

Summary

  1. Dynamic Convert Up Bonus: Implement a Dynamic Convert Up Bonus with a dynamic Convert Up Bonus per PDV Converted and a dynamic Convert Up Bonus Capacity. Add signed Grown Stalk slippage controls to Converts.
  1. Seed Gauge Points: Normalize the Seed Gauge Points every Season.
  1. Morning Auction: Change the Temperature every block during the Morning Auction.
  1. Soil Demand: Update the minimum Sown Pinto threshold to measure demand for Soil to be a function of the initial Soil issued.
  1. Till Scalar: Update the Till Scalar to dynamically adjust as a function of Pod Rate.
  1. Rain and Flood: Update the condition for the system to start Raining/Flooding to include the L2SR.
  1. Tractor Signatures: Upgrade Tractor to support smart contracts.
  1. Deposit Approvals: Fix checks for ERC1155 global approvals for Silo Deposits.
  1. Convert Penalty: Update the Generalized Convert Penalty such that it properly penalizes Converts that are negative to peg maintenance.
  1. Well Valuation: Normalize Well liquidity units and guard price calculations for very small pools.
  1. Deposit PDV Return: Correct the PDV returned by Deposits.

+

Links

Problems

1. Dynamic Convert Up Bonus

Despite the 200% Crop Ratio, there was an insufficient incentive to Convert up, leading the protocol to spend excessive time below its value target.

2. Seed Gauge Points

The effect of the changes in Gauge Points from Season to Season fluctuated with the total number of Gauge Points. This decreased the accuracy with which Pinto can adjust the Seeds between Whitelisted Deposited LP tokens.

3. Morning Auction

The Temperature during the Morning Auction did not increase continuously throughout the Auction, leading to more Pod issuance than needed.

4. Soil Demand

A static threshold (25 Soil) to measure demand for Soil made Pinto less resilient to Soil Demand manipulation at larger supply.

5. Till Scalar

Soil issued above the value target abruptly increased/decreased when the Pod Rate was close to the Pod Rate thresholds.

6. Rain and Flood

It may be less healthy for it to Flood at lower L2SRs than at higher L2SRs.

7. Tractor Signatures

Smart contracts were unable to utilize Tractor.

8. Deposit Approvals

Silo Deposits did not properly adhere to the ERC1155 token standard.

9. Convert Penalty

The implementation of the Pipeline Convert Penalty was mistakenly over-penalizing certain Converts.

10. Well Valuation

The time-weighted Well liquidity getter returned values in the non-Pinto token’s native decimal precision. The shared Well price calculation also lacked a minimum Pinto-reserve guard, thereby allowing it to calculate prices for very small pools.

11. Deposit PDV Return

The Deposit function returned raw Stalk in the slot documented as PDV, so callers could misinterpret the value of a Deposit even though its stored accounting used the calculated PDV.

Solutions

1. Dynamic Convert Up Bonus

Implement a Dynamic Convert Up Bonus that works similarly to the Cultivation System – which has demonstrated efficacy with a similar problem in the Field (elaborated in Rationale) – to create a one-time Stalk bonus, realized immediately upon Convert. The Convert Up Bonus per PDV is dynamic, and fluctuates based on the demand for Converts over the past two Seasons. The Convert Up Bonus Capacity, measured in PDV, changes similarly to how the Soil supply changes in the Field. The bonus applies to Well LP → Pinto Converts, is capped by the Deposit’s available Grown Stalk, and uses capacity that ramps to its Season maximum over the first half of the Season. The gauge resets the bonus and maximum capacity to zero when TWAΔP is positive. The new Convert variants allow callers to require a minimum net Grown Stalk result, including a minimum bonus. For more info see Dynamic Convert Bonus and Penalty System: Fine-Tuned Convert Incentives.

2. Seed Gauge Points

Normalize the Seed Gauge Points across Whitelisted LP tokens to target a total of 10,000 every Season, subject to integer rounding.

3. Morning Auction

Upgrade the Morning Auction to change the Temperature based on elapsed time, observable every block, over 600 seconds with a floor of 1% of the Maximum Temperature, subject to fixed-point rounding.

4. Soil Demand

Update the threshold to measure demand for Soil to be min(initial Soil, max(50 Pinto, 5% of initial Soil)).

5. Till Scalar

Set the Till Scalar to decrease linearly from 1.2 at a 3% Pod Rate to 0.25 at 25%, clamped at those endpoints, for above-target and mixed-sign Soil issuance.

6. Rain and Flood

Update the criteria for Pinto to Rain/Flood to be TWAΔP > 0, Pod Rate < 3%, and L2SR >= 40%.

7. Tractor Signatures

Update the Tractor system to be ERC-1271 compatible.

8. Deposit Approvals

Update Silo Deposits to properly support the ERC1155 global approval standard.

9. Convert Penalty

Update the Pipeline Convert Penalty to take the maximum of the penalty for Converting beyond the value target and the penalty for Converting more than the instantaneous DeltaP, capped at the PDV Converted.

10. Well Valuation

Normalize the time-weighted Well liquidity getter to 18 decimal places. Return a zero price when the reserves used by the shared Well price calculation contain fewer than 10 Pinto.

11. Deposit PDV Return

Return the calculated PDV in the Deposit function’s PDV output while retaining its existing token-count and stem outputs.

Rationale

1. Dynamic Convert Up Bonus

The Cultivation System in the Field has demonstrated efficacy at creating an efficient market for Soil and Temperature. For the Dynamic Convert Up Bonus, the need to offer a Convert Up Bonus Capacity that generally meets demand, and offer a reasonable Stalk Bonus per PDV, is a very similar problem (i.e., amount, rate). Thus, a very similar mechanism has been created for the Silo.

Changing the Convert Up Bonus per PDV dynamically based on demand over the past two Seasons – decreasing the Bonus when demand increases or at least 95% of capacity is used, increasing it when demand decreases and Pinto’s Seed rate is higher than the highest LP Seed rate, and otherwise keeping it constant – will allow the protocol to discover the Bonus per PDV at which there is demand to Convert.

By changing the Convert Up Bonus Capacity to meet demand for Converts up, the protocol will minimize the instances where there is a significant amount of unused Capacity. This should minimize the disincentive to Convert by avoiding instances where there is significant unused Convert Up Bonus Capacity.

2. Seed Gauge Points

Normalizing the Seed Gauge Points every Season, subject to integer rounding, will result in a similar magnitude of changes in Seeds from Season to Season across long periods of time. This will keep the protocol’s response to changes in state more consistent.

3. Morning Auction

By jumping the Temperature during the Morning Auction after a number of blocks, the protocol was paying a higher interest rate than it needed to to participants in the Morning Auction. By changing the Temperature every block, the protocol reduces the gaps between offered Temperatures when attracting lenders.

4. Soil Demand

Scaling the minimum Sown threshold with initial Soil makes the cost of registering demand grow with the available supply. Capping the threshold at initial Soil keeps it reachable in Seasons with fewer than 50 Soil initially available.

5. Till Scalar

Interpolating between the existing endpoint scalars removes abrupt changes in Soil issuance at Pod Rate boundaries. Higher Pod Rates still reduce Soil issuance. The same interpolation applies to above-target issuance and Soil issuance when TWAΔP is nonpositive but instantaneous ΔP is positive, preserving the response to debt while smoothing its transitions.

6. Rain and Flood

When Pinto Floods at lower L2SRs, Pinto risks short term yield farmers exiting the protocol, decreasing the L2SR further. It may be healthier for the system to continue growing without a Flood to stunt momentum until the L2SR is high enough to sustain large exits without compromising long term sustainability.

7. Tractor Signatures

Smart wallets can use ERC-1271 contract signatures to authorize Tractor requisitions. By allowing smart contracts to utilize Tractor, smart wallets are able to interact with the Pinto protocol more easily.

8. Deposit Approvals

By supporting ERC1155 global approvals, Silo Deposits adhere to the ERC1155 Standard.

9. Convert Penalty

Pinto penalizes Converts when the Convert moves Pinto away from its value target, and when the number of tokens Converted exceeds the DeltaP of the Well(s). When a Deposit is penalized, the maximum penalty is equal to the number of Grown Stalk the Deposit has (per PDV). When a farmer Converted past the value target, they were effectively penalized twice (once for moving Pinto away from the target, and another for Converting beyond deltaP), which could double-count the overlapping penalized PDV. Given that the maximum number that Pinto could ever penalize per PDV is the number of Grown Stalk associated with that PDV (as any penalty beyond that would mean that a farmer would lose less Grown Stalk by manually Withdrawing and Depositing LP tokens rather than Converting), the penalty should be capped at 100% of the Grown Stalk of the Converted assets.

10. Well Valuation

Normalizing liquidity to a common precision makes getter results comparable across non-Pinto tokens with different decimals. Returning zero for a Well with fewer than 10 Pinto reserves avoids presenting a price calculation from a pool too small for the protocol’s minimum-reserve criterion.

11. Deposit PDV Return

Returning the calculated PDV ensures that a contract calling the Deposit function receives the Deposit’s value in Pinto, rather than the number of Stalk minted. This corrects the external result without changing the Deposit’s Stalk minting calculation.

Contract Changes

Initialization

Executed InitPI13.init(address,uint256) at 0x59816de18d73690d30c6b9de2375c34b2ef7e7e7, reading key 0 from 0xbe95c6806ab4eefc10ac9e96938c3a222964dd91. Set maxTotalGaugePoints to 10000e18 and normalized existing LP Gauge Points. Added the Convert Up Bonus gauge with initial maximum capacity 0, capacity factor 1%, tracked deficit 16,702.835 Pinto, and stored bonus-per-PDV value 2027670666 (0.2027670666 Stalk per PDV). Set the Morning duration to 600 seconds and morningControl to floor(1e18 / 240).

Facet Changes

FacetActionPrevious ImplementationNew Implementation
FieldFacetReplace0x36e4dd6f2be854962174c3e398cd0e11d49e404c0x32124b4da9b23659c1ad4b8be4fc2d274701c3d1
ConvertFacetReplace0x9e090554525af3e39b7191bcefaed4a594bfdf240x508900b00970af419c915c921ecc81d7e0a7ebcb
ConvertGettersFacetReplace0xc2eddd1cfb0ac4aab93a6aaedc097b8ccc1147100x32a036190967a11280ecd944d90b85d86f43e24f
PipelineConvertFacetReplace0x68206dab632667e293589078800a9a7ccca39b630x51b9fca1c4900584861efc794458dfa47775dd4b
SiloFacetReplace0xf6af001b8879a2e30db294b4c8deccbd0d168b340xf4e60ecdc7ddd4037f1b9aa7d27a30d367871ca5
SiloGettersFacetReplace0x954fba56a8356e7439f41a39579c7be59791d92f0xa9f983f26828a99146f7f119a358ad930edbf420
GaugeFacetReplace0xb054a1348d2a9fd5ba1eaa51ef1aee2d6ad402ed0xa98400591c72ce2a2bde3b170f5a6a1b070ee4ea
GaugeGettersFacetReplace0x889d0183c752b89e8d6cd62870b4f8eb70d108930x7d5b807202b8ae3dfb4b6d988d85622590b22862
SeasonFacetReplace0x0c5aa699e1979493e172d114193ee75c6a5afb390xb9d1c6e65a8934ec86d70f358028943e63ee0793
SeasonGettersFacetReplace0x47246b05945031432f30becbf602d2d7dc6fece00x87e626e6187bc0df123cf6441ccc9f31a46f178e
ApprovalFacetReplace0x463edf62ff627351518dcf0ac015c1e98562412f0xa456002541ffdd0cf4c8cdd273210581f2bf0314
ClaimFacetReplace0x8bbcc20eaf03191f1970ed5d93567ab76034f44d0x5e71bf027203bcbc9b1bd22504720d8e8be30cf7
BDVFacetReplace0xc20d8ab2b5d9039cc4c1fc66c0d740aa1983298a0xc09d2bca905ea40ba8999da6521f811331c13062
OracleFacetReplace0x5d8e457dd58f443237e105c2f27dc2c75133976c0x83c442257dffa7887418f1bd249a400eccfac60d
TractorFacetReplace0x007a0b3bf5a9efc922e83bf0ebe7bf27fc2103bf0xc2fc7963f76205dc57842e1a90c3e487bd16a556

The cut replaced 233 existing selectors and added 11 selectors. It removed no selectors. ApprovalFacet and BDVFacet had import-only changes. ClaimFacet and OracleFacet retained their own source files but were redeployed with updated dependencies. Replacing a facet did not change every function in it.

Other Contract / Parameter Changes

Externally linked libraries are listed below. Every listed library address changed. LibGerminate, LibShipping and LibWellMinting retained their own source files, although their compiled dependencies may differ. The LibIncentive branch relocation preserved its reward outputs. The old LibSilo and LibTokenSilo deployments varied by consuming facet.

LibraryPrevious ImplementationNew ImplementationUsed By
LibConvert0x98b7efa3ceb5076a59aa54256657114dba4401a1 (ConvertFacet)0xb3626b534ff81442579913de1f31c51a045b5261ConvertFacet, PipelineConvertFacetNew direct dependency: PipelineConvertFacet
LibPipelineConvert0xdd7f09a5c4ea7d742a6a2916509e968faffd22a5 (ConvertFacet, PipelineConvertFacet)0xfc537aa415b89def06d97e23c04baf4039e8bbcbConvertFacet, PipelineConvertFacet
LibSilo0xb8d171d90bbcd178b594b69b7c3f510775eeaf46 (ConvertFacet, PipelineConvertFacet, ClaimFacet)0xefa4e6492966228a7af3d5d9045bd9c9e5dc72bf (SiloFacet)0x9f327f1f6810aaf5a4ab0704b62b4ed6bb0ea334ClaimFacet, ConvertFacet, PipelineConvertFacet, SiloFacet
LibTokenSilo0x8013c1b3d6d63741c6fefb05b4106f330cf18118 (ConvertFacet, PipelineConvertFacet, ClaimFacet)0xf2a0e7fb0e9b1189b14274418e4ac78ae449b4ed (SiloFacet)0xe97ee5afcb656126c6a89b72d8617061213f9f4dClaimFacet, SiloFacetRemoved direct dependency: ConvertFacet, PipelineConvertFacet
LibEvaluate0xe3de9e4f8cfd5f52522e2a6ace70787c880dbf89 (SeasonFacet)0xbff46c34d49b976d9c133fafb0529cff6704138bSeasonFacet
LibGauge0x72a5e9f867dda828473b19f1f9e5c2f0d72b99b2 (SeasonFacet)0x35a71bc019539dda1e04e549609c6f620644e2c7SeasonFacet
LibIncentive0x20ad7475af48004993a9b0da582155b0c15c6fba (SeasonFacet)0x31046cd4b22c6af8a677f641f4d706ccce1ca570SeasonFacet
LibShipping0x3d71794eb70bea52681b8bce8e9c7af33fbdbad1 (SeasonFacet)0x71a9f8e8a9082381ba7352d5b82e5e0849c6ddf2SeasonFacet
LibWellMinting0x795381dfec56fda5a423080f6d7b446c3172974c (SeasonFacet, SeasonGettersFacet)0x7cbd0b120a1ee1cdac1ed245ee23a80b37c7a6f9SeasonFacet, SeasonGettersFacet
LibFlood0xaba142b51d6684e5471537379cead55afe2f1202 (SeasonFacet)0x3bd60d6c0df87fdd90c510d1de5c1a089f4e6b25SeasonFacet
LibGerminate0x46a29a054861fa5eba24ed262c4215cc3e2365f1 (SeasonFacet)0xbcf22afbbda11ac84ea001451d8ae60b424b0b97SeasonFacet
LibWeather0x9f0e6b3e54a91d677e30ce180dbe193cc65c388d (SeasonFacet)0xed46c5936939d4ffd25284b4825e14f02e4bb90dSeasonFacet

The new bonus gauge used target-Season bounds of 250–1,000, a minimum maximum capacity of 50 PDV, and capacity-factor adjustment bounds of 0.5–1.5 percentage points before inversion for decreases. The factor was bounded between 1% and 100% when adjusted. Its tracked use, prior-Season use and last-used bonus began at 0. Existing Pod Rate bounds (3% and 25%), L2SR bounds (5%, 40% and 80%) and Till Scalar endpoints (1.2 and 0.25) were retained. The Soil-demand calculation replaced the fixed 25-Pinto threshold with min(initialSoil, max(50e6, floor(initialSoil * 0.05e6 / 1e6))).

Function Changes

Event Changes

+

+

\ No newline at end of file diff --git a/public/pi/14/index.html b/public/pi/14/index.html new file mode 100644 index 000000000..36d83aec8 --- /dev/null +++ b/public/pi/14/index.html @@ -0,0 +1,797 @@ +PI-14: wstETH Liquidity, Pod Referrals and Batched Operations

PI-14: wstETH Liquidity, Pod Referrals and Batched Operations

Executed on January 20, 2026 at 01:14 UTC.

Summary

  1. wstETH Liquidity: Whitelist the Pinto-wstETH Well to decentralize the assets providing liquidity against Pinto.
  1. Dynamic LP Distribution: Add a dynamic LP Distribution Gauge to shift the optimal Deposited LP distribution from Pinto-cbETH to Pinto-wstETH over 360 successful scheduled updates.
  1. Pod Referrals: Introduce Pod referrals to reward eligible Farmers for attracting Sowing, and adjust above-peg Soil issuance for the additional Pods.
  1. Tractor Dynamic Data: Add dynamic operator data and compressed-data publication to Tractor.
  1. Batch Converts: Add batch Converts, including multiple Anti-Lambda-Lambda Converts, to reduce repeated transaction overhead.
  1. Batch Pod Marketplace Operations: Add batch creation, filling and cancellation of Pod Listings and Pod Orders.

Links

Problems

1. wstETH Liquidity

Pinto exclusively incentivized liquidity that was issues by Coinbase/Circle. Concentrated exposure to a single (set) of entities goes directly against Pinto’s value proposition as a censorship resistant currency.

2. Dynamic LP Distribution

Optimal LP distribution targets were fixed until updated. Prior to this upgrade changes in distribution targets happened all at once, not gradually over time.

3. Pod Referrals

Farmers did not receive a protocol referral bonus for attracting another Farmer to Sow.

4. Tractor Dynamic Data

Tractor’s existing operator paste instructions filled specified locations in signed Blueprint calldata. They did not provide a separate key-value channel through which Blueprint contracts could read arbitrary-length operator data during execution. Publishing a Requisition also required emitting its full structured data.

5. Batch Converts

Multiple Convert operations required separate calls, including repeated checks around each call. Each Anti-Lambda-Lambda Convert could update only one Deposit, so updating several Deposits required several operations even when bundled through farm or advancedFarm.

6. Batch Pod Marketplace Operations

Creating, filling or cancelling several Pod Listings or Pod Orders required individual calls. Combining calls through farm or advancedFarm still repeated the checks around each marketplace action.

Solutions

1. wstETH Liquidity

Deploy and whitelist an upgradeable Constant Product 2 Pinto-wstETH Well. wstETH is the non-rebasing wrapped representation of Lido’s stETH. Its value reflects the underlying staking position rather than an automatically increasing token balance. The Base deployment introduces a different staking-provider exposure alongside Pinto’s existing assets.

Configure the Well with the Multi Flow Pump, the existing default Gauge Point and liquidity-weight implementations, and a composed Chainlink oracle using ETH/USD and wstETH/ETH feeds. Start its optimal Deposited LP share and Gauge Points at zero, with an initial Stalk growth rate of 1 raw unit per PDV per Season.

2. Dynamic LP Distribution

Add a stateful LP Distribution Gauge with two configured entries. Decrease Pinto-cbETH’s optimal share from 33.333333% to 0% and increase Pinto-wstETH’s share from 0% to 33.333333%. Each scheduled update changes the two targets by 0.092593 percentage points in opposite directions, clamping the final step to the target. Starting from these values, the targets are reached on update 360. A subsequent successful update disables the Gauge after finding both targets already reached.

During Sunrise, the existing Seed Gauge runs before the generalized Gauges. The new optimal shares therefore affect subsequent Seed Gauge calculations. Changing these targets adjusts incentives. It does not transfer liquidity or move Farmers’ Deposits automatically.

Each distribution entry can optionally supply a function that recalculates its signed change. Neither initial entry configures such a function. A failed optional call or unsupported encoding retains that entry’s prior change. A failed outer Gauge call retains its stored value and data and rolls back changes made within that call. If a Gauge call succeeds but returns incorrectly encoded data, decoding that data reverts the entire Sunrise transaction.

The 360-update progression describes the configured Sunrise path. The deployed lpDistributionUpdateGauge entry point also accepts caller-supplied Gauge data without an owner-only or self-call restriction. The implementation therefore does not enforce an exclusive once-per-Season schedule for all calls to that entry point.

3. Pod Referrals

Add sowWithReferral, allowing a Farmer to specify a referrer while retaining sowWithMin’s minimum acceptable Temperature, minimum Soil requirement and choice of balance source. An eligible, nonzero referrer distinct from the Sowing Farmer receives a nominal 10% bonus, and the referred Farmer receives a nominal 5% bonus. These rates apply to rounded portions of the Pinto actually Sown and are converted into Pods using the same Sowing calculation.

Issue the ordinary Plot first, then the referred Farmer’s bonus Plot, then the referrer’s bonus Plot. Bonus Pods consume no additional Soil and burn no additional Pinto. Both bonus allocations count toward one protocol-wide limit of 2,000,000 Pods. When approaching the limit, the referred Farmer’s bonus is allocated first, and the referrer receives only the remaining budget. Referral bonuses stop when the shared limit is reached. Invalid referrals leave ordinary Sowing intact with zero referral bonuses.

Track Pinto Sown for referral eligibility. A Farmer qualifies after Sowing at least 1,000 Pinto, including the historical values loaded at initialization. An eligible Farmer who meets this Sowing threshold can designate an otherwise ineligible address as a delegate, change that delegate, or clear it. This grants eligibility to the specified address. Bonuses are paid to the eligible address passed as the referral, rather than automatically redirected from the original Farmer’s address.

Adjust the above-peg Soil calculation by multiplying its Temperature-based debt denominator by 1 + referrerPercentage + refereePercentage, with the percentages normalized to their six-decimal representation. At the initialized rates this factor is 1.15 before the existing Pod Rate and cultivation adjustments. The implemented formula uses the configured percentages even when no valid referral is used or the bonus budget has been exhausted. It does not check isReferralSystemEnabled(). Below-peg Soil issuance is not changed by this formula. The configured percentages continue to reduce calculated Soil after the cap is exhausted until a subsequent change alters the implementation or parameters.

4. Tractor Dynamic Data

Add tractorDynamicData, which accepts the existing signed Requisition and static operator data plus an array of numeric keys and arbitrary byte values. Blueprint contracts can read these values through getTractorData(key) during execution. The function clears the supplied keys after the Tractor calls complete, and transient storage is also cleared at transaction end. Missing or cleared keys return empty bytes.

Preserve Requisition verification, Blueprint execution limits and the existing execution-result array. Add publishData(bytes), which emits the supplied bytes for off-chain distribution. It does not decompress the data or verify a Requisition. Keep publishRequisition as the separate verified structured-publication path.

5. Batch Converts

Add batchConvert, which processes a nonempty array of Convert requests in order using shared Convert logic. Each request supplies its encoded Convert type, Deposit stems, token counts and signed Grown Stalk slippage tolerance. The result array returns the Convert kind, resulting Stem, input and output token counts, and input and output PDV for each operation (the ABI retains the fromBdv and toBdv field names).

Each Anti-Lambda-Lambda item still updates only one Deposit. Several such items can appear in one batch. Each operation sees the state left by earlier operations, including consumed Convert capacity. If any operation or the enclosing checks revert, the entire batch reverts.

6. Batch Pod Marketplace Operations

Add batch functions to create, fill and cancel Pod Listings and Pod Orders. Preserve the existing ownership, listing/order validation, transfer and allowance rules through the shared helpers. Each batch runs in order and is atomic if an operation reverts.

Listing fills use one payer balance mode for the batch while preserving each Listing’s receiving mode. Order creation makes one aggregate token-receipt call for the requested Pinto and returns an array of Order IDs. Order fills and cancellations use one receiving mode per batch. The existing single-operation entry points remain available.

Rationale

1. wstETH Liquidity

Adding a Lido-based staking asset diversifies provider exposure away from Coinbase/Circle to support the protocol’s censorship-resistance objective.

2. Dynamic LP Distribution

A gradual change gives Farmers time to respond to changing Seed incentives while preserving the combined configured optimal share of the two ETH-linked Wells. The generalized mechanism eliminates the need for repeated manual target updates.

3. Pod Referrals

The referral incentive rewards attracting additional Sowing while bounding the total bonus debt. The tradeoff is more Pods for the same number of Pinto burned. The proposal favored that additional cost to attract Sowing. The eligibility threshold ties access to prior participation to create a cost for self-referrals, while delegation supports a separate referral address designed to preserve on-chain privacy.

The revised above-peg denominator accounts for full referral participation when setting Soil. When participation is lower or the bonus cap is met, realized bonus issuance can be lower than this assumption.

4. Tractor Dynamic Data

A transient key-value channel lets Blueprint contracts consume variable-length information without forcing it into fixed paste locations in signed calldata. Explicit cleanup limits the lifetime to the Tractor call on the successful path, while EIP-1153 supplies transaction-level cleanup. Compressed-data publication provides an off-chain distribution option without changing what constitutes a valid signed Requisition.

5. Batch Converts

Batch Converts apply asset-backing and Pinto-supply checks, together with reentrancy protection, once around the entire batch. Each Convert retains its own accounting, slippage enforcement and events. This reduces repeated overhead and allows multiple Deposit valuation updates in one transaction. If any Convert fails, the entire batch reverts.

6. Batch Pod Marketplace Operations

Batching reduces repeated checks and, for Order creation, repeated token receipts. It simplifies submitting several related operations while retaining individual marketplace events.

Contract Changes

Initialization

Executed InitPI14.init(address,uint256) at 0xc1d6cfc744fd017ebc989e63d89374bee1e5a1fc, passing helper storage 0xbe95c6806ab4eefc10ac9e96938c3a222964dd91 and key 1.

The initializer deployed and whitelisted the Pinto-wstETH Well, configured the stateful LP Distribution Gauge, and loaded historical referral eligibility data from the helper. Execution events confirmed the 10% referrer rate, 5% referee rate, 2,000,000-Pod budget and 1,000-Pinto eligibility threshold. The initializer did not update Tractor’s version. Historical before/after calls both returned 1.0.0.

The storage update moved s.sys.initialSoil to the upper half of its slot and used the lower half for the referral eligibility threshold. It did not migrate the previous starting-Soil value. At the execution block, getSoilSoldOutThreshold() and getSoilMostlySoldOutThreshold() returned zero, down from 20.497512 and 57.393033 Soil respectively in the preceding block. Sun.setSoil populates the relocated field at the next successful Sunrise. The public initialSoil() getter still returns remaining s.sys.soil.

Facet Changes

Replaced 228 selectors and added 22 selectors across 19 facet implementations. No selectors were removed. Add / Replace denotes facets receiving both new and existing selectors. Replacement alone does not mean every function in a facet changed.

FacetActionPrevious ImplementationNew Implementation
GaugeFacetAdd / Replace0xa98400591c72ce2a2bde3b170f5a6a1b070ee4ea0xf9f1d9c6ef1ca5ec0897c266d7b4e016e955d916
GaugeGettersFacetReplace0x7d5b807202b8ae3dfb4b6d988d85622590b228620xc0b381741820808b6407cdc8b03e8561259f8e5d
SeasonFacetReplace0xb9d1c6e65a8934ec86d70f358028943e63ee07930x4aeee50b11c3682605dceca1feacd96349383cd2
FieldFacetAdd / Replace0x32124b4da9b23659c1ad4b8be4fc2d274701c3d10xae94197e16b31443fe1c333a32eda30eb3c1a942
TractorFacetAdd / Replace0xc2fc7963f76205dc57842e1a90c3e487bd16a5560xc8706ff2a0da6b3367aa506dcbb608ccf96148de
MarketplaceFacetReplace0x5aeb7c0a256b167bae026056d32818539b1734b40x85436279a52537ef03864e268d73d3ba37e169ec
MarketplaceBatchFacetAddNot applicable — new facet0x40e42f3d568faf47c539a7d2a61e24629819bad4
ConvertFacetReplace0x508900b00970af419c915c921ecc81d7e0a7ebcb0xdc37f26363b305affc93c564ee879a265bcbff4d
ConvertGettersFacetReplace0x32a036190967a11280ecd944d90b85d86f43e24f0x334a110ad41fd417d4c8c3f82d9c85a3850192be
ConvertBatchFacetAddNot applicable — new facet0x923a7096f7338660e60b4dc0ae21d2413e399739
ClaimFacetReplace0x5e71bf027203bcbc9b1bd22504720d8e8be30cf70xfc4499f812014bebaf9686ce0312a77cca65137a
PipelineConvertFacetReplace0x51b9fca1c4900584861efc794458dfa47775dd4b0xa66460626d1f8845085b1cdd5e527db1db998b1b
SiloFacetReplace0xf4e60ecdc7ddd4037f1b9aa7d27a30d367871ca50x8646649c0f80db8665358f4548ae0d1ecc3910a5
SiloGettersFacetReplace0xa9f983f26828a99146f7f119a358ad930edbf4200x92a2ddc9d6bcde63fb4473033ef8beea4145d0fd
MetadataFacetReplace0xf6506176a027ed4d5cdbab23d9dfcdec2b35b2a80xced0ea96c44341343c13dc671c22e858e21675e0
ApprovalFacetReplace0xa456002541ffdd0cf4c8cdd273210581f2bf03140x596050ccbbe49966a29be8663b2ed6a1f5dc1870
TokenFacetReplace0x7f492edcd56335b2d2aee29dfe39df33bbe43bb80xd29e38e4a803feac3503fd7402181bba79d3d3f0
TokenSupportFacetReplace0x9d214daf535396d515d93831fc7fe5fa137b4f300x7f1bb9f51c636012cfaadc9e2db124edd21a7b92
FarmFacetReplace0x39322b0448a7c7b6abf980d204fa0c45df1886dc0x16d28e43e43c6d5b2e95140f2f3000dcf87eb1d9

Other Contract / Parameter Changes

Deployed the Pinto-wstETH Well proxy at 0x3e1155245ff9a6a019bc35827e801c6ed2ce91b9, with the Well implementation instance at 0x3e11afd88f9987df06557ee84d8a38879b0503b0. The Base wstETH token is 0xc1cba3fcea344f92d9239c08c0568f6f2f0ee452.

Configured the existing LSDChainlinkOracle at 0x3ca165997a12863eb63e4418d2e97aca3cdcdadc with ETH/USD feed 0x71041dddad3595f9ced3dccfbe3d1f4b0a16bb70 and a 3,600-second timeout, and wstETH/ETH feed 0x43a5c292a453a3bf3606fa856197f09d7b74251a and a 129,600-second timeout. The new asset uses wellBdv, issues 1e10 raw Stalk units per PDV, and starts with stalkEarnedPerSeason = 1, zero Gauge Points and zero optimal share.

The Well uses Aquifer 0xba51aa60b3b8d9a36cc748a62aa56801060183f8, base Well implementation 0xba510990a720725ab1f9a0d231f045fc906909f4, Constant Product 2 at 0xba510c289fd067ebba41335afa11f0591940d6fe and Multi Flow Pump at 0xba51aaaa66dab6c236b356ad713f759c206dcb93. These configured components were not new PI-14 component deployments.

The linked-library inventory below lists the external dependencies of the added or replaced facets. It also identifies LibConvert as a consumer of LibTokenSilo. LibSeedGauge is the renamed successor to LibGauge, shown in the previous-implementation column. All listed deployments changed. A changed address does not imply a changed economic rule in that library’s own source.

LibraryPrevious ImplementationNew ImplementationUsed By
LibEvaluate0xbff46c34d49b976d9c133fafb0529cff6704138b0x1105414b01a6d2214d1c33a1f756dea2e5e87259SeasonFacet
LibFlood0x3bd60d6c0df87fdd90c510d1de5c1a089f4e6b250xef75cae236476bfedc5207d57e5ea7ea315a8c12SeasonFacet
LibGerminate0xbcf22afbbda11ac84ea001451d8ae60b424b0b970x752f502897667c6ba438d35b39439c84210dad06SeasonFacet
LibIncentive0x31046cd4b22c6af8a677f641f4d706ccce1ca5700x735aab105c222bee6aaf520adc4cf3128fdcc6dbSeasonFacet
LibSeedGauge (formerly LibGauge)0x35a71bc019539dda1e04e549609c6f620644e2c70xbcc581f0d70a033e21b31ea695fd3c2978503146SeasonFacet
LibShipping0x71a9f8e8a9082381ba7352d5b82e5e0849c6ddf20xf528edef6598d1907eef6e7ad1a8b87e54c736a9SeasonFacet
LibWeather0xed46c5936939d4ffd25284b4825e14f02e4bb90d0xf8569d0f4aa794ea4c9ca5efadda38433ad52bbbSeasonFacet
LibWellMinting0x7cbd0b120a1ee1cdac1ed245ee23a80b37c7a6f90xcfceea3eeaeccb8dcda9cbc37d72523c10855c62SeasonFacet
LibConvert0xb3626b534ff81442579913de1f31c51a045b52610x7665b799e4e05c2ddc4306826322e9d0729965f7ConvertBatchFacet, ConvertFacet, PipelineConvertFacet
LibPipelineConvert0xfc537aa415b89def06d97e23c04baf4039e8bbcb0x249be8f283471f2d4f08a4dae1108c632c650d6bConvertBatchFacet, ConvertFacet, PipelineConvertFacet
LibSilo0x9f327f1f6810aaf5a4ab0704b62b4ed6bb0ea3340x648a2ab1358bf9df357772e2fd5d4ceec824ecfaClaimFacet, ConvertBatchFacet, ConvertFacet, PipelineConvertFacet, SiloFacet
LibTokenSilo0xe97ee5afcb656126c6a89b72d8617061213f9f4d0xff684446076ebc98cb2998a219dac957eb66b0aeClaimFacet, LibConvert, SiloFacet

Function Changes

Event Changes

\ No newline at end of file diff --git a/public/pi/15/index.html b/public/pi/15/index.html new file mode 100644 index 000000000..d6fdf5d04 --- /dev/null +++ b/public/pi/15/index.html @@ -0,0 +1,797 @@ +PI-15: Beanstalk Repayments and Bug Fixes

PI-15: Beanstalk Repayments and Bug Fixes

Executed on March 6, 2026 at 16:58 UTC.

Summary

  1. Beanstalk Repayments: Add separate repayment routes for Beanstalk's Field, Silo and Barn obligations, with transferable positions, contract-account claims and accounting hooks for Pinto shipments and Internal Balance transfers.
  1. Convert Accounting and Penalties: Fix capacity double-counting and normalize the Grown Stalk penalty to simulated liquidity impact.
  1. Referral Eligibility: Preserve a former delegate's independently earned eligibility when referral delegation changes, and reject delegation to the zero address.
  1. Plot Management: Add bounded queries of Plot indexes and combine adjacent Plots to simplify position management.

Links

Background

Pinto committed at launch to start repaying Beanstalk’s obligations after supply exceeds 1 billion Pinto. The original writeup specifies Arbitrum block 276160746 for the holder snapshot, with Silo allocations based on fully recapitalized Unripe value, equivalent Field positions and Barn Fertilizer balances.

Problems

1. Beanstalk Repayments

The contracts and accounting needed to repay Beanstalk’s obligations had not yet been implemented.

2. Convert Accounting and Penalties

The per-block Convert capacity used to calculate Grown Stalk penalties tracks movement toward peg across all Wells and within each Well. Its accounting counted earlier Converts again with each new Convert in the same block, overstating capacity usage.

Grown Stalk penalties had two calculation problems. Overall movement toward or away from peg was measured from the spot reserve imbalance immediately before the Convert, making the result sensitive to preceding trades. The resulting penalty amount was then treated directly as Pinto Denominated Value (PDV) subject to Grown Stalk removal, rather than scaled to the Convert’s size and simulated effect on pool liquidity.

3. Referral Eligibility

Removing delegation from an account cleared the former delegate's eligibility, even when that account had independently Sown enough Pinto to qualify. The function also permitted delegation to the zero address.

4. Plot Management

The Field interface lacked bounded queries for positions in an account's Plot-index list and a way to combine adjacent Plots.

Solutions

1. Beanstalk Repayments

Add separate repayment positions for Beanstalk’s Field, Silo and Barn obligations, with transfers and claims on Base.

Under the normal allocation, 48.5% of newly minted Pinto goes to the regular Silo and 48.5% to the regular Field. The remaining 3% shifts from the budget to Beanstalk repayments as supply crosses 1 billion Pinto: initially 1% each to the repayment Field, Silo and Barn. Once the Barn is repaid, the repayment Field and Silo each receive 1.5%; once the Silo is repaid, the repayment Field receives 3%.

2. Convert Accounting and Penalties

Count each Convert’s use of the per-block, overall and per-Well capacity once, preserving the correct remaining capacity for later Converts in the same block. This capacity governs Grown Stalk penalties and is separate from Convert Up bonus capacity.

Make the overall penalty less sensitive to trades immediately before a Convert by measuring its effect against a reserve baseline that limits sudden changes. Individual Well checks still use spot reserves.

Scale Grown Stalk penalties to the proportion of a Convert that moves away from peg or exceeds remaining capacity. The penalty reflects the Convert’s size and expected liquidity impact, rather than treating the raw reserve imbalance as an amount of deposit value to penalize. At most 100% of the output PDV is subject to this penalty.

Apply these changes to ordinary and batch Pinto ↔ Well LP Converts and Pipeline Converts. Same-token Converts receive no penalty from this calculation. Existing Grown Stalk minimums, directional bonuses or penalties, and slippage protections still apply; invalid reserve or oracle data can prevent a Convert.

3. Referral Eligibility

When changing a delegate, clear the former delegate's eligibility only if their own recorded Sowing is below the eligibility threshold. Reject a zero-address delegate.

4. Plot Management

Add getters for Plot-index list length, a Plot's stored reverse index, selected array positions and half-open index ranges. Position queries preserve the requested order. Range queries require a nonempty range within the list bounds.

Add combinePlots for at least two positive caller-owned Plots supplied in ascending, exactly adjacent Pod Line order. Aggregate their Pods into the first Plot, remove later Plots from account indexing, and cancel listings for those later Plots. The first Plot's listing remains. Index removal uses swap-and-pop, so account-list order is not preserved.

Rationale

1. Beanstalk Repayments

Give Beanstalk holders a way to receive the repayments Pinto committed to at launch. Transferable positions let holders pass future repayment rights to someone else, while keeping track of Pinto already earned. Separate Field, Silo and Barn positions preserve the different claims holders had in Beanstalk. Repayment limits prevent paying more than is owed or using more newly minted Pinto than allocated.

2. Convert Accounting and Penalties

Later Converts should not face higher Grown Stalk penalties because earlier Converts were counted more than once. Correcting that accounting preserves the capacity actually available in each block.

Penalties should reflect how much a Convert moves Pinto away from peg or exceeds available capacity. Making the calculation less sensitive to preceding trades and scaling it to the Convert’s size makes the penalty better reflect that Convert’s effect.

3. Referral Eligibility

Delegation changes should preserve eligibility earned through an account’s own Sowing. Rejecting the zero address prevents assigning it referral eligibility.

4. Plot Management

Combining Plots simplifies management without moving their Pod Line position or creating Pods.

Contract Changes

At Base block 43,013,477, the cut added 14 selectors, replaced 197 and removed three. The source merged March 10, after execution. This inventory excludes standalone Blueprint deployments in that merge.

Initialization

Executed InitBeanstalkShipments through init(ShipmentRoute[],address). It replaced shipment routes, called addField, set Field 1's pods to 919768387056514 raw units (919,768,387.056514 Pods at six decimals), and registered the supplied SiloPayback's protocolUpdate(address,address,uint256) hook with encoding type 0x00. It assumes the newly added Field is Field 1. It does not explicitly reset harvestable or harvested, and account Plot population is separate.

Removed the three temporary population selectors. The populator-only initializeRepaymentPlots wrote quantities and index mappings in batches without guarding against repeated entries. Historical receipts confirm that 62 successful batches populated all 7,598 Plots exactly once, matching the population dataset. Two repeated attempts reverted.

Facet Changes

The previous implementations below are verified against historical routing at Base block 43,013,476, immediately before PI-15. All 197 replaced selectors match the listed addresses, all 14 added selectors were absent, and the three removed selectors pointed to TempRepaymentFieldFacet. PI-15 was the only Diamond upgrade in its execution block.

FacetActionPrevious ImplementationNew Implementation
SeasonFacetReplace0x4aeee50b11c3682605dceca1feacd96349383cd20x0dbb045a6cb0a2d8a7320c40f57bbaa1325eb509
SeasonGettersFacetReplace0x87e626e6187bc0df123cf6441ccc9f31a46f178e0x66fb2def6075067cd83ef17cd17e78389c2130fe
TokenHookFacetAddNot applicable: new selectors0x59479226df7b0f9aa0baf8c20a37c59d3dfdf590
ShipmentPlannerFacetAddNot applicable: new selectors0xf0e6e13c39d6dffcac002b722ce3b27460678b88
FieldFacetAdd / Replace0xae94197e16b31443fe1c333a32eda30eb3c1a9420xa0e75d184e4cbd9ee4bcff1e4241644a4f40520e
TokenFacetReplace0xd29e38e4a803feac3503fd7402181bba79d3d3f00x72c3b15c61c75231722f299b743d04b6e6cb1e5d
TractorFacetReplace0xc8706ff2a0da6b3367aa506dcbb608ccf96148de0x31e42c360092ac719a02b2b67b6ed8586c856824
MarketplaceFacetReplace0x85436279a52537ef03864e268d73d3ba37e169ec0xeb0433332dad2cf2bececa144602ccc4d15e474e
MarketplaceBatchFacetReplace0x40e42f3d568faf47c539a7d2a61e24629819bad40x5da1e415f6aad25bd27859de1b6001d0596b43c3
ClaimFacetReplace0xfc4499f812014bebaf9686ce0312a77cca65137a0xab86a40c4aeb2af5e739bfdb66f21fd4ca9e7098
SiloFacetReplace0x8646649c0f80db8665358f4548ae0d1ecc3910a50x051b60dad9c5a87355ffc5fb795c00e95c849a2a
GaugeFacetReplace0xf9f1d9c6ef1ca5ec0897c266d7b4e016e955d9160xe7ec22cb41db7935aea4b4d7a418c1a52d37239f
ConvertFacetReplace0xdc37f26363b305affc93c564ee879a265bcbff4d0x978ec1c303999e0a4eb4928dc3a4b39f0e9b7fa0
ConvertBatchFacetReplace0x923a7096f7338660e60b4dc0ae21d2413e3997390xbc27599d5345c082dd0bd258a8d92c416e2dd4e1
ConvertGettersFacetAdd / Replace0x334a110ad41fd417d4c8c3f82d9c85a3850192be0xfd29acd8b38c85ca6b88ed776b06ad059599dca4
PipelineConvertFacetReplace0xa66460626d1f8845085b1cdd5e527db1db998b1b0xdedf1678bee92b4759b8efd20e918df27a7ff21d
TempRepaymentFieldFacetRemove0x2b467c15188058ed1c91091dd53805a816c278f7Not applicable: removed selectors

ConvertGettersFacet adds the new penalty overload and replaces 15 other selectors. This cut leaves the prior penalty selector untouched.

Other Contract / Parameter Changes

Runtime link offsets verify these libraries, including indirect LibTokenSilo. PipelineConvertFacet uses the new libraries despite stale compiler settings. Previous dependencies belong to the previous facets verified against pre-PI-15 routing.

LibraryPrevious ImplementationNew ImplementationUsed By
LibEvaluate0x1105414b01a6d2214d1c33a1f756dea2e5e872590x6353f809bdb71c2c646f6336fa5b63deba466967SeasonFacet
LibShipping0xf528edef6598d1907eef6e7ad1a8b87e54c736a90xf6b8ff56917c18953e6a95c3bbcae51d64be6e83SeasonFacet
LibIncentive0x735aab105c222bee6aaf520adc4cf3128fdcc6db0xc00bdb284e2d0ddf528633554a7d82d5089918cbSeasonFacet
LibFlood0xef75cae236476bfedc5207d57e5ea7ea315a8c120xa6217c08de815e91ef8d3f1738d5a911beb7e7a2SeasonFacet
LibWeather0xf8569d0f4aa794ea4c9ca5efadda38433ad52bbb0x98f56c080a2c6214241f456d92e9fb3491be2bc7SeasonFacet
LibGerminate0x752f502897667c6ba438d35b39439c84210dad060xd91dc083a764f8d1ad391cbe055e110ef0a87247SeasonFacet
LibSeedGauge0xbcc581f0d70a033e21b31ea695fd3c29785031460x19c469e8516bdc38cb5f9957154a11f987796b03SeasonFacet
LibWellMinting0xcfceea3eeaeccb8dcda9cbc37d72523c10855c62 (SeasonFacet) / 0x7cbd0b120a1ee1cdac1ed245ee23a80b37c7a6f9 (SeasonGettersFacet)0xf4b01d96cdb6ef6fa80635e28b64ad6b1c8ede18SeasonFacet, SeasonGettersFacet
LibSilo0x648a2ab1358bf9df357772e2fd5d4ceec824ecfa0x273815fac17fb44679df4cb04b41a14d5e18db47ClaimFacet, ConvertBatchFacet, ConvertFacet, PipelineConvertFacet, SiloFacet
LibTokenSilo0xff684446076ebc98cb2998a219dac957eb66b0ae0x3622bc9e648d9569212a91cb3de0453923623f4dClaimFacet, LibConvert, SiloFacet
LibConvert0x7665b799e4e05c2ddc4306826322e9d0729965f70xa40fe465001f914b9b2508e6be695951e564bb6eConvertBatchFacet, ConvertFacet, PipelineConvertFacet
LibPipelineConvert0x249be8f283471f2d4f08a4dae1108c632c650d6b0xbc9e24ced57ffa5d46632c2ff0e50f14f29350bfConvertBatchFacet, ConvertFacet, PipelineConvertFacet

LibReceiving is internal to the shipping path, not a separate external link.

Repayment deployment sets. Constructor records verify initial implementations and administrators, not proxy storage or application ownership at execution.

Set and contractDeployed addressInitial implementationInitial proxy adminDeployment block
PR Silo0xBa0534B16017E861bA15f1587D8A060e15F7f3360xCebbDb437330a2f9049A4882918762Bc1A5fB5820xf71f4d69d8ad7eb6dcfb1c8ac36fdda3d057500d42043042
PR Barn0x724c87b9A6Ea6BA7A7CF3bfc0309DE778fB280270xd5a8E2FF523Cb3dB614A669c4044E908Ebaad0410xf71f4d69d8ad7eb6dcfb1c8ac36fdda3d057500d42043046
PR distributor0xB0e3DC9066C7aFC90065008e8d7a3c6Cb1F66B37Not applicable: direct deploymentNot applicable42043050
Executed-route Silo0x525C94754C51946a7a3B72580Ce0DF36922E1E640xDbb10C0cE795FFd3A4003CF0EcC849b25a788EB10xE5A707d49968937C860762fB256CE9dC7B1370F042062562
Executed-route Barn0x68bDbb0402a3Ca89C7C4af8e41C021635102d1580x5bb2b891496F9f4db1467755eDc240329EA08E2C0xE5A707d49968937C860762fB256CE9dC7B1370F042062570
Executed-route set distributor0xbA941Af3292c49b585f4EC5C8164c1dfc893EEdC0xED3Ead9D8b6E57f666E60ccf833f3ed1Be2Dd4c00xE5A707d49968937C860762fB256CE9dC7B1370F042062579

The reference lists L1ContractMessenger at 0xD2abd9a7E7F10e3bF4376fb03A07fca729A55b6f. Its deployed bytecode matches the source, with 50 fixed whitelisted callers. Its immutable Base destination, 0x1152691C30aAd82eB9baE7e32d662B19391e34Db, had no contract code at PI-15 execution and differs from the distributor above. This messenger therefore could not register a receiver in the PI-15 distributor as configured.

Function Changes

Event Changes

\ No newline at end of file diff --git a/public/pi/2/index.html b/public/pi/2/index.html new file mode 100644 index 000000000..ca7ace75e --- /dev/null +++ b/public/pi/2/index.html @@ -0,0 +1,797 @@ +PI-2: Remove Anti Lambda to Lambda Convert

PI-2: Remove Anti Lambda to Lambda Convert

Executed on November 27, 2024 at 21:11 UTC.

Summary

Remove the Anti Lambda to Lambda (AL2L) Convert functionality from the Silo to prevent users from removing each other's Rain Stalk.

Links

Background

Before this upgrade, AL2L Converts allowed any Farmer to Convert another Farmer's Deposit in order to decrease its Pinto-Denominated Value (PDV) if the current PDV of the Deposit (i.e., the PDV per token * the number of tokens) is less than the recorded PDV (i.e., the PDV stored onchain, which is used by the protocol to determine how many Stalk and Seeds to award the Deposit).

The ability to decrease a Deposit's PDV is necessary because as the value in liquidity pools changes due to changes in the price of the non-Pinto asset in the liquidity pool and/or the ratio of the assets in the liquidity pool changes, it is possible for the PDV of the Deposit to decrease substantially. By enabling anyone to decrease the PDV associated with a Deposit that is recorded by the protocol, the instances where the protocol is awarding excess Stalk and Seeds to a Deposit beyond the current value the Deposit is contributing to the protocol can be drastically reduced without requiring the protocol to regularly check the PDV of each Deposit, which would be expensive. Of course, there is no incentive for a Farmer to decrease their own PDV. Thus, the AL2L Convert is callable by any user on eligible Deposits that had completed Germination.

Problem

AL2L Converts had a bug in their implementation that would result in a loss of the Rain Stalk associated with the Deposit while it's Raining and/or Flooding. Rain Stalk is the snapshot of Stalk holdings taken each time it begins to Rain, which determines pro rata ownership of the proceeds from the Flood sale. While an AL2L Convert should decrease the Rain Stalk associated with a Deposit in the instance where its PDV is decreased, the AL2L Convert erroneously removed Rain Stalk during withdrawal without restoring the Farmer's Rain Stalk snapshot when the Deposit was recreated.

Solution

Remove AL2L Converts until a fix can be implemented to allow Farmers to retain the appropriate number of Rain Stalk during Converts.

Rationale

Temporarily removing AL2L Converts prevents another Farmer from triggering the erroneous Rain Stalk removal while a fix is developed. The tradeoff is that AL2L Converts cannot reduce overstated Deposit PDV during this period.

Contract Changes

Initialization

No initializer was called. The Diamond Cut used the zero address for its initializer and empty initialization calldata.

Facet Changes

FacetActionPrevious ImplementationNew Implementation
ConvertFacetReplace0x379D2d7FF9907F127f1226a9024BCF07896197340xF07C34E81D56fF02c01869bf1F833C07BB52BF2b
ConvertGettersFacetReplace0xfE55E1e7f3FdAef6b1E6E3d6D53f84a3741518170x518F109e57c872F8aceC3b3e9a6Ce5f5e8E80097

Other Contract / Parameter Changes

No protocol parameters changed. The replacement ConvertFacet links to the following libraries (previous → new addresses):

LibraryPrevious ImplementationNew ImplementationUsed By
LibConvert0x3dedd64cfbf6db642cf6a22ce747fdfb9f17b5700x67e19ab71b645b8b42062b2a5c8e49ef900fee9eConvertFacet
LibPipelineConvert0x4917dcbafc47b57b9ec004424a44ccdc5834d0540x2fc411d1ed590416ec2bc398f624bf462b60ff49ConvertFacet
LibSilo0x351ca256f86c10b01f2640f22ca379cf1e74d8e20x453c79a1c29d81b67b3be4e2b8810674f63606d8ConvertFacet
LibTokenSilo0xbbe1d3e7bb0b50d1999f631674efd5446881612a0x1915dcd16475dd25e2f5588888421cf80fc8d116ConvertFacet

Function Changes

\ No newline at end of file diff --git a/public/pi/3/index.html b/public/pi/3/index.html new file mode 100644 index 000000000..346db7ea5 --- /dev/null +++ b/public/pi/3/index.html @@ -0,0 +1,798 @@ +PI-3: Bug Fixes and Parameter Changes

PI-3: Bug Fixes and Parameter Changes

Executed on December 5, 2024 at 02:52 UTC.

Summary

  1. Rain Stalk Preservation: Update the Silo such that Deposits do not lose Rain Stalk upon transfer or Convert into non-Germinating Deposits.
  1. AL2L Converts: Re-add Anti Lambda to Lambda (AL2L) Converts.
  1. gm Reward: Update the gm reward to properly issue Pinto when the gm function is called 239 to 240 seconds late.
  1. Flood Pods: Update Soil issuance above peg to properly account for Pods that became Harvestable due to a Flood.
  1. Soil Issuance Above Peg: Change the Soil issuance above peg multiplier on Pods that became Harvestable from 1.5x to 1.2x when the Pod Rate is Excessively Low. Stop halving above-peg Soil issuance when the Pod Rate is Reasonably High and Pinto’s price is above the excessive-price threshold. Retain the 0.5x multiplier for Excessively High Pod Rates.
  1. Morning Auction Duration: Extend the duration of the Morning from 5 to 10 minutes.
  1. Minimum Temperature: Change the minimum Temperature at the beginning of the Morning from a fixed 1% to 1% of the Maximum Temperature.
  1. Maximum Temperature Increases: Reduce the Maximum Temperature increase from 3 percentage points to 2 percentage points wherever it currently increases by 3 percentage points.
  1. Excessively Low Pod Rate Threshold: Lower the Excessively Low Pod Rate threshold from 5% to 3%.

Links

Problems

1. Rain Stalk Preservation

Rain Stalk is the snapshot of Stalk holdings taken each time it begins to Rain, which determines pro rata ownership of the proceeds from the Flood sale. Rain Stalk was erroneously burned upon the transfer or Convert of a Deposit.

2. AL2L Converts

AL2L Converts were disabled in PI-2 due to a bug where all Rain Stalk was erroneously removed as a result of an AL2L Convert while it was Raining.

3. gm Reward

The gm reward was 0 Pinto when the gm function was called 239 to 240 seconds after it could have been called.

4. Flood Pods

Soil issuance above peg is intended to be a function of the number of Pods that became Harvestable at the beginning of the Season. Pods that became Harvestable due to a Flood were erroneously omitted from this calculation.

5. Soil Issuance Above Peg

Soil issuance above peg was too aggressive when the Pod Rate was Excessively Low. The 0.5x multiplier intended for Excessively High Pod Rates also applied when the Pod Rate was Reasonably High and Pinto’s price was above the excessive-price threshold. This incorrectly halved Soil issuance in those cases.

6. Morning Auction Duration

The previous 5 minute duration of the Morning did not give sufficient time to participants in the Morning Auction who are submitting transactions manually to participate.

7. Minimum Temperature

The minimum Temperature of 1% at the beginning of the Morning resulted in paying more interest than necessary at lower Maximum Temperatures.

8. Maximum Temperature Increases

The Maximum Temperature increased too quickly below peg, which disincentivized lending to the protocol in an efficient fashion and resulted in the protocol overpaying for loans.

9. Excessively Low Pod Rate Threshold

The Excessively Low Pod Rate threshold was too high.

Solutions

1. Rain Stalk Preservation

2. AL2L Converts

Re-add ANTI_LAMBDA_LAMBDA as a valid Convert type with a fix to the bug that removed all of the Rain Stalk during an AL2L Convert instead of reducing it by the appropriate number.

3. gm Reward

Update LibIncentive.fracExp to properly return the scaled reward when the gm function is 239 to 240 seconds late.

4. Flood Pods

5. Soil Issuance Above Peg

Update soilCoefficientLow in the evaluationParameters struct from 1.5e18 to 1.2e18 (i.e., 1.5x -> 1.2x). Update Sun.setSoilAbovePeg to apply the 0.5x Soil multiplier only when the Pod Rate is Excessively High. When the Pod Rate is Reasonably High and Pinto’s price is above the excessive-price threshold, issue the unadjusted Soil quantity instead of halving it.

6. Morning Auction Duration

Update delta in LibDibbler.morningTemperature such that each interval during the Morning lasts 24 seconds (12 blocks) instead of 12 seconds (6 blocks), extending the length of the Morning from 5 minutes to 10 minutes.

7. Minimum Temperature

8. Maximum Temperature Increases

9. Excessively Low Pod Rate Threshold

Update podRateLowerBound in the evaluationParameters struct from 0.05e18 (5%) to 0.03e18 (3%).

Rationale

1. Rain Stalk Preservation

Preserving Rain Roots through Deposit transfers and Converts into non-Germinating Deposits preserves ownership of Flood proceeds while allowing those operations.

2. AL2L Converts

Restoring AL2L Converts with the Rain Stalk fix restores their functionality without removing all of a user’s Rain Stalk.

3. gm Reward

Correcting the reward calculation preserves the intended incentive to call gm throughout the 239-to-240-second interval.

4. Flood Pods

Including Pods made Harvestable by a Flood keeps above-peg Soil issuance consistent with the total number of Pods made Harvestable.

5. Soil Issuance Above Peg

There is no need for the protocol to so aggressively try to increase the Pod Rate when the protocol has an excessively low Pod Rate. Removing the unintended 0.5x multiplier approximately doubles Soil issuance in the affected Reasonably High Pod Rate cases, restoring the quantity calculated from newly Harvestable Pods and the Maximum Temperature. The 0.5x reduction remains in place when the Pod Rate is Excessively High, when the protocol more strongly limits new debt.

6. Morning Auction Duration

By doubling the duration of the Morning Auction – and each interval of the auction – farmers will have more opportunity to participate manually, which should generally result in the protocol having to pay lower interest rates. A longer Morning Auction has minimal downside because the protocol will still offer Soil at the Maximum Temperature for 50 minutes during each Season, which leaves ample time for farmers to participate once the Morning Auction ends.

7. Minimum Temperature

The hard set minimum of 1% Temperature during the Morning Auction reduced the effectiveness of the auction during periods where the Maximum Temperature was very low. In instances where the protocol has little to no outstanding debt, it is highly plausible that some farmers would be willing to lend to the protocol at less than 1%. This minimum made it such that even if farmers were willing to do so, they would be unable to, resulting in the protocol potentially overpaying to issue debt.

8. Maximum Temperature Increases

The protocol raised the Maximum Temperature too quickly. By changing the Maximum Temperature increases from 3 percentage points to 2 percentage points it should decrease the rate the protocol needs to pay to attract creditors without decreasing its ability to do so.

The protocol was experiencing a nearly constantly increasing Maximum Temperature, which poses a short term threat to the protocol because it creates an incentive for potential creditors to wait for a higher interest rate, and a long term threat because if the Maximum Temperature increases in perpetuity, the protocol may eventually collapse under the weight of excessive outstanding debt.

By lowering the rate at which the Maximum Temperature increases, it should create a more efficient market for Soil in the short term and give contributors more time to design a better mechanism to prevent runaway Maximum Temperature in the long run.

9. Excessively Low Pod Rate Threshold

The Excessively Low Pod Rate threshold indicates the rate below which the protocol strongly prefers to take on more debt. It is likely safer for the protocol to be slightly more conservative and set this threshold to be 3% instead of 5%.

Contract Changes

Initialization

Executed InitPI3.init() at 0xa35c864c9154ef9fccdc037c489ee8bc30631477. It updated podRateLowerBound from 0.05e18 (5%) to 0.03e18 (3%), soilCoefficientLow from 1.5e18 (1.5x) to 1.2e18 (1.2x), and s.sys.casesV2 with the revised Temperature adjustments. If lastSopSeason equaled the current Season, it added totalSupply / 1000 to Soil.

Facet Changes

ApprovalFacet, ConvertGettersFacet, ClaimFacet, SiloFacet, SiloGettersFacet and SeasonGettersFacet were replaced without changes to their facet source files. Shared-library changes are described below.

FacetActionPrevious ImplementationNew Implementation
ConvertFacetReplace0xf07c34e81d56ff02c01869bf1f833c07bb52bf2b0x7bab1d09727be8f0427c6dd1d503b3d4ba697d93
PipelineConvertFacetReplace0x9d108e7f673c773ac196bde4bebc6758088d2e590x508320dcc2b4e9f79555bcae1478e6ce736b22ab
FieldFacetAddN/A0x0ab2b647fdfaa3abffca2a10fe78eb0ded438faf
FieldFacetReplace0x6430f859a3b8825d25382ebc7941fcd7196357970x0ab2b647fdfaa3abffca2a10fe78eb0ded438faf
SeasonFacetReplace0x269c8386be50c176f03355c7c7925356fdef9f840x6ea855d9473168f4540d4818976ea814ecbf3456
ApprovalFacetReplace0x540e776e8f0eac5dfa82110b827cb6cea67056690xa7df4372b0404cd468703451950e2af8615996b2
ConvertGettersFacetReplace0x518f109e57c872f8acec3b3e9a6ce5f5e8e800970xb70708268fff1b6038def6f7d29a3bee037e901c
ClaimFacetReplace0xea0aad388e2df06f90a218ca2eda199294fbaadb0x28bcfb5ad84dd460f2fd080dfd706105b8fc21c6
SiloFacetReplace0x3235540bb01ef11e4208a9b99c2f2dd9860e721a0xd2d3d44edbbc66ef90b29627dfd0a06d3ca0cad4
SiloGettersFacetReplace0x039ec53bb37f8fe240798e3591d9439c68e72b7b0x6abfe707418d80a6e06b77853ed6c098b8af6711
SeasonGettersFacetReplace0x8b1ba2ea90916eca3d5b0ba428a8c5909768492a0xd0813e2378a73b7cb49bd4ff6a4bf67edcea1264

Other Contract / Parameter Changes

Externally Linked Libraries

The table lists the external library deployments linked by the replaced facets. Where previous deployments differed by facet, the previous address is labeled with its consuming facets.

FieldFacet, ApprovalFacet, ConvertGettersFacet and SiloGettersFacet had no externally linked libraries in either implementation.

LibPipelineConvert, LibTokenSilo, LibEvaluate, LibGauge, LibShipping, LibWellMinting and LibGerminate were redeployed with unchanged library source files. Their new addresses do not indicate additional source changes beyond those described below.

LibraryPrevious ImplementationNew ImplementationUsed By
LibConvert0x67e19ab71b645b8b42062b2a5c8e49ef900fee9e0xcce6631b13ee44ad9d8146241b20f10c1a803aa2ConvertFacet
LibPipelineConvert0x2fc411d1ed590416ec2bc398f624bf462b60ff49 (ConvertFacet); 0x4917dcbafc47b57b9ec004424a44ccdc5834d054 (PipelineConvertFacet)0xb387ad744cc1a80ab629eea5ca15459076719a7aConvertFacet, PipelineConvertFacet
LibSilo0x453c79a1c29d81b67b3be4e2b8810674f63606d8 (ConvertFacet); 0x351ca256f86c10b01f2640f22ca379cf1e74d8e2 (PipelineConvertFacet, ClaimFacet, SiloFacet)0x5a686e6024d1d40994ae99979ceb63bf67724b04ConvertFacet, PipelineConvertFacet, ClaimFacet, SiloFacet
LibTokenSilo0x1915dcd16475dd25e2f5588888421cf80fc8d116 (ConvertFacet); 0xbbe1d3e7bb0b50d1999f631674efd5446881612a (PipelineConvertFacet, ClaimFacet, SiloFacet)0x0da233676f46427c31928f5f85678d6737f4ec7eConvertFacet, PipelineConvertFacet, ClaimFacet, SiloFacet
LibEvaluate0x7f1770fa1b43abdbe8095295ecae37c00d4ba7f80x7a7d5a8899f9d68530ef3c551b9cb5610bc9bd02SeasonFacet
LibGauge0xcd376159cfa7ff6c60a3b6d55e2ce75cec5156690x6c2736cfc57c1328b7d3db611812297c9754e230SeasonFacet
LibIncentive0x86da3aba20454a441eceae9d5b960564abd0cba10xeb9bd84e354e68142e8e996823887edb4dfcf433SeasonFacet
LibShipping0x2b6a87195446b28c404cd5d78351998a1e8b31f90x64d40771f9f6490afe20c135dc07ea48b8addc78SeasonFacet
LibWellMinting0x78e2a41721b97f33e13a383d15726b1ac96c2a19 (SeasonFacet); 0x4910f9a342c79ea50a4395477cfdb11f36a010ad (SeasonGettersFacet)0x7124f182847880f4961de89068b249c3299304afSeasonFacet, SeasonGettersFacet
LibFlood0xd668ecc7df030202ee50f9c465db7f7da7581a480xed513e167369af0119090d67b8910c02b2b468f6SeasonFacet
LibGerminate0x06cc9fb93b3cefa5dc6bb5f418c7358cd3ea0a850x384374407a64aa24d3335ff12c870debaa04c3e5SeasonFacet

Function Changes

Event Changes

Existing event signatures were unchanged. The revised calculations changed the following emitted values.

+

\ No newline at end of file diff --git a/public/pi/4/index.html b/public/pi/4/index.html new file mode 100644 index 000000000..82828b637 --- /dev/null +++ b/public/pi/4/index.html @@ -0,0 +1,797 @@ +PI-4: Demand for Soil Adjustments

PI-4: Demand for Soil Adjustments

Executed on December 8, 2024 at 06:46 UTC.

Summary

  1. 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.
  1. 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

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

2. Steady Demand Range

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.

FacetActionPrevious ImplementationNew Implementation
SeasonFacetReplace0x6Ea855d9473168f4540D4818976Ea814ECBf34560x15cBDFaF5715F2a1B6e23b3ef7c4D67843a6C836
GaugeGettersFacetReplace0xD26a44C9F7C58864c2ea938BE9E2f0Ae25954bc20x34eaa05624E0B8cFAB251571E429fD88Cec7ec12
SeasonGettersFacetReplace0xD0813e2378A73B7cB49Bd4ff6a4Bf67EdcEa12640x995E1cA9Bd858bff94448dCC0E097bd4d564e74B

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

LibraryPrevious ImplementationNew ImplementationUsed By
LibEvaluate0x7a7d5a8899f9d68530ef3c551b9cb5610bc9bd020x595eb8aa763325235f988eedc582d74046fd7bcaSeasonFacet
LibGauge0x6c2736cfc57c1328b7d3db611812297c9754e2300xe7e55a27a369bef6d20dd081ff7ddff90d6f7482SeasonFacet
LibIncentive0xeb9bd84e354e68142e8e996823887edb4dfcf4330xfe1fe5508b33401c20e45fcd10161783de443479SeasonFacet
LibShipping0x64d40771f9f6490afe20c135dc07ea48b8addc780x86c9bdf4b2a7ab22c90048f0d741b81c546895b7SeasonFacet
LibWellMinting0x7124f182847880f4961de89068b249c3299304af0x4e81e73a1ca24ff99a79914a887d13b9c641e2f2SeasonFacet, SeasonGettersFacet
LibFlood0xed513e167369af0119090d67b8910c02b2b468f60x249ae0deb8f7ebccaa574c7396c7d099d87e7e3dSeasonFacet
LibGerminate0x384374407a64aa24d3335ff12c870debaa04c3e50x7c748262b168e85a5e0973021e44b163fcb578d9SeasonFacet

Function Changes

Event Changes

\ No newline at end of file diff --git a/public/pi/5/index.html b/public/pi/5/index.html new file mode 100644 index 000000000..a2a8b8d2e --- /dev/null +++ b/public/pi/5/index.html @@ -0,0 +1,807 @@ +PI-5: Soil Issuance and Parameter Changes

PI-5: Soil Issuance and Parameter Changes

Executed on January 2, 2025 at 06:11 UTC.

Summary

  1. Maximum Temperature Decimals: Upgrade the Maximum Temperature from 0 to 6 decimal precision.
  1. Soil Issuance Below Peg Changes: Scale Soil issuance when time-weighted average ΔP (TWAΔP) <= 0 and instantaneous ΔP (INSTΔP) <= 0 by (1 - min(L2SR, 0.99)) and set a minimum Soil issued to 1% of min(|TWAΔP|, |INSTΔP|), before rounding. ΔP measures a Pinto supply imbalance, while P denotes price.
  1. Soil Issuance Above Peg Changes: Change the scalar on Pods that became Harvestable at the beginning of the Season for Soil issuance above peg:
    • from 0.5 to 0.25 when the Pod Rate is Excessively High.
    • from 1 to 0.5 when the Pod Rate is Reasonably High.
    • from 1 to 1.2 when the Pod Rate is Excessively Low, price is Excessively High, and Soil demand is increasing.
  1. Soil Issuance Fix When INSTΔP > 0 and TWAΔP < 0: Change Soil issuance when the inter-block MEV manipulation resistant instantaneous ΔP (INSTΔP) > 0 and TWAΔP < 0 to be 1% of |TWAΔP| scaled by:
    • 0.25 when the Pod Rate is Excessively High.
    • 0.5 when the Pod Rate is Reasonably High.
    • 1 when the Pod Rate is Reasonably Low.
    • 1.2 when the Pod Rate is Excessively Low.
  1. Case Adjustment Changes: Lower the Maximum Temperature adjustments in several instances when TWAΔP <= 0 (detailed below).
  1. Intended Crop Scalar Adjustment: PI-5 intended to increase certain Crop Scalar decreases from 1 to 2 percentage points per Season, but an encoding error left them unchanged. PI-6 implemented the correction.
  1. New Events: Introduce new events SeasonMetrics and RainStatus, and add beans to SeasonOfPlentyWell.

Links

Problems

1. Maximum Temperature Decimals

Maximum Temperature adjustments were limited to 100-basis-point changes, which reduced the granularity available to adjust the Maximum Temperature in each case.

2. Soil Issuance Below Peg Changes

Pinto did not factor the L2SR into its Soil issuance.

3. Soil Issuance Above Peg Changes

The protocol is willing to issue Pods every Season in order to measure changing demand for Soil, including when TWAΔP > 0, but the protocol did so at higher coefficients than this adjustment targets.

4. Soil Issuance Fix When INSTΔP > 0 and TWAΔP < 0

When issuing Soil below peg, the protocol compared INSTΔP and TWAΔP and issued the minimum of the absolute values of the two in order to minimize debt issuance. However, when INSTΔP > 0 and TWAΔP < 0, the protocol issued |TWAΔP| Soil which led to excessive debt issuance in instances where there was a large |TWAΔP| but the protocol was over its value target at the time of the gm call.

5. Case Adjustment Changes

The Maximum Temperature was likely increasing more aggressively than necessary in certain instances when TWAΔP <= 0, particularly when the Pod Rate is above its optimal level or when the Pod Rate is Reasonably Low and there is increasing demand for Soil.

6. Intended Crop Scalar Adjustment

The selected cases decreased the Crop Scalar by one percentage point per Season. PI-5 intended a two-percentage-point decrease, but its constant encoding did not implement it.

7. New Events

There was no straightforward off-chain method to get certain Flood and Season data.

Solutions

1. Maximum Temperature Decimals

2. Soil Issuance Below Peg Changes

3. Soil Issuance Above Peg Changes

4. Soil Issuance Fix When INSTΔP > 0 and TWAΔP < 0

5. Case Adjustment Changes

Update s.sys.casesV2 with the new Maximum Temperature adjustments bolded on the right. Across all L2SR tiers with TWAΔP <= 0, change +1 to 0 percentage points for Reasonably Low Pod Rate with increasing Soil demand. For Reasonably or Excessively High Pod Rate, change +2, +1, and 0 to +1, +0.5, and −0.5 percentage points for decreasing, steady, and increasing Soil demand, respectively.

PI-5 as executed. The intended Crop Scalar decrease from −0.01 to −0.02 was implemented in PI-6.

6. Intended Crop Scalar Adjustment

The intended two-percentage-point decrease applied to Reasonably Low L2SR, Reasonably High price, and Reasonably or Excessively High Pod Rate. PI-5 installed constants that still encoded a one-percentage-point decrease. PI-6 corrected the encoding.

7. New Events

event SeasonMetrics(
+    uint256 indexed season,
+    uint256 deltaPodDemand,
+    uint256 lpToSupplyRatio,
+    uint256 podRate,
+    uint256 thisSowTime,
+    uint256 lastSowTime
+);
+
+event RainStatus(uint256 indexed season, bool raining);
+

Rationale

1. Maximum Temperature Decimals

Changing the Maximum Temperature by a minimum of 100 basis points does not allow the protocol to respond with a sufficiently high level of granularity. By changing the minimum change to .0001 basis points (or 0.000001%), the protocol will be well equipped to change the Maximum Temperature as it grows in complexity well into the future.

2. Soil Issuance Below Peg Changes

The protocol does not need to issue enough Soil to return the price to peg if all of it were Sown. Issuing less Soil each Season gives the market more time to respond in ways other than issuing debt (e.g., via Converts, new Deposits, etc).

When the L2SR is high and P < 1, the protocol should rely more heavily on Converts from LP tokens to Pinto to increase the price rather than issuing more debt. Scaling Soil when P < 1 by 1 - L2SR reflects this. At higher L2SR, the protocol marginally prefers sacrificing liquidity through LP → Pinto Converts than to issue additional debt. See the Beanstalk State Space for the underlying liquidity/debt framework.

A minimum of 1% of min(|TWAΔP|, |INSTΔP|) when INSTΔP <= 0 caps the effect of the (1 - L2SR) scalar at 99%, before integer rounding. Soil can still be zero when the input is zero or rounding removes the remaining amount.

3. Soil Issuance Above Peg Changes

When TWAΔP > 0, the protocol issues debt in order to measure changing demand for Soil and to avoid entering a situation where the protocol has no outstanding debt. This Soil issuance is based on the number of Pods that became Harvestable at the beginning of the Season.

However, the protocol is aiming to reduce replacement debt with respect to the amount of Soil that it issues relative to the number of Pods that became Harvestable. This solution allows for greater granularity with respect to the ratio of how much Soil is issued relative to how many Pods became Harvestable, and lowers the ratio in two Pod Rate categories to reduce replacement debt. Applying 1.2 to the previously excluded case makes all Excessively Low Pod Rate cases use the same coefficient.

4. Soil Issuance Fix When INSTΔP > 0 and TWAΔP < 0

Issuing |TWAΔP| Soil when INSTΔP > 0 and TWAΔP < 0 does not achieve the goal of minimizing Soil issuance when INSTΔP > 0. Instead, when INSTΔP > 0, the protocol should take a similar approach to how it issues Soil when TWAΔP > 0, (i.e., issue enough Soil to measure changing demand).

However, because in this scenario no Pods became Harvestable at the beginning of the Season, the Soil issuance mechanic when TWAΔP > 0 cannot be used. By instead issuing 1% of | TWAΔP | scaled according to the same coefficients based on the Pod Rate when TWAΔP > 0, the protocol is able to issue enough Soil to measure demand while factoring in the Pod Rate and limiting additional debt issuance.

5. Case Adjustment Changes

If the protocol increases the Maximum Temperature too quickly, it can disincentivize prospective lenders to lend to the protocol by creating a greater potential benefit for them to lend to the protocol later on. By leveraging the new Maximum Temperature decimal precision to increase the Maximum Temperature more conservatively, the protocol can minimize the incentive to wait to lend to the protocol and decrease the overall rate at which the Maximum Temperature increases which will likely enable the protocol to more sustainably issue debt over time.

6. Intended Crop Scalar Adjustment

The intended faster decrease would favor LP over Pinto exposure in the selected cases. PI-5 did not realize that adjustment because its encoded constants were unchanged. The correction belongs to PI-6.

7. New Events

The added metrics and Rain transitions allow off-chain consumers to reconstruct Season state, while the added beans field records the number of Pinto minted to each Well during a Flood.

Contract Changes

Initialization

InitPI5.init() at 0x78a9b261e59dd31d2f50230103d07e3e65bbe02b initialized the Soil scalars and Pod Rate coefficients, installed the V2 case table, and multiplied the stored Maximum Temperature by 1e6 to preserve its value at six-decimal precision.

Facet Changes

FacetActionPrevious ImplementationNew Implementation
SeasonFacetReplace0x15cBDFaF5715F2a1B6e23b3ef7c4D67843a6C8360xFC52fC3C8a29F74603006fF03915770014D9F049
FieldFacetReplace0x0Ab2b647Fdfaa3Abffca2a10fe78Eb0dED438fAf0x8906b9131B7c6354f3e14b8656B546CfCfc9eDF1
GaugeGettersFacetReplace0x34eaa05624E0B8cFAB251571E429fD88Cec7ec120x04912D77F69Bd03f8846A432B0AbacfC028bea33
SeasonGettersFacetReplace0x995E1cA9Bd858bff94448dCC0E097bd4d564e74B0xFA0093b9CA5D00c9E6623767eb09489d90aBF150
SeasonGettersFacetAddNot applicable — new selectors0xFA0093b9CA5D00c9E6623767eb09489d90aBF150
ConvertGettersFacetReplace0xb70708268fff1b6038dEf6F7d29a3bEe037e901c0x115E83Bcb217A06D13210009e7CD8b44cE1af509
SiloGettersFacetReplace0x6aBFE707418D80a6E06b77853ED6c098B8aF67110x6C1dc649E93be43FfF670a2407Fa4Edc4996BB95

Other Contract / Parameter Changes

Maximum Temperature storage and case adjustments moved from whole percentage points to six decimal places. The initializer rescaled existing Temperature without changing its economic value.

Initialized belowPegSoilL2SRScalar to 1e6 (1) and abovePegDeltaBSoilScalar to 0.01e6 (1%). Above-target Soil coefficients changed from 0.5 to 0.25 for Excessively High Pod Rate and from 1 to 0.5 for Reasonably High Pod Rate. Reasonably Low remained 1 and the configured Excessively Low coefficient remained 1.2, as set by PI-3.

External Library Deployments

All seven linked libraries were redeployed. LibEvaluate, LibWellMinting, and LibFlood changed their own source files. LibGauge, LibIncentive, LibShipping, and LibGerminate did not. FieldFacet, GaugeGettersFacet, ConvertGettersFacet, and SiloGettersFacet have no externally linked libraries. GaugeGettersFacet, ConvertGettersFacet, and SiloGettersFacet retained their own source files and getter interfaces despite their replacement.

LibraryPrevious ImplementationNew ImplementationUsed By
LibEvaluate0x595eb8aa763325235f988eedc582d74046fd7bca0x69c7d1feb4b963ff9b8338a765c13bb5c3b19792SeasonFacet
LibGauge0xe7e55a27a369bef6d20dd081ff7ddff90d6f74820x07b75f35e90eb114035d3c67ac7738f11fb70a26SeasonFacet
LibIncentive0xfe1fe5508b33401c20e45fcd10161783de4434790x4e5dae995c2e8eef23b44a95034064262326e703SeasonFacet
LibShipping0x86c9bdf4b2a7ab22c90048f0d741b81c546895b70x6ccdfc6fd7885a07e5d4ee5e998a66afe6a65705SeasonFacet
LibWellMinting0x4e81e73a1ca24ff99a79914a887d13b9c641e2f20xd972df7cfd286778951aa829a40e9ab7f7db1d5aSeasonFacet, SeasonGettersFacet
LibFlood0x249ae0deb8f7ebccaa574c7396c7d099d87e7e3d0x0b316cb760a677ed1c581041c7d2118bc66aa87cSeasonFacet
LibGerminate0x7c748262b168e85a5e0973021e44b163fcb578d90x636234f909174c764d216ef9bd22175f01a107b2SeasonFacet

Function Changes

Event Changes

\ No newline at end of file diff --git a/public/pi/5/pi5-cases-highlighted.png b/public/pi/5/pi5-cases-highlighted.png new file mode 100644 index 000000000..1d6a8776e Binary files /dev/null and b/public/pi/5/pi5-cases-highlighted.png differ diff --git a/public/pi/6/index.html b/public/pi/6/index.html new file mode 100644 index 000000000..b309f6b06 --- /dev/null +++ b/public/pi/6/index.html @@ -0,0 +1,825 @@ +PI-6: Introduce Cultivation System and Crop Ratio Changes

PI-6: Introduce Cultivation System and Crop Ratio Changes

Executed on March 12, 2025 at 22:23 UTC.

Summary

  1. Cultivation System: Introduce the Cultivation System to dynamically issue Soil in line with demand for it.
  1. Minimum Soil Issuance: Create a parameter for the minimum number of Soil that can be issued when the time-weighted average and instantaneous Pinto supply deltas are nonpositive and their minimum absolute value is nonzero and set it to 50 Soil. Each delta measures the Pinto shortage or surplus relative to the $1 peg, using time-weighted average or instantaneous pool reserves. A negative value indicates a surplus.
  1. Generalized Gauge System: Create a generalized gauge system such that any future state variable can be updated via a gauge upon the gm call with minimal development effort.
  1. Maximum Crop Ratio Increase: Increase the Maximum Crop Ratio from 100% to 150%.
  1. Crop Scalar Adjustments: Properly increase the magnitude of the Crop Scalar decreases from 1 to 2 percentage points per Season when price is Reasonably High, the Pod Rate is Reasonably or Excessively High and the L2SR is Reasonably Low as intended in PI-5 (detailed below).

Links

Problems

1. Cultivation System

When the protocol issues significant numbers of Soil that are not Sown into, it signals to the market that the protocol is not creditworthy. When the protocol issues less Soil than there is demand for, it is not borrowing efficiently. The protocol lacked a method to discover the optimal number of Soil to issue.

2. Minimum Soil Issuance

At particularly low numbers of Soil, demand for Soil cannot be accurately measured. With the introduction of the Cultivation System, which starts the number of Soil available at a very low number and then ramps it up to meet demand, the protocol may issue too little Soil to accurately measure demand.

3. Generalized Gauge System

There are potentially several state variables that could be adjusted at the beginning of each Season, but without a generalized mechanism to do so each variable required a bespoke implementation.

4. Maximum Crop Ratio Increase

The Maximum Crop Ratio of 100% limited the ability of the protocol to create a sufficiently strong incentive to counter the preference demonstrated by the market to hold Deposited LP over Deposited Pinto when it is trying to incentivize LP -> Pinto Converts.

5. Crop Scalar Adjustments

When price is Reasonably High, the Pod Rate is Reasonably or Excessively High and the L2SR is Reasonably Low, the Crop Scalar did not decrease quickly enough. PI-5 intended to increase the magnitude of the Crop Scalar adjustments in these instances, but an encoding error left the decreases at 1 percentage point per Season instead of the intended 2.

Solutions

1. Cultivation System

Introduce the Cultivation System, which uses a gauge to adjust the Cultivation Factor, which acts as a scalar on Soil issuance relative to the maximum number of Soil the protocol would be willing to issue if there was infinite demand for Soil.

The Cultivation Factor is updated as follows:

Where:

The adjustment coefficient decreases linearly from 2% to 0.5% as the Pod Rate rises from 3% to 25%, and is clamped outside those bounds. Rᴰ denotes the Pod Rate. Its lower and upper bounds are 3% and 25%, respectively.

2. Minimum Soil Issuance

The Cultivation System includes a 50-Soil floor when the time-weighted average and instantaneous Pinto supply deltas are nonpositive and their minimum absolute value is nonzero to prevent instances where the protocol issues too little Soil to be able to accurately measure demand.

Therefore, we define the Soil issued when the time-weighted average and instantaneous Pinto supply deltas are nonpositive to be:

+

Where:

3. Generalized Gauge System

Add the following to AppStorage:

struct GaugeData {
+    GaugeId[] gaugeIds;
+    mapping(GaugeId => Gauge) gauges;
+}
+
+enum GaugeId {
+    CULTIVATION_FACTOR
+}
+

Introduce a Gauge Implementation as:

struct Gauge {
+    bytes value;
+    address target;
+    bytes4 selector;
+    bytes data;
+}
+

A gauge selector must adhere to the following function definition:

foo(
+    bytes memory value,
+    bytes memory systemData,
+    bytes memory gaugeData
+) external view returns
+(
+    bytes memory,
+    bytes memory
+)
+

The function must return the updated encoded value first and encoded gauge data second.

Gauges have a GaugeId that is set upon adding a new Gauge. Gauges are called during the gm call, upon which each Gauge’s returned value and/or data are stored.

The following new events are associated with the generalized gauge system:

    event Engaged(GaugeId gaugeId, bytes value);
+    event AddedGauge(GaugeId gaugeId, Gauge gauge);
+    event RemovedGauge(GaugeId gaugeId);
+    event UpdatedGauge(GaugeId gaugeId, Gauge gauge);
+

4. Maximum Crop Ratio Increase

Update s.sys.evaluationParameters.maxBeanMaxLpGpPerBdvRatio from 100e18 to 150e18. These 18-decimal fixed-point values represent 100% and 150%. In the code name, Bean denotes Pinto, Bdv denotes PDV, and MaxLpGp denotes maximum LP gauge points.

5. Crop Scalar Adjustments

Update s.sys.casesV2 to reflect the Crop Scalar decreases from 1 to 2 percentage points per Season for case IDs 57–59 and 66–68. These six cases cover Reasonably High price, Reasonably Low L2SR, and Reasonably or Excessively High Pod Rate across decreasing, steady, and increasing Soil demand. Their encoded adjustment changed from −1e18 to −2e18.

PI-6 as executed. Highlighted cells show the six Crop Scalar decreases from −0.01 to −0.02. Maximum Temperature adjustments were unchanged.

Rationale

1. Cultivation System

Starting with a very low number of Soil minimizes the instances where the protocol fails to find demand for Soil by a wide margin while the protocol is raising the Maximum Temperature to discover the interest rate at which it can attract demand. Instead, the Cultivation System enables the protocol to ramp up available Soil once demand for Soil has been discovered. This should result in lower overall Maximum Temperatures necessary to reduce supply.

2. Minimum Soil Issuance

Setting a minimum Soil of 50 when the time-weighted average and instantaneous Pinto supply deltas are nonpositive and their minimum absolute value is nonzero helps ensure that the protocol can accurately measure demand for Soil even in instances where the Cultivation System would otherwise result in there being a de minimis number of Soil.

3. Generalized Gauge System

Previously, adding 1) State that updates on a gm call and 2) Logic that executes during the gm call required 1) significant technical understanding of the entire gm call, 2) an implicit understanding of the current ordering of actions within the gm, and 3) appending or manipulating the state stored on the Pinto Diamond Contract. The Generalized Gauge System introduces a framework in which new features can be appended to the gm call that 1) isolates state and logic on a Gauge basis, and 2) Introduces explicit execution ordering (i.e., the order in which the Diamond State changes within a gm call), in a modular and composable fashion, such that iterating on Gauges requires minimal onboarding and minimal background knowledge of other Gauges, in a way that minimizes additional security risk per additional Gauge.

4. Maximum Crop Ratio Increase

Prior to this change, the Maximum Crop Ratio of 100% imposed an upper bound on the ratio of Seeds per PDV of Deposited Pinto and the maximum Seeds per 1 PDV of LP Deposited of 1:1. The idea behind this limit was that at all times, the protocol should not express a preference to have Depositors hold Deposited Pinto over Deposited LP because it would mean that the protocol is not looking to preserve liquidity.

However, this failed to capture the fact that the market prefers to hold Deposited LP over Deposited Pinto, such that even if the protocol offers Deposited Pinto as many Seeds per PDV as the highest-rewarded Deposited LP token, the market may still prefer to hold LP. By setting the Maximum Crop Ratio too low, the protocol has therefore been unable to sufficiently incentivize Converts and return the price to its value target consistently when the price is too low.

5. Crop Scalar Adjustments

When price is Reasonably High, the Pod Rate is Reasonably or Excessively High and the L2SR is Reasonably Low, the Crop Scalar should decrease more quickly to more aggressively encourage Converts from Pinto to LP tokens to preserve liquidity. In similar instances but where the L2SR is Excessively Low, the protocol already acts incredibly aggressively to preserve liquidity, but in instances where the L2SR is Reasonably Low, it does not act any more aggressively than when the L2SR is Reasonably or Excessively High. This change refines the Crop Scalar change to better factor in the fact that the L2SR is lower than optimal.

Contract Changes

Initialization

Executed InitPI6.init() at 0x43474d1dabd2213ff6c18b5ba69f8c847808c2c4. It registered the Cultivation Factor gauge at 0.5, set the Soil distribution period to 86,400 seconds (24 hours) and minimum Soil issuance to 50 Soil, installed the corrected Crop Scalar cases, increased the maximum Crop Ratio from 100% to 150%, and reset the Crop Scalar to 67%.

Facet Changes

FacetActionPrevious ImplementationNew Implementation
SeasonFacetReplace0xfc52fc3c8a29f74603006ff03915770014d9f0490xa932cab249fc9ddd073cdb5d40bf304a50025cd6
SeasonGettersFacetReplace0xfa0093b9ca5d00c9e6623767eb09489d90abf1500xf3d017981d0818274210661ba3cc85d143afa78e
GaugeFacetReplace0x2a8827a73de0703b3f6e24895818a3e6d9f8eeba0x25ce5e07e26b4140086f28834dea1c092fc10f90
GaugeFacetAddN/A0x25ce5e07e26b4140086f28834dea1c092fc10f90
GaugeGettersFacetReplace0x04912d77f69bd03f8846a432b0abacfc028bea330xb1cb5aa3c2e91268aae9c97d59ad90d8df979da3
ClaimFacetReplace0x28bcfb5ad84dd460f2fd080dfd706105b8fc21c60xcbb67c0dadf1c2774215d8afd4fef34c7741474b
PipelineConvertFacetReplace0x508320dcc2b4e9f79555bcae1478e6ce736b22ab0x1c3ecf2ae6bd491d112f5a2cea5927a231437437
SiloGettersFacetReplace0x6c1dc649e93be43fff670a2407fa4edc4996bb950x48f040332c3ccccf620e3ed6bbab3d117c9238ca
OracleFacetReplace0x755b6b8844faa8361d54cdee16b418770a412cb40x72827f9a9c3f4a0e36c7de20bb7b830abf385d2e

Other Contract / Parameter Changes

Added soilDistributionPeriod = 86400 seconds and minSoilIssuance = 50e6 (50 Soil) to the evaluation parameters, replacing two reserved buffer slots. Initialized the Cultivation Factor to 50e6 (0.5), bounded by 1e6 (0.01) and 100e6 (1). Increased maxBeanMaxLpGpPerBdvRatio from 100e18 to 150e18 and reset beanToMaxLpGpPerBdvRatio to 67e18 (67%). Corrected the selected Crop Scalar decreases from 1 to 2 percentage points per Season.

The replacement facets linked the following library implementations:

All ten listed library addresses changed. ClaimFacet, PipelineConvertFacet, SiloGettersFacet, and OracleFacet retained their own source files and interfaces despite their replacement. Shared-library behavior may still change.

LibraryPrevious ImplementationNew ImplementationUsed By
LibEvaluate0x69c7d1feb4b963ff9b8338a765c13bb5c3b197920xfad4e8659830d22ce9e4d87eaef52674bf805fdbSeasonFacet
LibGauge0x07b75f35e90eb114035d3c67ac7738f11fb70a260x573c652702091e7265688902ef63c82e21917b4fSeasonFacet
LibIncentive0x4e5dae995c2e8eef23b44a95034064262326e7030x6fac8752c40475c83720acbad2f0c32476243350SeasonFacet
LibShipping0x6ccdfc6fd7885a07e5d4ee5e998a66afe6a657050xab1d90c08dfa6d4c520dad967e97c5eee1d61af2SeasonFacet
LibWellMinting0xd972df7cfd286778951aa829a40e9ab7f7db1d5a0xa31576ac3be233a845e665b98bc384b51e1f4b78SeasonFacet, SeasonGettersFacet
LibFlood0x0b316cb760a677ed1c581041c7d2118bc66aa87c0x8595c632071edec9ab2cd84350d8eef46f181577SeasonFacet
LibGerminate0x636234f909174c764d216ef9bd22175f01a107b20x30f89cd09b92938864b819a552471f2c8771c83dSeasonFacet
LibSilo0x5a686e6024d1d40994ae99979ceb63bf67724b040x85e7554e3af2cfb5ec7a90b53b15b6730055905cClaimFacet, PipelineConvertFacet
LibTokenSilo0x0da233676f46427c31928f5f85678d6737f4ec7e0x31b1b337778948f2d5a1f70722cef7cca1b72e06ClaimFacet, PipelineConvertFacet
LibPipelineConvert0xb387ad744cc1a80ab629eea5ca15459076719a7a0xc7ed19335fcfc73552394dd911cdd56db1ac5e56PipelineConvertFacet

Function Changes

  • Added cultivationFactor(bytes,bytes,bytes), a view function that returns the encoded adjusted Cultivation Factor and unchanged gauge data. It does not store the factor itself. The adjustment uses the previous Season’s recorded Soil sellout, Pod Rate, and largest-USD-liquidity Well price.

Event Changes

\ No newline at end of file diff --git a/public/pi/6/pi6-cases.png b/public/pi/6/pi6-cases.png new file mode 100644 index 000000000..cf8af091d Binary files /dev/null and b/public/pi/6/pi6-cases.png differ diff --git a/public/pi/7/index.html b/public/pi/7/index.html new file mode 100644 index 000000000..7ede21382 --- /dev/null +++ b/public/pi/7/index.html @@ -0,0 +1,797 @@ +PI-7: Dynamic Convert Down Penalty

PI-7: Dynamic Convert Down Penalty

Executed on March 25, 2025 at 20:44 UTC.

Summary

Introduce a Dynamic Stalk Penalty to Pinto -> LP Converts as a function of the L2SR and a bounded counter determined by whether previous Seasons were spent above or below the value target.

Decrease the Excessively High Price threshold () to account for the higher volatility above the value target that this Dynamic Stalk Penalty potentially creates.

Links

Problem

Previously, when the price of Pinto crossed above its value target, the Convert Down Penalty went from 100% (i.e., loss of Grown Stalk above the non-Germinating minimum) to 0% (i.e., no Penalty). Given the overwhelming preference demonstrated by Depositors to hold LP over Pinto in the Silo, as soon as the Convert Penalty went to 0, there were Pinto -> LP Converts that returned the price to its value target. This had the effect of keeping the time the price spent above its value target to an absolute minimum.

While this minimized the amount of minting, which can minimize downside volatility, it also compromised the protocol’s ability to oscillate across the value target, and to spend comparable amounts of time above and below the value target, which decreases utility and therefore long-term demand.

The binary between a 100% penalty and no penalty to Convert Down also favored users with automated execution, concentrating the distribution of LP Deposits and therefore control of the ability to Convert Up when the price is below its value target. A widespread distribution of LP and Pinto ownership is healthier for the protocol than a concentrated one.

Solution

Introduce a Dynamic Stalk Penalty for Pinto -> LP Converts as a function of the L2SR and a counter from 0 to 12 that increases by 1 when a Season has and decreases by 1 otherwise. The penalty ratio ranges from 0% to 100% of the Stalk accumulated from Seeds of the Converted Deposit. The penalty preserves the minimum Grown Stalk required for the output Deposit to remain non-Germinating.

The Stalk Penalty Factor updates according to the counter rule below.

To implement this system, introduce a CONVERT_DOWN_PENALTY gauge system that updates the Dynamic Stalk Penalty incurred by Pinto -> LP Converts.

We define the Stalk Penalty Factor in Season () for a given Season of PI-7 deployment (), maximum Stalk Penalty Factor ( ), and time-weighted average Pinto supply delta over the previous Season () as:

We define the Dynamic Stalk Penalty for Pinto -> LP Converts () for a given instantaneous Pump-reserve price of the output Well , , , L2SR at the end of the previous Season (), optimal L2SR (), and as:

The stored penalty ratio is initialized to 0. These normalized equations omit fixed-point rounding. The applied loss is rounded upward and capped to preserve the non-Germinating minimum. If supplied Grown Stalk is already below that minimum, this helper leaves it unchanged and applies no additional loss. The chart shows the decaying Dynamic Stalk Penalty as Seasons are spent above the value target:

Decrease (excessivePriceThreshold) from $1.05 to $1.025.

Rationale

With the introduction of a Dynamic Stalk Penalty for Pinto -> LP Converts that uses a gauge that increases by 1 each Season the protocol logs a and decreases by 1 each Season the protocol logs a , from 0-12, the protocol can discover the Stalk Penalty at which Converts are disincentivized sufficiently to enable the protocol to keep the price above the value target and then oscillate the penalty above and below this penalty % to incentivize the protocol to alternate each Season above and below the value target. This should lead to more oscillations across the value target, and therefore utility for Pinto.

The logarithmic factor falls most sharply when the counter first increases from zero, then falls more slowly with each additional increase. This favors reaching a Season with a after an extended period where for multiple Seasons. The aim is to let the price move above its target after a prolonged period below it, while making smaller adjustments when the price is already alternating around the target.

The L2SR is factored into the Penalty because at higher liquidity levels the protocol is more comfortable spending more time above the value target and printing more Pinto, so it should further disincentivize Converts in those instances than when it has lower liquidity.

The Excessively High Price threshold () is lowered from $1.05 to $1.025 so Pinto-to-LP Converts can bypass the Dynamic Stalk Penalty once the output Well’s price exceeds $1.025. Allowing them to bypass the penalty at a lower price helps limit how far and how long the price stays above the target, reducing the risk of excessive minting.

Contract Changes

Initialization

InitPI7.init() at 0xd44375790b7ef3d2b0d9b0b96cac0476fcdee568 lowered excessivePriceThreshold from 1.05e6 ($1.05) to 1.025e6 ($1.025). It added the CONVERT_DOWN_PENALTY gauge with penalty ratio 0, counter 0, a counter step of 1 per Season, and a counter cap of 12.

Facet Changes

FacetActionPrevious ImplementationNew Implementation
ConvertFacetReplace0x7Bab1D09727BE8F0427c6DD1d503b3D4BA697D930x1F421eC312C60f9f6E9f6F79e0E56f496aE27e4e
ConvertGettersFacetAdd / Replace0x115E83Bcb217A06D13210009e7CD8b44cE1af5090xfBaD01D4C722B0850444DD63dc273aD2c1C0d321
PipelineConvertFacetReplace0x1C3ecf2ae6bD491d112F5A2CEa5927A2314374370x7a28DFd0e5BBf281e0a853BFEb4609FF093D0BD1
GaugeFacetAdd / Replace0x25cE5E07e26b4140086F28834DEA1c092Fc10f900x55C0e1643e70f9Fb7eEb8c640A303ad9DE263302
SeasonFacetReplace0xa932CaB249fc9ddd073cdB5d40Bf304a50025CD60x5D1f0c38835A0fb55B5Df11341ae217F1f8a01DA
ApprovalFacetReplace0xA7DF4372b0404Cd468703451950e2af8615996b20x65d67f299A4Ad1CfF49a6C77A2Fb463A86643Ab4
SeasonGettersFacetReplace0xF3D017981D0818274210661BA3cc85D143aFA78E0xab2a1bC987e64C4bE13fFB090b01A5888a345C9e
ClaimFacetReplace0xcbb67C0dADf1c2774215d8AFd4fEF34C7741474B0x8738F66d4a0431B084b7fF8f59097312A5B5531F
SiloGettersFacetReplace0x48F040332c3CcCcF620E3Ed6bBab3d117c9238Ca0xa66113Be17098B2594aBA1614055fCc31B3abd67
GaugeGettersFacetReplace0xB1Cb5aA3c2e91268aAe9C97d59AD90D8DF979DA30x07d6EDB2E4afad408beadAAf30bC21b8F804d1F7
OracleFacetReplace0x72827F9a9C3F4A0e36C7DE20BB7B830ABF385D2E0x7256FAd9Eb704173aFE2185D1A44EDF826FF6C86

Other Contract / Parameter Changes

ApprovalFacet, SeasonGettersFacet, ClaimFacet, SiloGettersFacet, GaugeGettersFacet, and OracleFacet retained their own source files and interfaces. SeasonFacet changed only a comment in its own source. Shared dependencies can still change. The externally linked libraries below were redeployed. A changed deployment address does not imply every library function changed. ConvertGettersFacet, GaugeFacet, ApprovalFacet, SiloGettersFacet, GaugeGettersFacet, and OracleFacet have no externally linked libraries in their new deployed metadata.

LibraryPrevious ImplementationNew ImplementationUsed By
LibEvaluate0xfad4e8659830d22ce9e4d87eaef52674bf805fdb0x9a2848cbde1d2fcaeebb712fd8f1eb65a4bda874SeasonFacet
LibGauge0x573c652702091e7265688902ef63c82e21917b4f0xd749370071c7fe42bbe7b81dfa85ba8ec24864b0SeasonFacet
LibIncentive0x6fac8752c40475c83720acbad2f0c324762433500x5630463e432cbd8ddb870d646213011da9166889SeasonFacet
LibShipping0xab1d90c08dfa6d4c520dad967e97c5eee1d61af20xd8a274fcabe2a5cfc1c18b1f844f7fb2941d38f5SeasonFacet
LibWellMinting0xa31576ac3be233a845e665b98bc384b51e1f4b780x9500f6e8742ecb924af9c97922851d648b613d07SeasonFacet, SeasonGettersFacet
LibFlood0x8595c632071edec9ab2cd84350d8eef46f1815770xc4667d3a3c7c0c42a5bf351f98861963b2597f51SeasonFacet
LibGerminate0x30f89cd09b92938864b819a552471f2c8771c83d0xc6f5423a60acd02f0c8d8d6d5281caa00899b0f9SeasonFacet
LibConvert0xcce6631b13ee44ad9d8146241b20f10c1a803aa20x812d9a79aea7db58bc3b0a149ba2694ef37fd1ddConvertFacet
LibPipelineConvert0xb387ad744cc1a80ab629eea5ca15459076719a7a (ConvertFacet); 0xc7ed19335fcfc73552394dd911cdd56db1ac5e56 (PipelineConvertFacet)0xad2f28b08ff993ee8faaeb20235234ade0773022ConvertFacet, PipelineConvertFacet
LibSilo0x5a686e6024d1d40994ae99979ceb63bf67724b04 (ConvertFacet); 0x85e7554e3af2cfb5ec7a90b53b15b6730055905c (PipelineConvertFacet, ClaimFacet)0xf5daf4e2ca77cf48f4ec17d10f0b48a8c2ca9e5cClaimFacet, ConvertFacet, PipelineConvertFacet
LibTokenSilo0x0da233676f46427c31928f5f85678d6737f4ec7e (ConvertFacet); 0x31b1b337778948f2d5a1f70722cef7cca1b72e06 (PipelineConvertFacet, ClaimFacet)0xecc6509f71b74c9b14f035d35fb9113519f88bb5ClaimFacet, ConvertFacet, PipelineConvertFacet

Function Changes

Event Changes

\ No newline at end of file diff --git a/public/pi/8/image.png b/public/pi/8/image.png new file mode 100644 index 000000000..94ca25686 Binary files /dev/null and b/public/pi/8/image.png differ diff --git a/public/pi/8/index.html b/public/pi/8/index.html new file mode 100644 index 000000000..ed9748691 --- /dev/null +++ b/public/pi/8/index.html @@ -0,0 +1,797 @@ +PI-8: Misc. Efficiency Improvements

PI-8: Misc. Efficiency Improvements

Executed on April 17, 2025 at 19:23 UTC.

Summary

  1. Maximum Crop Ratio Increase: Increase the Maximum Crop Ratio from 150% to 200%.
  1. Extremely High Pod Rate Level: Introduce a new Extremely High Pod Rate level, set the threshold above which the Pod Rate is considered Extremely High to 100%, and set the Maximum Temperature adjustments for the Extremely High Pod Rate cases.
  1. Demand for Soil Measurement Update: Update the mechanism for measuring demand for Soil when Soil is sold out over the previous two Seasons.
  1. Demand for Soil Measurement Threshold: Add a minimum threshold of 25 Pinto for how much Soil must be Sown in order to measure demand for Soil.
  1. On-Chain Deposit Sorting: Add helper functions for sorting Deposits on-chain.
  1. Tractor Helper Functions: Add Tractor execution helpers, caller-context views and operator controls to support more expressive Blueprints.
  1. Interface and Event Updates: Update parameter-setting compatibility and conversion-penalty event data for integrations.

Links

Problems

1. Maximum Crop Ratio Increase

The recent increase of the Maximum Crop Ratio from 100% to 150% did not sufficiently change the ability for the protocol to incentivize Depositors to Convert LP to Pinto.

2. Extremely High Pod Rate Level

The protocol did not have a way to distinguish how it changes the Maximum Temperature when the protocol has a Pod Rate that is high but not so high that it is a potential threat to the long term health of the protocol, and when it is.

3. Demand for Soil Measurement Update

With the introduction of the Cultivation System, the protocol regularly was in the circumstance where the number of Soil issued from Season to Season was very different, such that the existing method to measure changes in demand for Soil in instances where the Soil sold out last Season no longer worked.

4. Demand for Soil Measurement Threshold

Demand for Soil was highly manipulable with very little capital due to the lack of a minimum number of Pinto that must be Sown in order to measure demand.

5. On-Chain Deposit Sorting

The inability to sort a user's Deposits on-chain led to inefficient execution when Withdrawing a user's Deposits with the lowest Mown Stalk per PDV for Tractor operations.

6. Tractor Helper Functions

Expressive Blueprints were difficult to implement given the existing set of view functions and events for Tractor metadata.

7. Interface and Event Updates

The parameter-setting interface used an older tuple signature that omitted the existing rain-related Crop Scalar setting. Conversion-penalty events reported only the Stalk lost, without identifying the account or the Grown Stalk retained.

Solutions

1. Maximum Crop Ratio Increase

Update s.sys.evaluationParameters.maxBeanMaxLpGpPerBdvRatio from 150e18 to 200e18.

2. Extremely High Pod Rate Level

Create a new Extremely High Pod Rate threshold and set it to 100%. Apply the new Extremely High Pod Rate Maximum Temperature adjustments only when the Pod Rate exceeds 100% and TWAΔP < 0.

3. Demand for Soil Measurement Update

Update the method to measure changing demand for Soil as follows.

After the 25-Pinto minimum is met, a sellout in less than 20 minutes, more than 5 minutes faster than the prior sellout, or following a Season without a sellout means increasing demand. Otherwise, sellouts within 5 minutes of the prior sellout mean increasing demand if at least 5% more Soil was Sown, and steady demand otherwise. A sellout more than 5 minutes slower uses the change in number of Soil Sown. Seasons without a sellout also use that comparison of the number of Soil Sown.

The diagram below assumes consecutive sellouts, at least 25 Pinto Sown, and a sellout time of at least 20 minutes. Its time boundaries are 5 minutes faster or slower, and its quantity boundaries are 95% and 105% of the prior Season’s Soil Sown.

If Soil did not sell out last Season but sold out the Season prior, the protocol compares the number of Soil sold across the two previous Seasons.

4. Demand for Soil Measurement Threshold

Set the minimum number of Pinto that must be Sown in a Season in order for demand for Soil to be measured – and thus not considered decreasing – to 25.

5. On-Chain Deposit Sorting

Add a function that allows anyone to validate and store a Farmer's supplied Deposit ordering for one token (depositIdList) in ascending Stem order (descending Mown Stalk per PDV) (i.e., the Deposit with the lowest Mown Stalk per PDV is at the last index in the list).

6. Tractor Helper Functions

Add external contracts to support the Tractor ecosystem. TractorHelpers provides getSortedDeposits (descending Stem) and getSortedWhitelistedTokensBySeeds (descending Seeds). Their deployment addresses are listed under Other Contract / Parameter Changes.

Egis reviewed the Sow Blueprint and supporting SiloHelpers, PriceManipulation, PerFunctionPausable and OperatorWhitelist contracts (final audit report here). The report identifies review commit c9eb6ff25dd0ae87d454ab4e5b719af3ca402f72 and resolution commit 378c67ea1dcfdd184a227c24a42dc81f8ff136cb. It does not include BeanstalkPrice or attest to the exact deployed bytecode listed here.

7. Interface and Event Updates

Update the parameter-setting interface to include the existing rain-related Crop Scalar setting. Expand conversion-penalty events to identify the account and report both Grown Stalk lost and Grown Stalk retained.

Rationale

1. Maximum Crop Ratio Increase

The protocol can incentivize LP -> Pinto Converts by awarding more Seeds to Pinto Deposits. The recent change of the Maximum Crop Ratio from 100% to 150% marked the first time the protocol was willing to offer more Seeds to Pinto Deposits than to any LP Deposit. However, this change was insufficient to incentivize enough LP -> Pinto Converts to consistently return the Pinto price to its value target. Increasing the Maximum Crop Ratio further to 200% may improve the ability of the protocol to return the Pinto price to its value target.

2. Extremely High Pod Rate Level

Before PI-8, the protocol had an Excessively High Pod Rate threshold, above which the protocol treated all Pod Rates the same. However, given the fact that the Excessively High Pod Rate threshold is still generally at a low and healthy Pod Rate, it is suboptimal for the protocol to treat all Pod Rates above that threshold identically. Introducing an Extremely High Pod Rate threshold solves this problem.

Setting the Extremely High Pod Rate threshold at 100% is a sufficiently high Pod Rate such that when the protocol has a higher Pod Rate, it should act more conservatively with respect to changes in the Maximum Temperature.

3. Demand for Soil Measurement Update

The examples below assume at least 25 Pinto were Sown and the sellout took at least 20 minutes. Similar sellout times are within 5 minutes of one another. A similar number of Soil means at least 95% but less than 105% of the prior Season’s number.

If Soil sold out in consecutive Seasons and sold out more than 5 minutes faster the second Season, demand for Soil should be considered increasing.

If Soil sold out in consecutive Seasons and at least 5% more Soil was sold the second Season, demand for Soil should be considered increasing.

If Soil sold out in consecutive Seasons and the time it took to sell out was similar and the number of Soil sold was similar, demand for Soil should be considered steady.

If Soil sold out in consecutive Seasons and the time it took to sell out was similar but the number of Soil sold out was less, demand for Soil should be considered steady because the number of Soil sold being less was a function of the protocol being willing to issue less Soil due to a significant change in TWA∆P, not there necessarily being less demand for Soil. Thus, time is a better proxy for changing demand for Soil than number of Soil sold.

If Soil sold out in consecutive Seasons and it took longer to sell out and there was a similar number of Soil sold, demand for Soil should be considered steady. This is because even though Soil took longer to sell out the second Season, if the same number of Soil was sold but Soil didn't sell out, demand for Soil would be considered steady. It would be incoherent for the protocol to consider demand for Soil to be decreasing if it sold out, but steady if it didn't sell out given the same amount of time and number of Soil sold.

If Soil sold out in consecutive Seasons and it took more than 5 minutes longer to sell out and more than 5% less Soil was sold, demand for Soil should be considered decreasing.

If Soil sold out two Seasons ago but did not sell out last Season, it makes sense for the protocol only to consider the number of Soil sown because it is possible that more Soil was sown but it didn't sell out because the increase in the Cultivation Factor resulted in a significant increase in the number of Soil available. By checking the number of Soil sown the protocol can accurately measure changing demand over the previous two Seasons.

4. Demand for Soil Measurement Threshold

The introduction of a minimum threshold below which demand for Soil is always decreasing raises the minimum number of Pinto required to influence the demand for Soil measurement. Previously, the measurement could be influenced essentially for the cost of gas. The new threshold requires at least 25 Pinto to be Sown before demand can be steady or increasing.

5. On-Chain Deposit Sorting

Pinto stores a list of Deposits that the farmer owns on chain. An on chain list allows Smart Contracts to access the value a given farmer owns, without using indexing services. The Deposit list does not enforce any sorting rules when adding/removing entries. By having an optional function that allows anyone to validate and store a supplied ordering in descending order in terms of Mown Stalk per PDV in a permissionless fashion (which in PI-8 updated the ordered array but not its index mapping), smart contracts can more easily find the Deposits with the lowest Mown Stalk per PDV in a gas efficient fashion.

TractorHelpers traverses the stored Deposit list backward in order to use the Deposits with the lowest Mown Stalk per PDV in the Sow Orderbook. This ordering depends on the stored list being sorted in ascending Stem order.

6. Tractor Helper Functions

Shared withdrawal-planning and caller-context helpers let Blueprints coordinate Deposits, operators and token transfers without duplicating that logic. Explicit execution metadata also makes Tractor activity easier for integrations to identify.

7. Interface and Event Updates

Including the existing rain-related setting in the parameter tuple keeps the administrative interface aligned with stored configuration. Identifying the account and retained Grown Stalk in conversion-penalty events gives indexers the context needed to interpret each penalty.

Contract Changes

Initialization

InitPI8.init() at 0xeb393ee29335d6f75cbadbddbd115553e275bb3c set minSoilSownDemand from 0 to 25e6 (25 Pinto per Season) and maxBeanMaxLpGpPerBdvRatio from 150e18 to 200e18 (150% to 200%). It rescaled the existing Crop Scalar to approximately preserve the Crop Ratio, then rounded the scalar down to whole percentage points.

Facet Changes

The executed diamond cut replaced 17 facets, added eight selectors and removed the prior updateSeedGaugeSettings selector. Replacing a facet does not mean every function in that facet changed.

FacetActionPrevious ImplementationNew Implementation
SiloFacetAdd / Replace0xd2d3d44edbbc66ef90b29627dfd0a06d3ca0cad40xd954a3245a868ab3e991786d4e5e71892099a19d
SiloGettersFacetAdd / Replace0xa66113be17098b2594aba1614055fcc31b3abd670x6f9a49560a1db78cd32f1332e15fcaedc77aa66b
ConvertFacetReplace0x1f421ec312c60f9f6e9f6f79e0e56f496ae27e4e0x1af9097b043e26f41d082c5adb89cd606528e526
PipelineConvertFacetReplace0x7a28dfd0e5bbf281e0a853bfeb4609ff093d0bd10xf26ab0c4a354f12c9e8fa86c423f463e2c72ddd8
TractorFacetAdd / Replace0xd06128e88b7b84c214c400b86ca17770813567cf0x007a0b3bf5a9efc922e83bf0ebe7bf27fc2103bf
FieldFacetAdd / Replace0x8906b9131b7c6354f3e14b8656b546cfcfc9edf10x0b5888a4c6fb90d26fb4d5f782d45c9e86dcc974
ApprovalFacetReplace0x65d67f299a4ad1cff49a6c77a2fb463a86643ab40x61b9a20a5fc4a9965c2309c2feff56b5ebe855cd
ConvertGettersFacetReplace0xfbad01d4c722b0850444dd63dc273ad2c1c0d3210xe0b8fca80b1a7060fea44c6f823b221ec9d7217c
GaugeFacetReplace0x55c0e1643e70f9fb7eeb8c640a303ad9de2633020x42575b2f01d18cf3ed670c9fe82ee90332739d03
GaugeGettersFacetReplace0x07d6edb2e4afad408beadaaf30bc21b8f804d1f70x0f97cb8bb44d3d7a0afaeac24bbfe152215e3c5a
SeasonFacetReplace0x5d1f0c38835a0fb55b5df11341ae217f1f8a01da0x5545a4ab5cd3f6e7db0883e73ea4805f6e1270a9
SeasonGettersFacetReplace0xab2a1bc987e64c4be13ffb090b01a5888a345c9e0xebaa2c95efc7f1cef1a57dfb5fe05f8935d7390e
TokenFacetReplace0x8ab92619de059d8777822e022baaf546a614753d0x7f492edcd56335b2d2aee29dfe39df33bbe43bb8
TokenSupportFacetReplace0xd2d6808a2b669723abc669ba5b5d79a8717344150x9d214daf535396d515d93831fc7fe5fa137b4f30
MarketplaceFacetReplace0x1fbdebc461857d5d8306a64b199ff84975dfc6f80x1f4504295c5bd57cdbd8caf4df9ab13381cb0ad4
ClaimFacetReplace0x8738f66d4a0431b084b7ff8f59097312a5b5531f0x44df048857445cd8cba3b8cc26132816d827ff14
WhitelistFacetAdd / Replace / Remove0x45ee6286468f2b1406915446913b744db5a4c5d20xaaca4a18ddad39fb3a2441ff279afde06bd61b62

Other Contract / Parameter Changes

Supporting ContractNew Deployment
BeanstalkPrice0x13D25ABCB6a19948d35654715c729c6501230b49
PriceManipulation0x774c111F471FBa61B13D63C9B585882e3c6cf7A6
OperatorWhitelist0xF4ee12763976C3025194ef0E272a8390164Cc18f
TractorHelpers0x2808b14d287F8CA77eb25B16575aF187d5A05119
SowBlueprintv00xbb0a41927895F8ca2b4ECCc659ba158735fCF28B

The table below lists the externally linked libraries recorded in the previous and new deployed facet metadata. Shared dependencies are deduplicated. LibSilo and LibTokenSilo each had two previous deployments, identified by their consuming facets. The other replaced facets had no externally linked library dependencies. Address changes do not imply that every library function changed. The final row records the additional library linked by the supporting TractorHelpers deployment.

LibraryPrevious ImplementationNew ImplementationUsed By
LibSilo0x5a686e6024d1d40994ae99979ceb63bf67724b04 (SiloFacet)
0xf5daf4e2ca77cf48f4ec17d10f0b48a8c2ca9e5c (ConvertFacet, PipelineConvertFacet, ClaimFacet)		0x49bfc93e96d467d79fc809c8f6da466f8ebb8975SiloFacet, ConvertFacet, PipelineConvertFacet, ClaimFacet
LibTokenSilo0x0da233676f46427c31928f5f85678d6737f4ec7e (SiloFacet)
0xecc6509f71b74c9b14f035d35fb9113519f88bb5 (ConvertFacet, PipelineConvertFacet, ClaimFacet)		0xe47c1d275ceb1554ce802a0755cc679294f1ae81SiloFacet, ConvertFacet, PipelineConvertFacet, ClaimFacet
LibConvert0x812d9a79aea7db58bc3b0a149ba2694ef37fd1dd0xd10b907e2f8f452c4d43848a4f632a00eff9530bConvertFacet
LibPipelineConvert0xad2f28b08ff993ee8faaeb20235234ade07730220x9b42c78bd19fdf3cf3b3c16c9184e1169bf2c7aaConvertFacet, PipelineConvertFacet
LibEvaluate0x9a2848cbde1d2fcaeebb712fd8f1eb65a4bda8740x311877f9ffbaf12b905df3e1f8c3b5f3c5527bd4SeasonFacet
LibGauge0xd749370071c7fe42bbe7b81dfa85ba8ec24864b00x28d436b9bbbe755dea4db747483f693d71847984SeasonFacet
LibIncentive0x5630463e432cbd8ddb870d646213011da91668890x09240a6c83350caaf110d9de6e23a659625d5476SeasonFacet
LibShipping0xd8a274fcabe2a5cfc1c18b1f844f7fb2941d38f50x3e3442a75ed4dd47e64e4522da625701049d6477SeasonFacet
LibWellMinting0x9500f6e8742ecb924af9c97922851d648b613d070x6dd836e7fe603bd73532bf6b5cbb188b7fcc7fa9SeasonFacet, SeasonGettersFacet
LibFlood0xc4667d3a3c7c0c42a5bf351f98861963b2597f510xff823fbb0ae114b8e41c0529c7d87702cc5d06a8SeasonFacet
LibGerminate0xc6f5423a60acd02f0c8d8d6d5281caa00899b0f90x74f0910564523a9a9a0b4db23505f653af20548cSeasonFacet
LibTractorHelpersNot applicable — new supporting dependency0xcc035410d5570f2c5e841091c87d5d051761e569TractorHelpers

Function Changes

Event Changes

\ No newline at end of file diff --git a/public/pi/9/index.html b/public/pi/9/index.html new file mode 100644 index 000000000..1c6700356 --- /dev/null +++ b/public/pi/9/index.html @@ -0,0 +1,797 @@ +PI-9: Helper Function Bug Fix

PI-9: Helper Function Bug Fix

Executed on April 18, 2025 at 18:48 UTC.

Summary

Update the _setSortedDepositIds function to properly set the Deposit ID-to-index mapping.

Links

Problem

The protocol stores a list of each Farmer's Deposits on-chain, which is used to allow clients like the Pinto UI to easily query Deposit data. The protocol also stores a mapping of Deposit IDs to index in order to efficiently look up a Deposit's index. PI-8 introduced an updateSortedDepositIds function that allows anyone to submit a Deposit ordering for one token, validated in ascending Stem order, but this function did not properly update the mapping to reflect the new ordering. As a result, a later full Deposit removal could use a stale index and remove the wrong ID from the list.

Solution

Update LibSilo._setSortedDepositIds to properly update the mapping based on the new ordering. Each Deposit ID is mapped to its zero-based index before the ordered list is stored.

Rationale

Keeping the index mapping consistent with the ordered list preserves correct Deposit index lookup and removal after reordering. The existing validation requires a nonempty, complete list in strictly ascending Stem order.

Contract Changes

Initialization

No initializer was called. The upgrade did not automatically rewrite existing account mappings. A successful call to updateSortedDepositIds updates the supplied account and token’s index mapping.

Facet Changes

FacetActionPrevious ImplementationNew Implementation
ApprovalFacetReplace0x61b9a20a5fc4a9965c2309c2feff56b5ebe855cd0xa7c95ed70be8f91f8d8af91de193710fa7ab32bb
ClaimFacetReplace0x44df048857445cd8cba3b8cc26132816d827ff140xd38c3e61bf08734cd808aca15c944389968612e0
ConvertFacetReplace0x1af9097b043e26f41d082c5adb89cd606528e5260xdfa197784879926e2358a7c71c6a0bd487f919fd
PipelineConvertFacetReplace0xf26ab0c4a354f12c9e8fa86c423f463e2c72ddd80xc54cd71bfa5d0fe05d887eabbec4dbbc94cf74ba
SiloFacetReplace0xd954a3245a868ab3e991786d4e5e71892099a19d0xf6af001b8879a2e30db294b4c8deccbd0d168b34
SiloGettersFacetReplace0x6f9a49560a1db78cd32f1332e15fcaedc77aa66b0xadfd7fbe59ca2624cec1b04f9bc65c7f90efed36

All six facets were replaced with unchanged external interfaces. The changed internal helper is called only by SiloFacet.updateSortedDepositIds(). The other replacements do not introduce additional function changes.

Other Contract / Parameter Changes

The externally linked libraries below were redeployed. Only LibSilo’s own source changed. LibTokenSilo, LibConvert and LibPipelineConvert retained their own source. ApprovalFacet and SiloGettersFacet have no externally linked libraries. No protocol parameters were changed.

LibraryPrevious ImplementationNew ImplementationUsed By
LibSilo0x49bfc93e96d467d79fc809c8f6da466f8ebb89750xefa4e6492966228a7af3d5d9045bd9c9e5dc72bfClaimFacet, ConvertFacet, PipelineConvertFacet, SiloFacet
LibTokenSilo0xe47c1d275ceb1554ce802a0755cc679294f1ae810xf2a0e7fb0e9b1189b14274418e4ac78ae449b4edClaimFacet, ConvertFacet, PipelineConvertFacet, SiloFacet
LibConvert0xd10b907e2f8f452c4d43848a4f632a00eff9530b0x71e8ab0a025c0b96d64c34759880e6ba2ba0baa0ConvertFacet
LibPipelineConvert0x9b42c78bd19fdf3cf3b3c16c9184e1169bf2c7aa0xa4a2d1e394faac3e60297a55cdceeb38c0b6ca18ConvertFacet, PipelineConvertFacet

Function Changes

\ No newline at end of file diff --git a/public/pi/index.html b/public/pi/index.html new file mode 100644 index 000000000..0ab065b12 --- /dev/null +++ b/public/pi/index.html @@ -0,0 +1 @@ +Pinto ImprovementsPinto

Pinto Improvements

  1. PI-0: Fix the PINTO:USDC Multi Flow Pump and Update Multi Flow Pump Cap Parameters
  2. PI-1: Convert Newly Earned Pinto and Misc. Bug Fixes
  3. PI-2: Remove Anti Lambda to Lambda Convert
  4. PI-3: Bug Fixes and Parameter Changes
  5. PI-4: Demand for Soil Adjustments
  6. PI-5: Soil Issuance and Parameter Changes
  7. PI-6: Introduce Cultivation System and Crop Ratio Changes
  8. PI-7: Dynamic Convert Down Penalty
  9. PI-8: Misc. Efficiency Improvements
  10. PI-9: Helper Function Bug Fix
  11. PI-10: Fix Cultivation Gauge and Revise Parameters
  12. PI-11: Update Convert Down Penalty Gauge and Dewhitelist Pools
  13. PI-12: Decrease Excessively Low L2SR Threshold
  14. PI-13: Dynamic Convert Up Bonus + Optimizations
  15. PI-14: wstETH Liquidity, Pod Referrals and Batched Operations
  16. PI-15: Beanstalk Repayments and Bug Fixes
\ No newline at end of file diff --git a/src/components/landing/ProtocolUpgrades.tsx b/src/components/landing/ProtocolUpgrades.tsx index f9981f30d..e658a59fc 100644 --- a/src/components/landing/ProtocolUpgrades.tsx +++ b/src/components/landing/ProtocolUpgrades.tsx @@ -43,24 +43,35 @@ interface TimelineEvent { // Pinto Improvement Proposals const piAudits: TimelineEvent[] = [ + { + name: "PI-15", + description: "Beanstalk Repayments and Bug Fixes", + githubLink: "/pi/15/", + hashLink: "", + date: "March 6, 2026", + timestamp: new Date("March 6, 2026").getTime(), + auditHash: "", + auditor: "bean", + type: ["modelImprovement"], + }, { name: "PI-14", - description: "Protocol Upgrade", - githubLink: "https://github.com/pinto-org/protocol/pull/164", + description: "wstETH Liquidity, Pod Referrals and Batched Operations", + githubLink: "/pi/14/", hashLink: "", - date: "January 19, 2026", - timestamp: new Date("January 19, 2026").getTime(), + date: "January 20, 2026", + timestamp: new Date("January 20, 2026").getTime(), auditHash: "", auditor: "bean", type: ["modelImprovement"], }, { name: "PI-13", - description: "Dynamic Convert Up Bonus and Optimizations", - githubLink: "https://github.com/pinto-org/protocol/pull/46", + description: "Dynamic Convert Up Bonus + Optimizations", + githubLink: "/pi/13/", hashLink: "", - date: "October 21, 2025", - timestamp: new Date("October 18, 2025").getTime(), + date: "October 23, 2025", + timestamp: new Date("October 23, 2025").getTime(), auditHash: "", auditor: "bean", type: ["modelImprovement"], @@ -69,7 +80,7 @@ const piAudits: TimelineEvent[] = [ { name: "PI-12", description: "Decrease Excessively Low L2SR Threshold", - githubLink: "https://github.com/pinto-org/protocol/issues/142", + githubLink: "/pi/12/", hashLink: "", date: "September 8, 2025", timestamp: new Date("September 8, 2025").getTime(), @@ -80,7 +91,7 @@ const piAudits: TimelineEvent[] = [ { name: "PI-11", description: "Update Convert Down Penalty Gauge and Dewhitelist Pools", - githubLink: "https://github.com/pinto-org/protocol/pull/136", + githubLink: "/pi/11/", hashLink: "", date: "July 31, 2025", timestamp: new Date("July 31, 2025").getTime(), @@ -91,7 +102,7 @@ const piAudits: TimelineEvent[] = [ { name: "PI-10", description: "Fix Cultivation Gauge and Revise Parameters", - githubLink: "https://github.com/pinto-org/protocol/pull/114", + githubLink: "/pi/10/", hashLink: "", date: "June 19, 2025", timestamp: new Date("June 19, 2025").getTime(), @@ -102,7 +113,7 @@ const piAudits: TimelineEvent[] = [ { name: "PI-9", description: "Helper Function Bug Fix", - githubLink: "https://github.com/pinto-org/protocol/pull/77", + githubLink: "/pi/9/", hashLink: "", date: "April 18, 2025", timestamp: new Date("April 18, 2025").getTime(), @@ -113,7 +124,7 @@ const piAudits: TimelineEvent[] = [ { name: "PI-8", description: "Misc. Efficiency Improvements", - githubLink: "https://github.com/pinto-org/protocol/pull/47", + githubLink: "/pi/8/", hashLink: "", date: "April 17, 2025", timestamp: new Date("April 17, 2025").getTime(), @@ -123,8 +134,8 @@ const piAudits: TimelineEvent[] = [ }, { name: "PI-7", - description: "Convert Down Penalty", - githubLink: "https://github.com/pinto-org/protocol/pull/33", + description: "Dynamic Convert Down Penalty", + githubLink: "/pi/7/", hashLink: "", date: "March 25, 2025", timestamp: new Date("March 25, 2025").getTime(), @@ -134,8 +145,8 @@ const piAudits: TimelineEvent[] = [ }, { name: "PI-6", - description: "Soil Issuance Below Target, Crop Ratio Changes", - githubLink: "https://github.com/pinto-org/protocol/pull/8", + description: "Introduce Cultivation System and Crop Ratio Changes", + githubLink: "/pi/6/", hashLink: "", date: "March 12, 2025", timestamp: new Date("March 12, 2025").getTime(), @@ -147,7 +158,7 @@ const piAudits: TimelineEvent[] = [ { name: "PI-5", description: "Soil Issuance and Parameter Changes", - githubLink: "https://github.com/pinto-org/protocol/pull/7", + githubLink: "/pi/5/", hashLink: "", date: "January 2, 2025", timestamp: new Date("January 2, 2025").getTime(), @@ -158,7 +169,7 @@ const piAudits: TimelineEvent[] = [ { name: "PI-4", description: "Demand for Soil Adjustments", - githubLink: "https://github.com/pinto-org/protocol/pull/5", + githubLink: "/pi/4/", hashLink: "", date: "December 8, 2024", timestamp: new Date("December 8, 2024").getTime(), @@ -169,18 +180,18 @@ const piAudits: TimelineEvent[] = [ { name: "PI-3", description: "Bug Fixes and Parameter Changes", - githubLink: "https://github.com/pinto-org/protocol/pull/4", + githubLink: "/pi/3/", hashLink: "", - date: "December 4, 2024", - timestamp: new Date("December 4, 2024").getTime(), + date: "December 5, 2024", + timestamp: new Date("December 5, 2024").getTime(), auditHash: "", auditor: "cantina", type: ["parametrization", "utility"], }, { name: "PI-2", - description: "Remove Anti L2L Convert", - githubLink: "https://github.com/pinto-org/protocol/pull/3", + description: "Remove Anti Lambda to Lambda Convert", + githubLink: "/pi/2/", hashLink: "", date: "November 27, 2024", timestamp: new Date("November 27, 2024").getTime(), @@ -190,22 +201,22 @@ const piAudits: TimelineEvent[] = [ }, { name: "PI-1", - description: "Convert Earned Pinto, Misc. Fixes", - githubLink: "https://github.com/pinto-org/protocol/pull/2", + description: "Convert Newly Earned Pinto and Misc. Bug Fixes", + githubLink: "/pi/1/", hashLink: "", - date: "November 26, 2024", - timestamp: new Date("November 26, 2024").getTime(), + date: "November 27, 2024", + timestamp: new Date("November 27, 2024").getTime(), auditHash: "", auditor: "cantina", type: ["parametrization", "utility"], }, { name: "PI-0", - description: "Update Pump Parameters", - githubLink: "https://github.com/pinto-org/protocol/pull/1", + description: "Fix the PINTO:USDC Multi Flow Pump and Update Multi Flow Pump Cap Parameters", + githubLink: "/pi/0/", hashLink: "", - date: "November 19, 2024", - timestamp: new Date("November 19, 2024 13:00:00").getTime(), + date: "November 20, 2024", + timestamp: new Date("November 20, 2024 13:00:00").getTime(), auditHash: "", auditor: "cantina", type: ["parametrization", "bugFix"],