diff --git a/53.md b/53.md
index 523a998b..a0270e51 100644
--- a/53.md
+++ b/53.md
@@ -10,7 +10,7 @@ This NIP introduces event kinds to advertise live spaces and the participation o
 
 ## Live Streaming
 
-A special event with `kind:30311` "Live Streaming Event" is defined as an _addressable event_ whose tags advertise the content and participats of a live stream. 
+A special event with `kind:30311` "Live Streaming Event" is defined as an _addressable event_ whose tags advertise the content and participants of a live stream.
 
 Each `p` tag SHOULD have a **displayable** marker name for the current role (e.g. `Host`, `Speaker`, `Participant`) of the user in the event and the relay information MAY be empty. This event will be constantly updated as participants join and leave the activity.
 
@@ -63,7 +63,7 @@ This feature is important to avoid malicious event owners adding large account h
 
 ### Live Chat Message
 
-Event `kind:1311` is live chat's channel message. Clients MUST include the `a` tag of the activity. An `e` tag denotes the direct parent message this post is replying to. 
+Event `kind:1311` is live chat's channel message. Clients MUST include the `a` tag of the activity. An `e` tag denotes the direct parent message this post is replying to.
 
 ```jsonc
 {
@@ -249,9 +249,9 @@ Event management:
 ```
 ### Room Presence
 
-New `kind: 10312` provides an event which signals presence of a listener. 
+New `kind: 10312` provides an event which signals presence of a listener.
 
-The presence event SHOULD be updated at regular intervals and clients SHOULD filter presence events older than 
+The presence event SHOULD be updated at regular intervals and clients SHOULD filter presence events older than
 a given time window.
 
 **This kind `10312` is a regular replaceable event, as such presence can only be indicated in one room at a time.**
diff --git a/EE.md b/EE.md
index 6b24e0d9..090fa29f 100644
--- a/EE.md
+++ b/EE.md
@@ -82,7 +82,7 @@ This is a concise overview of the security trade-offs and considerations of this
 
 ### Forward Secrecy and Post-compromise Security
 
-- As per the MLS spec, keys are deleted as soon as they are used to encrypt or decrypt a message. This is usually handled by the MLS implementation library itself but attention needs to be paid by clients to ensure they're not storing secrets (expecially the [exporter secret](#group-events)) for longer than absolutely necessary.
+- As per the MLS spec, keys are deleted as soon as they are used to encrypt or decrypt a message. This is usually handled by the MLS implementation library itself but attention needs to be paid by clients to ensure they're not storing secrets (especially the [exporter secret](#group-events)) for longer than absolutely necessary.
 - This NIP maintains MLS forward secrecy and post-compromise security guarantees. You can read more about those in the MLS Architectural Overview section on [Forward Secrecy and Post-compromise Security](https://www.ietf.org/archive/id/draft-ietf-mls-architecture-15.html#name-forward-and-post-compromise).
 
 ### Leakage of various keys