Both contracts/escrow/src/lib.rs and contracts/milestones/src/lib.rs define pub const MAX_SPONSORS: u32 = 20 and enforce it (TooManySponsors) to bound per-contributor loops to a small, predictable constant. contracts/maintenance-pool/src/lib.rs has no equivalent constant or check on deposit_count at all — deposit() increments it unconditionally on every call, forever (see also the separate, already-filed #45 about the unchecked-increment overflow panic this enables).
Beyond the overflow-panic fix #45 tracks, this is a design inconsistency worth resolving deliberately: either give maintenance-pool the same kind of bounded-deposit-count model escrow/milestones use for contributors (with a documented reason a "recurring, open-ended" pool doesn't need one, if that's the intended design), or explicitly cap it.
Both
contracts/escrow/src/lib.rsandcontracts/milestones/src/lib.rsdefinepub const MAX_SPONSORS: u32 = 20and enforce it (TooManySponsors) to bound per-contributor loops to a small, predictable constant.contracts/maintenance-pool/src/lib.rshas no equivalent constant or check ondeposit_countat all —deposit()increments it unconditionally on every call, forever (see also the separate, already-filed #45 about the unchecked-increment overflow panic this enables).Beyond the overflow-panic fix #45 tracks, this is a design inconsistency worth resolving deliberately: either give maintenance-pool the same kind of bounded-deposit-count model escrow/milestones use for contributors (with a documented reason a "recurring, open-ended" pool doesn't need one, if that's the intended design), or explicitly cap it.