Yam Core Development

Product
#1

Sirs, ladies and gents, this post is for upcoming work establishment and improvements to the yam protocol, it consists of developments, deployments, maintenance and related operations at yam.

@e: I have been leading the work on a range of initiatives at yam for the past year from development planning to execution, code reviews, websites and smart contract developments, updates and deployments, building interfaces, tooling, organizing and operating engineering and service funds, reimbursements and contributors payouts, contributors onboarding and support, communications with partners and other parties, infrastructure stability and maintenance. With thanks to all the contributors that i have worked with, even with the challenges we had, we developed, experimented, learned and got to where we are at yam with your help and contributions, i hope you will continue contributing adding more value on yam in the future.

Currently there are multiple things i see the need to focus on for adding value to the success of yam on the top of the maintained stability we have as a protocol.

I will ensure and focus on the release of an upgraded yam core, additional protocol features, improvements and deployments after audits, new yam website with maintenance, new api releases and upgraded tooling, maintaining infrastructure, coordinating security and managing the mentioned points for the next year.

Protocol Mission

We want to get back the value that yam originally had on its launch, and surpass it bringing back community and a gradually increasing token holder base, adding multiple features beyond the current governance function to the yam protocol.

Yam DAO is a self governed community building integrated and novel DeFi products designed to grow the value of the Yam ecosystem. Empowered by shared economic incentives in pursuit of a decentralized self sovereign financial system for all.

Fast Forward, History and Future Goals

Yam started the “DeFi Summer” and its big wave, which many joined with yield farming but that’s not necessarily going in the same path as to what it offers, we still have the farming function but we have bigger goals. As we have experimented and discovered while building on multiple features and projects, the plan is to continue supporting good ideas, adding functionality and value to the token, to then distribute profits we are gaining to the token holders, getting yam into a wider range of audience, keeping everything fully governed and decentralized.

Planned Improvements

Development

  • Protocol Restructure: Contracts - Devdocs

    Description: The protocol had two migrations in the past as well for how its mechanism work, with then turning off the rebase, which plays a big part in the conversion of the numbers in the protocol, even though the core and governance has been maintained and secure to date, it was not very simple if you are a developer or an enthusiast to get yourself familiar with how everything work in accordance to each other, specially on a smart contract level and its little available documentation. That aside, everyone sees how many changes happened on defi in terms of scalability, in specific speaking about general layer 2 focuses and high gas prices on the ethereum mainnet, thats one of the things that can be dealt with. (Read more on Yam Multichain here)

    Plan: Reconstruct all existent, relevant and focus on creating new contracts, with what i have started working with here. Contracts are undergoing major changes, while it will still essentially work to what we have currently related to governance. Major changes will include Governance upgrade, Token upgrade with delegation, Multichain implementation (to Optimism, Arbitrum and other chains), Protocol bridges (network specific), Treasury upgrade, Proxy modular functionality controlled by governance and a migrator. Audited and open source contracts libraries will be used, for example to Compound and OpenZeppelin, with more to be considered moving forward.

    Features remaining with the new deployment:

    • Governance and voting token.
    • Token holders controlled treasury.

    Timeline:

    1. Development
    2. Development Testing
    3. Public Testing
    4. Audit and Selections
    5. Deployment
    6. Previous to New gov access
    7. Unlock Migrator, Migration Announcement, Migrate!
    8. Announcement
    9. Maintenance

  • Protocol Restructure: Website - Devdocs

    Description: The yam website will be the place to go to, for any user in need of information about yam as well to interact with the protocol, where they will have access of multiple pages for doing so.

    Plan: Website will include everything we have currently and more to fulfill the needs of the newly developed contracts and tools use. Consisting of an informational landing page, a governance page that will display the onchain proposals as well to the possibility to create a simple proposal if you have the minimum tokens, a treasury page that shows the different balances of tokens owned by the treasury with charts and related statistics, a user page to show what the user has of yam tokens or any other yam project tokens, and a farm page showing clearly what we have to interact with and the how-to for accessibility. It will undergo an upgrade as well to a restructure, using the tools that we have and will be building such as the yam sdk, subgraph and api.

    • Sitemap (Base)
      • Landing
      • Governance
        • Vote
      • Treasury
        • Statistics
      • Tools
      • Docs
    • Sitemap
      • Landing
      • Governance
        • Vote
        • Proposal
      • Treasury
        • Statistics
      • Farm
      • Projects
      • Tools
        • SDK
        • API
        • Subgraph
      • User
      • Docs

  • Yam SDK - Devdocs

    Description: The Yam SDK will be one of the tools used by multiple parties and dapps, its purpose is to make developers interact with yam easier. Main use will be on the yam website for features and interactions with smart contracts, and generally for any party interested in yam read/write data.

    Plan: SDK to include everything you need related to yam, yam smart contracts interactions, with further helper functions as well to wrappers related to yam projects. It will interact programmatically with off-chain and on-chain data, with different public and private APIs, smart contracts and other tools we are building such as the yam subgraph.

  • Yam API - Devdocs

    Description: The Yam API will help save and collect special data, having historical data as well to specific endpoints for different data collection related to yam. It will serve the website mainly and other 3rd party applications.

    Plan: Yam API will include different data endpoint groups, from: yam historical data, treasury data, a wrapper for yam smart contracts basic read functions, a section of helper endpoints and other needed relevant endpoints overtime. The API also aims to deliver data in a more decentralized way, and thats one of the things that will be the focus on to achieve.

  • Yam Subgraph - Devdocs

    Description: The Yam Subgraph will be used as a way to query what that the yam smart contracts entails with ease, it will be used for specific calls through the API, the SDK and other places as well to 3rd party applications. As described: where all data is stored and processed on open networks with verifiable integrity, the yam subgraph will makes querying its data fast, reliable, and secure.

    Plan: Yam Subgraph will cover the yam smart contracts read functions and events, with additional interesting data for collection, such as user, token and governance data relations.

See development documents for further information.

Deployment

Contracts: Working with bleeding edge technology with some material that auditors have no yet full reach on, will require a good amount of testing pre and post audits making sure everything is fully functional before moving into production, once the development is finished with major testing coverage, deployed and tested on test networks, we will move into next phase deploying on the main networks, such as Ethereum Mainnet, Optimism, Arbitrum, Polygon or other, this will be voted on.

Website: After development finalization, deployment will be split into 2 phases (except to small changes or critical bug fixes). The phases are testing build and live build, the testing build will undergo tests from the community and anyone interested, making sure everything is working, then it will be deployed live. As well on each deployment prepared automated tests will make sure things are working perfectly.

SDK, API, Subgraph: Having as much test coverage as possible. Will also be split into 2 phases, with automated tests running pre live deployments and releases approvals.

Security

Governance:

  • Current: Governance is in good stand, guardian is set in place to protect against any malicious attacks. Moving into the future: a process and a proposal that will outline different options to be chosen from, will be written and decided upon to how we will migrate this on release of the contracts upgrades.
  • Multichain: Each network will have a signing mechanism that will be required to always be signed for the network governance to work and be included, this will act as another layer of protection to block wider range of malicious attacks against the protocol.
    • Guardian will also be able to decline any cross networks malicious actions.

Bug Bounties: A security document of which the critical bugs will fall under, will be posted in the near future, and will include a section detailing what is covered and what the bug bounties to be valued at. A proposal will also be written and proposed for signaling on snapshot to confirm the numbers and final details.

Maintenance

Maintaining code and bug fixing is key for a better product, that will be focused on as well to having the website, api, code, tooling and everything else we develop, working as described in its own repos, for things to be online and serving the users. Target is to maintain stability. Development will go through updates and bug fixes with additional features support and changes that we see fit to make products better. Documentation is also to always be maintained.

Contributors

  • Currently working with 6+ developers and 2 designers that i am planning to hire, as well to more devs and relevant contributors in Q4 of this year.
  • Additionally bounty based work tasks are posted with more to come.

Timeline

Q3 2022

Public

  • Upgraded Yam Contracts
  • Yam Protocol: Multichain Governance (Alpha)
  • Yam Slick New Website (Static)

Work In Progress

  • Contracts: Upgraded Contracts, Basic Multichain Governance
  • Websites: Website Design, Website Base, Partial Network Connections, Partial SDK and API Integrations
  • Infrastructure: SDK API Subgraph Base Structure, SDK Testnet Contracts Connection, SDK Basic Subgraph Integration, API Partial Endpoints Connections

Q4 2022

Public

  • Yam Protocol: Multichain Governance (Testing)
  • Yam Slick New Website (Testing)
  • Website Proposal Page (Current Interact)
  • New Tooling: SDK
  • Snapshot: Signaling for L2 Networks

Work In Progress

  • Contracts: Multichain Governance, Testnet Deployments and Interactions
  • Websites: Website Static Interactions, Proposal Page Design, User Page Design, Network Connections, SDK and API Integrations
  • Infrastructure: SDK and API Website Integration, Contracts Coverage, Fallbacks Subgraph Integration, Partial Test Coverage, Partial Developer Docs, API Security, Subgraph API Integration, Partial Test Coverage, Partial Developer Docs

Q1 2023

Public

  • Contracts Audits
  • Launch Potential
  • Yam Protocol: Multichain Governance (Mainnet, Multichain)
  • Yam Slick New Website (Multichain)
  • New Tooling: API, Subgraph
  • Snapshot: First Secondary Network
  • Snapshot: Bug Bounty

Work In Progress

  • Contracts: Audit Contracts, Audit Corrections and Testing, Partial Developer Docs
  • Websites: Manual Testing, Updates, Partial User Docs
  • Infrastructure: SDK Manual Testing, Automation, Tests Coverage, Developer Docs, API Partial Test Coverage, Partial Developer Docs, Subgraph Automation, Tests Coverage, Developer Docs

Q2 2023

Public

  • Snapshot: Second Secondary Network

Work In Progress

  • Contracts: More Explorations, Developer Docs
  • Websites: User Onboarding, Projects Page Design, Developer Docs
  • Infrastructure: SDK Projects Structure, Linked Distribution Assistance, API Data Decentralization, Manual Testing, Tests Coverage, Developer Docs, Subgraph Maintenance, Updates

Q3 2023

Public

  • Advanced Planning

Work In Progress

  • Contracts: Maintenance, Accounting for Updates
  • Websites: Maintenance, Accounting for Updates
  • Infrastructure: Maintenance, Accounting for Updates

Notes

  • Relevant snapshot proposals will be created every time we need further vote and signaling.
  • Everything mentioned here is to be achieved and already in progress under development, although keep in mind some things can probably change or be different as we progress more into the future. Such will reflect changes on the development documents and in the documentation of the repositories related.

:heart::ocean::sweet_potato:

Looking forward and very excited for stable, secure, modular and solid standing structure of a core with fine contracts, websites and tools, to lead by example as what always yam was to other DAOs projects, and for anyone else interested with starting their own!

See you on other chains.

E.

Yam Protocol Multichain
2022-05 - E Monthly transparency report
2022-05 - E Monthly transparency report
YAM ReOrg 3 month Grant Request (June-August)
E Contributor Comp
#2

Please note, timelines are yet to be finalized and will be ready shortly

#3

In order to fully evaluate your proposal some sort of schedule of approximate cost and time would be necessary. This is obviously a large endeavor where depending on the cost benefit and time required to complete it might make sense allocate resources to highest priority.

ie. IMHO going multichain unless the cost was minimal is not of high priority.

ps. Some of your links are broken.

#4

This one year development plan appears very comprehensive.

In addition to the question by Feddas about costs, I also want to see the ongoing maintenance work broke out separately from project based tasks.

For instance the projects like New Website would be best broke out into individual projects. Each with its own scope of work, schedule, costs and requirements – and then each put up for vote separately.

There is the question of who will be doing this work and who will be contributing to this work from other silos if any. For instance, will you being doing all the work, doing some of the work, or farming it all out. If it’s farmed out, how does that arrangement work, who are these new devs and how can token holders be assured that there won’t be an attack such as happened once in the past.

In other words, there is a lot of work and projects being defined here and some is of much higher priority than others. I feel it serves the DAO and token holders to have this work prioritized and separated into individual projects.

#5

I am trying to parse out the problems that are being solved by some of these solutions and I am having trouble doing so for some. I agree with @designer that each piece needs to be more completely and individually scoped, explaining what the problem to be solved is, how exactly it will be solved, and what solving it means for end users, and who those end users are.

Broken link. Should it be https://github.com/ethedev/yam-dev-docs/blob/master/yam-contracts.md?

I support many of these ideas in principle, but In its current form this is just a list of “cool things we should do.” Each of these elements needs to be evaluated separately and better specified.

  • What are the goals of a governance upgrade? What will the benefits be?
  • Our token already has delegation. What we really need is a token downgrade to remove all the un-used rebasing logic.
  • I don’t support your framing of “multi-chain” as the only “product” we currently have is the DAO itself and in order to run it, we only need to governance contracts and treasury to live on one chain. Determining if we should migrate either or both to a L2 is an important question, but we don’t need to start spending time building bridges to chains we won’t use. This is a solution looking for a problem.
  • Why does the treasury need to be upgraded? It seems to be a perfectly usable contract. Moving it to a L2 is a separate question.

Generally I agree with the idea that we need to clean up our messy and bloated contracts and I would support funding work to do so. But it needs to be scoped and specified and we don’t need multi-chain bridges to nowhere.

We have had discussions before about making a new website and even had designs and copy done for it by @blokku-chan and @designer but the decision was made to hold off on building anything new until we figured out wtf YAM is and how it works. Assuming that people accept the Re-Org changes that Designer and I are proposing, then we may finally be at a point where we can start updating and upgrading the website. But I strongly believe that a “new website” is not necessary or a good use of time and resources. We just need to fix and upgrade our current one (which I have been trying to do as an opportunity to learn react, and will continue to do).

Most of the structure that you lay out already exists in the current site, so why are we reinventing the wheel?

The actual scope of work as I understand it is to add the following pages:

  • Tools

    • API: Just data display? What data?
    • SDK: Links to the repo and docs?
    • Subgraph querying functionality within the site? Why not just link to the graph subgraph page as an MVP. The real work seems to be the actual implementation of the subgraph.

  • User (although this information is already available by clicking on your wallet address. So I don’t understand what the work here is.)

    image

Like with the governance contracts, I also agree that upgrading the website is an important task. But it needs to be scoped, specified, and approved. The fact that it has been sitting in a broken state for the last year is a red flag for me, and I don’t understand why none of the easy fixes have even been attempted. Why should anyone expect that the new website will work better than the old website when we can’t even fix the old one?

This mentions that the subgraph will be used by the SDK and APIs to get YAM contract data. Does that mean that this needs to be worked on before the other 2? We already have a YAM SDK and existing API endpoints that are supposed to do many of the things listed. Is the “more decentralized way to deliver data” is via a subgraph? What data points are going to be provided? Who will use them and why?

In reference to the SDK, Please provide more information on what “everything you need” is. What helper functions? How will they help and what will they allow different types of users to do that they cannot do now? how is this different from the SDK that exists in the current yam-www repo? yam-www/src/yam-sdk at master · yam-finance/yam-www · GitHub. Who will use this and why?

Another reason why this multi-chain endeavor is risky (and in my opinion a bad idea). It add significant new attack surfaces to everything we do. It requires that we understand the security parameters of each chain individually and monitor them. Not to mention that other chains may have subtle breaking features that cause unexpected problems. See the Agave and Hundred Finance re-entrancy exploits that occurred on gnosisChain due to insecure implementations of bridged tokens that went unnoticed. The more chains and bridged tokens, the larger the surface area for problems like this.

No amount of bug bounties shrinks this potential problem.

Not sure why you are working with 6 devs already without mentioning it to anyone. If you don’t get this pre-approved you may not get approval for payments when you ask for it. If that is a risk you want to take fine. But I wouldn’t do it.

Regarding your timeline, it seems like you are proposing to do everything simultaneously. I highly recommend against this and we have seen in the past what has happened when we have done that. Look at the trail of half finished projects that the DAO has in its wake. We need to prove we can finish one thing before trying to do 5. Focus on getting one thing done at a time. Get it done well and in order or importance.

If the contracts are important, then let’s focus on those. The existing website can get updated as needed with new information and when the contracts are done, then the new website gets focused on.

I support funding well scoped and planned projects. But this is about 5 different projects, and none of them are clearly scoped or specified. So until they are I recommend taking a step back and determining what the problems that we most need to solve and focus on the parts of this proposal that do that the best.

#6

Thank you everybody for your input and feedback! I will expand on the plan above so everyone can understand it in full with my general perspective then ill be addressing other technical details related to your comments.

The Plan: The initial plan from all this is very simple: having a full fledged development team behind yam to be moving it forward, expanding it to a wider user reach. As i have mentioned previously i believe and see a huge potential for yam, comparing it with really interesting protocols we all know of such as Aave, Uniswap, Compound, Optimism…,. Here what i see yam is “The perfect example DAO for DAOs” (ill explain that more below). What i have in mind and trying to build is not just a feature such as “multichain” for all values to go under, even while a feature like that is extremely great to have, the idea is way beyond that. Whole new code base from scratch with a set of interesting features that has builders focusing on its daily advancements and being there for further integrations, features, maintenance, security and stability.

The perfect example DAO for DAOs: In “History and Future Goals” i wrote about how things started, and remembering how yam was an example for people that they have forked so many times. Here is one piece of the puzzle that i am trying to work towards. Yam must have the level of core it should have, in terms of base, code quality, documentation, functionalities, integrations and tooling, with full clarification to how things work. That is a huge yet very essential for the future of Yam, specially long term for any partner or developer who will want to work on or integrate with us, it will be inviting for them not otherwise. People will again notice the great “Yam”.

Thats what i believe is of highest priority “the core”. Specially as we live in DeFi!
It is a key piece in what needs to be achieved for bringing back token holders and community.

Original schedule outlined as follows:

  • Starting from July-August (once plan milestones scopes ready).
  • Development for 1.25 years (5 quarters) with further planning and maintenance coverage.
  • Myself and multiple developers with different focuses: 3-4 contracts, 2-3 backend and 2-3 frontend (eventually team of 8-9~).
  • Capital of $1.1Mil (accounting for: Contracts audits (150k~) and one fail safe quarter).
  • Timeline of milestones to accomplish detailed above in high level (still working on it).
  • Visuals of timeline for the community to see as the progress is ongoing.

Model changes with a new schedule:
Even while i would really like for yam to have at least 8+ developers working on the core all together, i can see the time for this coming at a later stage. Since we are in a bear market, and i got few signals from different token holders/investors, to focus on initial parts to minimize the cost and try scaling down the time needed for delivery, my plan schedule changed and i am working on a different model, where it will requires me to work directly within different repos and things will be worked on as one previous finishes, so not in parallel, which was not of my main intention but rather firmly reviewing/directing developers and for myself to be focusing heavily on the contracts, security and network integrations.

The different model will require me to put more work hours and reduce substantially the developer hires.

But i am up for the challenge.

Currently in process of reworking the original schedule and will be posting it shortly. I am also working on the milestones and scope of work entailed, it will be on github.

Thank you again, i appreciate your support.

#7

thank you, taking all that into account and working on finalizing it accordingly, ill mention you once its ready and for the multichain (which is one of the multi-planned features) will be expanding more at Yam Protocol Multichain

thank you, are you referring to the “Maintenance” section or the maintenance within the quarter? the maintenance specified in the last quarter is related to any fail safe time, the one mentioned in its own section is more related to bug fixes, changes and adjustments, that is accounted for within the development time, so for answering your question normally these specific tasks will be spotted at the time and worked on accordingly.

yes everything will be fully scoped, but it will all fall under this core development plan, please check what i just added above

yes, i will be doing the work and will be responsible of removing any contributor that does anything wrong, also i have always done so im going to still be reviewing everything submitted by all contributors that im working with, for your other question regarding individuals with ongoing proposals focusing on their stuff, which can cross involve one of the points i am covering, we will collaborate on it together, lets say there is a faq page and you are working on the copy, and we need to have it on the website we will co-work on having it ready in a timely manner according to when we need it delivered by

yes agreed, thats what will come from me finalizing the updated milestones and new schedule!

thank you, yes thats what im working on now and please check what i added above to have an idea of what i want to achieve, also as i just added stay put for the timeline and schedule update

the new website is completely different code base from what you see there, its all from scratch, and it will be linked to the new contracts/sdk, itll still have the pages i mentioned about above to extra stuff

these pages are nothing of what you listed, there will just be links to docs and yes to the subgraph page itself

good question and no it was to be made in parallel to be tested and interact with the new contracts, but now that will be changed and you will be able to see this shortly on the updated milestones

the thing you see there isnt an sdk its just a file with helper functions, this will be scrapped and created fully from scratch, it will focus on delivering interactions to the new yam contracts mainly for the yam website as well for any other party that needs to interact with yam contracts

i hear your concerns but that is no excuse to not be on other chains, all the contracts will be audited and any network from the first will be chosen by the community through voting, also i have planned out all the security measures for the non mainnet networks, there going to be a whole structure in place to protect each network and specially the connections of the networks with each other, also please see Security>Governance>Multichain section (im going to further cover how everything will work simultaneously security wise)

i remember mentioning it already in the past weeks, and its more the onboarding/preparation for work commencing

yes correct (while it works as long as each individual focuses on their parts), that was the on previous model of schedule and planned timeline, however on the new model these will change and will be more of what you expressed in liking!