PI-14: Whitelist Pinto-wstETH, Add dynamic LP Distribution, and Pod Referral

[fr1jo]

PI-14: Whitelist Pinto-wstETH, Add dynamic LP Distribution, and Pod Referral

Summary

• Deploy and add the Pinto:wstETH Well to the Deposit Whitelist;
• Implement a Gauge that adjusts the optimal distribution of liquidity;
• Implement a referral system that grants farmers Pods when another farmer Sows using their referral;
• Upgrade Tractor to allow Blueprint smart contracts to use dynamic calldata and;
• Add batching functionality for Converts and Pod Marketplace actions.

Links

• PI-14 GitHub PR
• Safe Transaction
• BaseScan Transaction

Problem

• 85% of the value that trades against Pinto is censorable by Coinbase/Circle. A high concentration dependent on one party lowers the censorship resistance of Pinto.

• Pinto currently does not have a way to autonomously adjust the optimal distribution of liquidity.

• Farmers do not have an direct incentive to encourage users outside of the protocol to participate.

• Tractor does not allow for dynamically sized payloads, limiting the expressivity of Blueprint contracts (contracts built on top of Tractor).

• Users are only able to Anti-Lambda-Lambda (AL2L) one Deposit per function call, increasing the friction for farmers to efficiently update other farmer's Deposits' PDV.

• Users are unable to buy/list multiple Plots in the same function call, increasing the friction to interact with the Pod marketplace..

Solution

• Deploy and Whitelist the Pinto-wsETH Well. wstETH is an ETH liquid staking derivative similar in purpose and structure to cbETH, but is non-custodial. It is collateralized by ETH staked via validators coordinated by the Lido protocol. Lido does not custody users’ wstETH or control user keys. nstead, it can influence validator selection and protocol upgrades through its governance processes. Taking over wstETH would require capture of Lido DAO governance and coordinated validator collusion at the Ethereum consensus layer, followed by social acceptance by the Ethereum ecosystem. There is no single custodian, issuer, or legal control point capable of unilaterally seizing or censoring wstETH. Thus, migrating some of the liquidity from cbETH to wstETH will significantly increase the overall censorship resistance of Pinto.

• Implement a dynamic optimal LP distribution system that allows the protocol to adjust its optimal distribution over time, rather than incentivizing a static distribution. Every Season, the optimal distribution for each LP token on the Deposit Whitelist changes based its LP Distribution Function The implementation can be seen in the Appendix section.

• Set the dynamic optimal LP distribution to decrease the Pinto-cbETH optimal LP distribution from 33.33% to 0% in 360 Seasons, and increase the Pinto-wstETH optimal LP distribution from 0% to 33.33% in 360 Seasons.

• Implement the Pod Referral system, enablingFarmers to receive additional Pods (in excess of the Temperature) for Sowing with a referral. Both the referrer and referee receive bonus Pods. The referrer receives 5% bonus Pods and referred Farmer receives 10% bonus Pods. The referrer's Pods are immediately after the referee's Pods in the Pod Line.can refer another Farmer and gain a 5% bonus Pods when lending to the Field. Referred Farmers gain 10% of the Pods minted, up to 2 million Pods.

• Upgrade Tractor to handle dynamically sized payloads. Operators can inject dynamic calldata by calling tractorDynamicData. The implementation can be seen in the Appendix section

• Add batch functionality to the existing Convert and Marketplace actions.

Economic Rationale

• By adjusting the optimal distribution of LP and then allowing the LP Seed Gauge to change the incentives to hold Deposited cbETH and wstETH over time, there should be minimal value lost by Farmers who may require time to migrate.

• There is no need at this time to change the overall distribution of liquidity. By changing the optimal distribution of cbETH and wstETH in lockstep, maintaining the same overall optimal exposure to ETH while gradually changing the particular form of ETH exposure is achieved.

• The Pod Referral system increases the actual Temperature, and therefore the Pod Rate of the protocol. While at the margin the protocol would prefer to issue less debt, the current state of the protocol is such that it would rather issue more debt to decrease supply. By adding the Referral System, the marginal incentive to attract other Farmers to Sow increases.

• Eliminating the friction to using Tractor efficiently allows farmers to better access and use the protocol efficiently. Pod referral Economic rationale

• Batching functionality allows for more gas efficient interactions on the Farm. Lowering the cost to interact with the Farm allows farmers to use the protocol more efficiently.

Technical Rationale

• Manual liquidity migrations require significant development effort. The implementation of a generalized dynamic optimal liquidity distribution mechanism removes the need to do manual migrations moving forward.

• At the time of deployment, Pinto needs to retroactively store the number of Pinto Sown by each farmer. Given that this may update between the multisig proposal and execution, Pinto needs a way to initialize these values. Given the stateless requirement of Initialization functions, and the asynchronous nature of the PCM signing transactions and deployment of the Init contract, a Helper Contract that serves as Init Storage allows for dynamic data in the init function was created to solve this problem.

• Allowing Tractor operators with the ability to inject dynamic calldata increases the expressivity of Blueprint smart contracts.

• Tractor dynamic data leverages EIP-1153: Transient storage(https://eips.ethereum.org/EIPS/eip-1153) for gas efficient temporary storage.

• While interfaces can utilize the farm and advancedFarm function to call multiple Pinto actions in one transaction, each action performs an gaseous invariant check to verify that the protocol is secure and solvent. Implementing protocol batching for Converts and Marketplace actions (e.g creating, cancelling, and filling Pod Listings and Orders) significantly reduces the cost of said actions.

Contract Changes

Facet	New Upgraded FacetAddress	Previous Deprecated FacetAddress
GaugeFacet	0xf9F1D9c6eF1Ca5ec0897C266d7B4E016e955d916	0xa98400591c72ce2A2BDe3B170F5A6A1b070Ee4EA
GaugeGettersFacet	0xc0b381741820808b6407CdC8b03E8561259F8e5D	0x7D5B807202B8AE3dFb4b6d988d85622590b22862
SeasonFacet	0x4AeEE50B11C3682605dCeCA1FeACd96349383cd2	0xB9D1C6e65a8934ec86d70F358028943e63ee0793
FieldFacet	0xae94197E16B31443fE1C333A32eDa30eb3c1A942	0x32124b4Da9B23659C1ad4B8bE4fc2D274701C3D1
TractorFacet	0xC8706ff2A0dA6B3367AA506dCBb608cCF96148DE	0xc2Fc7963F76205dC57842e1a90c3E487Bd16a556
MarketplaceFacet	0x85436279a52537EF03864e268d73D3ba37E169eC	0x5AEB7C0a256b167BAe026056d32818539b1734B4
MarketplaceBatchFacet	0x40E42F3D568FAf47C539A7D2A61E24629819baD4	NEW - No previous address
ConvertFacet	0xdC37f26363B305affc93C564EE879A265BcBFF4D	0x508900b00970AF419c915C921ECc81d7E0a7eBCB
ConvertGettersFacet	0x334a110Ad41Fd417D4C8C3f82D9C85A3850192be	0x32A036190967A11280ecD944d90B85d86f43e24f
ConvertBatchFacet	0x923a7096f7338660e60b4dc0aE21d2413E399739	NEW - No previous address
ClaimFacet	0xfc4499F812014BEBAF9686Ce0312a77ccA65137a	0x5e71Bf027203BcBc9b1Bd22504720D8E8Be30Cf7
PipelineConvertFacet	0xa66460626D1F8845085B1CdD5E527Db1Db998B1b	0x51B9fcA1c4900584861Efc794458Dfa47775dD4B
SiloFacet	0x8646649c0f80db8665358f4548AE0d1ecC3910a5	0xf4e60EcDC7ddD4037F1B9AA7D27a30d367871ca5
SiloGettersFacet	0x92a2Ddc9D6BcDE63Fb4473033EF8BeEa4145d0fd	0xA9f983F26828A99146f7F119A358ad930eDBf420
MetadataFacet	0xCed0eA96c44341343C13Dc671C22e858e21675e0	0xf6506176A027ed4d5CdBaB23d9DFcdEC2B35b2A8
ApprovalFacet	0x596050cCBbe49966A29bE8663b2ed6A1f5DC1870	0xA456002541fFdD0Cf4c8CDd273210581F2bF0314
TokenFacet	0xd29e38e4a803Feac3503Fd7402181BbA79d3D3F0	0x7f492EDCd56335B2d2AEE29DfE39DF33bbe43bb8
TokenSupportFacet	0x7F1BB9F51C636012CFaADc9E2DB124EDd21a7b92	0x9D214Daf535396D515D93831fC7fe5fa137B4F30
FarmFacet	0x16d28e43E43c6D5B2E95140F2f3000dCF87eB1D9	0x39322b0448a7c7B6aBf980d204fA0c45Df1886DC

Appendix

Optimal LP Distribution Gauge

Each LP token on the Deposit Whitelist has 1) a target optimal percent LP distribution ($λ^{{∗}^{T}}$), 2) the change in optimal percent LP distribution ($∆λ^{∗}$), and optionally, 3) a LP Distribution Function. ($f^{{λ}^d}$)

the LP Distribution Function is a generic function that takes in 1) the change in optimal percent LP distribution last Season ($∆λ_{t-1}^{∗}$), and generic calldata set for the given LP token ($λ_{D}$), and returns the change in optimal percent LP distribution this season.

$$ f^{{λ}^d} = f(∆λ^{∗}_{t-1},λ_{D}) $$

Currently, there are no LP Distribution Functions defined in Pinto.

Each Season, Pinto iterates through each of the whitelisted LP tokens, invokes the LP Distribution function (if applicable), and changes the change in optimal percent LP deposited PDV.

$$ ∆λ^{∗}_{t} = \begin{cases} f^{{λ}^d} , & \text{if } f^{{λ}^d} \ \text{is defined} \\ λ^{{∗}^{T}} - λ^{∗}_{t-1}, & \text{if } ∆λ^{∗}_{t-1} > | λ^{{∗}^{T}} - λ^{∗}_{t-1} | \\ ∆λ^{∗}_{t-1} & \text{else} \end{cases} $$

The optimal percent LP deposited PDV for a given Season is calculated as:

$$ λ^{∗}_{t} =λ^{∗}_{t-1}+ ∆λ^{∗}_{t} $$

Tractor Dynamic Data

Tractor Blueprint Contracts (e.g smart contracts that are intended to be called within a tractor call) can use dynamic data by calling getTractorData with a key value.

Data can only be set at the key value by calling tractorDynamicData and inputting data by a (key, value) pair.

Data set via this method will only be active until the end of the tractor call.