Loading...
LoadingLoading...
LoadingLoading audit report...
WalletGuard.ai, powered by Gestalt Labs
Findings selected for deep verification. Where possible we generated a Solidity proof-of-concept and executed it against a forked mainnet.
Wallet.solFunction: confirmAndCheck, hasConfirmed, revokeLines: 367-368, 217-219, 144-151Wallet.solFunction: revoke, hasConfirmed, confirmAndCheckLines: 150, 207, 289No specific centralization concerns identified.
| Agent | Status | Findings | Severity | Confidence | Duration | Coverage |
|---|---|---|---|---|---|---|
| reentrancy | success | 29 | 5C3H3M | 76% | 4.0m | Delegatecall patterns and address trust (critical vulnerability), Access control modifiers and owner checks (silently failing modifiers), Initialization logic via constructor and delegatecall, Multi-sig confirmation flow and state management, Daily limit enforcement and underLimit checks, Owner management functions (addOwner, removeOwner, changeOwner), Fallback function delegation pattern, Input validation on addresses, Return value handling in delegatecall-based functions, Confirmation bitmap mechanism for owner multi-sig tracking, including overflow at index >= 256, Hash collision vectors in operation identification using sha3(msg.data, block.number), Modifier-based access control (onlyowner, onlymanyowners) and their return value semantics, Daily limit enforcement and interaction with m_required == 1 shortcut, State management during owner changes (changeOwner, addOwner, removeOwner) and clearPending() destructiveness, reorganizeOwners() logic and m_ownerIndex pointer consistency, Constructor parameter validation in initMultiowned and initDaylimit, revoke() operation validation and pending state verification, Cross-function attack chains combining multiple findings, Cross-function reentrancy via delegatecall to untrusted _walletLibrary, Access control enforcement in modifiers (onlyowner, onlymanyowners), Confirmation count logic and off-by-one errors in confirmAndCheck, Daily limit bypass via m_required == 1 special case, revoke function state consistency and event emission, clearPending race conditions with ongoing confirmations, underLimit modifier behavior and non-owner access, hasConfirmed delegatecall return value decoding, changeRequirement parameter validation, removeOwner state invariants (m_required <= m_numOwners), Daily limit timestamp manipulation via now / 1 days, reorganizeOwners efficiency and correctness |
| access control | success | 36 | 8C5H4M | 86% | 5.4m | Access control on execute() function and daily limit bypass, Delegatecall usage and hardcoded library address vulnerability, Initialization via constructor delegatecall to undeployed address, Multi-sig confirmation tracking via confirmAndCheck() and bitmap-based owner indexing, Revoke mechanism and pending operation state management, Owner management functions (changeOwner, addOwner, removeOwner), Daily limit tracking and m_spentToday reset logic, Operation hash generation and block.number inclusion, Contract creation via create() function and assembly error handling, Input validation on _required parameter, Delegatecall return value checks in fallback and explicit functions, Access control modifiers (onlyowner, onlymanyowners) and their enforcement, Delegatecall to hardcoded library address and return value handling, Constructor initialization and delegatecall to undeployed address, State variable initialization and validator checks, Confirmation logic and bitmap operations for multi-sig tracking, Daily limit enforcement and bypass conditions, Owner management (add, remove, change) and state consistency, Pending transaction storage and collision detection, Revocation and clearPending mechanisms, Operation hash computation and replay vectors, Assembly code safety (create function), Type mismatches in delegatecall return values, Delegatecall safety and address validation, Multi-signature confirmation tracking and replay, Operation hash computation and block-dependent logic, Daily limit enforcement and bypass paths, Owner management and state consistency, Storage corruption via untrusted delegatecall targets, Reentrancy in confirmation and execution functions, Initialization and uninitialization guard modifiers, Bitmap overflow in owner confirmation tracking, Unbounded array growth in pending operation queue |
| economic | success | 31 | 5C8H | 85% | 5.1m | Delegatecall pattern and hardcoded library address vulnerability, Multisig operation hash collision and confirmation validation, Bit-shift overflow in ownership bitmap operations, Daily spend limit reset logic and timestamp boundary exploitation, Owner management functions (add, remove, change) and state consistency, Delegatecall return value handling in constant functions, Array compaction and reorganizeOwners() logic, Duplicate owner detection in initialization, Access control modifiers and ownership checks, Transaction storage and confirmation state management, Operation hash collision and reuse vulnerabilities (block.number inclusion), Multi-sig confirmation logic and bitmap overflow in confirmAndCheck(), Daily limit enforcement and underLimit() function with timestamp-based resets, Pending transaction storage and re-creation via hash collisions, Confirmation revocation logic and bitwise operations, Owner validation in initMultiowned() and access control modifiers, Transaction execution paths in execute() and confirm() functions, clearPending() behavior and orphaned confirmation states, Root cause analysis of reported findings to identify chained exploits, Delegatecall fallback routing and authorization bypass, Owner confirmation bitmap logic and overflow in 2**ownerIndex, Operation hash computation including block.number dependency, Pending operation tracking and clearPending() side effects, Daily limit enforcement and underLimit() state modifications, Owner array reorganization and m_ownerIndex consistency, Address-to-uint casting and type confusion, Constructor initialization via delegatecall without validation, Transaction confirmation without data integrity checks, Timestamp-based daily limit and boundary exploitation |
| logic validation | success | 31 | 5C4H3M | 77% | 4.9m | Input validation on initialization functions (initWallet, initMultiowned), Daily limit enforcement and timestamp manipulation vectors, Multisig confirmation logic and state management (confirmAndCheck, revoke), Owner management functions (addOwner, removeOwner, changeOwner), Transaction execution and storage (execute, confirm), Operation hash computation and replay vectors, Delegatecall security and hardcoded library address risks, Arithmetic safety in bitmask operations (2**ownerIndex), Fallback function and unchecked delegatecall patterns, State machine integrity across multi-step transactions, Assembly-based contract creation and error handling, Root cause analysis of hash collision vulnerabilities in execute()/confirm() using block.number, Modifier return value handling in confirmAndCheck() and onlymanyowners, Parameter validation in initMultiowned() for _required bounds and duplicate owners, Daily limit bypass conditions in execute() when m_required == 1, Bit shift overflow in confirmation bitmap tracking (2**ownerIndex), Operation hash collision and state tracking across block boundaries, clearPending() orphaned confirmation state issues, Struct value semantics and persistence in confirmAndCheck(), Overflow protection in underLimit() effectiveness, Interaction between revoke() and deleted pending states, Input validation on constructor parameters (_owners array, _required value), delegatecall mechanics in constructor and fallback function, Operation hash computation in execute() using block.number, Confirmation tracking via confirmAndCheck and bitmap encoding, Daily limit enforcement logic in underLimit() and execute(), Owner management in addOwner, removeOwner, reorganizeOwners, Pending operation tracking via m_pending and m_pendingIndex, clearPending logic and its interaction with confirmation state, revoke function and its state consistency, hasConfirmed and bitmap collision detection, Transaction storage in m_txs and cleanup in confirm(), Assembly code in Wallet constructor for delegatecall setup |
| code quality | success | 22 | 1L | 82% | 6.0m | Access control via isOwner and onlyowner modifier implementation, Multi-signature confirmation logic in confirmAndCheck and pending operation tracking, Delegatecall usage in Wallet proxy and constructor assembly, Daily spending limit enforcement in underLimit function, Owner management (add, remove, change) and storage reorganization, Transaction execution and confirmation state management, Bit shift overflow in owner bitmap tracking, Constructor initialization via delegatecall, Fallback function and ether receiving mechanism, Owner index overflow in confirmAndCheck bitmask calculation (2**ownerIndex with unchecked bounds), Unchecked delegatecall in fallback function to untrusted library address, Daily limit bypass via m_required == 1 short-circuit in execute(), Operation hash collision vulnerabilities with block.number inclusion, Revoke operation state cleanup and m_pendingIndex orphaning, Transaction storage collision via insufficient empty condition checks, removeOwner/reorganizeOwners m_ownerIndex consistency bugs, onlyowner modifier lack of revert vs silent failure, clearPending() null-check treating bytes32(0) as sentinel, delegatecall return value mishandling in hasConfirmed/isOwner stubs, Gas optimizations in underLimit and confirmAndCheck, Cross-function state consistency between execute/confirm/revoke, Signature and confirmation accumulation invariants, Daily spend tracking and reset logic |
| compiler bugs | success | 10 | 3C2H | 93% | 1.9m | Delegatecall to untrusted library address, Bitmap overflow in confirmation logic (ownerIndex >= 256), Daily limit bypass via m_required == 1 condition, Non-owner access control in confirmAndCheck, Multi-sig execution flow and confirmation tracking, Owner management (addOwner, removeOwner, changeOwner), Transaction hashing and storage collision risks, Reentrancy in execute() and confirm(), Modifier execution flow control and missing require() statements, Confirmation bitmap overflow in 2**ownerIndex operations, Daily limit bypass via m_required == 1 shortcut in execute(), Missing validation in initMultiowned() for _required parameter, Delegatecall return value handling in isOwner() and hasConfirmed(), Operation hash collision via block.number dependency, Owner state management and reorganizeOwners() correctness, Interaction between clearPending() and pending transaction state, Underflow/overflow in confirmation count tracking (yetNeeded decrement), Transaction re-execution prevention via m_txs state cleanup, Cross-function reentrancy and state corruption paths, Delegatecall authorization and return value handling in fallback, Pending operation state management across owner changes, Daily limit enforcement in single-signature and multi-signature paths, Operation hash generation and collision resistance, Owner index bit-field reuse after owner removal, Cross-function state consistency in execute/confirm/confirmAndCheck flow, Storage variable initialization and uninitialized state risks, Modifier evaluation in delegatecall context vs Wallet context |
| assembly safety | success | 30 | 8C5H1M | 92% | 5.8m | Delegatecall patterns and library trust, Confirmation bitmap logic and owner indexing, Daily limit enforcement and reset mechanisms, Operation hashing and transaction storage, Constructor initialization and validation, Owner management (add, remove, change), Revocation and re-confirmation cycles, Assembly blocks in constructor and create(), Pending state management and clearPending(), Access control via onlyowner and onlymanyowners modifiers, State machine for transaction confirmation, Overflow/underflow in arithmetic (2^ownerIndex), Input validation for constructor parameters, Timestamp-based daily limit reset, Contract creation via execute(), Return value semantics in confirm(), Codepoint scan for non-ASCII characters in identifiers, functions, strings, Delegatecall to hardcoded untrusted library address and its implications for state initialization and function dispatch, Access control mechanisms (onlyowner and onlymanyowners modifiers) and their failure modes, Multi-signature confirmation logic (confirmAndCheck function) and bitmap-based owner tracking, Daily spending limit enforcement and bypass conditions, Operation hash computation and storage in execute() and confirm() functions, Initialization flow and state machine (only_uninitialized modifier), Pending operation management (clearPending function), Owner management functions (changeOwner, addOwner, removeOwner) and their interactions with confirmation state, Return value handling in delegatecall wrappers (hasConfirmed, isOwner), Revoke functionality and state persistence issues, Integer overflow in bitmap calculations (2**ownerIndex for ownerIndex >= 256), Modifier return-value semantics and silent-failure patterns, Delegatecall return value handling in fallback and explicit functions, Struct-by-value vs storage reference in confirmAndCheck(), Constructor bytecode parsing and codecopy offset calculation, Owner confirmation bitmap overflow with large ownerIndex values, Daily limit overflow detection logic, Access control on reorganizeOwners() and owner management functions, Multi-signature confirmation state persistence, Owner initialization and storage layout, Cross-function consistency in confirmation tracking |
| l2 specific | success | 22 | 3C2H3M | 84% | 6.6m | Access control modifiers (onlyowner, onlymanyowners, only_uninitialized), Daily limit enforcement and reset logic, Multisig confirmation tracking using bitmask, Owner management (add, remove, change), Transaction execution and confirmation, Delegatecall usage in constructor and fallback, Hash-based transaction storage and replay, Pending transaction state management and clearing, Cross-function call chains and state consistency, Assembly code in constructor for ABI encoding, delegatecall patterns in Wallet and fallback function, onlyowner and onlymanyowners modifier enforcement and revert behavior, confirmAndCheck() state initialization and reinitialization logic, Operation hash computation via sha3(msg.data, block.number) for collision potential, clearPending() atomicity and transaction deletion without confirmation cleanup, execute() daily limit bypass when m_required == 1, Bit shift overflow in 2**ownerIndex when index > 255, Daily limit reset via block.timestamp and today() function exploitability, initMultiowned() parameter validation for m_required vs m_numOwners, addOwner() and changeOwner() input validation and duplicate prevention, revoke() silent failure on non-owner calls, Pending transaction storage collision between execute() and confirm(), Owner index bounds checking and array manipulation in reorganizeOwners(), Multi-sig confirmation threshold reachability and lock-up scenarios |
| math verification | success | 20 | 7C3H1M | 88% | 4.6m | Multi-signature authorization checks and onlymanyowners modifier behavior, Library delegatecall mechanism and hardcoded library address, Daily spending limit enforcement in execute() function, Operation hash computation and collision resistance, Confirmation and revocation logic with bitwise operations, Owner management (addOwner, removeOwner, changeOwner), Pending operation storage and clearPending() array management, Wallet constructor initialization via delegatecall, Cross-contract delegatecall return value handling in isOwner/hasConfirmed, Modifier precedence and conditional execution logic, Confirmation bitmap overflow via 2**ownerIndex when ownerIndex >= 256, Operation hash collision between execute() and confirm() due to block.number inclusion, revoke() operator precedence bug allowing failed revocations, Daily limit bypass via m_required == 1 shortcut in execute(), clearPending() state inconsistency enabling transaction re-execution, confirmAndCheck() silent failure without revert in onlymanyowners modifier, delegatecall return value mishandling in hasConfirmed() and isOwner(), Delegatecall return value handling in Wallet fallback and confirm functions, Operation hash computation using block.number in execute(), Pending operation state management across multiple functions, clearPending() interaction with multi-sig operations, revoke() validation and state consistency, Owner index bit-set manipulation in confirm/revoke, Multi-sig confirmation logic and threshold enforcement, Daily limit enforcement and underLimit() checks, Transaction storage and retrieval via hash mapping, Cross-function invariants for pending operations, Edge cases in PendingState struct initialization |
| upgrade | success | 31 | 7C4H5M | 83% | 4.7m | Proxy pattern and delegatecall security, Implementation contract initialization guards, Access control on administrative functions (changeOwner, addOwner, removeOwner, changeRequirement, kill), Multisig confirmation logic and state machine, Daily spending limit enforcement, Operation hash generation and collision resistance, Owner indexing and bitmask confirmation mechanism, Pending transaction storage and deletion, Input validation on owner addresses, Proxy pattern and delegatecall risks, Multi-signature confirmation logic and bitmap overflow, Owner authorization checks (onlyowner and onlymanyowners modifiers), Daily limit enforcement in execute(), Operation hash collision via block.number, clearPending() state clearing in ownership changes, Initialization security (initMultiowned, initWallet), Permission validation on sensitive functions (changeOwner, addOwner, removeOwner), Array compaction logic in reorganizeOwners(), Transaction storage and confirmation state management, Non-owner function call handling (silent returns vs reverts), Proxy delegation and fallback function security, Initialization and re-initialization vulnerabilities, Owner management and access control (addOwner, removeOwner, changeOwner, changeRequirement), Multi-sig confirmation logic and hash computation, Daily limit enforcement and day boundary handling, Bitmap-based confirmation tracking (ownerIndexBit overflow), Transaction execution and confirmation flow, Storage layout and state management |
| cipher alpha | success | 14 | 4C5H3M | 77% | 3.0m | Cross-function reentrancy (categories: reentrancy), 3 RALPH iterations, Adversarial verification (iteration 3) |
| cipher beta | success | 19 | 7C7H3M | 85% | 3.6m | Economic exploit simulation (categories: flash_loan, governance, oracle_manipulation), 3 RALPH iterations, Adversarial verification (iteration 3) |
| cipher general | success | 13 | 3C3H4M | 82% | 2.9m | General-category PoC verification (categories: access_control, signature_auth, integer_overflow, precision_loss, input_validation, unchecked_call, state_machine, timestamp_dependence, dos, upgrade_safety, storage_collision, standard_compliance, gas_optimization, logic_error, compiler_bug, assembly_safety, l2_specific, encoding_collision, delegatecall_safety, xss, csrf, cors_misconfiguration, session_management, data_exposure, open_redirect, ssrf, security_headers, cryptographic_weakness, other), 3 RALPH iterations, Adversarial verification (iteration 3) |
Invalid JSON in Claude response (stop_reason: max_tokens, outputTokens: 16384)
How this affects your report: findings normally surfaced by this specialist are missing; overlapping coverage from other agents still applies.
Invalid JSON in Claude response (stop_reason: max_tokens, outputTokens: 16384)
How this affects your report: findings normally surfaced by this specialist are missing; overlapping coverage from other agents still applies.
Invalid JSON in Claude response (stop_reason: max_tokens, outputTokens: 16384)
How this affects your report: findings normally surfaced by this specialist are missing; overlapping coverage from other agents still applies.
This report is an automated point-in-time assessment and does not guarantee protection against all possible attacks. It does not cover off-chain components, economic modeling, or business logic correctness unless explicitly noted. Changes to the contract after the audit commit are not reviewed. This is not financial or legal advice. WalletGuard, powered by Gestalt Labs, provides this analysis as-is with no warranty of completeness.
[](https://walletguard.ai/audit/add28169-b4d2-45ec-8c4a-602bce9afc9d)
<a href="https://walletguard.ai/audit/add28169-b4d2-45ec-8c4a-602bce9afc9d"> <img src="https://walletguard.ai/api/badge/add28169-b4d2-45ec-8c4a-602bce9afc9d" alt="WalletGuard Audit Badge" /> </a>
Secured by WalletGuard