diff --git a/proposals/4140-delayed-events-futures.md b/proposals/4140-delayed-events-futures.md
index 7cb50642c..e7445b0cd 100644
--- a/proposals/4140-delayed-events-futures.md
+++ b/proposals/4140-delayed-events-futures.md
@@ -38,7 +38,9 @@ time and then distributing as normal via federation.
   - [MQTT style Last Will](#mqtt-style-last-will)
   - [`M_INVALID_PARAM` instead of `M_MAX_DELAY_EXCEEDED`](#m_invalid_param-instead-of-m_max_delay_exceeded)
   - [Naming](#naming)
-  - [`M_INVALID_PARAM` instead of `M_MAX_DELAY_EXCEEDED`](#m_invalid_param-instead-of-m_max_delay_exceeded)
+  - [Don't provide a `send` action](#dont-provide-a-send-action)
+  - [Use `DELETE` HTTP method for `cancel` action](#use-delete-http-method-for-cancel-action)
+  - [[Ab]use typing notifications](#abuse-typing-notifications)
 - [Security considerations](#security-considerations)
 - [Unstable prefix](#unstable-prefix)
 - [Dependencies](#dependencies)
@@ -717,14 +719,14 @@ The following alternative names for this concept are considered
 - PostponedEvents
 - LastWill
 
-### Don't provide a `send` action
+### Don't provide a `send` action
 
 Instead of providing a `send` action for delayed events, the client could cancel the outstanding delayed event and send
 a new non-delayed event instead.
 
 This would simplify the API, but it's less efficient since the client would have to send two requests instead of one.
 
-### Use `DELETE` HTTP method for `cancel` action
+### Use `DELETE` HTTP method for `cancel` action
 
 Instead of providing a `cancel` action for delayed events, the client could send a `DELETE` request to the same endpoint.