From b135726ea45188ecd40186dec7be53c85f2d02c8 Mon Sep 17 00:00:00 2001
From: Kegan Dougal <7190048+kegsay@users.noreply.github.com>
Date: Fri, 26 Sep 2025 15:57:35 +0100
Subject: [PATCH] Update 4354-sticky-events.md

---
 proposals/4354-sticky-events.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/proposals/4354-sticky-events.md b/proposals/4354-sticky-events.md
index ee71fb97e..920b8d622 100644
--- a/proposals/4354-sticky-events.md
+++ b/proposals/4354-sticky-events.md
@@ -347,7 +347,7 @@ a standardised mechanism for determining keys on sticky events, the `content.sti
 ```
 
 `content.sticky_key` is ignored server-side[^encryption] and is purely informational. Clients which
-receive a sticky event with a sticky key SHOULD keep a map with keys determined via the 3-uple[^4uple]
+receive a sticky event with a `sticky_key` SHOULD keep a map with keys determined via the 3-uple[^4uple]
 `(room_id, sender, content.sticky_key)` to track the current values in the map. Nothing stops
 users sending multiple events with the same `sticky_key`. To deterministically tie-break, clients which
 implement this behaviour MUST: