errors.sol

Overview

This Solidity source file defines an abstract contract named Errors that serves as a centralized repository for error codes used throughout the smart contract system. The contract enumerates various error constants as unsigned 16-bit integers (uint16), each uniquely associated with a specific failure or exceptional condition encountered during contract execution. This design facilitates consistent error handling and reporting across multiple contracts by referencing these error codes.

Contract: Errors

Description

The Errors contract is abstract, meaning it cannot be deployed on its own but is intended to be inherited by other contracts that require standardized error codes. It contains only constant declarations representing different error types, grouped into logical categories based on their functionality or the domain they relate to.

Properties

• versionErrors (string constant): Specifies the version of the error codes, here set to "6.2.0". This property can be used for version control or compatibility checks across the system.

• Multiple error constants (uint16 constant): Each error constant corresponds to a specific error condition, represented as an unsigned 16-bit integer. These codes are organized into thematic groups, aiding maintainability and clarity.

Error Code Categories

1. General Errors (400 - 418 range):
   Include errors related to gameplay, ownership, message validity, data correctness, and operational states.
   Examples:

   • ERR_NO_SALT (400) — Indicates no salt was provided where expected.

   • ERR_ALREADY_PLAY (401) — Indicates an attempt to play where already playing.

   • ERR_NOT_OWNER (402) — Indicates an unauthorized caller.

2. Public Keys General Errors (101 - 103 range):
   Errors related to public key validation.
   Examples:

   • ERR_ZERO_PUBKEY (101) — Public key is zero or missing.

   • ERR_REPEATING_KEY (102) — Duplicate public key detected.

   • ERR_BAD_LEN (103) — Invalid key length.

3. Incorrect Values Errors (200 range):
   Related to invalid value inputs.
   Example:

   • ERR_TOO_SMALL_VALUE (200) — Value provided is too small.

4. Transaction (TRX) List Errors (300 range):
   Related to transaction management and queue overflow.
   Examples:

   • ERR_TRX_NOT_FOUND (300) — Transaction not found.

   • ERR_TRX_WAITLIST_OVERFLOWED (301) — Waitlist overflow.

   • ERR_MAX_CLEANUP_TXNS_INVALID (302) — Invalid cleanup transaction count.

5. Message Signer and Groth16 Related Errors (501 - 514 range):
   Pertaining to cryptographic proof verification, signature validation, and key management.
   Examples:

   • ERR_INVALID_SIGNATURE (501) — Signature invalid.

   • ERR_FACTOR_EXPIRED (502) — Factor (likely a cryptographic nonce or token) expired.

   • ERR_INVALID_PROOF (504) — Zero-knowledge proof invalid.

   • ERR_REPEATING_CERT (512) — Duplicate certificate detected.

6. Wallet Access Recovery Errors (600 range):
   Related to seed phrase management for wallet recovery.
   Examples:

   • ERR_SEED_PHRASE_NEW_CANDIDATE_EXISTS (600) — A new seed phrase candidate already exists.

   • ERR_SEED_PHRASE_NEW_CANDIDATE_NOT_FOUND (601) — Expected new seed phrase candidate not found.

7. Security Card Errors (700 range):
   Errors related to the use and management of security cards.
   Examples:

   • ERR_CARD_IS_TURNED_ON (700) — Security card is already enabled.

   • ERR_NO_CARDS (701) — No security cards available.

   • ERR_TOO_MUCH_CARDS_ADDED (702) — Exceeded maximum number of security cards.

   • ERR_CARD_EXISTS (703) — Security card already exists.

   • ERR_CARD_IS_TURNED_OFF (704) — Security card is disabled.

   • ERR_CARD_NOT_FOUND (705) — Security card not found.

Usage

Contracts inheriting from Errors can use these constants to revert transactions or to encode error states in return values, enabling standardized error reporting. For example:

require(msg.sender == owner, Errors.ERR_NOT_OWNER);

This usage ensures that all contracts interpret the same error codes consistently, simplifying debugging and user feedback.

Implementation Details

• Use of uint16 for error codes constrains error identifiers to a small integer range, optimizing storage and gas costs when errors are emitted or stored.

• Constants are grouped by functional domain and assigned non-overlapping ranges to prevent confusion and facilitate future expansions.

• The contract is abstract and contains no functions or modifiers, serving solely as an error code namespace.

Interaction with Other System Components

• It is expected that multiple contracts across the system import or inherit from Errors to unify error handling.

• The error codes likely correspond to error messages or exceptions handled in frontend applications or off-chain systems that interact with these contracts.

• The version string versionErrors can be used to verify compatibility between contracts and client applications or during contract upgrades.

Visual Diagram

classDiagram
class Errors {
<<abstract>>
+string constant versionErrors
+uint16 constant ERR_NO_SALT
+uint16 constant ERR_ALREADY_PLAY
+uint16 constant ERR_NOT_OWNER
+uint16 constant ERR_MESSAGE_EXPIRED
+uint16 constant ERR_ZERO_PUBKEY
+uint16 constant ERR_REPEATING_KEY
+uint16 constant ERR_TOO_SMALL_VALUE
+uint16 constant ERR_TRX_NOT_FOUND
+uint16 constant ERR_INVALID_SIGNATURE
+uint16 constant ERR_SEED_PHRASE_NEW_CANDIDATE_EXISTS
+uint16 constant ERR_CARD_IS_TURNED_ON
}

This diagram illustrates the Errors contract as an abstract class containing multiple error constants. The constants serve as standardized identifiers for various error conditions categorized logically within the contract.