[meetestherpeter]

Summary

Harden governor & treasury_streams initialization and governor vote arithmetic

What was solved

#580 — [High] governor::initialize has no authorization check at all — anyone can claim and configure a freshly-deployed governor

Add an authorization check to governor::initialize so an arbitrary caller cannot front-run and configure a freshly-deployed governor. The issue's preferred approach is migrating to Soroban's __constructor pattern (as timelock does), which removes the front-running window entirely; alternatively, add an explicit require_auth() on the deploying admin. The fix must include a test confirming an unauthorized caller cannot initialize the contract.

Addressed:

• Changed: governor/src/lib.rs
• initialize (or its constructor-pattern replacement) must not be callable/front-runnable by an unauthorized party
• Add a test confirming an arbitrary caller cannot successfully initialize the contract
• Follow the sibling-contract pattern of explicit require_auth() on the admin, or migrate to __constructor per timelock/src/lib.rs precedent

#581 — [High] treasury_streams::initialize has the identical missing-authorization bug as governor (#120)

Add an explicit authorization check to treasury_streams::initialize so an unauthorized party cannot front-run initialization and set themselves as governor. The fix mirrors the sibling governor crate pattern (issue #120): require auth from the supplied governor address before persisting it, and add a test confirming an unauthorized caller is rejected.

Addressed:

• Changed: treasury_streams/src/lib.rs, treasury_streams/Cargo.toml
• Add governor.require_auth() (or equivalent explicit auth check) in treasury_streams::initialize before writing DataKey::Governor to storage
• Preserve existing AlreadyInitialized guard and all other initialize behavior
• Add a test confirming initialize cannot be front-run by an unauthorized party (auth failure)

#582 — [High] governor's vote-tally and deadline arithmetic uses raw, unchecked operators instead of this codebase's established checked_*/saturating_* convention

Replace unchecked vote-tally accumulation and deadline arithmetic in governor/src/lib.rs with checked arithmetic that fails closed with dedicated errors, and add a boundary test. Scope is limited to the four arithmetic sites in cast_vote and propose (for/against/abstain tallies and the snapshot+delay+period deadline), optionally factoring the deadline into a single helper to remove duplication.

Addressed:

• Changed: governor/src/lib.rs
• Replace proposal.for_votes += power with checked_add, panicking with a dedicated error on overflow
• Replace proposal.against_votes += power and proposal.abstain_votes += power with checked_add and dedicated overflow errors
• Replace the snapshot + config.voting_delay + config.voting_period expression in propose with a checked_add chain (or a single helper) that fails closed

Changes

• treasury_streams/src/lib.rs (modify)
• governor/src/lib.rs (modify)
• treasury_streams/Cargo.toml (modify)

Approach

1. [High] governor::initialize has no authorization check at all — anyone can claim and configure a freshly-deployed governor #580 — [High] governor::initialize has no authorization check at all — anyone can claim and configure a freshly-deployed governor (Changed: governor/src/lib.rs)
2. [High] treasury_streams::initialize has the identical missing-authorization bug as governor (#120) #581 — [High] treasury_streams::initialize has the identical missing-authorization bug as governor (Add a distinct 'pauser' role separate from full admin #120) (Changed: treasury_streams/src/lib.rs, treasury_streams/Cargo.toml)
3. [High] governor's vote-tally and deadline arithmetic uses raw, unchecked operators instead of this codebase's established checked_*/saturating_* convention #582 — [High] governor's vote-tally and deadline arithmetic uses raw, unchecked operators instead of this codebase's established checked_*/saturating_* convention (Changed: governor/src/lib.rs)

Issues

Closes #580
Closes #581
Closes #582

[drips-wave]

@meetestherpeter Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits