DEV Community: ArefXV

How ETH Is Received in Smart Contracts

ArefXV — Sat, 14 Jun 2025 17:19:25 +0000

How ETH Is Received in Smart Contracts — `receive()`, `fallback()`, and Common Mistakes

Smart contracts on Ethereum can receive ETH directly. But what actually happens when someone sends ETH to a contract? And why do some transactions fail silently while others go through?

Let’s dive deep into how Ether is handled in Solidity, the differences between receive() and fallback(), and some key developer mistakes you should avoid.

ETH Transfers 101

When you send ETH to a contract, one of two functions will be triggered based on the context:

receive() external payable
fallback() external payable

These are special functions in Solidity that aren’t called directly in code. They get triggered under very specific circumstances.

When Does `receive()` Run?

The receive() function runs when:

A contract receives ETH with empty calldata
The receive() function is marked payable

Example:

receive() external payable {
    emit Received(msg.sender, msg.value);
}

If someone calls the contract with just ETH (e.g., using .transfer() or sending ETH directly via MetaMask), this function will run.

Use case: Simple ETH deposits with no logic or function calls.

When Does fallback() Run?

The fallback() function is more general. It runs when:

A function is called that doesn’t exist

OR when calldata is not empty

AND receive() is either not present or doesn’t match

fallback() external payable {
    emit FallbackCalled(msg.sender, msg.value, msg.data);
}

You can also define a non-payable fallback if you want to reject ETH:

fallback() external {
    revert("ETH not accepted");
}

Common Developer Mistakes

1. Not defining receive() or fallback()

If your contract is meant to accept ETH but has neither, any direct ETH transfer will revert.

Fix: Add at least one payable function (receive() or fallback()).

2. Heavy Logic in Fallbacks

Since fallback functions can get triggered unintentionally, avoid writing logic-heavy operations that might increase gas use or create vulnerabilities.

3. Not Handling msg.data

Sometimes, users (or attackers) send ETH with extra calldata. If you're only using receive(), those transactions will revert. Always consider a fallback for maximum safety.

Real-World Example: Accepting ETH in a Treasury Contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.25;

contract Treasury {
    address public owner;

    event Received(address sender, uint256 amount);
    event FallbackCalled(address sender, uint256 amount, bytes data);

    constructor() {
        owner = msg.sender;
    }

    receive() external payable {
        emit Received(msg.sender, msg.value);
    }

    fallback() external payable {
        emit FallbackCalled(msg.sender, msg.value, msg.data);
    }

    function withdraw() external {
        require(msg.sender == owner, "Only owner");
        payable(owner).transfer(address(this).balance);
    }
}

Try sending ETH from your wallet or via Remix — both receive and fallback will log different events based on how the ETH was sent.

What About Vyper?

Vyper handles this similarly but doesn’t use receive() or fallback() keywords directly. It uses:

@external
@payable
def __default__():
    # Code here runs on unknown function call or direct ETH

Everything is handled in default, so you must manually manage what to accept and reject.

Best Practices

Always define receive() if your contract is meant to receive ETH directly.

Use a fallback() to catch unexpected calls or ETH sent with data.

Don’t rely on these functions for business logic.

Always emit logs for transparency (emit Received(...)) for off-chain monitoring.

Final Words

Many developers forget to test how their contracts behave with unexpected inputs or ETH sent manually. A missing receive() function can easily break dApps like fundraising contracts, treasuries, or NFT mints.

When building production-grade contracts, always include proper ETH handling, and test them via .call, .transfer, or even raw transactions.

Want me to cover gas optimizations, reentrancy, or cross-chain bridging next? Stay tuned.

Access Control in Solidity: Beyond onlyOwner

ArefXV — Tue, 10 Jun 2025 06:38:03 +0000

Access control is the backbone of secure smart contract design.

Whether you’re building a DeFi protocol, NFT minting contract, or on-chain governance system — you need to control who can do what.

But too often, developers default to a single onlyOwner check and call it a day. That might work for simple prototypes — but in production systems, it’s dangerous, inflexible, and often unsustainable.

In this guide, we’ll walk through the most important access control patterns in Solidity, their use cases, trade-offs, and how to do it right.

** The Foundations: onlyOwner and Ownable**

OpenZeppelin’s Ownable contract is the simplest form of access control:

function transferOwnership(address newOwner) public onlyOwner;

You define an owner, and functions are restricted via the onlyOwner modifier.

✅ Pros:
• Simple and lightweight
• Perfect for early-stage prototypes or single-admin tools

❌ Cons:
• No flexibility for multiple roles
• Hard to decentralize
• Difficult to scale with teams, DAOs, or governance

Role-Based Access: OpenZeppelin’s AccessControl

For more complex permissioning, OpenZeppelin provides a Role-Based Access Control (RBAC) system:

bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");

function mint() public onlyRole(MINTER_ROLE) { ... }

You can create any number of roles (e.g. PAUSER_ROLE, BURNER_ROLE) and assign/revoke them dynamically.

grantRole(MINTER_ROLE, user);
revokeRole(MINTER_ROLE, user);

✅ Pros:
• Fine-grained control
• Roles can be assigned to different addresses
• Great for modular permissioning
• Integrates well with on-chain governance

❌ Cons:
• Slightly more gas
• Requires thoughtful role management
• No built-in multi-sig support (but can integrate)

Modular Role Design: Real-World Patterns

Here are a few useful role patterns used in serious protocols:

Pausable Pattern

function pause() external onlyRole(PAUSER_ROLE);
function unpause() external onlyRole(PAUSER_ROLE);

Allows freezing protocol functions in emergencies (e.g., hacks, oracle failures).

Operator/Admin Split

ADMIN_ROLE: can assign/revoke other roles

OPERATOR_ROLE: can perform daily actions (e.g., rebalance, harvest, trigger events)

Keeps critical keys cold and uses hot wallets only for limited functions.

DAO-Ready Roles

When building for DAOs, make all roles assignable via proposals, not by a single owner.

Use:
• A TimelockController contract
• Role assignments gated by governance
• Non-upgradeable core + upgradeable modules

Upgrade-Safe Access Control

Rule of thumb: When upgrading contracts via proxies, access control must live in the same storage layout.

You can:
• Store roles in the proxy
• Avoid accidentally removing access in the next version
• Reserve storage slots for future roles (just in case)

Always test upgrades using tools like OpenZeppelin’s Upgrades plugin to ensure storage layout isn’t corrupted.

Common Mistakes

1. Hardcoding a single admin

require(msg.sender == 0x123...); // Don’t do this

Not flexible, not testable, and hard to migrate.

2. Using onlyOwner in upgradeable contracts without OwnableUpgradeable

Solidity doesn’t automatically preserve Ownable state unless you inherit from the correct proxy-safe version.

3. Forgetting to emit access change events

Always emit:

event RoleGranted(bytes32 role, address account, address sender);

Without logs, tracking permissions is nearly impossible

When to Use Which

Small contracts / MVP => Ownable
Multi-role systems => AccessControl
Governance / Timelock => AccessControl + TimelockController
Protocols with emergency handling => Add Pausable role
Teams with cold/hot wallets => Admin/operator split