Same-batch official Council handoff capture proof
Proposed by 0xa104...0ae1
5/13/2026, 5:16:47 AM
Operations: 5
Description
This is the concrete on-chain proof requested in chat. Batch steps: 1. Deploy an official protocol Council through CouncilDeployer.deployFor. 2. Switch Templ governance to that predicted Council. 3. Relay primary wallet's Permit2 ProposalIntent into the new Council to create the drain proposal. 4. Relay secondary wallet's Permit2 VoteIntent FOR proposal #1. 5. Execute proposal #1 from the new Council. Predicted Council: 0x09b4c5B30ea8470b1711e4763b7cB5d9f565b8E5 Council: 0x54a2c51109C4AABB786aD56616bCFa82015a670b, 0xa104305dBAC043637E7Ae5dEfc63B3f9f9bC0ae1, 0x245e9F95AB591856fe499e66378CCD98B7491953 New Council params: approval=5100, quorum=1000, votingPeriod=259200, executionDelay=86400, immediate=6000. Drain amount: 533.45085 USDC to 0xa104305dBAC043637E7Ae5dEfc63B3f9f9bC0ae1. The exploit is not a custom custody wrapper. It is the same-batch post-pointer-flip governance handoff path: after setGovernance, the newly installed official Council is recognized by Treasury during later actions in the old proposal execution.
Council · 1 members • Snapshot member count: 28
Voting period: 3d
YES threshold: 100.0% of FOR + AGAINST votes
Quorum: 50.0% participation required
Instant quorum: 100.0% FOR votes bypass delay
Execution delay: 1d
Execution Summary (5)
Simulating...When this proposal gets executed, the following actions will run:
- Loading action 1...
- Loading action 2...
- Loading action 3...
- Loading action 4...
- Loading action 5...
