All we have to go on are the statements, but DEF CON's statement is falsifiable and direct:
After going overbudget by more than 60%, [and] several bad-faith charges
Which, again, pattern matches to a pretty common mode in which consulting projects blow up: you give an optimistic estimate, learn partway into the project that you were hopelessly off, and then try to invoice your way through it.
EE’s statement is about as falsifiable and direct I would say:
Once a month, we billed for our work and submitted an updated estimated per badge final cost - committing as costs built to discount our work as necessary in order to hit DEFCON’s per unit cost targets.
In June, after 5 months of late night work, badges were fully designed, prototypes were working, and mass production was ongoing with the manufacturers we contracted on behalf of DEFCON. We billed DEFCON for our most recent work, discounting our labor by 25% in order to meet the agreed upon targets. Unfortunately, we were instead met with a work stoppage request and informed we would no longer be paid for services already rendered.
Easiest way for me to reconcile these is by assuming that DEF CON’s statement about going 60% over budget is referring to the estimated per badge final cost, not actual invoices. But yea, it’s hard to know what happened here just based on these statements.
I would be very interested to know what DefCon's budget for the badges is, and how much latitude was built in for things like chip shortages, rush shipping, etc. A big project like this, especially during major geopolitical strive, could have all sorts of unforseen complications. DefCon has been around the block a few times and should know how to handle things. But without details, it's impossible to know for sure.
This one seemed a bit riskier, using the new Raspberry Pi microcontroller that's not even for sale yet. Granted, the parts were probably donated, but getting the timelines right must have been a concern.
That's the thing that's weird to me. If DEFCON had a hard cost limit that they were unwilling to go over, structuring the contract with monthly invoicing based on materials and ongoing labor costs makes no sense. It would seem to me that the only sane way to do this would be to make it a fixed-cost $X contract, and the only monthly (or otherwise periodic) part of it would be to split payments by milestone or by some other rubric.