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)
Timeline
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:
Create safeguards to ensure something like this never happens again
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.
Conclusion
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.
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
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)â
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).
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 ?
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 