Incident Regarding Mistransferred Treasury Funds

This post is to inform the Gitcoin ecosystem about an incident of misdirected funds in relation to this Tally proposal: Tally | Gitcoin Proposal

The transfer intended for the MMM’s S19 budget did not land in its multisig, and instead was sent to a GTC token contract. This has rendered the funds stuck in the contract, with no way of recovering them.

Below I outline all the facts about what happened, the timeline of events and steps we are putting in place to ensure that a mistake like this does not happen again.

Relevant Data

  • Total amount transferred: 521.44K GTC
  • Sent to GTC token contract: 0xde30da39c46104798bb5aa3fe8b9e0e1f348163f
  • Proposal was created by Laura (MMM Workstream Lead)
  • Large token holders who signed off on the proposal include:
    • Kyle (ED of the Foundation)
    • Meg (Grants Stack WS Lead)
    • Jeremy (Passport WS Lead)
    • Carl (Steward Council member)
    • Myself (MMM co-lead)


  • Tuesday Sept 19 17:16 - Proposal published onchain
  • Thursday Sept 21 13:24 - Voting period started
    • Sept 22 - Carl, CoachJ, Jeremy votes
    • Sept 25 - Laura and Kyle vote (quorum is now met)
    • Sept 27 - Meg votes
  • Wednesday Sept 27 04:54 - Voting period ended
  • Saturday Sept 30 00:16 - Proposal executed
  • Sunday Oct 1 evening CET - CoachJ informed that funds have not yet landed in MMM’s multisig
  • Monday Oct 2 morning CET - CoachJ connects with Aditya (core dev on Allo) to explore whether the contract has a withdraw function and/or is upgradable
    • Aditya says no, and to double check with the contract owner to make sure
  • Monday Oct 2 6pm CET - CoachJ connects with Kyle to explain the situation and see if the funds are recoverable
    • Kyle says it is unlikely, but will do some digging to see if it is possible
  • Thursday Oct 5 - CoachJ confirms with Kyle that the funds are not recoverable
  • Thursday Oct 5 - CoachJ informs CSDO of the incident

Next steps

The intention of these steps are to:

  1. Create safeguards to ensure something like this never happens again
  2. Create clearer accountability if there is an incident like this again

Action items:

  • All proposals in Snapshot moving forward should have wallet addresses listed if there will be any transfers of funds
  • All proposals in Tally moving forward should have wallet addresses listed if there will be any transfers of funds
    • It is up to the Tally proposal creator to ensure that the funds are being transferred to the correct address based on the Snapshot description
    • It is up to Tally voters to ensure that the funds are being transferred to the correct address based on the Tally description
  • CSDO is going to explore the possibility of implementing a DAO Guardians program
    • DAO Guardians would be individuals contracted to review proposals and ensure their accuracy, particularly around proposals and large transactions
  • We’ve been in contact with the team at Tally who have graciously accepted some feedback requests that they will look to include in their roadmaps, including:
    • If the destination address is not a DAO multisig within our DAO admin address book, a warning will come up and confirm they still want to use the address
    • If an admin has an address labeled, then everyone can see that label (not just the admin) - this way anyone voting will have a better visual cue

Note: Though the Tally team was very receptive to our feedback and is keen to work with us in the future to prevent something like this from happening again, it is important to note that the root cause of this incident was due to human error, not issues with the Tally platform.


It is unfortunate that this incident occurred and I want to apologize on behalf of myself and others involved in this having happened. I am also confident that the steps being put into place will create more safeguards and clear accountability should a situation like this happen again.

Large token holders and multisig signers have a responsibility to be extra diligent when it comes to handling funds that do not belong to them (myself included). Unfortunate as this incident was, I hope it can serve as (yet another) lesson for many of us.

If you have any feedback, concerns or suggestions on other safeguards we can put in place, please leave a comment below.


Just for clarification’s sake, this post is meant to inform that roughly $464K USD from the Gitcoin treasury was lost and is unrecoverable?


Yes @essemharris that is correct.

1 Like

IMO bc the gitcoin treasury is the largest holder of GTC this is more likely to be a permanent reduction in the supply of available GTC than a loss of the DAO’s $USD. Already, we have to be careful with the rate at which we convert GTC into USD because of the downward price pressure. If we are ever in a situation where we have to turn our last 500k GTC into USD then that would be the real issue.

The process improvements that can be made from learning from this incident are so important.


obviously saddened this happened, but thankful its only a small portion of funds relative to the total treasury. i hope we learn something from this.

IMO bc the gitcoin treasury is the largest holder of GTC this is more likely to be a permanent reduction in the supply of available GTC than a loss of the DAO’s $USD.

ill be curious if this narrative of “its actually GTC burned” is seen as legitimate.

If we are ever in a situation where we have to turn our last 500k GTC into USD then that would be the real issue.

FYI the token supply is 100m GTC right now, but CAN be inflated UP TO 2% per year by the governance process calling the mint() function of the GTC smart contract. (But the DAO has never done this) Nor am I advocating for that at this time, I’m only noting it is an option baked into the GTC smart contract.


Thank you for the transparency here. I am extremely sorry for all parties directly affected at no fault of their own. This is a shitty situation all around :frowning:

I agree it should be made extremely clear and redundant where transfers are going. But as laid out, this action item could be even more dangerous. The transaction details and destination address are already laid out front and center, even before the actual description:

Asking voters to verify the address in the description opens the possibility for a malicious actor to put the correct address in the description while the on chain action sends somewhere else (not saying this is likely just thinking out loud).

All large delegates and Tally voters should be DAO Guardians, we don’t need a new special program or to contract anyone for this imo. Obviously, we all screwed up here to let this slip though, but hopefully that’s a huge wake up call to all delegates that they should be a DAO Guardian and need to do light due diligence on what they vote on.

This is certainly not a net positive situation for the DAO, but I think objectively these 500k GTC (.8% of the circulating supply) are stuck forever and burned.


To see organization waste funds in such reckless manner is disappointing.

I don’t care much for “burned/locked” narrative but I am concerned how multiple high-profile DAO individuals misallocated 450k which could have been avoided if even a single person exercised baseline level of due diligence.

I think a short checklist could help Tally voters to follow the motions of validating common budgets proposals without omitting steps or having to think too much about the process. At the minimum:

  • confirm recipient address is known & labeled
  • confirm correct token is being sent
  • check token amount
  • check executable code matches written description

Then you can go in more detail like “Confirm I am NOT sending token DIRECTLY to BRIDGE/TOKENADDRESS where it will get STUCK (again)”


Sorry to hear about this and thank you for the transparency. @Viriya will MMM be able to function as budgeted given this development?


In short @jengajojo, no.

These funds were supposed to provide the MMM workstream with funding for August, September and October.

MMM was able to use funds from S18 (May-July) to pay all its contributors and opex in August. However, MMM has insufficient funds to pay contributors and opex costs for September and October.

We will be re-requesting budget for the two months (a reduced amount, not for the original request of around $500k).

I just posted the new request to Tally here: Tally | Gitcoin Proposal


Should have used Kleros! Maybe next time? :wink:

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.