Incident Regarding Mistransferred Treasury Funds

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.


i did post this on twitter and there were some sympathetic views towards this perspective.

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 :ballot_box: 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.

1 Like

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. :ballot_box:

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 :thinking: 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 :arrow_up: from @DistributedDoge ! :dog2:

1 Like

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 ?


I’d love to see this. I’m adding this to the roadmap, hoping we can tackle this in S20 (starting next month) or S21 at the latest.


Sorry to hear about this!

How do you all feel about doing test transactions for anything above a certain amount?

Obviously it’s a balance between this not slowing down ops too much & securely avoiding situations like this.

What do you think the number would be that enables a nice balance between those things? 50K? 100K?

1 Like

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.

1 Like

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.

1 Like

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.


gm all,

here is my proposal to prevent an incident like this from happening in the future: Gitcoin WalletGuard 🛡️


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.