✔️ MCCP 18: Add Idle Finance dial for 3pool PYT

The Author of this Proposal is @Davide from Idle.

Simple Summary

It is proposed to add an Idle Finance Convex protocol (mUSDcrv) Perpetual Yield Tranches (PYTs) dial.


Idle DAO developed 2 products based on mStable ecosystem in Ethereum:

  • mStable PYTs, tranching the “Save” vault, where users can deposit mUSD tokens.
  • Convex PYTs, tranching mUSD pool, where users can deposit mUSDcrv Curve LP tokens.

In short, Junior Tranches TVL covers Senior Tranches in case of losses, but they leverage Senior Tranches TVL to receive APYs higher than the underlying yield source.
A wider range of users can deploy mUSD in the Save vault or increase the liquidity of mUSDcrv Curve pool through Convex – with Senior/Junior Tranches, they are now able to adjust their deposit depending on their risk profile.

This proposal suggests adding one dial for the Convex PYTs to receive additional MTA rewards and to incentivise this Junior Tranche.


Idle DAO launched a “Tranches Battle” and selected mUSD as one of the contest winners. This resulted in the development of PYTs using mUSD pool on Convex. The integration has been completed, and is ready to be launched. It’s already visible on the Beta page.

In addition, Idle DAO approved the launch of Gauges to reward Senior Tranches with $IDLE farming (initially at 990 IDLE/day). mUSDcrv PYTs will be eligible to benefit from these streams.

The support for the Senior Tranches of mUSDcrv PYTs in MTA dial will allow mStable to incentivize Curve pool liquidity, enabling users to adjust their liquidity deployment to their risk profile.

PYTs features
With Perpetual Yield Tranches, LPs can earn a higher share of yield by taking more risk (with Junior Tranche), or they can hedge risk by depositing their assets into an inherently protected tranche (with Senior Tranche). Senior Tranches have a first lien on the assets — they’re in line to be repaid first, in case of default.

PYTs are:

  • Epochless, flexible, with no locking periods: you can deposit or withdraw your liquidity at any time;
  • Fully fungible and composable ERC-20: other DeFi protocols and integrators can offer tailored products based on PYTs;
  • High-quality yield-bearing collateral: the built-in fund protection mechanism available on Senior Tranches makes them more resilient against default scenarios and can benefit from higher LTV.

About PYTs
Idle launched PYTs in late December, after 4 months of guarded launch. Idle PYTs’ smart contracts have been audited by two different professional auditing firms before the release (Consensys Diligence and Certik). All the related and previous audits for the Idle protocol are available here.

About Idle
Idle DAO is a decentralized organization that builds financial infrastructure for Web3. Businesses of every size – from brand new DeFi protocols to public companies – use our protocol to optimize capital efficiency and manage their treasuries with DeFi.

We believe that everyone deserves the best for their idle funds, both in terms of returns and risks. Since 2019, Idle has rolled out the features and services that allowed us to battle-test our products
throughout the years and become one of the most resilient protocols in the space.

To learn more about our products and services:


A new instance of the contract BasicRewardsForwarder will be deployed on Ethereum mainnet with the following parameters:

  • nexus = 0xAFcE80b19A8cE13DEc0739a1aaB7A028d6845Eb3 (Nexus contract)
  • rewardsToken = 0xa3BeD4E1c75D00fa6f4E5E6922DB7261B5E9AcD2 (MTA Deployed address)

And initialized with:

  • emissionsController = 0xBa69e6FC7Df49a3b75b565068Fb91ff2d9d91780 (Emissions Controller deployed address)
  • endRecipient = 0x7f366a2b4c4380fd9746cf10b4ded562c890b0b1

This contract receives the MTA from the Emissions Controller and forwards it to the staking contract controlled by Idle Finance (endRecipient). The Idle DAO controlled multisig calls then the depositReward function each week, so the contract is aware of the new rewards added and starts distributing those.

This contract will then be added to the Emissions Controller as a dial:

  • Emissions Controller (0xBa69e6FC7Df49a3b75b565068Fb91ff2d9d91780)
    • addDial (address recipient, uint8 cap, bool notify)
    • recipient = New deployed instance of BasicRewardsForwarder as specified above
    • uint8 cap = 0 uncapped (only used for MTA staking contracts to cap)
    • notify = true will call the function to notify and process the MTA rewards upon disperse

One open point is the contract address for endRecipient. This contract is yet to be deployed by Idle finance.


Thanks a lot, @dimsome for the writing and this great summary of the RFC
I’m highly in favour of this MCCP, reflecting a thorough and incentives-aligned process with Idle Finance


This proposal was amended in the following way:

  • added endRecipient address
  • added description to what happens after the rewardsForwarder adds the rewards
1 Like

Proposal is live on Snapshot

1 Like

I’m happy to see mStable governance approving the Snapshot, enabling mUSD liquidity providers to benefit from MTA rewards!

With the launch of IDLE Gauges, we’ve designed a new staking contract that accepts deposits using the mUSDcrv Gauge LP token.
By routing the MTA stream on top of the IDLE Gauges (instead of having 2 parallel streams), we would improve composability and let liquidity providers receive multiple layers of incentives (underlying yield + IDLE + MTA).

With this post, we propose to replace the old recipient of the Dial with the new address 0x7f366a2b4c4380fd9746cf10b4ded562c890b0b1

1 Like

On my opinion, since only the smart contract recipient changed, I don’t think we need to be going through governance again here and should be able to create a PR to have this changed in MCCP 18 instead of needing to go through the whole process again.

Would be great to get a few Yae’s to support Davide’s proposed change regardless. If anyone has any strong feelings around this, we’ll need to go through governance via an addendum to MCCP 18 I think :sweat_smile:

1 Like

I assume the workflow remains the same? Emissions Controller sends the MTA weekly to that address and then you would call the method account for these from the multisig?

I think this is such a minor change, materially nothing changes in the proposal. While we should be careful with governance, this does not mean we cannot be adaptive to new situations. So in this case, we could just accept the change as is without any votes? Any other opinions on this?


Go ahead and run it through IMO. Anyone concerned can see the requested change and that it happened in the open.


Correct, the flow is the same.

1 Like

Seems that there are no issues with just amending the address.

The proposal was amended in the following way:

  • Changed endRecipient = 0x7f366a2b4c4380fd9746cf10b4ded562c890b0b1