diff --git a/proposals/4354-sticky-events.md b/proposals/4354-sticky-events.md
index abcc60ba8..02147c779 100644
--- a/proposals/4354-sticky-events.md
+++ b/proposals/4354-sticky-events.md
@@ -46,7 +46,8 @@ which is the number of milliseconds for the event to be sticky. The presence of
 with a valid value makes the event “sticky”[^stickyobj]. Valid values are the integer range 0-3600000 (1 hour).
 For use cases that require stickiness beyond this limit, the application is responsible for sending another
 event to make it happen. The `sticky` key is not protected from redaction. A redacted sticky event is the same
-as a normal event. Note: this new top-level object is added to the [`ClientEvent` format](https://spec.matrix.org/v1.16/client-server-api/#room-event-format).
+as a normal event. Note: this new top-level object is added to the [`ClientEvent` format](https://spec.matrix.org/v1.16/client-server-api/#room-event-format)
+and the [`Persistent Data Unit`](https://spec.matrix.org/v1.16/rooms/v12/#event-format-1) for each room version.
 
 ```json
 {
@@ -70,10 +71,8 @@ added to the following endpoints:
 To calculate if any sticky event is still sticky:
 
 * Calculate the start time:  
-  * The start time is `min(now, origin_server_ts)`. This ensures that malicious origin timestamps cannot
+  * The start time is `min(received_ts, origin_server_ts)`. This ensures that malicious origin timestamps cannot
     specify start times in the future.  
-  * If the event is pushed over federation via `/send`, servers MAY use the current time as the start time instead. This minimises
-    the risk of clock skew causing the start time to be too far in the past. See “Potential issues \> Time”.  
 * Calculate the end time as `start_time + min(sticky_duration_ms, 3600000)`.  
 * If the end time is in the future, the event remains sticky.