From f0defbc63e14c69c6962eee1b7142860bfc7c885 Mon Sep 17 00:00:00 2001
From: Noah Litvin <335975+noahlitvin@users.noreply.github.com>
Date: Tue, 26 Mar 2024 14:32:33 -0400
Subject: [PATCH] SIP-369

---
 content/sips/sip-369.md | 59 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)
 create mode 100644 content/sips/sip-369.md

diff --git a/content/sips/sip-369.md b/content/sips/sip-369.md
new file mode 100644
index 000000000..543017521
--- /dev/null
+++ b/content/sips/sip-369.md
@@ -0,0 +1,59 @@
+---
+sip: 369
+title: Remove Maximum Rewards Distributors Limit
+network: Ethereum, Optimism & Base
+status: Draft
+type: Governance
+author: 'Noah Litvin (@noahlitvin)'
+created: 2024-03-26
+---
+
+<!--You can leave these HTML comments in your merged SIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new SIPs. Note that an SIP number will be assigned by an editor. When opening a pull request to submit your SIP, please use an abbreviated title in the filename, `sip-draft_title_abbrev.md`. The title should be 44 characters or less.-->
+
+## Simple Summary
+
+<!--"If you can't explain it simply, you don't understand it well enough." Simply describe the outcome the proposed changes intends to achieve. This should be non-technical and accessible to a casual community member.-->
+
+This SIP proposes to remove the maximum rewards distributions limit in the rewards manager module, originally implemented with [SIP-305](https://sips.synthetix.io/sips/sip-305/).
+
+## Abstract
+
+<!--A short (~200 word) description of the proposed change, the abstract should clearly describe the proposed change. This is what *will* be done if the SIP is implemented, not *why* it should be done or *how* it will be done. If the SIP proposes deploying a new contract, write, "we propose to deploy a new contract that will do x".-->
+
+Currently, a pool owner may only register a maximum of 10 rewards distributors per pool. This change entails simply removing this limit.
+
+## Motivation
+
+<!--This is the problem statement. This is the *why* of the SIP. It should clearly explain *why* the current state of the protocol is inadequate.  It is critical that you explain *why* the change is needed, if the SIP proposes changing how something is calculated, you must address *why* the current calculation is inaccurate or wrong. This is not the place to describe how the SIP will address the issue!-->
+
+This check was originally added as safety mechanism, to prevent a pool owner from registering so many rewards distributors that the `removeRewardsDistributor` function call would fail due to requiring too much gas to execute.
+
+The decision to set this at 10 was effectively arbitrary and, as more use cases are being explored for rewards distributors (such as distributing liquidated margin collateral from markets), exceeding 10 distributors seems like an increasingly realistic scenario.
+
+## Rationale
+
+<!--This is where you explain the reasoning behind how you propose to solve the problem. Why did you propose to implement the change in this way, what were the considerations and trade-offs. The rationale fleshes out what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
+
+Especially as Synthetix is primarily being deployed on gas-efficient blockchains, this check is now seen as less crucial. Pool owners can be expected to take responsibility for avoiding adding so many rewards distributors to their pool such that there are negative consequences related to gas usage.
+
+## Technical Specification
+
+<!--The technical specification should outline the public API of the changes proposed. That is, changes to any of the interfaces Synthetix currently exposes or the creations of new ones.-->
+
+Remove `_MAX_REWARD_DISTRIBUTIONS` and the check that relies on this value from `RewardsManagerModule.sol` in the core system.
+
+### Test Cases
+
+<!--Test cases for an implementation are mandatory for SIPs but can be included with the implementation..-->
+
+A test could demonstrate that 11 different rewards distributors can be added and then removed from a pool.
+
+### Configurable Values (Via SCCP)
+
+<!--Please list all values configurable via SCCP under this implementation.-->
+
+N/A
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).