diff --git a/.github/_typos.toml b/.github/_typos.toml
index d227af4c..2e7159b7 100644
--- a/.github/_typos.toml
+++ b/.github/_typos.toml
@@ -8,3 +8,4 @@ OTKs = "OTKs"
 [default.extend-words]
 OTK = "OTK"
 OTKs = "OTKs"
+Iy = "Iy"
diff --git a/.github/workflows/spell-check.yaml b/.github/workflows/spell-check.yaml
index 11f01938..ff444616 100644
--- a/.github/workflows/spell-check.yaml
+++ b/.github/workflows/spell-check.yaml
@@ -14,6 +14,6 @@ jobs:
       uses: actions/checkout@v4
 
     - name: Check spelling of proposals
-      uses: crate-ci/typos@9be36f97fdbe645ee9a12449fb13aca856c2516a
+      uses: crate-ci/typos@f2c1f08a7b3c1b96050cb786baaa2a94797bdb7d # v1.20.10
       with:
         config: ${{github.workspace}}/.github/_typos.toml
diff --git a/proposals/1711-x509-for-federation.md b/proposals/1711-x509-for-federation.md
index 7fd90560..ef351ade 100644
--- a/proposals/1711-x509-for-federation.md
+++ b/proposals/1711-x509-for-federation.md
@@ -174,7 +174,7 @@ certificates comes with a number of downsides.
 
 Configuring a working, federating homeserver is a process fraught with
 pitfalls. This proposal adds the requirement to obtain a signed certificate to
-that process. Even with modern intiatives such as Let's Encrypt, this is
+that process. Even with modern initiatives such as Let's Encrypt, this is
 another procedure requiring manual intervention across several moving parts.
 
 On the other hand: obtaining an SSL certificate should be a familiar process to
diff --git a/proposals/1884-replace-slashes-in-event_ids.md b/proposals/1884-replace-slashes-in-event_ids.md
index bec8d7ad..7ae91102 100644
--- a/proposals/1884-replace-slashes-in-event_ids.md
+++ b/proposals/1884-replace-slashes-in-event_ids.md
@@ -88,7 +88,7 @@ right encoding.
    A potential extension would be to change *all* Base64 encodings to be
    URL-safe. This would address the inconsistency. However, it feels like a
    large job which would span the entire matrix ecosystem (far larger than
-   updating clients to URL-encode their URL prarameters), and again the
+   updating clients to URL-encode their URL parameters), and again the
    situation would be confusing while the transition was in progress.
 
 2. Incompleteness. Event IDs are certainly not the only identifier which can
diff --git a/proposals/2140-terms-of-service-2.md b/proposals/2140-terms-of-service-2.md
index c7a4fbf8..df505d9f 100644
--- a/proposals/2140-terms-of-service-2.md
+++ b/proposals/2140-terms-of-service-2.md
@@ -34,7 +34,7 @@ way that Homeservers do.
 
 ## Proposal
 
-Throuhgout this proposal, $prefix will be used to refer to the prefix of the
+Throughout this proposal, $prefix will be used to refer to the prefix of the
 API in question, ie. `/_matrix/identity/v2` for the IS API and
 `/_matrix/integrations/v1` for the IM API.
 
diff --git a/proposals/2677-reactions.md b/proposals/2677-reactions.md
index 41d85ebd..18e789c0 100644
--- a/proposals/2677-reactions.md
+++ b/proposals/2677-reactions.md
@@ -51,7 +51,7 @@ property should contains a `key` that indicates the annotation being
 applied. For example, when reacting with emojis, the `key` contains the emoji
 being used.
 
-An event annotating another with the thumbs-up emoji would therefore have the following `m.relates_to` propperty:
+An event annotating another with the thumbs-up emoji would therefore have the following `m.relates_to` property:
 
 ```json
 "m.relates_to": {
diff --git a/proposals/2870-protect-acls-from-redaction.md b/proposals/2870-protect-acls-from-redaction.md
index aa526bf9..48abc6f9 100644
--- a/proposals/2870-protect-acls-from-redaction.md
+++ b/proposals/2870-protect-acls-from-redaction.md
@@ -40,7 +40,7 @@ the room administrator's understanding of their room's function.
 
 Another possible approach is to have servers prevent sending faulty ACL events by preventing their
 local clients from doing so, such as by rejecting redaction requests. This doesn't solve the issue
-over federation, but can reduce the liklihood of such events making it to the federation layer. This
+over federation, but can reduce the likelihood of such events making it to the federation layer. This
 is what Synapse currently does to help mitigate the issue. This is only effective if the server (or
 client, locally) implements it - it's common for both clients and servers to forget to add these checks
 during development, leading to occasional room breakage. This MSC instead tries to resolve the issue
diff --git a/proposals/3030-jump-to-date.md b/proposals/3030-jump-to-date.md
index 75f3af15..189c9330 100644
--- a/proposals/3030-jump-to-date.md
+++ b/proposals/3030-jump-to-date.md
@@ -152,7 +152,7 @@ the room was created.
 ## Alternatives
 
 We chose the current `/timestamp_to_event` route because it sounded like the
-easist path forward to bring it to fruition and get some real-world experience.
+easiest path forward to bring it to fruition and get some real-world experience.
 And was on our mind during the [initial discussion](https://docs.google.com/document/d/1KCEmpnGr4J-I8EeaVQ8QJZKBDu53ViI7V62y5BzfXr0/edit#bookmark=id.qu9k9wje9pxm) because there was some prior art with a [WIP
 implementation](https://github.com/matrix-org/synapse/pull/9445/commits/91b1b3606c9fb9eede0a6963bc42dfb70635449f)
 from @erikjohnston. The alternatives haven't been thrown out for a particular