Heartbeat anti-tamper: how Raven Anticheat detects when its client layer has been disabled
A heartbeat loop continuously reports client-side runtime state to the server. If the heartbeat stops, falls behind, or returns wrong values, the server treats the client as tampered and acts.
The problem heartbeat solves
The hardest cheat to detect is the one that quietly disables your anticheat client and then runs unobserved. Signature checks can be hooked. NUI inspection can be blocked. Runtime integrity functions can be no-op patched. Once the client layer is silent, a single-layer AC is blind. Heartbeat anti-tamper exists to make "silent" expensive: the absence of a heartbeat is itself a detection.
How the heartbeat loop works
The Raven client emits a signed payload at a fixed cadence (adaptive per server, see the 2026-02-17 changelog entry; previously fixed at 1500ms). The payload includes a cryptographic hash of critical runtime state - resource integrity, hook table fingerprints, event-handler addresses - along with a timestamp and a per-session nonce. The server verifies the signature, compares the hash against the expected baseline, and notes the inter-arrival time. Three failure modes are detected: the heartbeat does not arrive (silent client), the heartbeat arrives but its payload no longer matches expected values (tampered client), or the heartbeat arrives at the wrong cadence (replayed or stale client).
Why the cadence matters
A fixed heartbeat window is easier to evade - a cheat that briefly disables the client between heartbeats can keep the loop alive while still running unobserved. Adaptive cadence per server (calibrated against average tick latency over the first 24h) makes that window unpredictable to the cheat without complicating life for legitimate players on high-latency routes. The 2026-03 release rebalanced the default window from a fixed 1500ms to an adaptive 800-1500ms range, which dropped false positives on EU/AS routes by ~38%.
What happens when the heartbeat fails
Failure responses are configurable per server in three tiers. Tier 1 (warn) marks the player on the live map and notifies admins via the configured Discord webhook. Tier 2 (kick) drops the player from the server with a generic disconnect reason and logs the event with full evidence (last valid heartbeat, current timestamp, payload diff). Tier 3 (auto-ban) bans the player on the local server and queues them for promotion to the Global Ban Database after admin review. The default configuration is conservative - warn first, escalate only on repeat - because the heartbeat layer can produce false positives during legitimate network issues.
How heartbeat interacts with the trust score
Each heartbeat anomaly contributes to the per-player trust score (introduced in version 2026.4.0 - see /changelog). A single late heartbeat is noise. Multiple late heartbeats from the same player across sessions, a heartbeat that falls behind specifically when the player enters certain game states, or a heartbeat that consistently returns the same hash even though the resource pack updated - those are all signals that surface the player on the live map for admin review long before any single tier-3 ban fires.