[ Execution ] The Great Yamdemption


Yam holders have voted with a super majority to make the treasury fully redeemable 1:1 with Yam(appendix: link 1). The redemption period will last 12 months from the date the on-chain vote is executed. All unclaimed treasury funds will be donated to the charities voted on in link 1 (see appendix).


To discuss the implementation of the on-chain redemption vote and to critique and give feedback on the current plan. This forum post is not a venue to voice disagreement about a particular direction and I would kindly ask Ross to remove any comments with that intent or that are off topic.

Contract Implementation:

It has been suggested that Tribe’s redemption contract be used (link 2). This contract has held and still does hold significant value in it without any issues and has undergone a CodeArena public review (link 3). I agree with this suggestion but am also open to alternatives if they have approximately the same reputation/security.

The remaining charity fund distribution will be trigerable by any address once the 12 months(31,560,000 seconds) has passed. The contract, addresses or ratios will not be upgradeable. I suggest that the constructor take in and save 2 additional address arguments of which will be the 2 charities. Redeeming will have a require check validating that the 1 year has not elapsed. For the charity redemption there will be a new function that will require that at least the required amount of time has elapsed and will accept a transaction from any address to execute. It will then send 100% of the remaining funds to the specified charities with their given hardcoded ratios.

Execution Steps:

  • All protocol owned liquidity should be removed
  • All protocol owned Yam should be burnt by being sent to 0x0000000000000000000000000000000000000000
  • Minterships of Yam revoked from all locations (we need to trace what addresses have this)
  • Yam upgradability locked
  • YamRedeemer contract deployed and verified
  • Public review for verifying correct contract was deployed properly

Charity Distribution:

1,164,739.09 voting power voted for charities. Gitcoin received 448,048.59(38.47%) and Watoto received 716,690.5(61.53%) votes. The remaining treasury funds will be sent to the verified addresses in the ratios matching their respective votes.

Potential Attacks:

  • Yam must have no way of being minted or upgraded for the redemption contract to be secure with this current implementation. Mintership will need to be revoked. If Yam could be voted to be minted or upgraded (with the token address remaining constant) and then subsequently minted then, after a large percentage of voting power has redeemed, a bad faith actor could vote to mint more Yam and then redeem those Yam thus hurting those that haven’t redeemed yet.
  • Front-end depreciation could make redeeming a more difficult challenge for those less technical. There ideally will be clear instructions with how to redeem Yam through the Etherscan contract interface as well.

Please leave suggestions for the vote logistics so that we can achieve a smooth and safe on-chain execution.


1 Like

Please include in the smart contract where you donate all of your portion of the treasury directly to Watoto’s crypto address as you have agreed to. Thank you.

1 Like

I’m going to give you the benefit of the doubt and assume the rest of the convo just slipped your mind and you aren’t intentionally being misleading. I clearly said that would be your proposal that I would support with the donation of Yam. The agreement is I’d donate my tokens if you put together and got support for donating 100% of the unclaimed treasury funds to Watoto.

This thread you are inappropriately spamming is regarding a vote that has previously passed with a super majority of 1.9m voting power. Yam is a democratic DAO and any proposal attempting to supersede this already completed vote should exceed that quorum.

“You suggested a better idea that would help save more lives and I am on board with that as well”

My suggestion will do this, are you going back on your words?

I will not be commenting on anything other than the technical aspects of this proposal. I would encourage other discussion to happen on a thread that is not focused on the technical aspects of a redemption, which should generally be universal no matter what the broader strategy chosen.

This seems reasonable as they are a respected dev team and the contract has done well so far. Any modifications should be clearly noted and ideally we can get the final version on the YAM Github. @ethe will need to coordinate for this to happen.

edits above are mine to make the quote and specification more general. It should be noted that the changes above are modifications to the Tribe redemption contract as these are not currently part of that contract. Stating the obvious, but its surprising how often things like this are overlooked.

Protocol owned liquidity removal should happen at the same time as the contract deployment (or when treasury funds are sent) if possible.

The YAM token has a burn function which we should try to use. Yam.Finance: YAM Token | Address 0x0aacfbec6a24756c20d41914f2caba817c0d8521 | Etherscan

Mintership powers can be seen here: yamV3/YAMLogic3.sol at 0f61c94230bf6c44d4d06188a53c45832f84cae7 · yam-finance/yamV3 · GitHub

Here is my understanding of the state of all the minterships. I encourage others to confirm/check this.

  • Governance has minting powers through the timelock/governor.
  • The Incentivizer had minting powers but these were recently turned off with the incentives shutdown. They could be turned back on by governance.
  • The rebaser has been bricked so that can’t mint anymore.
  • The migrator has mintership powers, but the v2 token should be considered equivalent to v3. It may make sense to include the un-migrated supply in the total yam supply calc. There are 25,499.48 un-migrated YAMv2, which is equivalent to 63,781.85 scaled YAMv3 (supply multiplied by 2.5013 scaling factor). This is $10-15k worth depending on the final treasury size.

The steps for review, deployment, and voting should be clearly laid out so everyone is aware of what is happening.

I would guess this will be difficult with the current governance system. I don’t see how minting can be “turned off” without a new token implementation, which I believe should be out of scope. Upgradeability is equally difficult since governance controls that and would need to be bricked to stop this.

A potentially easier solution, although less certain, would be to empower the guardian to veto any non-emergency governance actions during the redemption period. During redemption, governance would be stopped by social consensus and only in the case of an emergency should any governance actions occur. The Guardian would be tasked with vetoing any votes that are proposed outside of this mandate. Some work would need to go into specifying what constitutes an emergency, but this isn’t far off from what the role of the governor is already. The timelock could be increased significantly to allow ample time for review and discussion, while also making it much less likely that a governance vote can get passed unaware.

We can have a discussion around the parameters of the timelock and guardian multi-sig to maximize security.

We should get a quote from @ethe to see what the hosting cost for the website is and maybe pre-fund that? I have to imagine that we could also throw together a front end hosted on fleek or eth.limo that will last at least a year. Directions on how to interact with the smart contract via etherscan and how to clone and run a local version of any front-end is a good idea too.

1 Like

Thank you for the detailed thoughts.

I do agree that we can avoid most of the concerns about attacks around upgradeability and mintership by extending: 0x8b4f1616751117C38a0f84F9A146cca191ea3EC5 (the timelock contract) to have the delay be the max allowed delay of 2592000 seconds (30 days). This will make the whole process much safer as bricking the governance would not be needed.

I can take ownership of writing a simple tutorial for redeeming via Etherscan user interface.

@ross Can you list out everywhere protocol owned liquidity is?

There will need to be payment sent to some contributors to finish up what is owing to them for previous work. @ross can you post those details here?

Here is the suggested contract and tests for public review and audit:

Before the contracts are deployed the charity addresses will need to be vetted publicly and replaced at the top of the YamRedeemer.sol contract.

After 2-3 days of public review I suggest these contract are deployed and the on-chain vote commence.


  • Give time for a public review of the Tribe redeemer modifications
  • Confirm and post here the two addresses of Gitcoin and Watoto. Note: These addresses will not receive anything for > 365 days and so should not be temporary. These can not be update. Nothing in this contract can be updated
  • Deploy code. Who deploys it does not matter but it should be verified on Etherscan and the address posted here for public review
  • On-chain vote commence with the options: 1. Proceed with redemption and selected charities. 2. Do not proceed

Vote Execution Steps
The vote will have several steps. Feedback on these will be much appreciated:

  1. Burn all Yam held in the Treasury
  2. Set the delay period for the governance to its hardcoded max of 30 days
  3. Transfer all tokens and ETH to the deployed YamRedeemer contract (address tbd)

The only treasury assets that have been pre-approved (to be paid out upon completion of work) and not paid out is the work @feddas was doing for treasury rebalancing and potentially voting with the treasury UMA by me.

Feddas would have to speak on his part. For the UMA, there have been no votes this month so If this is all moving forward then I won’t vote (or wont charge for any votes) that come up.

There is YAM that is currently in sablier streaming contracts. But these are 6 month streams so if this contract is the one that is used (1 yr duration) then there is ample time for those to complete and the YAM redeemed.

If I missed anything I hope those who I missed will correct me.

I’m on a bus so this is mostly from the top of my head. Will do a more thorough check later and can add addresses.

In terms of actual protocol owned liquidity there is the ETH that was just added to sushiswap yesterday. It was something like 230 ETH I believe.

Another source of funds that would need to be moved back to the treasury is the UMA, which is in separate contract that allows it to be voted with (by me). Only the timelock can withdraw these tokens.

Then there are funds in the multisig. Some ETH and USDC and YAM. Addresses can be seen on the yam GitHub.

I think that’s everything.

It bears asking whether the USDC and ETH in yearn should be unwound to send to the redemption contract. Keeping them as yearn tokens adds to the costs for small token holders to unwind the positions.

Thanks for the details. Can you shed more light on the “sablier streams”? Are those erc20’s that are vesting and will be paid out to the treasury or funds that need to be claimed by the governance system in 6 months etc?

I really wish the liquidity addition wasn’t executed in light of this vote going on-chain shortly. This will need to be removed and that Yam also burnt.

Edit: I do not think it makes sense to unwind any tokens except LP tokens that hold Yam as that needs to be burnt. It would make the vote more complicated and risky.

I suggest that the vote goes on chain this coming Monday October 31st.

The proposal is confusing. If I remember correctly, the community passed a Treasury redemption proposal with no donation.

You can review the vote count. A super majority voted for the charity option and none of Feddas other proposals came close to the same voter support or turnout. Also his proposals are 99% his and jpegs’ votes only. If anyone including Feddas can gain more voter support than the proposal this forum post is addressing then that will be more valid. The on-chain vote will decide exactly this.

The Streams are YAM paid to individual contributors over a 6 month period.

These were from the last executed proposal: proposals/Proposal32.sol at 379cc0e2b8071cdae774a44db91c6e79432ebf5e · yam-finance/proposals · GitHub

These are from the month before: proposals/Proposal29.sol at 379cc0e2b8071cdae774a44db91c6e79432ebf5e · yam-finance/proposals · GitHub

That’s all of them

“If anyone including Feddas can gain more voter support than the proposal this forum post is addressing then that will be more valid.”

By your definition, this snapshot has 2.1 million votes with super majority and more discourse and more unique voter turn out and related to your snapshot, so this will stand above your snapshot: Snapshot

Thank you for clarifying @1tx.capital

Now stand by your words.

Posting here from Discord: I know you already know this, but for others reading this, that vote Feddas(Steve) cites has many large voters here that have switched sides in favor of the redemption with the charity donation. In fact it is almost exclusively you and jpegs voting against it

Doesn’t matter, by your words, the old snapshot has more votes, more unique voters and a higher % overall votes against redemption.

Until you get more than 2.1 million votes your snapshot isn’t valid.

Just posting Ross’ comment regarding collecting Yam’s UMA here so that it doesn’t get missed in the review:

This is the contract that holds the Treasury UMA: DesignatedVoting | Address 0x8348c5ec31d486e6e4207fc0b17a906a0806550d | Etherscan
The timelock needs to call withdrawERC20 to retrieve it.
I have collected all rewards to the contract so all that needs to be done is the one call

Ross confirmed the above address for Gitcoin:

Watoto’s address can be confirmed as 0xC76AbD442D750fDeb9e3735BC39A4E70F634d678 here: Crypto Donation - Watoto