diff --git a/libcuframes/src/consumer.c b/libcuframes/src/consumer.c
index 5cc8b33..fce8170 100644
--- a/libcuframes/src/consumer.c
+++ b/libcuframes/src/consumer.c
@@ -322,15 +322,22 @@ int cuframes_subscriber_next(cuframes_subscriber_t *sub,
                 if (cerr != cudaSuccess) return CUFRAMES_ERR_CUDA;
             }
 
-            /* TOCTOU защита (v0.2 fallback only): legacy single event signals
-             * для последнего published frame. v0.3 per-slot events не нужны
-             * этой проверки — event[slot] = strict slot ordering guarantee. */
-            if (!sub->has_slot_events) {
-                uint64_t verify_seq = atomic_load_explicit(&sub->hdr->slots[slot_idx].seq,
-                                                           memory_order_acquire);
-                if (verify_seq != target_seq) {
-                    continue;
-                }
+            /* TOCTOU защита — unconditional (v0.2 и v0.3 обa). v0.3 per-slot
+             * events НЕ guaranty ordering: cudaEventRecord overwrites previous
+             * state каждый publish. Если producer wrapped ring пока consumer
+             * ждал event sync, slot[slot_idx] уже содержит seq > target.
+             * Event signal от nового publish satisfies stale wait — consumer
+             * читает new content thinking it's old (lazy consumption).
+             *
+             * Симптом в long-running pipeline: 50k+ ring wraps накапливают drift,
+             * output stream duplicates 60-70% frames despite stable encoder fps.
+             *
+             * Proper v0.4 fix: per-slot+per-publish event handle (event pool).
+             * Сейчас — post-sync verify catches main race window. */
+            uint64_t verify_seq = atomic_load_explicit(&sub->hdr->slots[slot_idx].seq,
+                                                       memory_order_acquire);
+            if (verify_seq != target_seq) {
+                continue;
             }
 
             /* Fill frame_out */