My Concerns around the Yambassadors Silo

In the last few days, while doing further due diligence on the Yambassadors Silo and scoping the work to vote with treasury UMA tokens, I have come to the conclusion that the amount of work that is being represented as necessary and the time to do it is not in line with the work that is actually required.

I will quote the relevant information, and the original posts and conversations are located here:
Yambassadors silo proposal
YIP-99 Delegate the UMA in our treasury to a contributor

YIP-99

To start, let’s look at the original post that @Snake made about voting with UMA in YIP-99.

In that post, the goals and specifications of the proposal are as follows:

Note that the goal of this proposal is to allow a 3rd party delegate to vote with the treasury UMA tokens. Also note the simplicity of the proposal. Discussion around implementation of the proposal was focused on who the delegate would be and not the creation of the contracts. There was no discussion of the timeframe or cost of doing the work to allow voting but based on the specifications, the effort required seems minimal.

There was positive sentiment at the time around @Snake being this delegate and doing this work but he turned the role down so the proposal was shelved.

Yambassadors Silo

Goals

Fast forward 5 months and @Snake proposed the Yambassadors Silo with the following goals:

Scope

The scope and specifications of the project were stated in the initial proposal as:

In subsequent posts. snake elaborated on the work to be done:

An astute reader will notice that the scope laid out above is very similar to that from YIP-99, with the only change being the language about creating a smart contract to interact with the designated voting factory. We will see later that this change is unnecessary.

Deliverables

The following deliverables, timeline, and milestones (with added clarifications from later posts added to them).

Understanding the scope of work

The scope of work proposed seems to be different between the 2 posts, with the second proposal listing a much more expansive scope of work. I will explore if that is actually the case.

In both proposals, the goal is to allow a 3rd party delegate to vote in UMA governance and oracle questions/disputes with the UMA tokens in the YAM treasury in order to earn voting rewards paid out by UMA for “correct” voting. The Yambassadors silo proposal also mentions other future work to participate in other governance actions with treasury funds, but there are no specifics and it is not included in the scope of work for which compensation is requested. Also not included in the scope of work for compensation is ongoing voting with the treasury tokens after the contracts are deployed, tested, etc.

As I understand it, the goals of this proposal as it is written are as follows:

  1. Deploy the contracts necessary to allow a third party to vote in UMA governance with YAM treasury UMA tokens.
  2. test any interactions with those contracts to assure they work correctly and as intended
  3. Write documentation that helps future delegates and YAM governance participants understand and participate in UMA governance and continue to earn money via voting with treasury UMA tokens.

In order to complete these goals, the following sub-steps need to be taken:

  1. [optional] the DAO should determine who it wants to be its voting delegate for its UMA tokens. (This can be decided later if necessary)

  2. An instance of UMA’s 2-Key designated voting contract needs to be created with the correct YAM governance contract as the owner. The default parameter when creating this contract is that the contract creator will be set as the voting delegate.

    This is done by calling the newDesignatedVoting() function on the UMA designatedVotingFactory contract and entering the YAM timelock contract in the address field. This can alternately be done using the UMA voting dApp at https://vote.umaproject.org

    Once this contract is created, it can be checked according to these instructions: Voting with the UMA 2-Key Contract | UMA Docs

  3. The DAO should then send a test transaction to the contract with a test amount of UMA (i.e. 1 UMA) in order to confirm that the contract works. This can be done as part of one of the monthly on-chain transactions.

    The code to be added to the monthly contract is a simple ERC-20 transfer to the 2-key contract and would look like this:

    IERC20 internal constant UMA = IERC20(0x04Fa0d235C4abf4BcF4787aF4CF447DE572eF828);
    
    UMA.transfer(TwoKeyContractAddress, testAmount*(10**18));
    

    the code used to propose the transaction would look like this:

    targets[2] = address(reserves);
    signatures[2] = "whitelistWithdrawals(address[],uint256[],address[])";
    
    address[] memory whos = new address[](1);
    uint256[] memory amounts = new uint256[](1);
    address[] memory tokens = new address[](1);
    
    whos[0] = address(proposal);
    amounts[0] = testAmount*(10**18);
    tokens[0] = address(UMA);
    
    calldatas[2] = abi.encode(whos, amounts, tokens);
    
    
  4. once the UMA has been sent, the delegate should confirm that they can vote with the contract, claim rewards to the contract, etc.This can all be done via the UMA voting dApp at vote.umaproject.org.

  5. After confirmation that the contract works for the voter, The DAO should submit a new on-chain transaction that confirms that the UMA and rewards can be removed from the contract by the DAO.

    the code used to propose the transaction would look like this:

    targets[0] = address(TwoKeyContractAddress);
    signatures[0] = "withdrawErc20(address,uint256)";
    calldatas[0] = abi.encode(address(UMA), testAmount*(10**18));
    
    
  6. The DAO can choose to change the delegate at this point. It would do so by calling a different function on the 2-key contract called resetMember() with the new delegate in the address field and 1 in the roleId field. The code would look like this:

    targets[0] = address(TwoKeyContractAddress);
    signatures[0] = "resetMember(uint256, address)";
    calldatas[0] = abi.encode(1, address(newDelegate));   
    
    

After the above 6 steps, goals 1 and 2 listed above are complete. In the next transaction, the balance of the UMA in the treasury can be transferred to the 2-key contract per step 3. The work then left to do is to complete goal 3 by writing the documentation required to facilitate future voting and use of these contracts in order to earn the treasury UMA.

Determining the amount of time required to complete the above scope of work.

When the above steps are complete, the goals listed in the Yambassador Silo proposal and YIP-99 will have been completed. How much time should we expect this work to take? Per @Snake, he expects this work to take 6 months and cost the DAO $80,000. Considering the code to make the transactions is written above, that leaves the creation of the contract, testing, and the documentation left as the significant scopes of work.

Creating the voting contract

Creating the 2 key voting contract does not take any significant amount of work, and to show this I went ahead and created the contract. You can view it here: DesignatedVoting | Address 0x8348c5ec31d486e6e4207fc0b17a906a0806550d | Etherscan.

I encourage all readers to confirm that the YAM timelock address is the owner (role 0) and my public wallet (0x88c868b1024ecaefdc648eb152e91c57dea984d0) is the delegate/voter (role 1). The voter role can be changed in the future if the DAO desires.

Testing the voting contract

Now that the 2-key contract has been created, @ethe can use the code in the scope of work section and send 1 UMA to the contract as part of the next on-chain proposal. He is paid for this already and it is a small lift. It can be tested with the rest of the proposal.

Once the UMA is in the contract, the delegated voter can test that voting works and retrieve rewards using the UMA voting dApp. In the following on-chain transaction the DAO can test removing the funds and change the voting address if desired. I expect the voting and testing to take at most a few hours, and adding the code to test removing the funds is part of scope that we already pay a developer for.

Documentation

That leaves the documentation as the final step of the process that requires completion. How to deploy the contract has been documented above, so we can clean that up and re-use it. I have also written a document here. We still need to include documentation and procedures around voting on UMA votes, but most of this documentation is already made by UMA:

Voting with the UMA 2-Key Contract | UMA Docs
How to vote via the Voter dApp | UMA Docs
Tokenholders Guide | UMA Docs

I don’t expect this document to take more than a day to put together. It can be published to the YAM github repo with the rest of the documentation about using UMA to vote so that it can be found in the future.

Summing it up

So adding this all up, we have a bunch of work that is already done and took a few hours to complete, the upcoming work that is included in the scope of work that we already pay a dev for, and a few hours of work on my part to test and document. I fail to see how this scope of work could ever be estimated to cost $80,000 or take 6 months to complete. The final ability for the DAO to vote with all the treasury UMA will take a few months to come about if we limit our on-chain votes to the monthly ones, but the scope of work and required working hours are much less than that. It could be completed much faster if we submitted additional on-chain proposals.

Contrary to the assertions made in the Yambassadors proposal, there are no complex smart contracts that need to be written, nor significant engineering work that needs to be done. I have done most of the code work described above and deployed the contracts and I am not a developer. It took me a few hours and some conversations with other developers including @ethe.

YAM has consistently overpaid and under-received for the much of the work that has been done on its behalf and it is time to take a stand against this. The new model that @designer, @chilly, and I are working on is a step forward in building a more robust and accountable DAO. But this new model relies on all of us to be vigilant and vet the proposals that are submitted. We all need to do a better job of looking into these proposals to make sure the DAO is getting good value for the money that it pays.

A Counter Proposal

edited 2022.06.02

While I agree with the overall goals of the Yambassadors Silo, I do not think that YAM should pay $80,000 for the scope of work included in the original grant proposal for it. I strongly recommend that the DAO reconsider the approval of the initial grant to fund the Yambassador Silo and either create a new vote to reject it, or get a significantly changed scope of work.

As a counter-offer, I submit the following proposal to do an equivalent scope of work (detailed in the “understanding the scope of work” section above) with the following next steps:

  • I have already created a working 2-key contract and provided the basic code to interact with it via on-chain transactions. I will coordinate with @ethe to will send a test amount of UMA (est. 2 UMA) to the contract in the upcoming on-chain transaction as well as send some of the UMA (est. 1 UMA) back to the treasury. This will test both sending and retrieving.
  • With the UMA left in the contract, I will vote on an UMA vote and confirm it works.
  • I will create documentation around UMA voting best practices and link to the relevant existing documents. I will publish this to the forum, and coordinate with having it added to github and other documentation resource locations for the DAO.
  • Upon completion of the prior steps and barring any issues, we will send the balance of the treasury UMA to the 2-key voting contract in the following on-chain transaction (July)
  • I will submits a proposal to be the UMA delegate and to vote on behalf of the DAO as part of my monthly moderation and operational duties. (I will formalize this in the future in my work proposals). If the DAO would prefer someone else to be the delegate then I will coordinate with @ethe to change the voting address to the person who is chosen

All the above work will be completed at no added cost to the DAO beyond our existing commitments and any Ethereum gas costs will be submitted as re-imbursables. While we are still working on determining how to structure compensation moving forward, everything listed generally falls into the current scopes of work for which @ethe and I are paid and or can be rolled into existing duties.

Because the price of “existing duties” is somewhat vague, I will break down what I expect it to take and what it would cost if done as a stand-alone project:

My time:

  • Prior work to deploy 2-key contract and research - 4 hours
  • prior general scope of work research - 8 hours
  • code writing to include in on-chain transaction - 8 hours
  • UMA vote testing - 4 hours
  • Documentation - 16 hours

my Estimated Total: 40 hours of work * $70/hr = $2,800.00

Other Time:

  • @ethe code deployment. Not entirely sure on the actual time, but I will guess 8 hrs added to each of the 2 on-chain votes to test.

@ethe Estimated Total: 16 hours of work * $70/hr = $1,120.00

Add in contingencies, and expectations that everything takes longer than expected (~25%) and we come to about $5,000 in expected cost to do this work in 2 working hour weeks (80 hours).

The work is intermittent so the date at which I expect the work to be completed will depend on on-chain transaction timings, but should be done by mid July if we meet the above schedule. Meeting this schedule will require that we include the test send and retrieve in this month’s proposal.

1 Like

Thank you Ross for digging into the project and also executing on it as a way to determine how much work it involves and what it is worth to the Yam DAO.

I didn’t vote on the Yambassadors proposal because there we too many unanswered questions. Bottom line, I just didn’t understand the proposal scope of work and therefor I could not ascertain the value to Yam DAO in relationship to the cost.

I support your counter proposal. But is there a plan for the ongoing execution of UMA voting using this system? As in what skills and commitment is required and if you are interested in doing it.

1 Like

I plan to put up another proposal next month with an offer to vote with the UMA after the work to set this up is complete While there may be a few votes that require some data analysis skills that I don’t have, I believe that they will be limited and that via coordination with other UMA voters and the UMA team, I will be able to get answers for all the proposals.

Supporting my counter-proposal does not mean that one needs to support me being the delegate to vote, although I plan to put my name in the ring next month.

I expect it would be no more than a 5 hour a week commitment, and I can keep track of that as I go through the process.

I appreciate your post on this @ross, looking back at the original proposal i imagined theres way more to be put into it in terms of development work.

For the less astute reader, remember you don’t pay the plumber for banging on the pipe. You pay him for knowing where to bang.

TLDR; for all of those that glaze over about these discussions ,
I’m in 100% agreement that Ross should move forward with this proposal as it will allow me to work on other projects and still hopefully give us all the same or equivalent results. Worst case, this is just another Yam promises and under delivers deal that we are used to under the current ‘core team’. At least he starts off this project with a great idea :innocent:

This code makes no sense in the context that you bring it up and shows a fundamental misunderstanding of solidity at the engineer level. This is likely code taken from a test function and is assuming that you have a contract that will be doing the proposal for you. This “pseudo code” also implies there are 3 actions that the time lock will take which is not consistent with the rest of your post. Please talk to @ethe about how he actually runs the proposal transaction vs how he tests them, but this ain’t it chief. You also missed a step in which the voter role retrieves the rewards (or the dao can do it via setting the timelock as the voter and running the retrieve rewards transaction before running withdraw). Checkout the retrieve rewards function on that contract you deployed.
I missed that you actually mention this as a footnote of step 4. I actually wouldn’t even do this if you stick with the 1 UMA as you propose (more on that below).

Like you said, you aren’t a dev and we can excuse this since you are committed to working so cheaply for the DAO. Hopefully, @ethe is more available to you as you move forward with this but feel free to reach out for a consult (I won’t ignore you :laughing:).

I’m glad I was able to take you from “I don’t understand what you are doing” to “I can do what you want to do for a lot less”. You make quite the sensationalist claims that I misrepresented something in my proposal but while you quoted pretty much all of my work, you don’t highlight where I asserted something that isn’t true. Regardless, you are claiming to be able to do the project that I estimated would take 4.5-6 months down to 2-2.5 weeks while proudly claiming you “did the work” with no dev experience.

That said let me share some of my other “concerns”.

I proposed 500 UMA be used to make sure there is plenty of incentive on-chain to entice a bad actor to act in case you mess up. 2 UMA comes to about $6.08 (at current price 3.04) . I urge you to reconsider and transfer more just to ensure that finding an issue is worth the gas of a potential attacker. Maybe 500 is too much, but 2 is not enough for what you are testing.

You seem to be budgeting about 4 hours for voting. This would probably give you enough time to vote once and with such little time to prepare, you’d just be guessing at the vote.

In a standard vote, you will need at a bare minimum to get acquainted with the dispute, confer with the community, do some due diligence (manually check data sources or run some scripts), then vote on one day and reveal on the next (while waiting on gas to be reasonable). At the same time, documenting the steps you took and the reasoning behind is the most crucial part of this exercise. 4 hours per vote seems unreasonable here but I guess it does just take 2 seconds to run a transaction when someone else lays out the work :wink:, check out the evidence rationale channel on UMA’s server for “compilation” purposes.

You changed the language from my proposal on this to be much more ambiguous, ironic since you had asked me for more details. I implore you to think about how UMA works and how disputes are costly affairs to those proposers and disputers involved. 20 hours to create a template, fill them out on each vote, documenting your sources and writing up the experience seems irrational even for someone that likes to write as much as you do. I guess since you won’t have anyone to bicker back and forth on revisions so you may get away with whatever is your first draft.

8 hours to write, review and test two on chain proposals? This would make it two of the fastest transactions that @ethe has put together in months. On chain contributors payments were typically given a week and those typically were copies of previous proposals with slight modifications. Call me a skeptic, but then again “we need norms around preventing corruption and people who are willing to call it out when they see it”.

The point of the silo I proposed was to bring others in and have them participate in UMA governance through YAM. Having a system in which a Yambassador or multiples of them can look out for the interests of the DAO and not put the treasury at risk was part of my long term vision. I guess it is in your best interest to keep YAM a DINO DAO (Decentralized in Name Only), but I would vote down your proposal and suggest we get an “outsider” to vote once this process hashed out and your documentation is available.

Lastly, you are asking to get reimbursed for the research you did on my research, I know the DAO is already getting a “great deal” but I don’t think that you should be getting compensated for writing a scope of work and research. You are already asking for compensation for going back and forth with me on my proposal (22.06.03- Specific Architectures (Ross) Contributor Compensation Request) which also kind of bothers me since I didn’t get paid to answer your questions.

No ill will though and I hope that you do succeed. Although I admit being irked that you worked on this without talking to me first or making it known that you’d be willing to do this work. Instead of collaborating, you chose to meet with others and ignore my messages once I noticed activity on-chain. It’s a shame because you spout ideals that you turn around and don’t follow while acting as the self elected conscience of the DAO.

Reading this post but not fully understanding the developer side of things, it seems to me that both @ross and @Snake have some valid points.

My question: Will this silo take a competent solidity developer such as @Snake or @ethe 6 months of full time work (40 hours a week) of active work to accomplish this silo?

@ethe has looked at this idea 3 times now (and more on the meetings beforehand). Each time with similar implementation technical details spelled out and this has yet to been implemented. Suddenly it clicks for everyone and its in fact so simple that someone that isn’t a developer could do it.

As @ross points out, it has been already been 6 months since I laid out this idea. I posted in YIP-99 to formalize this idea to the DAO. I ended my contributor stream the same week that I turned down my yip-99 delegate nomination. I was clear that this was a great idea, but that I had other priorities that I had to work on at the time.

So yes @feddas, I’d estimate that it would take 4 months with 2 month’s contingency to properly kick off this new effort for the DAO. @ross went from the scope of work being outside his knowledge-base to being able to get it done in two weeks because he spent a weekend looking at some solidity. If he would have bothered to do that in the past 6 months, he could have gotten the DAO enough rewards to triple what he is asking for and we would all be better off for it. I’m not sure what else was more pressing.

Can you clarify why it matters how much UMA is sent? What are you trying to entice a bad actor to do? My proposal limits the amount of UMA because we are testing the functions and whether voting works. Is there something else is being tested that requires more UMA?

From what i understood recently there is no solidity work involved in bringing this idea alive as to what it offers but instead more on being familiar with uma, previously i thought otherwise, thinking your proposal and focus requires working on creating contracts to then interact with uma protocol.

Brings us to my question, is there something else missing we are lacking information on or everything that was laid out on this post summarizes it?

The most recent on-chain transaction that has been posted for review by @ethe. Tests on the contract have passed. Assuming no issues are found, this will be submitted in a few days as the next on chain transaction.

Proposal26.sol is the proposal contract and Proposal26.t.sol is the test of the full interaction including the propose() call to the YAM governor.

In developing the code for this transaction, @ethe and I made some changes from what I initially proposed in the first post. The main change is that we are testing both the function to send the UMA and the function to retrieve the UMA in this transaction. This is done directly from the propose() transaction instead of via the Proposal26.sol.

The call to send the UMA can be seen on lines 101-109. It calls oneTimeTransfers() on the reserves contract to send 2 UMA to the two-key contract.

The call to retrieve the UMA can be seen on lines 111-113. It calls withdrawErc20() on the two-key contract to retrieve 1 UMA back.

If you are testing that you are sending to the right address or that you know how to transfer tokens, why even transfer a whole token. Send .000001 uma and you get the same result. In my opinion, off-chain testing should already give us this confidence.

If you are testing that the way you follow this process does not allow for a bad actor to steal your funds, you need to transfer enough tokens that the gas to exploit your process is worth it to the bad actor. It’s a simple security principle, a criminal is more likely to break into a car if they see $2,000 on the dash rather than a nickel.

So at 2 UMA you are sending too much or too little to meaningfully test the process.

The purpose of the test is to assure that the functions we are calling work and the way that the 2-key contract interacts with our treasury and governance contracts is as expected. As you said, it could be any amount. We are testing that we can send [some amount of] UMA tokens to the contract and then retrieve [some amount of] UMA tokens, not that the 2-key contract itself is safe from attack. That is assumed when we decided to use it.

The idea that sending 500 UMA to the contract is some sort of bug bounty makes no sense and is wholly outside the scope of what we are trying to do. The 2-key contract is an audited and battle tested contract that Risk Labs itself uses.

So the answer is that the amount is unimportant as long as it falls below the threshold of “is it bad if it lost”. The difference between losing 2 UMA and losing 0.00001 UMA is ~$5. We could have sent 2 wei worth of UMA and sent 2 wei back, and maybe that would have been better. Maybe a good idea for next time, but maybe easier to understand if people see whole numbers go in and whole numbers come out. In the grand scheme of things it doesn’t really matter. We don’t expect the transactions to fail (they are tested beforehand) and if they do, the amount is comparably insignificant.

Update:

There are 2 snapshot votes currently live regarding the Yambassadors Silo:

  1. Retract the previously approved Yambassadors grant request: Snapshot

  2. Determination of whether initial Yambassadors grant request was malicious or not, and whether to pay snake for his time working on it: Snapshot

Both votes are open until June 22nd at 1AM UTC.


I want to clear up a few statements that I view to be mis-characterizations in the text of the vote that @Snake submitted.

The only thing that has passed was to send some UMA to test the contract that I deployed. The retraction vote is to confirm that the DAO chooses not to move forward with the prior proposal.

The timeframe that I have quoted is “2 weeks for of work” which amounts to 80 hours. I never said that the project would be completed in 2 weeks time. Completion will take at least into July to be finished, but I only expect to spend 80 hours of time working on it.

My rate increased for the Re-Org work, which is a separate scope and silo. That does not apply here, and my work will be done based on my prior rate, and as part of the existing scope of work that I have previously been empowered to do for the DAO.

I wish I could have acted sooner and not had to do this after the vote was approved. But you submitted the vote yourself without confirmation of support, and then forced a scramble of voters to make a decision based on what I believe was incomplete documentation of the work. If you force someone’s hand, don’t come back complaining that they undercut you afterwards.

With all of this said, this episode has helped clarify how the system should work, that there needs to be a way to counterbid proposals, as well as a mechanism to pay for preliminary work done on a project, even if the original applicant doesn’t end up getting a grant to continue with the work.

My View

I do support Snake being paid for the work he put in. I don’t really want to comment on whether the act was malicious. As I have stated, I believe that the price-tag for the work as proposed is not worth what the DAO would get, hence this whole ordeal.

I believe that the amount of compensation should be discussed more thoroughly. While that amount may ultimately be contingent on whether DAO voters believe the proposal was malicious or not, maliciousness is not be what we should be voting on, but instead what the correct compensation is.

You are saying that I mischaracterized something, but you failed to mention what that was.

You are splitting hairs.

It doesn’t apply here that you changed the rate that you contribute to the DAO for just two weeks after your counter? How is this mischaracterizing your willingness to underbid? Are you saying that the reorg technical writing / diagramming that you started months ago is getting more expensive? You aren’t clearing anything up.

Such hypocrisy in this statement… You had plenty of time to say something about your own bid and I didn’t “force a scramble of voters” to make a decision. I followed your template, I gave two weeks for anyone to bring up an issue, and the vote on snapshot was up for just as long as your own proposals. You are using idioms to confuse readers, not clarify mischaracterizations. I’m not complaining that you undercut my efforts (although you did), I’ve actually been supporting your misguided efforts. I’ve only complained that you weren’t more transparent. Stop acting like you were.

You’ve commented on everything else, weird that this is your stance.

You didn’t want to discuss compensation when you were asking to be double paid by the DAO but now you ask for more discussion on my request to be reimbursed?

My view

You titled a section “My View”, but you don’t share what to comment on what your view is. You want to share your opinion on my opinions, but you only vote on your own proposals. I’ve already shared what my views are by voting to move forward with your proposal, retracting my own and voting to be reimbursed. What are your views? You wrote a lot and didn’t say much as usual. You are tossing around FUD instead of contributing, please be mindful of that. Go vote!