diff --git a/proposals/3909-membership-based-mutes.md b/proposals/3909-membership-based-mutes.md
new file mode 100644
index 000000000..472579e31
--- /dev/null
+++ b/proposals/3909-membership-based-mutes.md
@@ -0,0 +1,103 @@
+# MSC3909: Membership based mutes
+
+## Introduction
+
+As covered in in MSC3907 currently in matrix mutes are done via powerlevel manipulation.
+This MSC has the simple purpose of defining a path forward that alleviates this problem. Yes it does
+require a room version bump but this MSC will explain why this is an acceptable compromise.
+
+To achieve Mutes via membership a new membership state is proposed of `mute`. It would allow you to
+exclusively send Read markers and exempt events as defined later.
+
+A passive benefit of this MSC that is notable is that with the introduction of Partial joining of rooms the minimum
+state to join said room is important. As far as the authors understand this state is obligatorily going to be
+negatively effected by PL events climbing in number. This MSC mitigates this and this is a real world
+relevant example of why this MSC matters.
+## Proposal
+
+This proposal defines the `mute` membership type. If a user has this membership type in a room they
+are restricted to exclusively sending receipts, leaving via setting
+
+their membership to `leave-mute` as defined later and `m.room.redaction` events.
+
+This proposal also introduces the new membership type of `leave-mute` this special membership
+is set if a user leaves the room while their membership is `mute` this way you can still leave
+rooms while muted without introducing a security flaw.
+
+The legal transitions for the `mute` membership type based on Room version 10 would be
+`join` -> `mute` -> `leave-mute`, `join`(Requires sufficient PL to set membership to `mute`), `leave`(Exclusively via kick),
+`ban`.
+
+The legal transitions for the `leave-mute` membership type based on Room version 10 would be
+`mute` -> `leave-mute` -> `invite`(Requires sufficient PL to set membership to `mute` and to set membership to `invite`) , 
+`leave-mute`, `leave`(Requires sufficient PL to set membership to `mute`) `ban`.
+
+### Authorisation rules.
+
+To be written. Contributions welcome.
+## Potential issues
+
+On the potential issue that this MSC requires rooms that want to employ it to be created after the room version
+its included in becomes default or their homeserver makes it default or they manually select it for an upgrade is
+deemed acceptable. The reason this is deemed acceptable is because as has been made clear in discussions with
+community moderation teams for multiple communities not all communities want to use mutes in their toolkit and therefore
+not all communities will feel the need to upgrade their room version to gain access to this feature. 
+
+The UX around room version upgrades is being worked upon to make them less disruptive. There is work in 
+the area of deleting state for example that requires better room version upgrade mechanics. There is also history importing 
+work being done as another avenue of lessening the impact of room version upgrades in the future. 
+
+The authors of this MSC believes that communities that desire to use this MSC to its full potential are perfectly happy
+to accept the compromises involved in a room version bump. This MSCs purpose can be achieved via powerlevels 
+in earlier room versions. This comes at the cost of a skyrocketing state resolution complexity but this is always
+an option for communities that don't want to upgrade their room version or if this MSC fails.
+
+The authors of this MSC are not aware of any other potential issues that have not been covered elsewhere in this MSC.
+
+## Alternatives
+
+The alternative of staying with our current Mutes as PL way has been dismissed as undesirable due to the
+scaling issues. And also for the fact that it makes state resolution complexity grow at a faster rate
+due to that powerlevels have to all be resolved always.
+
+Going the path of RBAC or another powerlevels overhaul was also dismissed because this MSC intends to in
+a perfect world be able to be implemented quite quickly in a vacuum that is not tied to any other MSC.
+
+## Security considerations
+
+The `mute` membership type is going to be yet another thing that you can mess up implementing and that is
+recognised as an ok. The authors of this MSC believes that is an acceptable compromise since we avoid
+the PL churn of current mute implementations. The ability to bypass a mute by leaving the room is mitigated
+by the `leave-mute` membership type while still allowing full normal functionality except for re-joining a room via invite
+as muted.
+
+Because redactions are exempt from Mutes for privacy reasons this does re open the exploit that is closed by denying profile
+updates on paper. This exploit does not in practice get reintroduced to any large degree as clients don’t render redact
+reasons. And it is recommended that stakeholders that are worried about this abuse path use clients that render so called hidden
+events so you can see the redactions to observe if they have suspicious patterns. 
+## Unstable prefix
+
+This MSC is not recommended to be implemented before Authorisation rules are properly specified but if implemented.
+Please use the version string of `support.feline.mute.msc3909.v0.2`
+
+Once Authorisation rules are specified it's expected that the unstable version after that is v1. This is because the
+pre authorisation rules properly written down version cant be trusted to interoperate and this is why its NOT recommended 
+to implement a version that is based on this MSC before that section is written. 
+
+## Historical Prefixes
+
+`support.feline.mute.msc3909.v0` was the prefix for the first iteration of the MSC. This prefix was for when self banning
+was included.
+
+`support.feline.mute.msc3909.v0.1` was the prefix for the second iteration of the MSC. This prefix was current before
+the bug that ban was omitted from the transitions was fixed and redactions are now legal for muted parties to issue.
+
+## Dependencies
+
+This MSC builds on MSC3907, MSC3908 and MSC3784 (which at the time of writing have not yet been accepted
+into the spec).
+
+It does not require any of these MSCs to be implemented but it works best when implemented together with the rest of these MSCs.
+
+MSC3907 to coordinate mutes via policy list, MSC3908 to make temporary mutes an option when coordinated via policy lists
+and MSC3784 to help enable building better user experiences interacting with policy lists.