Client approval quorum differs from documented consensus model #70

Open
opened 2026-04-05 16:23:10 +00:00 by Skipper · 1 comment
Owner

Info

Severity: LOW
Attack vector: network-only

Impact

Allows a smaller set of online user agents than the documentation implies to approve new SDK clients.

Description

The current approval flow requires unanimous approval from currently connected user agents, not the broader quorum model described in the architecture. In a multi-user-agent deployment where only one agent is online, that single agent can approve a new SDK client.

Example flow

  1. Deploy multiple user agents but leave only one connected.
  2. Start a new SDK client approval flow.
  3. Collect approval only from currently connected user agents.
  4. Approve the client with fewer approvals than the documented model suggests.

Mitigation

Align the implementation with the documented quorum semantics and define how offline user agents affect approval decisions.

# Info **Severity**: **LOW** Attack vector: network-only ## Impact Allows a smaller set of online user agents than the documentation implies to approve new SDK clients. ## Description The current approval flow requires unanimous approval from currently connected user agents, not the broader quorum model described in the architecture. In a multi-user-agent deployment where only one agent is online, that single agent can approve a new SDK client. ## Example flow 1. Deploy multiple user agents but leave only one connected. 2. Start a new SDK client approval flow. 3. Collect approval only from currently connected user agents. 4. Approve the client with fewer approvals than the documented model suggests. ## Mitigation Align the implementation with the documented quorum semantics and define how offline user agents affect approval decisions.
Member

The finding is valid but requires a product decision before it can be fixed. The current implementation collects approvals only from currently connected operators — it has no awareness of how many operators are registered in the database. This means a single connected operator can approve a new SDK client even if four others are registered but offline.

The fix itself is straightforward (query operator_client for total registered count, then enforce a threshold before spawning ClientApprovalController), but the threshold policy needs to be decided first: all registered must be online, a simple majority, or a configurable minimum. Each option has different availability trade-offs.

The finding is valid but requires a product decision before it can be fixed. The current implementation collects approvals only from currently connected operators — it has no awareness of how many operators are registered in the database. This means a single connected operator can approve a new SDK client even if four others are registered but offline. The fix itself is straightforward (query operator_client for total registered count, then enforce a threshold before spawning ClientApprovalController), but the threshold policy needs to be decided first: all registered must be online, a simple majority, or a configurable minimum. Each option has different availability trade-offs.
Sign in to join this conversation.
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: MarketTakers/arbiter#70