Hi, Raf from Tally here. Iâm really sorry to hear that this happened.
We know that proposals have high stakes, so weâre adding more safety checks for both proposal creators and voters. Weâre talking with some of the leads and stewards about how we can help prevent this kind of thing from happening in the future. Theyâve already suggested some great ideas as part of the post-mortem for this incident.
Today, we added a warning to the Create Proposal tool when sending funds to a token contract. âThis is a token address, and in most cases is not recommended. Please make sure this is the intended addressâ
Proposal safety is a key pillar of our product, so weâll be rolling out more improvements to proposal drafts, simulations and safety checks over the next few months. Iâm especially keen for feedback from you all. My goal is to make sure that creating and voting on these high-stakes proposals is both easy and safe!
Feel free to reach out if you have suggestions or would like to preview some of our UX ideas.
I am really sad to see this happen. Signers/voters should triple check arguments and try to simulate all transactions to see they do what they were intended to do.
Safeâs UI is integrating Tenderly simulations for exactly this reason. Could it be that this can also be integrated in the voting process with Tally?
But really sending to own token contract is really easy to spot even in Tallyâs interface. I just looked at the UI.
Edit: To be clear, I am not taking the shitty view that I would have seen this if I was still participating in governance. I can very well imagine situations where itâs late, you are confused or tired and just press sign/vote.
Just sad to see that not one person noticed it before it was too late. I mean come on guys 136 people made an on-chain transaction spending their own ETH in gas to vote for such a mistake without even bothering to check what it is they are spending the ETH for.
Extremely sorry to learn about this incident. And, as a delegate who voted on the proposal, Iâm especially disappointed and frustrated.
IMO, I donât think delegates have the mindset that they should be checking executable code. I also donât think they have the mindset that they should confirm other particulars, eg, that the transfer amounts match the original budget proposals, that the Snapshot vote was approved with quorum, etc.
While itâs great that any delegate or interested member from the community can easily check these things on Tally, we should also have a checklist that someone other than the proposer can use to verify the proposal. For example:
Proposer is in good standing with the DAO / address has not been hacked
Proposal has been approved on Snapshot
Amount of tokens and exchange rate is correct
Recipient address is correct
Iâm happy to see Tally responding quickly with a UI improvement. I could also imagine Tally giving DAOs an address whitelisting / labeling feature to give users more confidence that the address the proposal is interacting with is the correct one.
That said, I would also like to see the DAO implement its own âsocial wareâ upgrade in light of this event.
Absolutely. A checklist and people checking that the advertised function is what the actual call data do is a must.
In my opinion we should educate governance voters that they are in essence multisig signers for such transactions. Itâs their responsibility to check the call data. Perhaps this is not widely understood and needs to be explained.
On a more personal note this is not an individual failure, but a collective governance failure. Donât feel bad about this. Neither you nor the other votes or the proposer are solely responsible for what happened.
Individual people can and do make mistakes. The collective as a whole should check for them and mitigate them. This is what failed and did not happen here.
Really drives home the importance of paying workstreams in your native token! this mishap would have been much much worse had it been in stables or eth
Will the reduced amount negatively affect the workstream ? I wouldnât want them penalized for no fault of theirs.
Ideally it would have been nice to have a snapshot vote before the tally vote, with the options of keeping the same budget, increasing it or reducing it (with the multi-sig signers involved abstaining from the vote)
Still trying to grok how this much funding was fumbled after all the years of experience between the members who were involved with the transfer.
Even if a test transaction was sent separately from a personal wallet with funds out of their own pockets it could have prevented this from happening.
I see that a test transaction is not the best way to approach voting mechanisms but still think that the method to send a small test transaction of $1 would be helpful regardless.
Perhaps there is a way to implement this into the procedure because a small transaction of this nature could have easily saved a half a million dollars. I am imagining the community is at a loss of words as we were until now.
The potential that this funding could have brought to the grant ecosystem is now lost for those who have been grinding day in and out to improve the Gitcoin platform. A major setback in the world of public goods.
To those who were involved with the transaction make sure to keep your chin up!
We are all rooting for you & hope that this learning lesson will improve the quality control happening during a transfer for a large sum of capital.
Itâs unfortunate to see a workstreamâs budget disappear this way. Iâm relieved that the community and contributors are being so forgiving in light of this incident.
The Tally team are the heroes we donât deserve in all of this. They delivered a great update as a response to this mishap. Itâs great seeing teamâs react so swiftly to community reports.
Whereâs the learning opportunity here?
Should we be incentivizing/ rewarding delegate participation? Instead of creating another internally appointed mini workstream?
Iâd love to explore delegate rewards, which could encourage more community participation and create an opportunity for them to earn GTC for their work in governance. Creating an internal DAO Guardians Program sounds like the DAO appointing more insiders and paying them for work we should have all been already been doing more of as contributors. Interested in governerds like @jengajojo@FractalVisions@CryptoReuMD@lefterisjp to offer their insights on this.
I like the idea of creating an attestation dashboard for the checks & balances to sign on chain prior to sending the main Tx from the vote.
Anyone could participate in these attestation check in events to get the full community participation of GTC holders or stakers to further decentralize the process.
Even a token of appreciation like the Kudos was a nice touch at the end of an educational quest on Gitcoin. The learning aspect of the platform was something that I was heavily drawn to in the past. That is one thing that would be really amazing to see implemented into the UI somehow down the road.
Maybe even refurbished kudos on PGN or other L2 options that align with the ecosystem such as Optimism.
I will just use what was mentioned above from @DistributedDoge !
I second this and is absolutely necessary from a decentralisation pov! For the actual implementation, while I have designed and delivered many delegates programs myself, for gitcoin we can perhaps start with a âDelegates QF Roundâ each quarter or so and iterate from there? What do you think @CoachJonathan ?
Yes my friend. Iâm fully engaged with the team that itâs been growing for the good of the community. With a very aligned and ethical responsabilities as far as i can say and i know from all the tagged ones in this post.
Iâd love to work with an internal workforce could be great, and a big opportunity to learn and discuss about what itâs the best for the different communities. As we can see in L2Beat for the pie that its being very popular we can have a spider web graphic with eight different values and align the projects inside.
This may not be the ideal place to share this but Iâm not aware of discussion on this vote happening anywhere else, so posting here. I voted âAgainstâ on this proposal - some people have reached out privately to learn why, so to be transparent Iâll also post in public.
First off, let me say I absolutely think we need to find a way to keep the MMM team compensated for both past and future work, I donât want to see the workstream stuck with $0 for the season, and regardless of my vote Iâm confident the proposal will pass given itâs basically at quorum already.
But I voted against it for a few reasons:
There hasnât really been any actual discussion (in public or that Iâve seen) about the issue, how to resolve it (financially) and the next steps, it was âhey this big mistake happenedâ and then âHereâs a new budget requestâ. The proposal says MMM âwill be staggering their budget request from the rest of Gitcoinâ going forward - what are the financial and operational implications of this?
I donât feel like any real ownership has been taken over the mistake (and I donât think itâs Tallyâs fault)
I am still a bit unsettled about the $100k+ sent from the CSDO multisig to MMM of which there still hasnât been any acknowledgment of it, unclear whether that was free gift or if itâs supposed to be paid back by this budget, if that will happen again, etc
IMO some key stakeholders should probably abstain from voting on this
But most importantly with so little discussion or debate, does this go and set the precedent that any time in the future funds are lost, workstreams can just turn around and request more and expect to get it?
I hesitated to vote no outright because i knew it would ruffle some feathers, but frankly, it looks pretty clear this is going to pass regardless so itâs more of an ideological pushback. I <3 the MMM team and want the DAO to support you all but I also would like more transparency, accountability, and to establish clear processes.
+1 need more info on workstream impact, new budget items, other funding sources in the interim (csdo) etc
No, this should not negatively impact the workstream. Because of how MMM operates, MMM often ends up with a large surplus at the end of each season. Looking ahead, it is fairly easy to estimate that MMM will come under the amount that theyâve requested, hence the lower budget request.
I think this is worth a larger discussion on how to treat situations like this. Technically a Snapshot vote was done to guarantee these funds, and now we had this situation + MMM is requesting a reduced amount that still will get them to the end of the season.
Maybe to move this conversation forward - what do you think are the pros/cons of running another Snapshot vote? What is the intention of doing that and what outcome are we hoping to achieve? Maybe letâs start there and we can get to the bottom of some sort of procedure we can put in place (and codified in our governance manual that I shared in a separate post).
Appreciate the thoughtful post, Connor. Would love to address a few of your comments and use your post to springboard the discussion that youâre seeing has been missing.
I think what would be helpful here is an actual discussion starter, maybe:
Some questions to get us started pondering how to handle future situations like this
A strawman for others to comment on and eventually arrive at a satisfactory conclusion
This would be super helpful to advancing the conversation.
I wouldnât worry too much about this comment - this is almost a sidebar convo and Laura will be posting about this in the coming days to explain why MMMâs budget is not going up at the same time as everyone elseâs.
What would have you feel like âreal ownershipâ has been taken? Are there any specific actions youâd like to see?
Apologies for not acknowledging this in the gov forum and only discussing this in CSDO channels. Funds were borrowed from the CSDO multisig in order to be able to pay contributors at the end of the month.
As soon as MMM receives funds for work completed in September, the full amount will be sent back to the CSDO multisig. @Sov had already flagged this and we will be creating new procedures around the use of the CSDO multisig moving forward to ensure transparency (that will ultimately be documented in the Governance Manual.
Would love your support on leading this discussion! If you have a place for us to start that would be super helpful and consider me your partner in driving this conversation and documenting its outcome for future implementation.
I voted âAbstainâ because my self delegated tokens wont make an impact on the decision and would be more visible in grey than in red.
Connor raises many valid concerns.
I thought these severance payments bundled with Devconnect expenses was a result of the mistake, but it is unclear. These could have been separated in sub bullet points for clarity.
+1 - With more clarity on the use of these funds, this vote does seem rushed and prevents proper procedures to be put in place through DAO participation. The idea of a DAO Guardians sounds redundant now that the DAO Infra Workstream (?) proposal (?) went up.
Bullish on this idea. Leaning in favor of this being a community led initiative (as it aligns with new EIs), rather than this being caked into another workstreamâs roadmap.
Up to. I think that self delegation sometimes itâs indifferent for the protocol but if we raise hands in the same way itâs more visible and valuable.
Thanks for the clarification, i was under the mistaken impression that gitcoin management reduced MMMâs budget for no fault of theirs and it would adversely impact their functioning.
Yes my thinking was that the snapshot vote was for allocating a certain amount X. Changing that to another amount Y requires a fresh vote as there are budgetary implications.
Hey everyone, I started a new thread to discuss governance we can put in place to create more clarity around how to handle situations like this moving forward.
mechanisms but still think that the method to send a small test transaction of $1 would be helpful regardless.
even refurbished kudos on PGN or other L2 options that align with the ecosystem such as Optimism.
from 
