diff --git a/proposals/4060-room-rules.md b/proposals/4060-room-rules.md
new file mode 100644
index 00000000000..997ad76aa7a
--- /dev/null
+++ b/proposals/4060-room-rules.md
@@ -0,0 +1,101 @@
+# MSC4060: Accept room rules before speaking
+
+A common feature among other chat platforms is a requirement for users to
+acknowledge that they've read the room's rules before they're allowed to send
+a message. It's typically a challenge to implement such a feature reliably as
+there's rarely anything preventing an automated client from accepting the rules
+and promptly spamming, however for the typical case a sufficient barrier is
+simply one which appears *most* of the time in front of users.
+
+This proposal introduces a feature where rooms can define rules that users must
+accept before they're allowed to speak. Perhaps controversially, this MSC does
+*not* require a new room version as it does not tie acceptance of the rules into
+the event authorization rules. This is a deliberate choice as a change in rules
+would constitute a requirement that all past agreements are rendered invalid,
+which may be a desired trait in some communities but not all. This is explored
+in a little bit more detail in the Alternatives section.
+
+## Proposal
+
+A new `m.room.rules` state event with empty string state key is defined to
+contain the rules themselves. Like [MSC3765](https://github.com/matrix-org/matrix-spec-proposals/pull/3765),
+this is done using Extensible Events:
+
+```jsonc
+{
+  "type": "m.room.rules",
+  "state_key": "",
+  "content": {
+    "m.text": [
+      {"body": "1. Don't be mean\n2. Be kind"},
+      {"mimetype": "text/html", "body": "<ol><li>Don't be mean</li><li>Be kind</li></ol>"}
+    ]
+  }
+  // other fields not shown
+}
+```
+
+A user "accepts" the rules by referencing the rules event. **TODO**: Pick method.
+
+**TODO**: Options include:
+
+1. [MSC4058](https://github.com/matrix-org/matrix-spec-proposals/pull/4058) -
+   the accepting user adds some structured metadata to the rules event.
+2. [MSC4059](https://github.com/matrix-org/matrix-spec-proposals/pull/4059) -
+   if changed to support mutations from unoriginal senders, mutating the event
+   content in some way. This is probably dangerous though.
+3. [Event relationships](https://spec.matrix.org/v1.8/client-server-api/#forming-relationships-between-events) -
+   like we've done for pretty much everything else.
+
+When `m.room.rules` is present in a room, and the user hasn't accepted them, the
+client SHOULD prompt the user to accept the rules before allowing them to send
+a message. In this MSC, it is expected that a bot will enforce acceptance before
+allowing the user to send a message. For example, redacting all of the user's
+events.
+
+Servers SHOULD require the user to accept the rules before allowing them to send
+events in the room.
+
+Notable exceptions for clients, servers, and moderation bots are events which
+are required for accepting the rules and membership events (ie: leaving rather
+than accepting).
+
+It is expected that a future MSC will define a structure or system to *require*
+acceptance of the rules at the room level, potentially tied into a
+[MSC4056](https://github.com/matrix-org/matrix-spec-proposals/pull/4056)-style
+role. Using a role would allow a subset of users to bypass the rules (in cases
+where they can't be bridged, for example), require this MSC's soft limit
+approach, or enforce the rules via event authorization.
+
+## Potential issues
+
+**TODO**: Detail.
+
+## Alternatives
+
+This MSC deliberately does not tie acceptance of the rules into the event
+authorization algorithm. Doing so with the current power level structure in
+Matrix rooms could potentially lead to over-imposed opinions on what it means
+to "speak" in a room, as well as requiring users to frequently accept rule
+changes.
+
+Instead, this MSC asks that a bot or local server make the decisions on what is
+allowable before acceptance, and whether the rules need to be accepted every
+time or not. It is expected that the protocol will eventually support many of
+the constraints implemented by these servers and bots through future MSCs, such
+as the role-based access control approach described in the proposal text above.
+
+## Security considerations
+
+**TODO**: Detail.
+
+## Unstable prefix
+
+While this MSC is not considered stable, implementations should use
+`org.matrix.msc4060.room.rules` in place of `m.room.rules`.
+
+**TODO**: Describe prefix for "accepting" the rules too.
+
+## Dependencies
+
+**TODO**: Declare.