
Loading...
Loading
Loading...
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.
src/assertionStakingPool/AbsBoldStakingPool.solFunction: withdrawFromPoolLines: 43-55The analyzed contract appears to be part of the Arbitrum BOLD (Bounded Liquidity Delay) protocol stack, encompassing a rollup challenge manager, staking pools, sequencer inbox, bridge components, and upgrade action logic. The analysis identified 0 critical, 0 high, 5 medium, 9 low, and 11 informational findings across 25 total submissions. The most consequential pattern identified is the use of tx.origin for allow-list authorization in AbsInbox, which enables a social-engineering or phishing vector that could allow unauthorized parties to bypass access controls when the allow-list is active. Overall, the contract suite demonstrates mature security engineering with correct CEI implementations and strong cryptographic hash binding on sensitive operations; the residual risk is moderate and concentrated in trust model design choices rather than direct exploits.
The inbox contract checks who originally started a transaction rather than who is directly calling it. This means if an approved user can be tricked into visiting a malicious website or calling a malicious contract, that malicious contract can silently submit messages to the inbox on the user's behalf, bypassing the intended access restriction entirely.
During the BOLD upgrade, a helper contract stores critical initialization data. Because anyone can call the function that writes this data, an attacker watching the blockchain could race to insert their own valid-looking data before the upgrade operator does. If the attacker's data is used to initialize the new rollup, the rollup could start with incorrect state parameters.
During a protocol upgrade, the migration script automatically refunds stakers from the old rollup, but it silently stops after processing 50 stakers. Any stakers beyond that limit receive no automated refund and must manually withdraw through separate mechanisms. If those mechanisms are unavailable or broken, those stakers could have difficulty recovering their funds.
2 centralization points identified
The risk is that the current owner makes a mistake when calling setOwner; there is no external attacker exploit path. This is a governance hygiene concern related to privileged role management.
setOwner()These functions triggering external rollup calls without access control is a design choice; any caller can initiate withdrawal-back-to-pool but the rollup's own guards prevent unauthorized fund movement. This is an administrative trust surface, not a direct exploit.
makeStakeWithdrawable()An attacker monitors the mempool for the BOLDUpgradeAction.perform() transaction. Before it lands, they call StateHashPreImageLookup.set() with valid but attacker-chosen execution state parameters (same hash, meaning a collision is infeasible, but any valid pair can be pre-inserted ahead of the operator). Separately, if the new rollup's challenge manager inherits staking pools that have accumulated dangling allowances from repeated failed createEdge or createAssertion calls, a future compromise of the challenge manager could allow draining those accumulated approvals. While neither path alone is immediately catastrophic, together they represent a sensitive upgrade window where both the initialization data integrity and the post-upgrade token approval hygiene are imperfect.
BOLDUpgradeAction.cleanupOldRollup silently leaves stakers beyond index 50 in the paused old rollup. Those stakers depend on post-upgrade withdrawal via the patched rollup user logic. If, separately, the anyTrustFastConfirmer role (which carries an explicit trust comment in fastConfirmNewAssertion) behaves incorrectly, additional staker funds could be misaccounted. While both findings individually represent bounded risk, together they describe a scenario where a subset of stakers are unprotected by the migration and also lack the fast-confirmation accounting guarantee.
| Agent | Status | Findings | Severity | Confidence | Duration | Coverage |
|---|---|---|---|---|---|---|
| reentrancy | success | 2 | 2L | 70% | 32.1s | Cross-function reentrancy in AbsBoldStakingPool (depositIntoPool, withdrawFromPool), CEI pattern compliance in all staking pool contracts, ERC-777 callback risk via safeTransferFrom in staking pools, AbsBridge.executeCall external call and state management, AbsOutbox.executeTransaction and recordOutputAsSpent ordering, EdgeChallengeManager.createLayerZeroEdge and refundStake external calls, RollupUserLogic.withdrawStakerFunds, newStakeOnNewAssertion token transfers, GasRefunder.onGasSpent ETH transfer without reentrancy guard, ERC20Bridge._executeLowLevelCall token transfer before data call, ERC20Inbox._deliverToBridge token transfer ordering, AssertionStakingPool.createAssertion token approval and external calls, EdgeStakingPool.createEdge token approval and external calls, ValidatorWallet.executeTransactionsWithGasRefunder arbitrary external calls, BOLDUpgradeAction.perform complex multi-contract interaction |
| access control | success | 5 | 1M2L | 76% | 57.3s | Access control modifiers on all public/external functions across all contracts, tx.origin usage for authorization in AbsInbox onlyAllowed modifier, Initializer protection in upgradeable contracts (AbsBridge, AbsInbox, AbsOutbox, EdgeChallengeManager, RollupAdminLogic), Ownership transfer patterns (single-step vs two-step), Signature verification patterns (ecrecover usage) - none found, Delegatecall safety in AdminFallbackProxy, DoubleLogicERC1967Upgrade, UpgradeExecutorMock, RollupProxy initialization logic and re-initialization protection, AssertionStakingPool and EdgeStakingPool access control, StateHashPreImageLookup access control in BOLDUpgradeAction, BOLDUpgradeAction.perform() caller restrictions, BridgeCreator and RollupCreator admin function access, ValidatorWallet executor/owner access controls, SequencerInbox batch poster and rollup owner access controls, AbsOutbox executeTransaction and initialize protections, ERC20Bridge and ERC20Inbox initialization guards, GasRefunder allowedContracts and allowedRefundees access controls |
| economic | success | 5 | 2L | 66% | 1.0m | Flash loan attack vectors on staking pool deposit/withdrawal accounting, Oracle manipulation - no price feeds present in this codebase, Governance attack vectors in rollup admin functions and staking pools, MEV/sandwich exposure in staking pool creation functions, Reward/supply manipulation in staking pool deposit accounting, Fee-on-transfer token compatibility with staking pools, Access control on administrative functions across all contracts, Reentrancy in staking pools, bridge, outbox executeCall flows, Integer overflow in delay buffer calculations and stake amounts, Sequencer inbox force-inclusion delay enforcement, BOLD upgrade action security and pre-image lookup access control, Cross-protocol composability between staking pools and rollup/challenge manager, Assertion hash collision resistance in RollupLib, Edge challenge manager stake refund logic, Outbox executeTransaction replay protection via spent bitmap |
| logic validation | success | 8 | 2M2L | 54% | 1.5m | AbsBoldStakingPool deposit/withdrawal logic and balance tracking, AssertionStakingPool.createAssertion allowance management and user-controlled input, EdgeStakingPool.createEdge allowance management, AssertionStakingPoolCreator and EdgeStakingPoolCreator CREATE2 determinism, AbsBridge inbox/outbox management and array index manipulation, AbsInbox allow-list validation and parameter bounds, AbsOutbox merkle proof validation and double-spend protection, SequencerInbox batch posting access control and delay buffer arithmetic, DelayBuffer calcBuffer arithmetic including unchecked blocks, EdgeChallengeManager stake handling and edge creation validation, RollupCore assertion lifecycle state machine, RollupUserLogic staking and confirmation logic, RollupAdminLogic admin function access control, BOLDUpgradeAction upgrade sequence and staker cleanup loop cap, StateHashPreImageLookup access control, BridgeCreator deployment flow, GasRefundEnabled modifier arithmetic, ValidatorWallet execution and access control, ERC20Bridge and ERC20Inbox token handling, MerkleLib and MerkleTreeLib hash collision risks, abi.encodePacked usage with dynamic types, Integer overflow/underflow in unchecked blocks, Downcast truncation (uint128, uint64) across all files, Timestamp dependence in delay calculations |
| code quality | success | 6 | 70% | 1.2m | ERC-20 token interaction patterns (SafeERC20, allowance management), Reentrancy in staking pool deposit/withdraw flows, Access control on admin functions (onlyRollupOrOwner, onlyDelegated, onlyProxyOwner), Rollup upgrade logic in BOLDUpgradeAction, Proxy storage layout and slot correctness, Integer overflow/underflow in Solidity 0.8+, Delayed inbox force inclusion logic, Outbox Merkle proof verification and spent bitmap, Challenge manager edge creation and staking flow, Gas refunder arithmetic for refund calculations, ERC-1967 proxy slot usage in AdminFallbackProxy, Assertion hash validation in RollupCore, Staker management (createNewStake, withdrawStaker, deleteStaker), Sequencer inbox batch posting and delay buffer logic, Cross-layer message validation in OneStepProverHostIo | |
| compiler bugs | success | 2 | 1M | 68% | 44.3s | Staking pool deposit/withdrawal logic in AbsBoldStakingPool for reentrancy and accounting issues, AssertionStakingPool.createAssertion for trust in caller-supplied stake amounts and allowance management, EdgeStakingPool.createEdge for allowance accumulation on failure, AbsBridge.executeCall for outbox validation and reentrancy, AbsOutbox.executeTransaction for double-spend protection via spent bitmap, SequencerInbox batch posting access control and force inclusion logic, RollupUserLogic staking, assertion creation, and withdrawal logic, RollupCore internal accounting for staker funds, EdgeChallengeManager stake transfer and refund logic, Compiler bug patterns: pragma versions are all ^0.8.x or >=0.8.x, well outside affected ranges for all known compiler bugs, AbsInbox retryable ticket submission cost validation, ERC20Bridge balance protection in _executeLowLevelCall, BOLDUpgradeAction staker cleanup and migration logic, ValidatorWallet executor permission checks, AdminFallbackProxy implementation slot routing |
| assembly safety | success | 5 | 1L | 76% | 1.1m | Full codepoint-by-codepoint scan for non-ASCII characters (RTLO U+202E, zero-width joiners U+200D/U+200B/U+200C, Cyrillic homoglyphs) in all identifiers, function names, string literals, and comments across all files, All assembly{} blocks in DelegateCallAware.sol (onlyProxyOwner sload), MerkleLib.sol (calculateRoot), ValidatorWallet.sol (executeTransactions error bubbling), AbsOutbox.sol (executeBridgeCall error bubbling), OutboxWithoutOptTester.sol - checked for hardcoded slots, reversed shift arguments, dangling free memory pointer, assembly return vs leave, unchecked delegatecall success, AbsBoldStakingPool deposit/withdraw logic for reentrancy and CEI ordering, AssertionStakingPool.createAssertion for input validation and allowance management, EdgeStakingPool.createEdge for input validation and allowance management, AbsOutbox executeTransaction and recordOutputAsSpent for double-spend protection, RollupUserLogic for stake accounting, validator whitelist bypass paths, SequencerInbox batch poster access control and delay buffer logic, ERC20Bridge._executeLowLevelCall for call-not-allowed and balance check pattern, BOLDUpgradeAction.perform for upgrade safety and validator whitelist handling, GasRefundEnabled modifier for gas manipulation via blob fee path, AbsInbox._createRetryableTicket for submission fee and value validation, RollupAdminLogic.forceRefundStaker, forceCreateAssertion, forceConfirmAssertion for whenPaused guards, ValidatorWallet executeTransactions for reentrancy and destination validation, StakingPoolCreatorUtils.getPool for CREATE2 address computation |
| l2 specific | success | 5 | 2L | 65% | 1.0m | AbsBoldStakingPool deposit/withdrawal logic and balance accounting, AssertionStakingPool createAssertion token approval patterns, EdgeStakingPool createEdge token approval and edge ID verification, StakingPoolCreatorUtils CREATE2 address computation and pool existence checks, AbsBridge message accumulator logic and outbox management, AbsInbox retryable ticket creation and allowlist enforcement, AbsOutbox merkle proof verification and spent bitmap tracking, SequencerInbox batch posting access control and delay buffer mechanics, ERC20Bridge calldata restrictions and balance protection, RollupCore staker management, assertion creation, and confirmation logic, RollupUserLogic validator whitelist, staking flows, and fast confirmation, RollupAdminLogic privileged operations and upgrade paths, BOLDUpgradeAction migration logic and staker cleanup, EdgeChallengeManager edge creation, bisection, and stake refund, EdgeChallengeManagerLib timer cache, confirmation, and one-step proof, ArbitrumChecker L2 detection via ArbSys precompile, GasRefundEnabled blob gas accounting, DelayBuffer buffer depletion and replenishment math, AdminFallbackProxy double-logic proxy routing, ValidatorWallet executor access control and transaction forwarding, MerkleTreeLib prefix proof and inclusion proof correctness, Cross-chain message paths (L1->L2 deposits, retryable tickets, L2->L1 withdrawals) |
| upgrade | success | 3 | 1M1L | 72% | 57.7s | Proxy pattern identification - AdminFallbackProxy (DoubleLogicERC1967Upgrade), RollupProxy, TransparentUpgradeableProxy usage throughout, Storage layout collision risks in RollupCore, AbsBridge, AbsInbox, AbsOutbox upgrade chains, Initialization risks - EdgeChallengeManager has _disableInitializers() in constructor (correct), AbsOutbox and AbsBridge use onlyDelegated guards, Access control on upgrade functions - RollupAdminLogic._authorizeUpgrade and _authorizeSecondaryUpgrade have no restrictions but are gated by proxy admin pattern, StateHashPreImageLookup.set() permissionless write access, AssertionStakingPool allowance accumulation pattern, BOLDUpgradeAction.cleanupOldRollup() staker cap behavior, AbsBoldStakingPool deposit/withdrawal logic for reentrancy and accounting errors, SequencerInbox batch poster access controls and delay buffer logic, EdgeChallengeManager stake handling and refund logic, RollupUserLogic staking and confirmation logic, AbsOutbox executeTransaction and spend bitmap logic, ERC20Bridge native token handling and balance protection, DelegateCallAware onlyDelegated and onlyProxyOwner modifiers, __gap variables in AbsBridge (40 slots), AbsInbox (47 slots), AbsOutbox (42 slots) for upgradeable storage safety |
This automated audit has inherent limitations. The following areas are not covered.
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/21e99eaf-ce1b-4724-9afc-2aab2138c09d)
<a href="https://walletguard.ai/audit/21e99eaf-ce1b-4724-9afc-2aab2138c09d"> <img src="https://walletguard.ai/api/badge/21e99eaf-ce1b-4724-9afc-2aab2138c09d" alt="WalletGuard Audit Badge" /> </a>