E Yam Core Development - Phase #2 (Aug Sep)


This proposal is to approve for E to continue on the developments priorities as mentioned on the core development plan.


@e: While planning out the roadmap for the upcoming stage and finalizing it with elements described at the Yam Core Development, currently i continue to focus on whats left from the top most priorities previously posted on Stage A. phase #2 for august and september, to then start on phase #3 and Stage B. afterwards.

  • Goals:
    • Yam token avg value section on the website.
    • Updated token delegation section on the website.
    • Create the Yam SDK base and begin website integration.
    • Improved proposals load time.
    • Finalize sdk integration and add basic testing.
    • Updated user page.
    • Collect feedback for potential bugfixes.
  • Comp: E fulltime monthly comp of $10k split 80% in USDC and 20% in YAM tokens vested over 6 months, based on the 30 day avg value.


Proceeding with onchain proposals to send the related comps as specified above.

Probably an obvious question, but does “Aug Sep” mean “August and September”, so 2 months? So this is for the work done in August and to be done in September? And this is a grant proposal, right?

If this is a grant proposal, please specify that. We are trying to make this process uniform among all contributors. I understand that there are still lots of parts that are unclear, but I ask that you try to follow that process and if you don’t think it works or have questions then please bring that up.

I am still unclear about the specification for much of this work and for some it requires looking through multiple forum threads to find any information.

I know you answered what this is in another thread, but it needs to live in an actual specification (or at the very least in one place).

Is this separate dashboard section on the main treasury page or a new page? Is it going to store the last X months of price data so we can determine how much to pay if a request is made for payment over a few months?

same exact comment as above.In the same thread linked above you wrote:

I still think token holders need a more complete description of what the SDK entails, how you expect it to be used, who will use it, etc. Right now your description basically says “clean up some code, add some code for developers to use.” This needs more specificity for me to support it.

What is the User page? Who are the users? What does this page do? Are you going to do any mock-ups?

Is this an active thing or are we just hoping that someone else will provide feedback? I’m hopeful that someone will give me feedback on my golf swing, but if all I do is go to the driving range it won’t help much. The only way to do that is to seek it out. How are you seeking out feedback on bugs?

It was my understanding that grant payments are capped at 70% stables with 30% vested YAM. This is what we have been talking about for a while now. Is that no longer acceptable in your mind?

Thank you for your comments.

Yes, August and September.

This is not yet a grant, but will get there around Phase #3.

It is a separate page, where we will maintain the yam price values and yes it will serve to easily and instantly pick up what we use for the 30 day average. Please take a look over here YAM Finance of the very first card.

It goes without saying what an SDK is, in my previous comment i explained further what its uses are. And i believe to have added what it entails in the SDK document, i updated it recently again with more details.

A software development kit (SDK) is a collection of software development tools in one installable package. They facilitate the creation of applications by having a compiler, debugger and sometimes a software framework

And correct its for developers to use, the updated full information is on the SDK document.

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 and yam smart contracts interactions as in read/write functions existent on the yam developed contracts, 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 (data and price fetching), smart contracts and other tools we are building such as the Yam API and Subgraph.

Alongside to what i said previously:
The SDK will play a role in several places, it will be a stable source of code for the yam governance contracts interactions, cleans up half the code from the website and helps with faster load time through navigation for token holders and anyone using the website, initially it will be first used within the yam website on action pages (delegation, voting, etc.). On completion developer docs will be available for developers to further integrate and interact with Yam on their dapps.

A place where the users will be able to see everything that they have on yam related to their accounts, the current popup will mainly be refactored into the page, it will be straight forward for the users to get linked to, will have general actions related to the user account such as registration, delegation and voting power for the moment. In the future it will be updated to include what more we think useful for the users, such as claim buttons other special notifications and more, think of it being a small dashboard to simplify everything for the user. And by users i mean token holders. Im going to develop it directly on the website, but i can also do a mockup and we can do a quick feedback collection over it.

Active thing. As ive done and always do for anything in the last stages of development, it gets posted on discord for a wide range of people to test it, and i believe you tested it after i announced with the mention.

So you can post on the chat for example and ill take a look over it, for bugs providing how it can be reproduced so i get to the bug to be able to fix it, and you can also post suggestions and value add ideas, very much like youve done, anything valuable is going to be implemented, once im finished with the main part of the development.

My comp is split on to govops/infrastructure as well, the total at the end of my yam comp is going to be much higher than 30%, its about 43% in yam which i picked and am good with.

Administrative stuff first:

You are the only contributor who has not moved their compensation into the grants model. What is preventing this from becoming a grant?

Not sure I agree with the logic here as it seems like it breaks the spirit of gov-ops being all YAM and other compensation (grants) being 70/30. But I am interested in getting some other opinions and have posted on the discord to have a discussion about it. Discord

Content Stuff

I understand what an SDK is. But I don’t understand what your SDK does to make development on YAM easier. I have forked your SDK document so I can comment on it in hackmd. Here is the link with questions: yam-dev-docs/yam-sdk.md at master · ethedev/yam-dev-docs · GitHub

Help me understand.

Ok, this is helpful. Not sure it needs to be a separate page though. These cards could live with the treasury cards at the top of the dashboard page (3x2 grid). We should also store some # of months of the YAM avg. prices into the past so that if someone asks a grant payout from a few month period they can find the prices and do the math themselves.

I’m not convinced this is useful right now. There are a very limited set of actions that token holders need on the site and they aren’t really spread all over. If all the governance info (delegation, voting power, etc) lives on the governance page, and farming stuff can all live on the farm page, what else do we need? Wont we now just have 2 places for all this info? I would push to get the existing pages as well designed and effective as possible and then maybe update the wallet modal if we have other needs.

E. I am at a loss for words… I told you multiple times that I will NOT be supporting any more of your request for compensations without a clear proposal BEFORE the work is done. You again are requesting payment for work done in August on Aug 29th. You have been a FULL TIME contributor and paid as such since the beginning there is no excuse and you will be responsible to the token holders.


Everything we do now, we need to ask ourselves, Who will utilize this? Will it add Value (token/treasury)? Is it moving the needle for the project? A “Must Have” or a “Nice to Have”?

Most of the proposed I think falls into the “Nice to Have” category, and who will utilize it is a huge question.

I am not in support of the comp request. Even if I was in support of the work, which I am not.

Let’s really dial back the busy work guys. Add value or stop wasting time. This is not an attack on anyone in specific because everyone is guilty. It’s a lean survival and predatory mentality necessary to allow Yam to persist through winter and be ready and able to gorge come spring. We know these cycles well, only the smart survive. We are not being smart, but rather wasteful and shortsighted.

Thank you for your comments, addressing each below.

@feddas im not sure what you mean, but reading your comment it sounds as if we had no meetings this month nor discussions (1), nor have i wrote a whole plan regarding the developments of yam and moving things forward (2) when in specific i took your suggestions into consideration updating the plan adding them in my top most priorities, phase #1 and #2 are entirely about it, pushing the very things that im interested to work on for the next stage, things that will bring tremendous value to yam (3).

  1. Where i mentioned a couple of times whats in progress (new pages for delegation and price, and the yam sdk) with what you will be able to test once it gets ready as i posted few days ago.
  2. ycore/development.md at master · ethedev/ycore · GitHub
  3. Having a fully stable ecosystem, the dao that will lead by example, not a mixed spaghetti code with unclear functionality.

Basically doing what you suggested and requested, im pushing your view forward, and now here i see you are opposing it, maybe i should be at loss for words.

Whats that supposed to mean? i told you from the start i am ok with this model but we shouldnt put restrictions nor limit ourselves with such. And, prioritizing these fixes are the priority, or is it not? really focusing on dev work instead of writing redundant proposals each month and wasting so much time, specially for something we agree on and talked about on the meetings. Yet here it is, posted, as discussed.

@jpgs.eth In full agreement with you, yet i dont see what are we misaligned on.

Originally the plan was one connected piece. Then after feedback from the team and community, as i mentioned to feddas it was adjusted and split into multiple parts adding priorities, mostly things that are almost always used by the people involved with yam, old and new yam token holders.

I think otherwise.

Happily answering what youre wondering about:

(in specific related to the “Phase #2” developments)

  • Who will utilize this?
    Token holders, and new people that would want to check what yam is or even start interact with it, we need to be welcoming.
  • Will it add Value (token/treasury)?
    It does add value for the token, the use of the token (accessibility), and adds value to the treasury in terms of actively supporting the protocol, building features and adjustments that are valuable for its potential to grow. (i will be posting about that more later on)
  • Is it moving the needle for the project? A “Must Have” or a “Nice to Have”?
    Yam doesnt have a clean codebase (1), accessibility is very limited (2), potential for features are also capped with what we have (3). “Stage A” solves the current accessibility and sets us in a temporary stable place with what we have, to be able to work with “what we have” for new people to interact with onchain functionality easily. Everything in the phase #2 is related and needed, then comes “Stage B” to move us beyond that, opening doors for great awesome stuff.
  1. A part of this is getting solved once the sdk v0.1a will be released, taking care of what we currently have of interactions. The other part is solidity which i wrote of and included on Stage B.
  2. Before august, anyone who wanted to delegate their yam or yam lp, wouldve had a hard time doing so or needed to access it through etherscan. Developed this month, it is accessible after its deployment. These things are important and i think we agree on that, please correct me if im wrong. Next (planned for Sep) is the user page, its going to hold also very important information, such things arent just nice to have but are must have. Thats “the” place to go to, for figuring out your yam stuff. If we dont provide that access to our users with ease, should we wait for Metamask, Etherscan or through other quirky methods for them to get to the bottom of it? i dont support so.
  3. That falls under “Stage B”, in short its hard to develop new things connected to yam, unless you are good enough figuring so many things out, and still whats there now isnt the best place to look at for code, this stage changes that completely, transforming what we have to another level.

Clarifying further for non technical people:

  • Yam token avg value section on the website.
    This page will help mostly with comp calculations (you can see it here, i still need to fix something on the api for it)
  • Updated token delegation section on the website.
    Delegation functionality, this is essential if you need to delegate to an address without going through so much. (its also available here now, deploying live the next week)
  • Create the Yam SDK base and begin website integration.
    Any interactions with the yam contracts is not easy not for users (since of the limited accessibility that we have which is getting changed now), nor for developers even if you are an expert frontend developer youll get stuck on things and it will take long for you to get anywhere. The Yam SDK will be the tool to use for any interactions with the contracts, for websites/apps/dapps. (If interested i can link you once published)
  • Improved proposals load time.
    Go here and youll understand, its to be fixed and thats one of the many things that the SDK will be solving.
  • Finalize sdk integration and add basic testing.
    Integrating the yam sdk into the yam website. Adding basic test coverage of what we have on the contracts for running it before deployments to make sure everything is functioning correctly.
  • Updated user page.
    As i mentioned above, it will be the place for token holders to easily access their relation with yam related information and some interactions.
  • Collect feedback for potential bugfixes.
    Fixing bugs in codes, to have a bug-free interaction experience for our token holders.

To conclude, i respect everyones view, my replies are there to clarify what someone may have missed, did not understand or not really familiar with, being outside of their scope and knowledge. I can understand that and dealing with it. In the same time, one should trust another, their skillset and their words of promises to advance otherwise it will be so difficult to do anything.

Lastly, id like to add that i agree on what @jpgs.eth once said about the forum being an echo chamber, i hope some day this will change, but i have no interest in writing walls of text or repetitively explaining some very basic things, thats been taking too much of my time and i see it extremely useless. Instead im still only really interested and excited in developing what i spent a fair amount of time planning for, and began on, the future of yam and roadmap.

For anything unclear please let me know, thank you.

In general I think it’s best practice in business world and DAO land to propose work for approval in advance. It streamlines things and prevents hard feelings about any miscommunication. Some of the work here I think definitely falls under the Gov Ops scope and should be billed accordingly. Just because something was discussed in a meeting and wasn’t objected to (if that is the case) doesn’t give implicit approval that the work won’t be questioned or rejected when requesting compensation after the fact. Let’s be super thoughtful and efficient about what work we are billing the token holders for and why. I appreciate the thought you have put into all this E and don’t want to discredit that work. You understand the modality we are in now and we need to adjust effectively.

Yam is a governance token that requires no interaction aside from voting and delegating. SDK and API is not at all useful to Yam. I have not and will not support any more time spent on building a SDK or API.

The only thing that is useful is the token delegation for LP and regular tokens, which has been requested many months ago and should have been completed well before.
Other than this, there is no problem to solve in respect to accessibility.

I would consider all of your solutions under “nice to have” and not necessary. There is nothing stopping people from “using” YAM and your solutions do not change that.


@jpgs.eth thank you for your comment, updated the report accordingly.

@feddas with all due respect, you have no idea of what youre talking about.

You listed only 2 functions from what you can do of interaction with yam, “voting” (you mean to vote) and “delegating” (you mean to delegate). There are plenty of more functions such as getting proposals, getting votes (not just voting), proposing, queuing, getting delegations (not just delegating), executing, getting actions of the proposal, getting the state, getting the receipt, and so on… i just listed a few things from what the interaction include. So please focus on what you know to do best and leave this for me to deal with.

Both are very useful for yam. Please read the docs of what the sdk does, giving huge access for us and for any developer to build applications and interact with yam easily, and for the api you already know what it does as i have explained it more than once before. Also youre saying that you have not supported this before (API), but you really did (and im not sure why you are saying such now, as i remember you requested from me and told me to finish on the priorities first then move on with what interest me, and thats exactly what i have done and am doing), otherwise we wouldnt have had such a nice dashboard powered by the yam api, both which i worked on to the smallest detail making sure it looks awesome.

Something nice to have isnt used in the very base of the project, both of these are very needed and are always used serving people the project itself…

There is a clear communication and knowledge problem here.

The person proposing the work (E) has an idea of the value and benefit of the work that he is doing. The people approving and funding the work do not understand the value and benefit of the work. This does not mean that the work is not valuable, just that there is a lack of understanding about how it is.

This is a problem that we have continually had at YAM. The developer wing of the DAO has not been able to communicate the value of the work they do to the non-developer side and the non-developer side has not put in the effort to understand it all on its own. Where the brunt of the blame falls in this problem is hard to say, but it exists on both sides.

The reality right now is that the token holders who are making funding decisions are mostly non-technical. That is just the way things are, and so the developers need to be able to sell their ideas to those token holders (or find others who understand what they are doing)

So saying things like “…please focus on what you know to do best and leave this for me to deal with.” is not going to help you here. You need to figure out how to make his understand what you are doing. You are starting to do that in the paragraphs above by actually explaining what it is that the things you are making do.

I have tried to be a bridge between the developer and non-developer sides of the DAO and it has not been easy. @ethe I have mentioned this before, but you are not good at expressing your ideas in a way that is easy to understand (especially for non-developers). Your SDK and API documents are unclear about what they will actually do, and not having public github repos for the SDK code isn’t helping you.

If someone doesn’t really understand how the project works, but they see that you are able to make it work fine then they won’t think that fixing it is necessary. It works! Your job is to show that it isn’t actually working well and explain how what you are proposing makes it better.

This is no different than anything else if life. If the wiring in your house is kind of crappy and sometimes your power shorts out or switches stop working, then you should probably fix it. But if it is just an inconvenience then it doesn’t stop you from living in the house. It is worth fixing, but if you don’t have the funds right now then it can wait. Now, if an electrician comes by and says “You are going to electrocute yourself and die one of these days if you don’t fix it” then you find the money to get it fixed.

So the question once again comes down to “what is the problem that we have?”, “How does this work solve that problem?”, and “is this worth spending time and money on right now?”, and “if not, what should we spend our time on?”

If you can’t convince the person paying by answering the first 2 questions then are you surprised that the answer you get for the last 2 is “no” and “something else”?

The non-developers working on YAM need to try and understand better how the actual DAO works and what it needs. But it is up to those who understand that part of the project to teach them and make them understand.

Yes I know there are a lot of different functions in Yam’s contracts but not all of them are actually useful. Currently, Yam is only a governance token.

You keep saying it’s useful, but you fail to provide any real world use cases where someone would actually want to use it.

If we ddnt have these functions nothing works.

used by multiple parties and dapps, its purpose is to make developers interact with yam easier.

will be on the yam website for features and interactions with smart contracts.

and generally for any party interested in yam read/write data.

will play a role in several places, it will be a stable source of code for the yam governance contracts interactions, cleans up half the code from the website and helps with faster load time through navigation for token holders and anyone using the website.

initially it will be first used within the yam website on action pages (delegation, voting, etc.).

available for developers to further integrate and interact with Yam on their dapps.

I have multiple times, not sure if you missed it…

Everything currently works without the SDK, throwing money and time at a problem that isn’t there isn’t what the tokenholders want.

Can you please explain to me how in REAL WORLD terms what a developer would want to do with the Yam SDK ASIDE from what’s already available on our website? ie, if it’s available on the website and working properly, that doesn’t count. What ELSE would a developer want to do which makes this SDK valuable?

Thats like saying we want to stay where we are, and for sure its not the case, hopefully. Also not everything works good enough, somethings can work better as i mentioned above, in the end its big value add for yam.

These are real world terms, and if you still havent gotten it and like me to explain further please let me know.

Anything concerning accessing yam on their applications.

Since you keep saying the same thing without any specific data or examples that isn’t already on our website, I am not approving anything to do with Yam Core Development.

You might have missed it, for anything else please let me know.

I didn’t… and still not approved. You might have missed my comments before but your welcome to read them.


i think you very much did