Duelling Admins in CRDT Systems

• Duelling Admins Problem is a concurrency conflict in CRDT-based systems where simultaneous admin demotions lead to ambiguous state transitions.
• The issue is compounded by Byzantine adversaries exploiting merge semantics flaws, revealing limitations in naive eventual-consistency approaches.
• Epoch-Resolved Arbitration introduces deterministic ordering and secure finality through epoch events and tie-break rules to resolve conflicting updates.

The Duelling Admins Problem refers to a fundamental anomaly in permissioned group-management systems built atop Conflict-Free Replicated Data Types (CRDTs), wherein two equally authorized administrators concurrently attempt to revoke each other’s administrative status. This concurrency-induced ambiguity is exacerbated by adversarial (Byzantine) actors and exposes the breakdown of naive eventual-consistency and merge semantics in CRDTs. Addressing this challenge requires the introduction of external arbitration mechanisms, prominently exemplified by Epoch-Resolved Arbitration (ERA), to guarantee finality and resistance to rollback attacks. The implications are central to the design of distributed group-management for instant messaging, collaborative platforms, and decentralized ledgers (Dougal, 30 Jan 2026).

1. Formal Model: Group-Management CRDTs and Events

In CRDT-based group management, the system is modeled as a replicated object where the state consists of a mapping from users to roles. The set of users $U$ is dynamic, and the set of roles $$R = \{\text{Reader} < \text{Writer} < \text{Admin}\}$$ is totally ordered. The system evolves by processing events such as $join(a)$, $promote(a,b,r)$, $demote(a,b,r)$, and $write(a)$. Each event is structured as a node in a directed acyclic graph (DAG) $G = (V,E)$, where each event $v \in V$ carries cryptographic pointers (hashes) to its direct causal ancestors, encoding the "happens-before" partial order $\prec$ (Dougal, 30 Jan 2026).

A materialized state, $\operatorname{MV}(G)$, is recovered by applying a deterministic, associative, commutative, and idempotent join operator $\sqcup$ to the heads of the DAG. The join operator's semantics ensure that the order of application of events consistent with $\prec$ yields the same state, assuming only monotonic role promotions and demotions and deferring unauthorized operations.

2. Statement of the Duelling Admins Problem

The anomaly arises when two administrators, $a$ and $b$, both holding Admin status, concurrently attempt to demote each other to a lower role; that is, two demote events $d_1 = demote(a,b,\text{Reader})$ and $d_2 = demote(b,a,\text{Reader})$ are issued such that $d_1 \parallel d_2$ (concurrent, neither causally dependent on the other). Given only the partial order induced by $\prec$, a merge must select some total extension. Depending on the extension, either $a$'s or $b$'s demotion is effective, with the other being rendered unauthorized upon evaluation. Thus, the merge outcome is ambiguous and subject to tie-break rules—e.g., lowest event hash or timestamp (Dougal, 30 Jan 2026).

A Byzantine admin exploits this indeterminacy via carefully crafted events (e.g., manipulating hash or timestamp) to ensure their preferred outcome. Worse, by crafting concurrent or "backdated" events, a malicious actor can repeatedly roll back an authentic demotion, ensuring permanent retention of administrative privilege even in the face of correct, authorized revocation.

3. Concurrency, Happens-Before, and Finality in CRDTs

The crucial structural property is the immutability of the event DAG and its "happens-before" relation. In a Byzantine-tolerant system, each event's identifier is the cryptographic hash of its payload and ancestor pointers, preventing equivocation (multiple payloads under a single event ID). However, for two concurrent, conflicting events $m \parallel m'$, the CRDT's merge semantics may admit rollback:

$$Rollback(m', m) \iff \operatorname{MV}(G \cup \{m, m'\}) \equiv \operatorname{MV}(G \cup \{m'\})$$

An event $m$ is final if no concurrent $m'$ can roll it back:

$$Final(m) \iff \forall m': (m' \parallel m) \implies \neg Rollback(m', m)$$

In the dueling admins situation, without a total ordering beyond $\prec$, neither demotion event becomes final.

4. Epoch-Resolved Arbitration (ERA) and Finality

ERA introduces a deterministic and asynchronous finality mechanism by means of a trusted "finality node" which periodically emits special epoch events. Each epoch event, $epoch_k$, aggregates pointers to all current heads of the event DAG. This mechanism organizes the timeline into layers ("onion rings"), causally sealing the contents of each epoch: for epoch $k$,

$Closed_k = \{v \mid v \prec epoch_k \}$

Any new event after $epoch_k$ must causally descend from $epoch_k$, preventing artificial backdating.

For each non-epoch event $e$, define

$epoch(e) = \min\{ k \mid e \prec epoch_k \}$

A total order $\preceq$ is imposed lexicographically on events by $(epoch(e), tieBreak(e))$. Thus, all events in earlier epochs precede those in later epochs; within the same epoch, a secondary tie-break (e.g., hash) is used.

Pseudocode for event reception and merge at each replica:

G = local_DAG_of_received_events maxEpochSeen = 0 def on_receive(event): insert(event, G) if event.is_epoch: maxEpochSeen = max(maxEpochSeen, event.epoch_id) def periodic_finality(): if is_finality_node: Heads = current_heads(G) k = maxEpochSeen + 1 epoch_k = make_epoch_event(Heads, k) broadcast(epoch_k) def epochIndex(e): for k in range(1, maxEpochSeen+1): if e.precedes(epoch_k): return k return inf def mergeAndMaterialise(G): E = all_non_epoch_events(G) sort E by (epochIndex(e), tieBreak(e)) Roles = empty_map() for e in E: apply_if_authorized(e, Roles) return Roles

5. Illustrative Example: Resolving a Duel

Consider $a$ and $b$ both as Admin in epoch 1. Each concurrently issues $d_1=demote(a,b,\text{Reader})$ and $d_2=demote(b,a,\text{Reader})$. Until finality is imposed, the order is ambiguous; any replica can see $d_1$ before $d_2$ or vice versa. When the finality node emits $epoch_2$, both $d_1$ and $d_2$ fall in $epoch(d_1)=epoch(d_2)=2$.

During merge, a tie-break (e.g., hash) produces a deterministic ordering, say $d_1 \prec d_2$. Applying $d_1$ first, $b$ loses Admin, hence $d_2$ is not authorized and is ignored. As these events are now in the closed past, no further events may be backdated to challenge the outcome; $d_1$ is thus final.

6. Trade-Offs: Consistency, Availability, Performance, and Trust

ERA raises the consistency of critical, non-monotonic operations (e.g., demote, revoke) from “weak” (multiple outcomes under eventual consistency and tie-break ambiguity) to “final.” Arbitrary rollback and Byzantine gaming of tie-break rules are preempted once an epoch closes.

Availability remains high: users operate and exchange events locally, peer-to-peer, even if the finality node is unavailable. The cost is that operations accumulate in a “pending” epoch ($\infty$) and only become final after the next epoch emission; liveness is never blocked, but finality is delayed.

Performance penalties are limited: each epoch event references all heads but can be throttled or aggregated. Materialization is indexed by epoch—a single integer comparison per event suffices. Application-level tradeoffs are tunable via epoch frequency.

ERA introduces the requirement of a trusted finality node that never equivocates (issues two concurrent epochs) and does not collude to reorder events. Detected equivocation is detectable and triggerable for failover to alternative finality nodes. In deployments, finality nodes can be rotated or chosen from rosters with reputational incentives, and CRDT event payloads may be end-to-end encrypted.

7. Broader Implications and Connections

The Duelling Admins problem sharply delineates the limitations of CRDTs in the face of adversarial, concurrent control changes. The necessity of bounded external arbitration (as with ERA) demonstrates that certain distributed application domains—specifically those involving non-monotonic control or role changes—cannot attain strong consistency solely via permutation-insensitive local merges. This finding informs architecture choices in secure, distributed group management for large-scale messaging, collaborative, and permissions systems, reconciling the inherent CAP trade-off by introducing controlled, bounded synchrony and centrality (Dougal, 30 Jan 2026).