YAM Roadmap - From YAM’s Contributors

The below is a roadmap broken out into each of the four key areas of the protocol: protocol, treasury, ecosystem/community, and organization. No specific timelines are attached, as the protocol is in its infancy and critical issues may shift. It is ultimately up to the community to decide whether to follow these initiatives, in what order to enact them, and whether to create new initiatives.

This document is to showcase what the current YAM Contributors are working on. If you would like to contribute, propose new initiatives, or otherwise weigh in, please join the discord or visit the forum.


  • LP Governance
    • Status: Code in Development
    • Priority: High
    • Summary: Currently only YAM tokens held in a wallet are available for governance participation, which means LPs cannot vote in on-chain proposals. We are working on a solution to allow both YAM holders and LP providers who stake in the incentives contract to participate in governance.
    • Next steps:
      • Complete code production and have core contributors review
      • Propose solution via governance
      • Receive audit
      • On-chain proposal and execution
  • Treasury Purchase Asset + Treasury wrap yUSD
    • Status: Concepting
    • Priority: High
    • Summary: Utilizing yUSD as the treasury purchase asset requires significant liquidity incentives due to its limited usage. Pairing with a more common asset would likely lead to deeper organic liquidity, and provide additional flexibility after the treasury purchase. The protocol could then wrap its own yUSD following purchase and/or diversify into other strategies and assets.
    • Next steps:
      • Gather community feedback and develop consensus around switching the purchase asset
      • Develop code
      • Audit
      • Governance process
  • Liquidity Incentives
    • Status: Dependent on other proposals
    • Priority: Medium
    • Summary: If our treasury purchase asset changes, we will need to re-evaluate the current liquidity incentives to ensure we are not overpaying for liquidity.
    • Next steps:
      • Determine treasury asset purchase modifications (if any)
      • Run week long liquidity test on new asset liquidity
      • Analyze market depth and estimate liquidity needs
      • Community feedback
      • Governance and code development
  • RageQuit
    • Status: Concepting
    • Priority: Low
    • Summary: The RageQuit function (named originally by MolochDAO) would allow YAM holders to redeem some pro rata portion of the treasury. This would create a hard price floor for YAM based on the treasury, as an arbitrage would exist if the treasury ever exceeded market cap. Several adjustments to the basic mechanism have been proposed to align incentives towards desired actions. At current market cap and treasury value, RageQuit is not economically rational, leading to its current low priority.
    • Next steps:
      • Continue developing concept with community
      • Track treasury and market cap, as priority increases as they approach equal value


  • Diversify treasury for sustainability/reduce tail risk
    • Status: Concepting
    • Priority: High
    • Summary: While it is tempting to chase the highest yield, the YAM community needs to think carefully of risk, specifically tail-risk, in the assets it holds in the treasury. In our current 100% allocation to yUSD, we are subject to DAI, USDT, USDC, and TUSD risk, yCRV smart contract risk, and yCRV Yearn Vault smart contract risk. The treasury drives most, if not all, the value of the protocol; ensuring no single tail risk can destroy the protocol should be a high priority. Once we have diversified our exposure, we can focus on optimizing risk-adjusted returns.
    • Next steps:
      • Determine diversification strategy
      • Develop with community
      • Governance and code development
  • Bug/Hack Protection Protocol
    • Status: Code Development
    • Priority: Medium/High
    • Summary: The community has been developing a protection protocol in which underwriters receive a share of all later premiums. The mechanism allows for a bootstrapping period to seed a strong initial protection pool, which will allow later protection buyers to access deep and affordable coverage.
    • Next steps:
      • Continue code development
      • Trial system on testnet
      • Forum discussion and off-chain proposal
      • Security Audit
      • Potential Economic Audit
      • On-chain proposal and execution

Ecosystem and Community:

  • Governance UI
    • Status: Complete
    • Priority: NA
    • Summary: YAM holders need a governance UI to track and vote on on-chain governance proposals.
    • Next steps:
      • Complete interface
      • Test
      • Deploy to production
  • Documentation
    • Status: Near Completion
    • Priority: High
    • Summary: While many high level overviews of the Yam protocol’s functionality exists, there is little information easily available for those who want to go deeper. Documentation would help solve this issue.
    • Next steps:
      • Complete Documentation draft
      • Receive feedback
      • Deploy to website
      • Iterate based on feedback
  • Mission, Vision, Values
    • Status: Concepting
    • Priority: Medium
    • Summary: Due to the unique launch and history of the Yam protocol, there has been little work done to clarify the mission and values of the protocol. In order to attract community members aligned with Yam, we must define a vision for the protocol. This is all the more important as the wave of food coins inspired by YAM exemplified opportunistic tendencies, often acted as pump and dumps, and generally were not well-received by the community. YAM has been different in its orientation, community, and actions since the beginning, and that needs to be made clear to the DeFi community.
    • Next Steps:
      • Analyze history and community of Yam
      • Determine key narratives
      • Publish a manifesto detailing the vision of Yam and its core values
  • Weekly Governance Calls
    • Status: Concepting
    • Priority: Low
    • Summary: Weekly governance calls are fairly industry standard and will allow for deeper engagement, discussion, and community input on important issues.
    • Next steps:
      • Determine a time that works best for our global community
      • Create infrastructure for publication of call recording
      • Designate a “Call Leader” who can help organize, create agendas, and disseminate write-ups


  • Compensate protocol and ecosystem contributors
    • Status: Concepting
    • Priority: High
    • Summary: The YAM community has established a history of retroactively compensating its community members, and this should extend to those who have contributed much of their time and effort over the past months. This would be a one-time payment that could set a potential structure to be iterated upon in the future.
    • Next steps:
      • Develop compensation plan for protocol and ecosystem contributors’ work thus far
      • Forum discussion
      • Off-chain proposal
      • On-chain proposal and execution
  • Hire full time contributors
    • Status: Concepting
    • Priority: Low
    • Summary: While full-time contributors are necessary for the long-term success of the protocol, there are various legal considerations to account for when developing a structure. Rather than rush this process, we should get a full understanding of how to best compensate on-going contributors from both an incentive structure and legal perspective. Community members are clearly willing to work without on-going compensation currently, and by retroactively compensating contributors according to the above, a precedent is set to let them know they will be appropriately compensated.
    • Next steps:
      • Understand legal considerations
      • Develop long-term aligned incentives
      • Forum discussion and Off-chain proposal
      • On-chain proposal and execution

Potential Order of Operations:

The below is a potential order of operations given the above objectives. Some of these will be developed simultaneously, and the below order may differ significantly based on community input and desire.

  • Documentation
  • LP Governance / Treasury purchase asset / LP Incentives
  • Compensate Contributors
  • Mission, Vision, Values
  • Weekly Governance Calls
  • Diversify treasury
  • Protection Protocol
  • RageQuit functionality
  • Full-time, on-going contributors

Hi ,once the treasure hold 2.7m yusd , Can we modify the treasure system? We can set a market cap goal for yam,such as 1 billion yusd. When the market cap is lower than that treasure just holding the yam produce by rebase ,instead of selling them. When the market cap is higher than the goal the treasure selling the yam gradually.

Some one may ask that what the usage of yam holing by treasure is. At one hand ,I think it can decrease the selling pressures .Another ,if the treasure won’t hold yam ,it indicates that the treasure suspect the value or the future of yam ,since why will the community members hold yam? This will decrease the community.


Amazing roadmap, excellent work :]

To supplement my reply in the tread on mission statement:

Utility/use case of the token matters. Altough it is much appreciated that dev team has put together this detailed and well organized roadmap, there is not one single mention on what exact issues or goals the project aims to solve or achieve. This seems to suggest that the token has no use, no purpose per se, and hence no value.

Issues like LP incentives and team incentives are important, but the actual commercial roadmap is much much more important.

For one thing, the price movement clearly shows that the market has difficulty in valuing the project. What is the project planning to do, and when? Even if the potential use case takes years to develop, at least the market can have something to imagine on and provide a valuation (perhaps based on hype but still better than nothing). Under the current state, there is no information available for investors to assess the project, hence the free fall of price.

Second, it is naive to assume that price actions wouldn’t affect the project. One instant negative is that as soon as the ragequit function becomes available, a large percent of holders will rush out of the door and significantly reduce the treasury size.

Third, it will be difficult for the community to approve any incentive plan, since it is hard to see the potential value the dev can deliver. It will not only be a death spiral of prices, but also a death spiral of community participation. People getting hurt by the price drop will blame the dev team, and refuse to approve any incentive; dev team will lack incentive and be disbanded, further delaying the development.

Even if the toke holders want to save the project, without a clear valuation of the token, they will have a hard time to determine how the incentives should be calculated and arranged. Then the easiest thing would be not to vote at all or reject any proposal.

To summarize, team needs to be aware of the risks of lacking a realistric goal for the project. Like I said in the other post, experiements are good, as long as there is a clear goal. Otherwise, Yam is no different than other fruit coin, regardless of if it being the first one.

I will try to make proposals on possible future uses for Yam in the next a few days, but we also need help to put together and organize the ideas of all the people.

I think you missed this. This alone is enough to base a project on. Still there are other concepts and endeavors being worked on.

I look forward to your proposals.

Thanks for pointing this out. I did miss this - this looks to be an interesting idea, but there is too little information about it. I don’t think majority of the community, not to mention the industry and the public is even aware that Yam team is working on this, and there is no verification of feasibility, potential market size, or profitability outlook on this, which is necessary for any financial or commercial project.

I will write up something around this idea for people to discuss more about this.

Here is a deeper write up on this as well: RFF: Revised Yam Bug/Hack Protection Protocol