EVM Remediation April 23, 2025 6 min read

Centralization Risks Remediation

How to reduce centralization risk through timelocks, multi-signature wallets, on-chain governance, and hard-coded parameter caps that protect users from compromised or malicious admins.

evmaccess-control

Centralization Risks Remediation

Overview

Centralization risk is a design-level vulnerability: a single address (or a small set controlled by one entity) can unilaterally execute privileged operations — pause all user activity, upgrade the contract implementation, set fees to 100%, or mint unlimited tokens. Whether or not the current owner is trustworthy, single-owner control creates a threat model where one compromised private key is sufficient to extract all user funds or permanently freeze the protocol.

This pattern is pervasive in DeFi. USDC’s issuer can freeze any address. Many lending protocols have an upgrade key that can replace the entire implementation in one transaction. Fee-parameterized AMMs allow an owner to set the fee to 100% between blocks. The concern is not necessarily malicious intent — it is that any off-chain risk (phishing, server compromise, insider threat, regulatory seizure) becomes an on-chain catastrophe without a mitigation layer between the admin key and user funds.

Related Detector: Access Control Detector

Recommended Fix

Before (Vulnerable)

contract CentralizedProtocol is Ownable {
    uint256 public fee;       // Owner can set to any value
    bool    public paused;    // Owner can freeze instantly

    // No delay, no multi-sig, no governance — one key controls everything
    function setFee(uint256 newFee) external onlyOwner {
        fee = newFee; // Can set to 100% in a single transaction
    }

    function pause() external onlyOwner {
        paused = true; // Instant — no user exit window
    }

    function upgradeTo(address newImpl) external onlyOwner {
        // Replaces entire implementation — no timelock, no veto
        _upgradeToAndCall(newImpl, "");
    }
}

After (Fixed)

import "@openzeppelin/contracts/governance/TimelockController.sol";
import "@openzeppelin/contracts/access/AccessControl.sol";

contract DecentralizedProtocol is AccessControl {
    // Hard-coded bounds that cannot be changed — no admin key can override these
    uint256 public constant MAX_FEE_BPS    = 100;   // 1% absolute ceiling
    uint256 public constant TIMELOCK_DELAY = 2 days; // Minimum delay before changes take effect

    uint256 public fee;
    bool    public paused;

    TimelockController public immutable timelock;

    bytes32 public constant PROPOSER_ROLE = keccak256("PROPOSER_ROLE");
    bytes32 public constant GUARDIAN_ROLE = keccak256("GUARDIAN_ROLE");

    constructor(address[] memory proposers, address[] memory guardians) {
        // Timelock owns itself — multi-sig is a proposer, not the direct owner
        timelock = new TimelockController(
            TIMELOCK_DELAY,
            proposers, // Multi-sig wallet addresses
            guardians, // Emergency pause signers (lower threshold)
            address(0)
        );
        _grantRole(DEFAULT_ADMIN_ROLE, address(timelock));
    }

    // Fee change must go through a 2-day timelock — users can exit before it takes effect
    function setFee(uint256 newFee) external onlyRole(DEFAULT_ADMIN_ROLE) {
        require(newFee <= MAX_FEE_BPS, "Fee exceeds maximum");
        fee = newFee;
    }

    // Emergency pause requires only a guardian, but unpause requires the timelock
    function pause() external onlyRole(GUARDIAN_ROLE) {
        paused = true;
        emit ProtocolPaused(msg.sender, block.timestamp);
    }

    function unpause() external onlyRole(DEFAULT_ADMIN_ROLE) {
        // Unpause goes through the timelock — guardian cannot silently unfreeze
        paused = false;
    }
}

Alternative Mitigations

Multi-signature wallet as the immediate admin — replaces a single key with an M-of-N approval requirement. A Gnosis Safe 4-of-7 means an attacker must compromise four independent signers to execute any privileged action:

// No code changes needed in the contract — deploy with a Gnosis Safe as owner:
// Safe address: 0x... (4-of-7 multi-sig)
// Even with the Safe as owner, add a timelock between the Safe and the contract
// for maximum protection.

// Pattern: Safe → Timelock → Protocol
// Execution path: 4-of-7 Safe signers propose → 48h delay → execute

OpenZeppelin Governor for on-chain governance — transitions admin control to token-weighted voting. No single entity can act; proposals require community approval, quorum, and a timelock before execution:

import "@openzeppelin/contracts/governance/Governor.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorSettings.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorTimelockControl.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorVotes.sol";

contract ProtocolGovernor is Governor, GovernorSettings, GovernorVotes, GovernorTimelockControl {
    constructor(IVotes token, TimelockController timelock)
        Governor("ProtocolGovernor")
        GovernorSettings(
            1,      // 1-block voting delay
            50400,  // ~1 week voting period (at 12s/block)
            100_000e18 // 100k tokens required to propose
        )
        GovernorVotes(token)
        GovernorTimelockControl(timelock)
    {}

    function quorum(uint256) public pure override returns (uint256) {
        return 4_000_000e18; // 4% of total supply must participate
    }
}

Immutable parameter caps — even with governance, hard-code absolute limits at deploy time that no proposal can override. This protects users from a governance capture where a whale coalition votes to extract fees:

contract BoundedProtocol {
    // These are set in the constructor and can NEVER be changed.
    // They define the worst-case outcome for users regardless of admin actions.
    uint256 public immutable MAX_FEE       = 50;    // 0.5% absolute ceiling
    uint256 public immutable MIN_TIMELOCK  = 1 days; // Minimum delay enforced in code
    uint256 public immutable MAX_SUPPLY    = 1_000_000_000e18; // Token supply cap

    function setFee(uint256 newFee) external onlyGovernance {
        require(newFee <= MAX_FEE, "Cannot exceed immutable fee cap");
        fee = newFee;
    }
}

Progressive decentralization roadmap — for protocols that launch with simpler admin structures and mature over time:

Phase 1 (Launch): 3-of-5 multi-sig with a 48-hour timelock. Deploy immutable parameter caps from day one.
Phase 2 (Growth): Expand to 5-of-9 multi-sig; increase timelock to 72 hours; publish a “decentralization schedule.”
Phase 3 (Maturity): Transition to on-chain governance with OpenZeppelin Governor. Remove multi-sig from the upgrade path; keep it only as an emergency pause guardian.
Phase 4 (Immutable): Renounce upgrade keys. Any future changes require a contract migration with a user opt-in window.

Common Mistakes

Adding a timelock but still allowing the owner to bypass it — a timelock is only effective if there is no emergency override that skips it. Audit all execution paths and ensure every state-changing operation routes through the timelock.

Multi-sig with signers on the same infrastructure — if all four Safe signers use the same cloud provider or the same password manager, the effective security is one key. Require signers to use different hardware, different custody solutions, and different geographic locations.

Setting the timelock delay below 24 hours — users need time to react to pending changes. A 2-hour timelock is meaningless during periods of high network congestion. Aim for a minimum of 48 hours for parameter changes and 7 days for upgrade operations.

Forgetting to set a maximum for every adjustable parameter — if a fee can be set between 0% and 100%, users cannot predict the worst case. Hard-code a MAX_FEE constant at deploy time so the upper bound is publicly verifiable on-chain without trusting the current admin.

References

OpenZeppelin: TimelockController
OpenZeppelin: Governor
Gnosis Safe Multi-Signature Wallet
Trail of Bits: Slither Upgrade Safety Checks
Compound Finance Governance Documentation

EVM Attack Pattern

Access Control Bypass

How attackers exploit missing or improper access restrictions on critical functions — responsible for over $1.3 billion in DeFi losses including the largest hack in history.

EVM Detector

Access Control

Detects missing or improperly implemented access controls on privileged functions, allowing unauthorized callers to execute restricted operations.

EVM Exploit

Access Control Bypass Exploit Generator

Sigvex exploit generator that validates missing access control by calling privileged functions from an unauthorized address and checking for storage mutations.

EVM Exploit

Bridge Message Manipulation Exploit Generator

Sigvex exploit generator that validates cross-chain bridge vulnerabilities including message replay, cross-chain replay, and Nomad-style uninitialized state exploitation.

EVM Exploit

Centralization Risks Exploit Generator

Sigvex exploit generator that validates centralization risk findings by classifying the specific privilege type and documenting the trust assumptions and attack scenarios enabled by single-owner control.

EVM Exploit

Cross-Chain Balance Inconsistency Exploit Generator

Sigvex exploit generator that validates cross-chain bridge balance inconsistency vulnerabilities including replay attacks, non-atomic operations, weak proof verification, and finality exploits that allow token supply inflation on the destination chain.

EVM Exploit

Default Visibility Exploit Generator

Sigvex exploit generator that validates default visibility vulnerabilities in Solidity contracts where missing visibility modifiers default to public, exposing sensitive initialization and admin functions.

EVM Exploit

Selfdestruct Vulnerability Exploit Generator

Sigvex exploit generator that validates selfdestruct vulnerabilities including unprotected self-destruction, library-based destruction (Parity-style), and forced ETH reception.

EVM Exploit

tx.origin Authentication Exploit Generator

Sigvex exploit generator that validates tx.origin authentication vulnerabilities by simulating a phishing scenario where an intermediary contract calls the victim with the owner's tx.origin.

EVM Exploit

Validator/Relayer Compromise Exploit Generator

Sigvex exploit generator that validates bridge validator and relayer compromise vulnerabilities including low M-of-N thresholds, key management failures, centralized relayers, and missing validator rotation — with the Ronin Bridge ($625M) as the canonical attack scenario.

EVM Remediation

Access Control Remediation

How to implement proper access controls on privileged functions using ownership patterns, role-based access, and multi-signature authorization.

EVM Remediation

Arbitrary Storage Write Remediation

How to eliminate arbitrary storage write vulnerabilities by removing user-controlled assembly SSTORE operations, using Solidity mappings, and enforcing slot allowlists for unavoidable inline assembly.

EVM Remediation

Bridge Message Remediation

How to secure cross-chain bridge message processing by implementing nonce-based replay protection, chain ID binding, explicit state initialization, and validator threshold requirements.

EVM Remediation

Cross-Chain Balance Inconsistency Remediation

How to eliminate cross-chain bridge balance vulnerabilities by implementing proof deduplication, deep finality requirements, Merkle proof verification, and the lock-and-mint pattern.

EVM Remediation

Default Visibility Remediation

How to eliminate default visibility vulnerabilities by always specifying explicit visibility modifiers on all functions and state variables, and upgrading to Solidity 0.5.0+ which enforces this at compile time.

EVM Remediation

ERC20 Violations Remediation

How to eliminate ERC20 integration vulnerabilities by using SafeERC20 for all token operations, measuring actual received amounts for fee-on-transfer tokens, and handling non-standard token behaviors such as missing return values and rebase mechanics.

EVM Remediation

Use the Sign In button in the navigation bar.

Sigvex

Advanced bytecode decompilation and security analysis across multiple runtimes. Detect vulnerabilities, exploits, and reverse-engineer smart contracts directly on-chain.

Product

Features
How It Works
Pricing

Resources

Knowledge Base
Research
Blog

Company

About
Contact
Security

Legal

Terms of Service
Privacy Policy
Cookie Policy
Acceptable Use

Built for developers, by developers.