DEV Community: Ajaye Favour

Rust Learning Log: Glob Imports, Library Crates, Multiple Binaries

Ajaye Favour — Tue, 03 Mar 2026 10:49:56 +0000

Today I learned about the glob operator, creating a library crate, and multiple binary crates

The Glob Operator:

The glob operator (*) lets you import everything from a module at once.

At first, it felt strong. Almost too powerful.

Up until now, Rust has been teaching me to be explicit, to name exactly what I'm bringing into scope. The glob operator relaxes that slightly.

That contrast made me think. Rust gives you convenience, but it also gives you responsibility.

Even as a learner, I can see how using a glob import might make code shorter but potentially less clear. It made me more aware of how imports shape readability.

Creating a Library Crate:
Learning how to create a library crate changed how I view Rust projects.
Before this, everything I built felt like "a program." Now I see that Rust encourages you to build reusable logic, code meant to be consumed by other parts of the project or even other projects.

A library crate feels like saying: this code is meant to be depended on.

That shift in perspective, from writing code for execution to writing code for reuse, feels like a major step in maturity.

Multiple Binary Crates:
This one surprised me. A single project can have multiple binary crates, meaning multiple entry points.

That made me realize Rust doesn't assume your project is a single purpose tool. You can structure a project to serve different commands, roles, or execution flows while sharing the same core logic.

It made everything I've learned about modules and visibility suddenly make more sense. Structure supports scale.

Some languages can have multiple main packages in a project, but they need to be in separate directories. Rust's approach with multiple binaries in the same workspace feels similar but more integrated.

At this point, I'm starting to see Rust in layers.

Ownership taught me about memory discipline. Enums taught me about modeling uncertainty. Modules taught me about structure. Visibility taught me about boundaries.

Crates and binaries are teaching me about architecture.

Rust doesn't just teach me how to code. It teaches me how to design systems.

I'm still learning and still early, I will get a clearer picture soon.

When you're building projects, do you start thinking about reusability and architecture upfront, or do you refactor toward it once things get complex?


// Using the glob operator (imports everything)
use std::collections::*;

fn example_glob() {
    let mut map = HashMap::new();
    map.insert("key", "value");
}

// Library crate structure
// src/lib.rs
pub fn greet(name: &str) -> String {
    format!("Hello, {}", name)
}

pub fn farewell(name: &str) -> String {
    format!("Goodbye, {}", name)
}

// Binary crate that uses the library
// src/main.rs
use my_library::greet;

fn main() {
    println!("{}", greet("Rust"));
}

// Additional binary crate
// src/bin/other_tool.rs
fn main() {
    println!("This is a separate binary in the same project");
}

// Documentation comment with examples
/// Adds two numbers together.
/// 
/// # Examples
/// 
/// ```


/// let sum = my_library::add(2, 3);
/// assert_eq!(sum, 5);
///

pub fn add(a: i32, b: i32) -> i32 {
a + b
}




#Rust #RustLang #LearningRust #Programming #SoftwareEngineering #SoftwareArchitecture #CodeOrganization #LibraryDesign #Documentation #Blockchain #Solidity #SystemsDesign #CleanCode

Preventing Denial of Service Attacks in Smart Contracts: Implementing the Withdrawal Pattern

Ajaye Favour — Tue, 25 Mar 2025 08:47:17 +0000

The Pull-Based Withdrawal Pattern: A Defense Against Smart Contract DoS Attacks

There is a hidden danger that can shut down a smart contract.

Picture yourself trying to withdraw money from your bank, but nothing happens every time you press the button. The bank isn’t out of money—it just refuses to process your transaction. Now imagine this happening to thousands of people at the same time.

This is what a denial-of-service (DoS) attack looks like in the blockchain world. Instead of hacking the system, attackers exploit weaknesses in the code to block others from using a smart contract. The contract is still there, but it’s as good as useless for many users.

In simple terms, a DoS attack is like blocking the only exit in a building—people are stuck inside, even though the door is right there.

These attacks can freeze funds, disrupt entire projects, and cause massive losses.

How Can Withdrawals Be Blocked in Smart Contracts?

Today, we will discuss how users can get stuck in smart contracts and the hidden danger of withdrawals.

If you find yourself in a situation where the vending machine that gives out snacks was jammed by someone intentionally and the machine can no longer give anyone a snack, what would you do? That’s exactly what happens with withdrawal functions in smart contracts—they can be jammed or blocked, stopping people from getting their money.

Why are withdrawal functions vulnerable?
Withdrawal functions in smart contracts are particularly vulnerable because they handle money being sent out of the contract.

When a withdrawal happens, the contract needs to send funds to someone’s address. This means:

The contract must interact with external addresses (EOAs or other contracts)
The contract has to transfer actual value (cryptocurrency)
The receiving address might do unexpected things when it gets money Now, one broken withdrawal can block everyone. Some contracts process all withdrawals in a single transaction. If one person’s withdrawal fails, the entire transaction reverts, blocking everyone else. Attackers exploit this by deliberately making their withdrawal fail, locking up funds for everyone.

There could also be gas limit problems. If a contract tries to send money to multiple people in a single transaction, the gas cost can become too high.

The Problem with Push-Based Payments

Some smart contracts implement a “push” payment model where the contract directly sends funds to recipients. While this approach seems straightforward, it introduces a critical vulnerability: the contract’s ability to function becomes dependent on the recipient’s ability to receive funds.

Let’s examine a real-world vulnerability found in the Putty Finance protocol and explain how the “withdrawal pattern” can prevent such issues.

In Putty Finance’s case, when users withdrew their funds, the contract first attempted to send a fee to the contract owner before sending the remaining funds to the user:

// send the fee to the admin/DAO if fee is greater than 0%
uint256 feeAmount = 0;
if (fee > 0) {
    feeAmount = (order.strike * fee) / 1000;
    ERC20(order.baseAsset).safeTransfer(owner(), feeAmount);
}

ERC20(order.baseAsset).safeTransfer(msg.sender, order.strike - feeAmount);

This design created two potential DoS scenarios:

The Zero Address Problem: If the contract owner is set to the zero address (0x0), many ERC20 tokens will revert the transfer, causing the entire withdrawal function to fail. This will permanently lock users’ funds in the contract.
Malicious Token Hooks: ERC777 tokens or similar standards that implement receiver hooks could be used by a malicious contract owner to implement logic that rejects incoming transfers, making it impossible for users to withdraw their funds.

Let’s see what the address zero and the ERC777 are.

The zero address (0x0000000000000000000000000000000000000000) is a special Ethereum address that no one controls. It is commonly used as a placeholder to indicate an uninitialized or non-existent address in smart contracts. Developers use it for various purposes, such as checking if an ownership variable has been set, burning tokens by sending them to an inaccessible location, or preventing accidental transfers. Since no private key exists for the zero address, any funds or tokens sent to it are permanently lost.

ERC777 is an advanced Ethereum token standard that improves upon ERC20 by introducing a built-in hook mechanism that enables smart contracts and external accounts to react when they receive tokens. It maintains backward compatibility with ERC20, meaning it can work with existing ERC20 applications. A key feature is the tokensReceived hook, which allows recipients (especially smart contracts) to execute custom logic upon receiving tokens, enabling automation and security enhancements. ERC777 also supports operator functionality, allowing approved addresses to send tokens on behalf of others, improving usability for wallets and DeFi applications.

Token hooks are callback functions that execute automatically when tokens are transferred. The most notable example is the ERC777 token standard, which introduced hooks as an improvement over the basic ERC20 standard.

When an ERC777 token is transferred, it calls the tokensReceived hook on the recipient's address if the recipient is a contract. This happens before the transfer completes, allowing the recipient to react to incoming tokens.

From the code above, if the baseAsset is an ERC777 token and the owner() is a contract, the owner could implement a malicious tokensReceived hook that deliberately reverts:

// Malicious owner contract

contract MaliciousOwner {
    function tokensReceived(
        address operator,
        address from,
        address to,
        uint256 amount,
        bytes calldata userData,
        bytes calldata operatorData
    ) external {
        // Deliberately revert when receiving tokens
        revert("Denied");
    }
}

Since the owner fee transfer happens before the user receives their funds, this malicious reversion blocks ALL user withdrawals, effectively holding user funds hostage.

The Withdrawal Pattern Solution

The “withdrawal pattern” is a best practice in smart contract design that separates the tracking of balances from the actual transfer of funds. It eliminates this vulnerability by separating the accounting from the transfer.

How It Works

Instead of immediately transferring funds to recipients, the contract tracks owed balances internally
Recipients must explicitly call a separate function to withdraw their funds
Each recipient’s withdrawal is isolated from others, preventing chain-wide DoS attacks

Implementation for Putty Finance

The recommended solution completely separates the fee collection from the user’s withdrawal:

mapping(address => uint256) public ownerFees;

function withdraw(Order memory order) public {
    // ... existing code ...

    // transfer strike to owner if put is expired or call is exercised
    if ((order.isCall && isExercised) || (!order.isCall && !isExercised)) {
        // Calculate fee but don't transfer it yet
        uint256 feeAmount = 0;
        if (fee > 0) {
            feeAmount = (order.strike * fee) / 1000;
            ownerFees[order.baseAsset] += feeAmount;
        }

        // Transfer user's portion immediately
        ERC20(order.baseAsset).safeTransfer(msg.sender, order.strike - feeAmount);
        return;
    }
    // ... rest of function ...
}

// Separate function for owner to collect fees
function withdrawFee(address baseAsset) public onlyOwner {
    uint256 _feeAmount = ownerFees[baseAsset];
    ownerFees[baseAsset] = 0;
    ERC20(baseAsset).safeTransfer(owner(), _feeAmount);
}

With this design, users can still successfully withdraw their funds even if the owner’s fee withdrawal fails for any reason.

Benefits of the Withdrawal Pattern

Isolation of Risks: Each party’s withdrawal is independent, preventing one failure from affecting others
Reduced Attack Surface: Eliminates vulnerabilities related to recipient behaviour
Better Gas Efficiency: Allows recipients to choose when to withdraw, potentially saving on gas costs
Clearer Accounting: This makes it easier to track who is owed what
Enhanced User Trust: Users know they can always withdraw their funds regardless of protocol owner actions

Implementing the Withdrawal Pattern in Your Contracts

To implement the withdrawal pattern in your own smart contracts:

Create a mapping to track balances owed to each address
When a payment would normally be made, update the balance in the mapping instead
Implement a separate withdrawal function that users call to claim their funds
Always follow the “checks-effects-interactions” pattern when implementing withdrawals to prevent reentrancy attacks

The withdrawal pattern is a fundamental security best practice for smart contract developers. By separating balance tracking from fund transfers, it prevents numerous DoS attack vectors and ensures that users maintain control over their assets.

As demonstrated in the Putty Finance example, even well-intentioned contract designs can contain vulnerabilities when they directly transfer funds to recipients during multi-step operations. By adopting the withdrawal pattern, you can build more resilient protocols that inspire user confidence and protect against potential DoS attacks.

Remember: design patterns matter in blockchain security. The withdrawal pattern isn’t just a coding preference—it’s an essential security measure for any contract that handles value transfers.

Always stay safe out there. It does not matter if you are a developer or a user. You should always ask yourself this question: Is the withdrawal pattern followed to prevent denial of service?

I hope you enjoyed this article. I will see you in the next one.

Understanding Ethereum’s Data Structure: A Simple Guide

Ajaye Favour — Wed, 29 Nov 2023 13:33:09 +0000

Have you ever wondered what Merkle Patricia Trie was? I know you've also thought about it at some point. I found a way to simplify it for you, breaking it down to what I call "its simplest form."
I'm really happy to share this because I know it will help a whole lot.
Now, let's dive into this amazing article on Merkle Patricia Tries.

Note: Try to picture this whole scenario.

Consider Ethereum as a massive digital notebook where all transactions are recorded. This notebook is not governed by a single entity, as it is decentralized. Now, each page in this notebook is a “block,” and it has a list of transactions. When a page is filled, we seal it with a special code called a “hash.” This hash is like a unique fingerprint for that page, and it also contains the fingerprint of the previous page. So, all the pages are connected in a chain, and if you try to change something on an old page, it messes up the fingerprints, and everyone can see it. This makes it really hard to cheat or tamper with the transactions.
Ethereum uses a special system called the “Merkle Patricia Trie.” Pronounced “try,” it’s basically a structured way of arranging and protecting all the important details.

How does this work? We will see that in a bit.

The Family Tree Analogy

Think of the Merkle Patricia Trie as a tree—a family tree. At the top of this tree is the main root, like the last name of a big family. This root represents all the information stored in Ethereum. Each branch of the tree leads to more branches or leaves, much like the different branches of a family tree leading to various relatives.

But Ethereum’s tree deals with information, not names and relationships. In this family tree, any item of data—transaction or account balance, for example—is comparable to one individual. Every piece of data has a unique identity, just as every individual has distinctive qualities.

To make things even more efficient, Ethereum uses a special type of code called hexadecimal. It’s like a mix of numbers and letters that helps organize and quickly find information within this tree-like structure. This code acts as the address of a particular piece of information.

Now, to keep everything secure, each piece of information in this tree has a unique code called a “hash.” This hash acts as a fingerprint—no two pieces of information have the same fingerprint. If anything changes in the information, even a tiny bit, its fingerprint (hash) changes too. This way, Ethereum can easily spot if anything has been tampered with or updated.
One cool thing about this tree structure is that it’s super smart about updates. Let’s say something changes—maybe a new transaction happens or an account balance is updated. Instead of reorganizing the entire tree, the system only updates the specific part related to that change. This keeps things speedy and efficient.

Basically, the main hash at the top of the tree acts like a seal on a precious box. If anything within that box changes, even slightly, the seal changes too. This alerts the system that something has been modified or added, ensuring the integrity and security of all the information stored in Ethereum.

I’m sure you made that big family picture, and you can see it right now. So, let’s introduce three essential branches in this family information tree: the “World State,” the “Transaction,” and the “Transaction Receipt.”

World state: This is like a family album capturing the current financial state of everyone in Ethereum. Think of it as a snapshot of all account balances and contract storage.

Transaction: This is similar to a diary entry, documenting the who, what, and when of a transaction. This contains details of a particular action, like sending cryptocurrency from one account to another, smart contract execution, decentralized application (DApp) interactions, and token swaps on decentralized exchanges. Each Ethereum transaction consists of several components. A few are Nonce, Gas Price, Gas Limit, to (recipient), value, data, V, R, S (Digital signature), etc.

Transaction Receipt: The “Transaction Receipt” is like a confirmation slip for a transaction. It verifies that a transaction has been successfully completed, detailing any changes in the world. Transaction receipts consist of post-transaction state, total gas used, logs created through execution of the transaction, etc.

It is necessary to comprehend Ethereum’s data structure in order to navigate the blockchain ecosystem. It influences everything, from transactions to smart contracts, and serves as the foundation for information organization and security. This information is essential for effectively interacting with Ethereum, guaranteeing informed choices and the integrity of interactions in this decentralized environment, regardless of whether you’re a developer, user, or enthusiast.

I really enjoyed writing this. I hope you enjoy reading it too.
Don’t forget to share your thoughts on this.
Don’t forget to follow me for more “simplest form” explanations on Ethereum, blockchain, and Web 3.

See you next time!

Solidity Inheritance

Ajaye Favour — Sat, 24 Jun 2023 09:38:01 +0000

**
**
Consider constructing a home with a different rooms and features. Each area has a distinct role and use, but they all work together to form a whole and useful living space.

Solidity inheritance works similarly. Inheritance allows you to create smart contracts that inherit properties and functionality from other contracts, just like rooms in a house inherit certain characteristics from the overall house design.

Let's say you have a base contract called House. This House contract defines some fundamental features that every house should have, such as a foundation, walls, and a roof. It serves as the blueprint for all the houses you will build.

Now, you want to create a specialized contract called SmartHouse that inherits from the House contract. The SmartHouse contract adds additional features like automated lighting, smart locks, and energy monitoring.

By using inheritance, you can easily create the SmartHouse contract by extending the House contract. It's like adding extra rooms and advanced technologies to your existing house design.

Solidity supports inheritance, which allows you to create new contracts based on existing ones. Inheritance is a way to reuse code and avoid duplicating functionality across multiple contracts.

To inherit from a parent contract, you can use the "is" keyword followed by the name of the parent contract.

solidity #smartcontracts #blockchain #solidityinheritance