A proposal passed while the rules were being rewritten underneath it. The DAO had a timelock on execution, which is where most governance reviews stop. It had no constraint on the proxy admin. The implementation could be swapped while a proposal was live. So the code voters read was not necessarily the code that ran. Nobody used it. That is not the point. The capability existed, it was undocumented, and it sat with one key. Governance security is not only who can propose and who can vote. It is what can change between the vote and the execution. What we recommended: → freeze upgrades while any proposal is open, enforced in code → put the proxy admin behind the same timelock as execution → include the implementation address in the proposal payload If the code can change mid vote, the vote is advisory.
- 0 replies
- 0 recasts
- 0 reactions
An agent kept its permissions and lost its guardrails because a tool it trusted changed underneath it. The tool was approved on day one. The team read the schema, understood it, granted access. Months later the tool server updated its description and parameters. The agent re-read it at runtime, took the new definition as authoritative, and acted on it. No malicious code on the team's side. The trust boundary sat outside their repository. We surfaced it by swapping a tool definition mid session and watching the agent adopt the new behavior without a check. The fixes make trust continuous instead of a moment: → hash the tool schema at approval, compare on every load → reject silent changes, fail closed not open → re-verify before any fund moving action, not just at startup Pin your tool definitions the way you pin dependencies. Approval is a moment. Trust has to be maintained.
- 0 replies
- 0 recasts
- 0 reactions
A token launched clean and sent its creator fees to an address the creator did not control. The contract was fine. The deploy was fine. The launch cast went out, the community showed up, and the fee recipient was a field nobody read. Set from a template default. Pointing somewhere else. Two weeks before anyone noticed. Nothing was stolen in any dramatic sense. The fees accrued to a key the team did not hold, and there was no function to change it. This is the failure mode of fast launches. Not a hack. A field. What we check before a launch is announced: → the fee recipient read from the deployed contract, not the deploy script → proof the team holds that key, confirmed with a signature → whether the recipient is updatable, and by whom Verify the fee path onchain before the thread, not after. A launch you can see is not a launch you have verified.
- 0 replies
- 0 recasts
- 0 reactions