20-Minute Solidity Self-Check Catches Common Mainnet Deployment Bugs

Access Control: Who Can Call What?

Before shipping your Solidity smart contract to mainnet, a quick 20-minute self-check can prevent common, costly mistakes. This isn't a replacement for a professional audit, but a vital first pass. Focus on functions that handle funds, minting, pausing, or upgrades. For each external or public function involved, ask yourself: should any random address be able to call this? If the answer is no, verify that a robust access control mechanism is in place. This means checking for modifiers like onlyOwner or onlyRole, or explicit require statements (e.g., require(msg.sender == owner)) directly within the function itself. Crucially, ensure these checks are also present in any internal functions that your guarded functions delegate to. A function might appear safe at the top level, but if it calls an unguarded internal function that then performs a critical action, the vulnerability remains. This layered check is often overlooked.

Consider a scenario where a transferFunds function is guarded by onlyOwner. If transferFunds internally calls another function, say _executeTransfer, and _executeTransfer is not also guarded or doesn't re-verify the caller's permissions, a malicious actor could potentially exploit this internal delegation. The goal is to ensure that no sensitive operation can be initiated by an unauthorized caller, even through indirect function calls.

Reentrancy: Can Funds Be Drained in a Loop?

Reentrancy is one of the most notorious attack vectors in smart contract development. It occurs when an external call from a contract to another contract allows the called contract to make a recursive call back into the original contract before the first execution has completed. This can lead to funds being drained repeatedly.

To check for reentrancy risks, examine all functions that perform an external call (e.g., call, send, transfer, or calls to other contract functions) before updating the contract's state. The established pattern to mitigate this is the Checks-Effects-Interactions pattern: first, perform all necessary checks (access control, conditions), then update the contract's internal state (e.g., balances, ownership), and only then perform any external interactions. This ensures that the state is updated before an attacker can re-enter the function. If your code calls an external contract, especially one that transfers Ether or tokens, after checking conditions but before updating your own internal state, you are vulnerable. If the external call fails or is exploited, your internal state remains unchanged, preventing infinite loops or double spending.

A common mistake is sending Ether or tokens and then updating the balance. For example:

function withdraw() public {
    uint amount = balances[msg.sender];
    // Interaction before updating state (vulnerable!)
    (bool success, ) = msg.sender.call{value: amount}("");
    // Effect (state update) happens too late
    balances[msg.sender] = 0;
    require(success, "Transfer failed");
}

The correct pattern would be:

function withdraw() public {
    uint amount = balances[msg.sender];
    // Effect (state update) happens first
    balances[msg.sender] = 0;
    // Interaction happens after state update
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success, "Transfer failed");
}

Integer Overflow/Underflow: Are Calculations Safe?

Before Solidity version 0.8.0, integer overflow and underflow were critical vulnerabilities. An overflow occurs when an arithmetic operation results in a value larger than the maximum representable value for its type, wrapping around to the minimum. Underflow is the opposite, wrapping around to the maximum. For example, adding 1 to the maximum value of a uint8 (255) results in 0. Subtracting 1 from 0 results in 255.

If your contract is written for a Solidity version below 0.8.0 and does not use SafeMath or similar libraries, you must manually check every arithmetic operation involving external inputs or critical state variables. Look for additions, subtractions, multiplications, and divisions. For additions, ensure a + b >= a. For subtractions, ensure a - b <= a. For multiplications, ensure a * b / a == b (though this can be tricky with zero values). If you are using Solidity 0.8.0 or later, these checks are built-in by default, and overflow/underflow will revert the transaction. However, if you've explicitly disabled the default checked arithmetic (e.g., using unchecked { ... } blocks), you must perform these checks manually within those blocks.

Denial of Service (DoS): Can the Contract Be Halted?

Denial of Service (DoS) vulnerabilities prevent legitimate users from accessing or using the contract's functionality. Common DoS vectors include gas limit issues, unexpected reverts in loops, or external dependencies that might fail. For this self-check, focus on loops that iterate over arrays or mappings whose size can be influenced by external actors. If a loop processes all elements of a potentially large array (e.g., paying out all participants in a lottery), and the gas cost to execute the loop exceeds the block gas limit, the function can become unusable for everyone. The same applies if the loop relies on external calls that might fail or revert.

A common pattern to mitigate this is to move away from iterating over unbounded collections within a single transaction. Instead, consider implementing a pull-payment system where users claim their funds individually. Alternatively, cap the number of items processed per transaction or use gas-efficient data structures. For example, instead of paying out all users in a loop, allow each user to call a claimReward() function.

Timestamp Dependence: Is the Contract Immune to Manipulation?

Smart contracts should not rely on block timestamps for critical logic, especially for time-sensitive operations like randomness generation or time locks. Miners have a degree of control over block timestamps, and they can manipulate them within certain bounds to their advantage. If your contract uses block.timestamp for anything other than general time tracking (like determining if a certain time has passed), you might be vulnerable.

Specifically, check any functions where block.timestamp is used to determine outcomes, unlock funds prematurely, or influence critical state changes. If block.timestamp is used to generate randomness, consider using commit-reveal schemes or external oracles. If it's used for time locks, ensure that the unlocking condition is based on a sufficiently large duration that miners cannot easily manipulate, or better yet, use block numbers for relative time passage if absolute time isn't critical.

Uninitialized Storage Pointers (Solidity <0.8.0): Are Storage Slots Correct?

In older versions of Solidity (prior to 0.8.0), uninitialized storage pointers could lead to critical vulnerabilities. If you declare a variable of a complex type (like a struct or mapping) and assign it to a storage pointer without explicitly initializing it, it might default to storage slot 0. If slot 0 is already in use by another variable, you could inadvertently overwrite or read from the wrong storage location. This can lead to incorrect state access, data corruption, or unintended function execution.

Always ensure that any storage pointers are explicitly initialized to a known state or a specific storage slot. If you are using structs or mappings, ensure they are properly instantiated before use. For example, if you have MyStruct storage myStructPtr = structs[key];, ensure that structs[key] actually exists or is intended to be initialized. If you are using Solidity 0.8.0 or later, this specific issue is largely mitigated due to stricter compiler checks and the introduction of value types for storage pointers, but it's a critical point for contracts targeting older versions or those with complex storage layouts.

Final Thoughts on Your Pre-Deployment Checklist

This 20-minute checklist covers the most common and impactful vulnerabilities found in new Solidity projects. It requires your eyes and a critical mindset, not complex tooling. While it doesn't replace a full professional audit, it acts as an essential first line of defense. Shipping a smart contract to mainnet is a significant event; treat it with the diligence it deserves. Catching these issues now saves immense pain, cost, and reputation damage later.