Fencing Token ​

• The token in an acquire response A is a monotonically increasing u64. No matter the key or which acquisition it is, the value is always greater than any token issued before it.
• In single mode, the server's global counter guarantees monotonicity; in cluster mode, it's the issuance number replicated via consensus — the token is assigned deterministically at the moment a committed command is applied, so every node computes the same value, and it keeps increasing across a leader change.
• If the protected resource enforces the rule "reject any token lower than the last one seen," it can block access from an old holder that wakes up late after lease expiry (with a lower token) — the last line of defense against client-side delays (like a GC pause) that the lock server has no control over.

See How It Works for the scenario that makes this validation necessary.