Governance & Audit Lifecycle

The shipping cadence

Security work has its own clock, separate from product. A defensible rhythm for a serious DeFi protocol:

Bug-bounty program design

A bug bounty isn't a marketing artifact — it's a contract between the protocol and the security research community. Design it carefully.

Platform choice

• Immunefi — largest, mature triage, charges a fee on payouts but reduces operational burden.
• Hats Finance — on-chain bounty payouts via vault, decentralized.
• Cantina — newer, integrates with Cantina's audit/contest products.
• In-house — only if you have the staff. Disclosure address + clear scope page + payout guarantees.

Scope clarity

Scope ambiguity is the #1 source of bounty disputes. Be explicit about:

• Which contract addresses (with chain IDs).
• Which commit hash if pre-deploy.
• Which categories are in scope (smart contracts, frontend, infra, oracles).
• What's out of scope (known issues, accepted risks, social engineering, third-party deps).
• What "in production" means (mainnet only? testnet too?).

Severity payouts

Industry-standard tiers, roughly:

Critical payouts can scale with funds-at-risk — e.g., 10% of funds at risk, capped at $X. Cap aggressively to keep the program economically sustainable.

KYC and disclosure terms

Most DeFi bounties pay anonymously up to a threshold (often $50k) and require KYC above that, for AML and sanctions screening. Pre-payment KYC is the rule for treasury-scale payouts. Disclosure typically requires 30-90 days post-fix; the protocol publishes a writeup with credit to the researcher (unless they prefer anonymity).

Retroactive payouts

If a researcher reports a critical bug that was already in the code at the time you launched the program, you pay even if the discovery happened later. Best practice. Some protocols extend retroactive payouts to bugs that were exploited before disclosure was practical.

Bounty triage workflow

The hot path from "a researcher hits submit" to "fix shipped." Your SOP should look something like:

1. T+0: Report lands in the triage inbox (Immunefi / discord / dedicated email).
2. T+1h (initial response SLA): On-call security engineer acknowledges receipt. Sets expectations on response time.
3. T+24h: Initial severity assessment. Reproduction attempt. Possibly: pause the affected functionality if active exploitation is plausible.
4. T+48h: Deduplication against existing open reports. Verdict: valid (with severity), invalid (with reason), or "need more info."
5. T+1 week: Fix in PR. Re-review. CVL invariant added.
6. T+1-4 weeks: Deploy fix to mainnet (timelock permitting).
7. T+disclosure window: Payout. Public writeup with credit.

Communication style

Researchers talk to each other. Bad triage gets the protocol a reputation that costs you future findings. Defensible posture:

• Fast initial response. Even "received, will reply by EOD" within an hour is reassuring.
• Transparent severity reasoning. When you downgrade a finding, explain why. "Likelihood is low because precondition X requires admin compromise" beats "downgraded to medium."
• Don't argue scope. If a finding is technically out-of-scope but valid, pay anyway — at a reduced rate if needed. Goodwill compounds.
• Credit by default. Public credit (with their consent) is part of the payout.

War-room SOP

The war room is what happens when a "this might be exploitable in production" finding lands. The SOP should be drilled at least quarterly.

Composition

• Lead: typically the senior security engineer on-call. Owns decisions, comms.
• Technical contributors: 2-3 engineers familiar with the affected code.
• Comms: someone empowered to author public statements, NOT the lead.
• Multi-sig signers: ready to execute pause / upgrade / migration.
• External observers (optional): trusted security advisors, audit firm contact.

Phases

1. Triage (0-30 min): Validate reproducibility. Confirm scope. Estimate funds at risk.
2. Containment (30 min - hours): Pause affected functions if pause exists. Notify multi-sig signers. Consider white-hat rescue if applicable.
3. Investigation (hours - days): Root cause. Affected addresses. Magnitude.
4. Remediation (days): Patch in branch. Re-review. Audit firm review of fix.
5. Recovery (days - weeks): Deploy patch (timelock). Restore functionality. User notifications.
6. Disclosure (1-4 weeks): Public postmortem.

Comms discipline

• One designated comms voice. Other team members in the war room do not tweet.
• Acknowledge fast ("we are investigating"), commit slowly. Don't speculate on cause or scope before you know.
• Don't reveal exploit details before the patch is deployed.
• Pre-write the "we are pausing" message before you need it.

Conference and publishing strategy

Your protocol's reputation in the security community is part of your job. The shape of contribution:

• Conference talks: DevCon, EthCC, Devconnect, ETHGlobal events, regional events. Technical content with public PoC repo. Aim for 1-2 per year per senior on the team.
• Workshops: Smaller, hands-on. Pair well with new tooling releases.
• Research articles: Long-form writeups on the protocol blog or a personal one. Postmortems, new attack vectors, lessons from formal verification.
• Public PoC repos: Foundry repos demonstrating attack classes or proving invariants. Cite them in talks.
• Disclosure writeups: For every meaningful incident, a public postmortem. Builds trust.

Governance security overlap

Governance is its own attack surface. Issues you should be conversant with:

• Timelock bypass. Most upgradeable protocols have a timelock (24h-7d) between proposal and execution. Bugs: missing timelock on critical functions; ability to clear queue mid-cycle; emergency-bypass too easy to trigger.
• Multi-sig hygiene. N-of-M signer set should have a known threshold; signers should be geo-distributed; recovery process should exist; lost keys should not brick the protocol.
• Governance attacks. Compound Beanstalk: attacker bought voting power, passed malicious proposal, drained treasury. Mitigation: voting delay; proposal threshold; emergency pause / veto.
• Delegation and flash-loan voting. Snapshot at proposal time, not at execution time. Block-snapshot voting prevents flash-loan governance.
• Upgrade authorization. Who can call upgradeTo? It should be the timelock, not the multi-sig directly.

A complete runbook example