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
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.
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.
The following deliverables, timeline, and milestones (with added clarifications from later posts added to them).
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:
- Deploy the contracts necessary to allow a third party to vote in UMA governance with YAM treasury UMA tokens.
- test any interactions with those contracts to assure they work correctly and as intended
- 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:
[optional] the DAO should determine who it wants to be its voting delegate for its UMA tokens. (This can be decided later if necessary)
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
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 = address(reserves); signatures = "whitelistWithdrawals(address,uint256,address)"; address memory whos = new address(1); uint256 memory amounts = new uint256(1); address memory tokens = new address(1); whos = address(proposal); amounts = testAmount*(10**18); tokens = address(UMA); calldatas = abi.encode(whos, amounts, tokens);
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.
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 = address(TwoKeyContractAddress); signatures = "withdrawErc20(address,uint256)"; calldatas = abi.encode(address(UMA), testAmount*(10**18));
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
1in the roleId field. The code would look like this:
targets = address(TwoKeyContractAddress); signatures = "resetMember(uint256, address)"; calldatas = 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.
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 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.
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.
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:
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.
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.
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:
- 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
- @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.