diff --git a/content/sips/sip-381.md b/content/sips/sip-381.md
new file mode 100644
index 000000000..562837591
--- /dev/null
+++ b/content/sips/sip-381.md
@@ -0,0 +1,59 @@
+---
+sip: 381
+title: Pool Owner Rewards Distribution Control
+type: Governance
+network: Ethereum, Optimism & Base
+author: 'Daniel Beal (@dbeal-eth),  Noah Litvin (@noahlitvin)'
+status: Draft
+created: 2024-05-05
+---
+
+<!--You can leave these HTML comments in your merged SCCP 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 SCCPs. Note that an SCCP number will be assigned by an editor. When opening a pull request to submit your SCCP, please use an abbreviated title in the filename, `sccp-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." Provide a simplified and layman-accessible explanation of the SCCP.-->
+
+This SIP proposes adding core system functionality such that a pool owner can adjust reward distributions.
+
+## Abstract
+
+<!--A short (~200 word) description of the variable change proposed.-->
+
+The current implementation of the rewards distributor functionality in the core system (per [SIP-305](https://sips.synthetix.io/sips/sip-305/)) only allows the address of a rewards distributor to control the values pertaining to its own amount and timeframe of distribution. The proposed change would add a function such that owner of a pool can also modify these values.
+
+## Motivation
+
+<!--The motivation is critical for SCCPs that want to update variables within Synthetix. It should clearly explain why the existing variable is not incentive aligned. SCCP submissions without sufficient motivation may be rejected outright.-->
+
+Accounting for the distribution of rewards among liquidity positions in pools is handled within the core system. This could fall out sync with the accounting in a rewards distributor contract after it has been integrated with a given pool by the pool's owner. In this case, a rewards distributor may not be able to recover depending on the sophistication of its implementation. By allowing pool owners to also modify these values, corrections become possible if necessary.
+
+Allowing a pool owner to modify the values dictating a rewards distribution should not introduce additional security concerns or trust assumptions, as a pool owner is already capable of adding and removing rewards distributions.
+
+## Specification
+
+<!--The specification should describe the syntax and semantics of any new feature, there are five sections
+1. Overview
+2. Rationale
+3. Technical Specification
+4. Test Cases
+5. Configurable Values
+-->
+
+The implementation of the SIP entails the introduction of a `distributeRewardsByOwner` function. This performs the same operation as the existing `distributeRewards` function, but can be called by the owner of a pool rather than only the rewards distributor itself.
+
+### Test Cases
+
+<!--Test cases for an implementation are mandatory for SIPs but can be included with the implementation..-->
+
+Relevant tests cases have been developed alongside the draft implementation for this SIP.
+
+### 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/).