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:
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:
executable code matches written descriptionThen 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? 
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:
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 
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 ?
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?
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:
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
+100
