Skip to content

Detecting Imposters

TKeeper is designed to operate correctly in the presence of Byzantine behavior. During multi-round protocols, the system detects and reports participants that provide invalid data or invalid zero-knowledge proofs, and it also tracks nodes that become unavailable mid-operation.

Where to Find imposters

TKeeper exposes detected imposters through the following channels:

Audit logs

  • Look for the imposters field inside the corresponding audit event payload.
  • If nodes become unavailable during the flow, they are recorded in audit logs separately as dead.
  • See Audit Event Structure in Compliance section.

Error responses

  • For failed operations, the response body may include imposters and dead fields.
  • See ErrorMessage in OpenApi.

Successful operation results

  • Signing results and decrypt responses also include imposters for transparency.

Example:

Each keeper id follows format keeper-{id} where id is peeked from value you set during initialization. 

{
  "errorType": "SOME_ERROR",
  "imposters": [
    "keeper-1"
  ],
  "dead": [
    "keeper-3"
  ]
}

Byzantine Flow Overview

Most TKeeper operations are executed in rounds. In each round:

  • The coordinator (the node that received the client request) orchestrates the next step.
  • The coordinator and/or participants validate incoming messages (including ZK proofs when applicable).
  • The system collects:
  • imposters: nodes that sent invalid payloads or invalid ZK proofs.
  • dead: nodes that became unavailable during the operation (timeouts, disconnects, crashes).

Round results include updated imposters & dead lists. These lists are also emitted into audit logs (see: Compliance section).

If at least one imposter or dead node is detected, the handling strategy depends on the operation type.

Signing

For signing protocols (GG20 and FROST), TKeeper treats any detected imposter or dead node as a reason to restart the protocol:

  • If imposters or dead are present, the coordinator restarts the signing protocol from scratch.
  • The next attempt forms a new quorum excluding the detected imposters and dead nodes.
  • The signing request remains the same, but the protocol is re-initialized with fresh commitments.

This behavior is intentional: GG20 and FROST are not safe to resume from an arbitrary intermediate state after adversarial behavior without introducing subtle vulnerabilities. A clean restart with new commitments and the same high-level operation is the safest approach.

Coordinator as an Imposter or Dead Node

If the coordinator is the faulty node, it can be detected via audit logs by its presence in imposters or dead. See: Compliance section.

In this case:

  • A restart is not possible (the coordinator is responsible for orchestration).
  • The operation fails.
  • No secret data is revealed to the coordinator.
  • The worst impact is on availability (the coordinator can disrupt completion, but cannot extract private material from this failure mode).

Decrypting

Decryption is threshold-based and returns explicit visibility into detected faulty parties:

  • The coordinator returns all detected imposters in the response body.
  • As long as at least t nodes are honest and the coordinator is among them, decryption completes successfully.
  • If the threshold cannot be satisfied (insufficient honest/available nodes), the operation fails without revealing private data.

Verifying and Encrypting

Verification and encryption depend on reconstructing the full public key.

  • As long as at least t nodes remain available and honest, these operations can complete successfully.