DEV Community: Olena

A .NET Dinosaur in Web3. Day 19 - Upgradeable Contracts

Olena — Mon, 01 Jun 2026 16:30:00 +0000

🏁 Day 7 of 7: Proxy Patterns, EVM Assembly, and Hot-Swapping Logic in Production

Day 7 was the one I didn't expect to enjoy this much.

Assembly code. Low-level EVM opcodes. A pattern that lets you upgrade a deployed smart contract without changing its address, without migrating data, and without breaking a single integration. All in one session.

✅ The 7-day challenge is officially done. Here's how it ended.

The Problem: Immutability Is Not Always a Feature

By default, every smart contract on Ethereum is immutable. Once deployed, the bytecode cannot be changed. If you find a critical bug six months later — or the business logic needs to change — you can't patch it. You can't roll out a new version to the same address.

In .NET, this is solved trivially: deploy a new DLL, update a config, restart the service. On a blockchain, there's no restart. There's no config file. There's only the bytecode sitting permanently at an address.

The Proxy Pattern solves this by splitting one logical contract into two physical ones.

The Proxy Pattern: Splitting State From Logic

Proxy Contract — holds the state. All balances, mappings, variables. Users always interact with this address. It never changes.

Implementation Contract — holds the logic. Just functions, no state of its own. Stateless by design.

When a user calls a function on the Proxy, the Proxy uses delegatecall to execute code from the Implementation — but in the context of the Proxy's own storage. The logic is borrowed. The memory is the Proxy's.

The .NET analogy: AssemblyLoadContext — dynamically loading an external DLL into the host process. The code is external, but the runtime memory and local state belong to the host.

To upgrade: deploy a new Implementation, call upgradeTo(newAddress) on the Proxy. Same address for users. New logic underneath.

The Critical Trap: Storage Slot Collisions

In Solidity, state variables are stored sequentially in 32-byte slots starting from Slot 0.

address public implementation; // Slot 0
address public admin;          // Slot 1
uint256 public storedValue;    // Slot 2

If V2 adds a new variable at the top of the list, it shifts everything down:

uint256 public newCounter;     // Slot 0 ← COLLISION
address public implementation; // Slot 1 ← was Slot 0
address public admin;          // Slot 2 ← was Slot 1

The Proxy's storage hasn't changed. But V2's bytecode now reads admin from Slot 2 — which in the Proxy holds storedValue. The owner address is silently overwritten. The contract is permanently broken.

The rule: new variables can only be appended at the end. Never insert, never reorder.

The Contracts

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

contract MiniProxy {
    address public implementation; // Slot 0
    address public admin;          // Slot 1

    constructor(address _implementation) {
        implementation = _implementation;
        admin = msg.sender;
    }

    function upgradeTo(address _newImplementation) external {
        require(msg.sender == admin, "Only admin");
        implementation = _newImplementation;
    }

    fallback() external payable {
        address _impl = implementation;
        assembly {
            calldatacopy(0, 0, calldatasize())
            let result := delegatecall(gas(), _impl, 0, calldatasize(), 0, 0)
            returndatacopy(0, 0, returndatasize())
            switch result
            case 0 { revert(0, returndatasize()) }
            default { return(0, returndatasize()) }
        }
    }

    receive() external payable {}
}

contract VaultV1 {
    address public implementation; // Slot 0 — mirrors Proxy
    address public admin;          // Slot 1 — mirrors Proxy
    uint256 public storedValue;    // Slot 2

    function setValue(uint256 _newValue) external {
        storedValue = _newValue;
    }
}

contract VaultV2 {
    address public implementation; // Slot 0 — unchanged
    address public admin;          // Slot 1 — unchanged
    uint256 public storedValue;    // Slot 2 — unchanged
    uint256 public transactionCount; // Slot 3 — new, appended at the end

    function setValue(uint256 _newValue) external {
        storedValue = _newValue;
        transactionCount += 1;
    }
}

The fallback function is the heart of the proxy. Every call that doesn't match a function in MiniProxy lands here. The assembly block copies the calldata, fires delegatecall to the implementation, copies the return data, and routes based on success or failure.

This is raw EVM. No abstractions. No safety net. Exactly what you want when you need to understand what's actually happening.

Console: Hot Upgrade in Action

npx hardhat ignition deploy ignition/modules/UpgradeableVault.ts --network localhost --reset
npx hardhat console --network localhost

const { viem } = await network.create();
const cViem = require("viem");

const proxyAddress = "0x9A676e781A523b5d0C0e43731313A708CB607508";
const v2Address = "0x0DCd1Bf9A1b36cE34237eEaFef220932846BCD82";

const proxy = await viem.getContractAt("MiniProxy", proxyAddress);

// Step 1: use V1 interface on the Proxy address
const vaultAsV1 = await viem.getContractAt("VaultV1", proxyAddress);
await vaultAsV1.write.setValue([42n]);
console.log("V1 stored value:", await vaultAsV1.read.storedValue()); // 42n

// Step 2: upgrade
await proxy.write.upgradeTo([v2Address]);
console.log("Upgrade successful.");

// Step 3: use V2 interface on the SAME Proxy address
const vaultAsV2 = await viem.getContractAt("VaultV2", proxyAddress);
console.log("Value preserved after upgrade:", await vaultAsV2.read.storedValue()); // 42n ✅

// Step 4: call V2 logic
await vaultAsV2.write.setValue([100n]);
console.log("New stored value:", await vaultAsV2.read.storedValue()); // 100n
console.log("Transaction count:", await vaultAsV2.read.transactionCount()); // 1n

The output:

42n survived the upgrade without collision
transactionCount initialised at zero and incremented correctly
The Proxy address never changed

A hot upgrade of production logic with zero downtime and zero data migration.

7 Days. 7 Contracts. What Actually Happened.

Day	Contract	Core concept
1	AccessControlledVault	constructor, modifier, custom errors, renounceOwnership
2	SimpleEscrow	Pull-over-Push, Bulkhead pattern, CEI, death of .transfer()
3	SimpleVotingDAO	O(1) storage design, Gas Limit DoS, block.timestamp in PoS
4	MyToken & ICO	ERC-20 standard, fixed-point math, approve race condition
5	SimpleStaking	Lazy Update pattern, time travel testing, IERC20 vs ERC20
6	SimpleAMM	x·y=k invariant, slippage, internal reserves
7	UpgradeableVault	delegatecall, Proxy pattern, storage slot collisions

What transferred directly from .NET: transaction thinking, CEI as a guard clause pattern, interface segregation, defensive architecture, separation of concerns.

What was genuinely new: gas as a design constraint, immutability as a default, price as an emergent property of math, and the fact that a 7-line assembly block can replace an entire upgrade infrastructure.

What's Next

The challenge covered maybe 5% of what's possible in Solidity. The plan now: take WishList Chain and Smart Money Tracker from MVP to v1, and go deeper into security — reentrancy patterns, audit techniques, real attack vectors.

✨ If you have ideas for the next challenge — drop them in the comments. 👇

Repo: github.com/alena-dev-soft

Follow the journey on Telegram: t.me/dotnetToWeb3

Stage: Hybrid 🦕⚡ — understands both worlds. Challenge complete.

A .NET Dinosaur in Web3. Day 18 - Automated Market Maker

Olena — Sun, 31 May 2026 15:26:18 +0000

🏦 Day 6 of 7: Building a Mini Uniswap in 80 Lines of Solidity

Imagine a vending machine. It has 1,000 coffee beans and 1,000 coins. No menu, no cashier — just one iron rule: the product of the two numbers inside must never decrease.

That's it!

This is how Uniswap works — and this is what I built on Day 6, coming from .NET. Here's how, why it's elegant, and where you can step on a rake.

Why an Order Book Doesn't Work on a Blockchain

Traditional exchanges — Binance, NYSE, any CEX — run on an order book. Market makers post bids and asks. A matching engine pairs them. Millions of updates per second, all in a centralised database.

In a blockchain, this is impossible. Transactions take 12 seconds. Every state change costs gas. Storing millions of constantly changing orders would eat all the profit before a single trade completes.

Uniswap's solution: replace the order book with a liquidity pool — a smart contract holding two tokens — and replace the matching engine with pure math.

Just a formula — below.

x · y = k — The Formula That Broke Finance

The Constant Product Invariant:

x · y = k

Where x is the reserve of Token0, y is the reserve of Token1, and k is a constant that must never decrease during swaps.

When a trader sells Token0 into the pool, x increases. To keep k constant, y must decrease — the contract sends out Token1. The price is determined automatically by the ratio of reserves.

Live example with numbers:

Pool: 1,000 Token0, 1,000 Token1. k = 1,000,000.

Trader sells 100 Token0:

amountOut = (reserveOut × amountIn) / (reserveIn + amountIn)
amountOut = (1000 × 100) / (1000 + 100)
amountOut = 100,000 / 1,100
amountOut ≈ 90.9 Token1

The trader gets ~90.9, not 100. That gap is slippage — and it's not a bug. It's the formula protecting the pool. The more you buy relative to pool size, the worse your price gets. Naturally. Mathematically.

After the swap: pool has 1,100 Token0 and ~909.1 Token1. k ≈ 1,000,000. Invariant holds.

The Contract: SimpleAMM

Three functions. Each one exists for a specific reason.

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

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";

contract SimpleAMM {
    error ZeroAmount();
    error InvalidToken();
    error ZeroLiquidity();
    error TransferFailed();
    error InvalidRatio();

    IERC20 public immutable token0;
    IERC20 public immutable token1;

    // Internal reserves — cheaper than calling balanceOf() every time
    uint256 public reserve0;
    uint256 public reserve1;

    event LiquidityAdded(address indexed provider, uint256 amount0, uint256 amount1);
    event Swap(address indexed trader, address tokenIn, uint256 amountIn, uint256 amountOut);

    constructor(address _token0, address _token1) {
        token0 = IERC20(_token0);
        token1 = IERC20(_token1);
    }

    // Pure math — no state, no side effects
    function getAmountOut(uint256 _amountIn, uint256 _reserveIn, uint256 _reserveOut)
        public pure returns (uint256)
    {
        if (_amountIn == 0) revert ZeroAmount();
        if (_reserveIn == 0 || _reserveOut == 0) revert ZeroLiquidity();

        // Multiply first, divide last — always
        uint256 numerator = _reserveOut * _amountIn;
        uint256 denominator = _reserveIn + _amountIn;
        return numerator / denominator;
    }

    function addLiquidity(uint256 _amount0, uint256 _amount1) external {
        if (_amount0 == 0 || _amount1 == 0) revert ZeroAmount();

        // If pool already has liquidity, enforce the current price ratio
        if (reserve0 > 0 && reserve1 > 0) {
            if (_amount0 * reserve1 != _amount1 * reserve0) revert InvalidRatio();
        }

        if (!token0.transferFrom(msg.sender, address(this), _amount0)) revert TransferFailed();
        if (!token1.transferFrom(msg.sender, address(this), _amount1)) revert TransferFailed();

        reserve0 += _amount0;
        reserve1 += _amount1;

        emit LiquidityAdded(msg.sender, _amount0, _amount1);
    }

    function swap(address _tokenIn, uint256 _amountIn) external returns (uint256 amountOut) {
        if (_amountIn == 0) revert ZeroAmount();
        if (_tokenIn != address(token0) && _tokenIn != address(token1)) revert InvalidToken();

        bool isToken0 = _tokenIn == address(token0);

        (IERC20 tokenIn, IERC20 tokenOut, uint256 reserveIn, uint256 reserveOut) = isToken0
            ? (token0, token1, reserve0, reserve1)
            : (token1, token0, reserve1, reserve0);

        // CEI: pull tokens in first
        if (!tokenIn.transferFrom(msg.sender, address(this), _amountIn)) revert TransferFailed();

        // Calculate output
        amountOut = getAmountOut(_amountIn, reserveIn, reserveOut);

        // Update reserves
        if (isToken0) {
            reserve0 += _amountIn;
            reserve1 -= amountOut;
        } else {
            reserve0 -= amountOut;
            reserve1 += _amountIn;
        }

        emit Swap(msg.sender, _tokenIn, _amountIn, amountOut);

        // Send output tokens to trader
        if (!tokenOut.transfer(msg.sender, amountOut)) revert TransferFailed();
    }
}

getAmountOut — pure math, no state. Separated deliberately so it can be called by anyone to preview a trade before executing it. In DeFi this is standard: quote first, then transact.

addLiquidity — the ratio check is the interesting part. If the pool already has reserves, you can't deposit in arbitrary proportions. _amount0 * reserve1 != _amount1 * reserve0 detects any imbalance. Deposit skewed amounts and you'd instantly change the price — essentially donating money to arbitrageurs.

swap — the ternary tuple assignment is the cleanest part of the contract. Instead of two separate if/else branches, one line maps all four variables correctly based on direction:

(IERC20 tokenIn, IERC20 tokenOut, uint256 reserveIn, uint256 reserveOut) = isToken0
    ? (token0, token1, reserve0, reserve1)
    : (token1, token0, reserve1, reserve0);

Where You Can Step on a Rake

Integer division truncates, silently.

getAmountOut divides at the end — intentionally. But the truncation still happens. 100,000 / 1,100 = 90, not 90.909.... The pool keeps the remainder. At scale across millions of trades, this accumulated dust is non-trivial. Production AMMs handle this with basis points (fee = 30 bps = multiply by 997/1000 before dividing).

Internal reserves vs balanceOf.

The contract tracks reserve0 and reserve1 internally instead of calling token0.balanceOf(address(this)) every time. Two reasons: gas savings (SLOAD is expensive, external calls are more expensive), and security — if someone sends tokens directly to the contract without going through addLiquidity, the reserves won't silently become unbalanced and break the invariant.

Console Verification Flow

npx hardhat ignition deploy ignition/modules/SimpleAMM.ts --network localhost --reset
npx hardhat console --network localhost

const { viem } = await network.create();
const [owner, trader] = await viem.getWalletClients();
const cViem = require("viem");

const t0Address = "0x5FbDB2315678afecb367f032d93F642f64180aa3";
const t1Address = "0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512";
const ammAddress = "0x9fE46736679d2D9a65F0992F2272dE9f3c7fa6e0";

const token0 = await viem.getContractAt("MyToken", t0Address);
const token1 = await viem.getContractAt("MyToken", t1Address);
const amm = await viem.getContractAt("SimpleAMM", ammAddress);

// Trader buys tokens via ICO
const t0AsTrader = await viem.getContractAt("MyToken", t0Address, { client: { wallet: trader } });
const t1AsTrader = await viem.getContractAt("MyToken", t1Address, { client: { wallet: trader } });
await t0AsTrader.write.buyTokens({ value: cViem.parseEther("2") }); // 2000 Token0
await t1AsTrader.write.buyTokens({ value: cViem.parseEther("2") }); // 2000 Token1

// Add liquidity 1000:1000
const ammAsTrader = await viem.getContractAt("SimpleAMM", ammAddress, { client: { wallet: trader } });
await t0AsTrader.write.approve([ammAddress, cViem.parseEther("1000")]);
await t1AsTrader.write.approve([ammAddress, cViem.parseEther("1000")]);
await ammAsTrader.write.addLiquidity([cViem.parseEther("1000"), cViem.parseEther("1000")]);

console.log("Reserve 0:", cViem.formatEther(await amm.read.reserve0())); // 1000
console.log("Reserve 1:", cViem.formatEther(await amm.read.reserve1())); // 1000

// Swap 100 Token0 → Token1
await t0AsTrader.write.approve([ammAddress, cViem.parseEther("100")]);
await ammAsTrader.write.swap([t0Address, cViem.parseEther("100")]);

const traderT1Balance = await token1.read.balanceOf([trader.account.address]);
console.log("Trader Token1 after swap:", cViem.formatEther(traderT1Balance));
// ~1090.909... — math checks out

The formula lands exactly. 1,000 × 100 / 1,100 = 90.909... Token1 received. The invariant holds.

What This Day Actually Meant

Six days ago I was writing owner = msg.sender in a constructor. Today I implemented the core pricing engine of a decentralised exchange.

What transferred directly from .NET:

CEI pattern — same as any transactional system
Separation of pure logic (getAmountOut) from state mutation (swap) — same as keeping domain logic out of controllers
Defensive checks before any state change — same as guard clauses

What was genuinely new:

Thinking in invariants instead of conditions
Price as an emergent property of reserves, not a stored value
The elegance of x · y = k — one line that replaces an entire matching engine

What's Next

Day 7: Reentrancy Protection — the vulnerability that cost $60M in the 2016 DAO hack, and how to write contracts that can't be drained.

Repo: github.com/alena-dev-soft

Follow the journey on Telegram: t.me/dotnetToWeb3

Stage: Dinosaur 🦕 — going deeper into the bedrock. Day 6 of 7.

A .NET Dinosaur in Web3. Day 17 - Staking

Olena — Sat, 30 May 2026 12:00:00 +0000

Day 5 of 7: Lazy Updates, Time Travel, and Earning Rewards Without Loops

Day 5 connected everything from the previous four days into one working system. The ERC-20 token from Day 4 becomes the asset. The staking contract locks it, tracks time, and pays out rewards — without a single loop.

The Problem With Naive Staking

The obvious approach: store all stakers in an array, iterate through them on a schedule, distribute rewards. In .NET this would be a background job touching a database table.

In Solidity, iterating through all stakers is a Gas Limit DoS attack. The more users stake, the more expensive the distribution call becomes. Eventually it becomes physically impossible to mine. The contract freezes.

The solution: Lazy Updates. Never iterate over users. Calculate each user's rewards on-demand, at the exact moment they interact with the contract.

The Contract: SimpleStaking

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

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";

contract SimpleStaking {
    error ZeroAmount();
    error InsufficientStake();
    error TransferFailed();

    IERC20 public immutable stakingToken;

    uint256 public constant REWARD_RATE_PER_SECOND = 1;

    struct Staker {
        uint256 stakedAmount;
        uint256 rewardsAccrued;
        uint256 lastUpdateTime;
    }

    mapping(address => Staker) public stakers;

    event Staked(address indexed user, uint256 amount);
    event Unstaked(address indexed user, uint256 amount);
    event RewardClaimed(address indexed user, uint256 reward);

    constructor(address _tokenAddress) {
        stakingToken = IERC20(_tokenAddress);
    }

    modifier updateReward(address _account) {
        Staker storage staker = stakers[_account];
        if (staker.stakedAmount > 0) {
            uint256 timeElapsed = block.timestamp - staker.lastUpdateTime;
            uint256 earned = staker.stakedAmount * timeElapsed * REWARD_RATE_PER_SECOND / 100;
            staker.rewardsAccrued += earned;
        }
        staker.lastUpdateTime = block.timestamp;
        _;
    }

    function stake(uint256 _amount) external updateReward(msg.sender) {
        if (_amount == 0) revert ZeroAmount();
        stakers[msg.sender].stakedAmount += _amount;
        emit Staked(msg.sender, _amount);
        bool success = stakingToken.transferFrom(msg.sender, address(this), _amount);
        if (!success) revert TransferFailed();
    }

    function unstake(uint256 _amount) external updateReward(msg.sender) {
        Staker storage staker = stakers[msg.sender];
        if (staker.stakedAmount < _amount) revert InsufficientStake();
        staker.stakedAmount -= _amount;
        emit Unstaked(msg.sender, _amount);
        bool success = stakingToken.transfer(msg.sender, _amount);
        if (!success) revert TransferFailed();
    }

    function claimReward() external updateReward(msg.sender) {
        Staker storage staker = stakers[msg.sender];
        uint256 reward = staker.rewardsAccrued;
        if (reward > 0) {
            staker.rewardsAccrued = 0;
            emit RewardClaimed(msg.sender, reward);
            bool success = stakingToken.transfer(msg.sender, reward);
            if (!success) revert TransferFailed();
        }
    }
}

What Actually Clicked

The updateReward modifier is the entire architecture.

Every function that changes staker state — stake, unstake, claimReward — is decorated with updateReward. Before anything else runs, the modifier calculates how much time has passed since the user's last interaction and accrues the earned rewards to their record. Then _; passes control to the function body.

This is the Lazy Update pattern: no background job, no scheduler, no iteration. The math runs exactly once per user per transaction, in O(1).

The .NET analogy: instead of a scheduled IHostedService that iterates all accounts every minute, you calculate the accrued interest inline when the user touches their account. Same result, zero coordination overhead.

IERC20 vs ERC20 — interface vs implementation.

The staking contract imports IERC20 rather than ERC20. It doesn't need the full implementation — it only needs to call transferFrom and transfer. Using the interface keeps the contract lean and makes it compatible with any ERC-20 token, not just MyToken. The same pattern as coding to IRepository<T> instead of a concrete class in .NET.

The approve dependency.

Before calling stake(), the user must call approve(stakingAddress, amount) on the token contract. The staking contract then calls transferFrom to pull the tokens in. This is the same OAuth2-style delegation from Day 4 — now applied in a real protocol flow.

Struct field access in Viem.

When reading a mapping that returns a struct, Viem returns a tuple. The fields are accessible both by index and by destructuring:

// By index
const profile = await staking.read.stakers([investor.account.address]);
console.log(profile["0"]); // stakedAmount

// By destructuring — cleaner
const [stakedAmount, rewardsAccrued, lastUpdateTime] =
    await staking.read.stakers([investor.account.address]);

The destructuring version is more readable and avoids magic index numbers.

Testing: Time Travel in Hardhat

Testing time-dependent reward logic requires advancing the blockchain clock. Hardhat exposes two low-level RPC commands for this:

// Shift the node's clock forward by 100 seconds
await network.provider.send("evm_increaseTime", [100]);

// Mine an empty block to commit the new timestamp
await network.provider.send("evm_mine");

Or via the test helpers in Hardhat 3:

await context.networkHelpers.time.increase(100);

The reward formula: stakedAmount × timeElapsed × REWARD_RATE_PER_SECOND / 100

With 100 MET staked for 100 seconds at rate 1:
100 × 100 × 1 / 100 = 100 MET

The test: investor buys 1000 MET, stakes 100, advances 100 seconds, claims reward. Final balance: 1001 MET (900 unstaked + 100 reward claimed — with one extra block of time from the claimReward call itself adding ~1 MET).

One fix that took time: the original test called buyTokens([], { value: ... }) with an empty args array. Viem requires omitting the args array entirely for functions with no parameters: buyTokens({ value: ... }). Small difference, silent failure.

Console Use Case: Full Staking Cycle

npx hardhat ignition deploy ignition/modules/SimpleStaking.ts --network localhost --reset
npx hardhat console --network localhost

const { viem } = await network.create();
const [owner, investor] = await viem.getWalletClients();
const cViem = require("viem");

const tokenAddress = "0x5FbDB2315678afecb367f032d93F642f64180aa3";
const stakingAddress = "0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512";

const token = await viem.getContractAt("MyToken", tokenAddress);
const staking = await viem.getContractAt("SimpleStaking", stakingAddress);

// Seed staking contract with reward reserves
await token.write.transfer([stakingAddress, cViem.parseEther("5000")]);

// Investor buys 1000 MET via ICO
const tokenAsInvestor = await viem.getContractAt("MyToken", tokenAddress, { client: { wallet: investor } });
await tokenAsInvestor.write.buyTokens({ value: cViem.parseEther("1") });

// approve + stake
const stakingAsInvestor = await viem.getContractAt("SimpleStaking", stakingAddress, { client: { wallet: investor } });
await tokenAsInvestor.write.approve([stakingAddress, cViem.parseEther("200")]);
await stakingAsInvestor.write.stake([cViem.parseEther("200")]);

// Verify staked amount
const [stakedAmount] = await staking.read.stakers([investor.account.address]);
console.log("Staked:", cViem.formatEther(stakedAmount)); // 200

// Time travel: advance 100 seconds
await network.provider.send("evm_increaseTime", [100]);
await network.provider.send("evm_mine");

// Claim rewards
await stakingAsInvestor.write.claimReward();

// Check final balance
const finalBalance = await token.read.balanceOf([investor.account.address]);
console.log("Final MET balance:", cViem.formatEther(finalBalance));
// 800 (unstaked) + rewards accrued over 100 seconds

The balance grows. The reward math lands. The Lazy Update pattern works.

What's Next

Day 6: ERC-721 NFT — non-fungible tokens, metadata, and what "ownership" means on-chain.

Repo: github.com/alena-dev-soft

Follow the journey on Telegram: t.me/dotnetToWeb3

Stage: Dinosaur 🦕 — going deeper into the bedrock. Day 5 of 7.

A .NET Dinosaur in Web3. Day 16 - ERC-20 Token & ICO

Olena — Fri, 29 May 2026 07:20:56 +0000

A .NET Dinosaur in Web3. Day 16 - ERC-20 Token & ICO

😈 Day 4 of 7: Building Own Currency… Cryptocurrency!

Day 4 it’s exactly give me some practice with build something cool and satisfied… and real. By the end of the session I had deployed my own cryptocurrency, run an ICO, transferred tokens between wallets and delegated spending rights between accounts.

I think I will back to this day of challenge when I will start build my token for WishList Chain project.

What Is ERC-20?

I little bit of theory:

ERC-20 is an interface standard. Any smart contract that implements it must expose a specific set of functions: transfer, approve, transferFrom, balanceOf, allowance, totalSupply. Any DEX, any wallet, any protocol knows how to interact with your token automatically — because they know the interface.

The .NET analogy is exact: it's a C# interface. The standard is the contract. The implementation is yours.

Instead of writing the entire standard from scratch, we inherit from OpenZeppelin's battle-tested implementation:

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract MyToken is ERC20 {
    // All standard ERC-20 logic inherited
    // We add our own ICO mechanics on top
}

Multiply. Multiply. Multiply. Then — and only then — divide.

Maths in Solidity really surprised me.

No floating point - ever.

It what we learned in previous challenge day. Just for remind…

Solidity has no float, no double, no decimal. If you divide 1 by 3, you get 0. Not 0.333 — zero.

Every token has a decimals parameter. ETH and standard ERC-20 tokens use 18. That means "1 token" is stored as:

1_000_000_000_000_000_000  // 10^18

The minimum unit is called wei — the equivalent of a penny, except there are 10^18 of them per token. All financial logic operates in wei. If you want to mint 2.5 tokens, you write 2500000000000000000.

The rule: always multiply before dividing. Dividing first truncates to zero before the multiplication can recover anything.

// Correct — multiply first
uint256 tokensToMint = (msg.value * 333) / 1000;

// Wrong — divide first, then multiply by a truncated zero
uint256 tokensToMint = (msg.value / 1000) * 333;

SafeMath is dead.

Pre-Solidity 0.8.0, every arithmetic operation required a library call: a.add(b) instead of a + b. This protected against overflow — when adding 1 to uint256 max wraps around to zero.

Since 0.8.0, the compiler checks automatically. Overflow reverts the transaction. The library is no longer needed and old tutorials that still use it are just showing their age.

approve — The OAuth2 of Web3

This was the most important concept of the day, because it's the foundation of DeFi.

approve(spender, amount) grants an external address (another contract, another wallet) the right to spend your tokens up to a limit. This is stored in the allowance mapping. The spender then calls transferFrom(owner, destination, amount) to act on that permission.

The .NET mental model: it's OAuth2 delegated access. The approve call is issuing a scoped token. The allowance mapping is the token store. transferFrom is the API call using that scoped token.

The tokens don't move during approve. The ledger only updates when transferFrom is called. The owner retains their balance the entire time — the contract just knows who is permitted to move it.

This same pattern is how staking contracts work: you approve the staking contract to spend your tokens, then the staking contract calls transferFrom to lock them.

The Approve Race Condition

There's a known vulnerability in the standard approve function worth understanding.

Scenario: you've approved a spender for 100 tokens. You change your mind and call approve(spender, 50). If the spender is watching the mempool, they can front-run your change — execute transferFrom for the original 100 before your reduction lands, then execute another transferFrom for 50 after it does. Result: they drained 150 instead of 50.

The fix: increaseAllowance and decreaseAllowance, which modify the limit atomically relative to the current value. OpenZeppelin provides both.

Testing in Console: Full Use Case

Before moving on, it's worth running the full token lifecycle manually in the Hardhat console. This is where the theory becomes tangible — you actually watch balances jump between mappings inside a deployed contract.

One important thing about viem in the Hardhat REPL.

The viem object returned by network.create() is not the full viem package — it's only Hardhat's internal helpers. So viem.parseEther() and viem.formatEther() don't exist on it. The fix:

const cViem = require("viem");
cViem.formatEther(balance);  // works
cViem.parseEther("500");     // works

Also: const declarations can't be redeclared in the same REPL session. If you get Identifier already declared, just use a different variable name.

Step 1 — Initialise clients and contract

const { viem } = await network.create();
const [owner, investor, friend] = await viem.getWalletClients();

const tokenAddress = "0x5FbDB2315678afecb367f032d93F642f64180aa3";
const token = await viem.getContractAt("MyToken", tokenAddress);
const cViem = require("viem");

Step 2 — Verify the pre-mint

const ownerBalance = await token.read.balanceOf([owner.account.address]);
console.log("Owner balance:", cViem.formatEther(ownerBalance)); // 50000

Step 3 — Investor buys tokens via ICO

const tokenAsInvestor = await viem.getContractAt("MyToken", tokenAddress, { client: { wallet: investor } });
await tokenAsInvestor.write.buyTokens([], { value: 2000000000000000000n });

const investorBalance = await token.read.balanceOf([investor.account.address]);
console.log("Investor balance:", cViem.formatEther(investorBalance)); // 2000

2 ETH × 1000 rate = 2000 MET. The math lands exactly because both ETH and MET use 18 decimals — no scaling needed.

Step 4 — Peer-to-peer transfer

await tokenAsInvestor.write.transfer([friend.account.address, cViem.parseEther("500")]);

const remaining = await token.read.balanceOf([investor.account.address]);
const friendBalance = await token.read.balanceOf([friend.account.address]);

console.log("Investor remaining:", cViem.formatEther(remaining)); // 1500
console.log("Friend balance:", cViem.formatEther(friendBalance)); // 500

Step 5 — Delegated spending: approve + transferFrom

This is the OAuth2 moment. Investor grants Friend a spending allowance:

await tokenAsInvestor.write.approve([friend.account.address, cViem.parseEther("300")]);

// Verify the allowance is recorded
const allowance = await token.read.allowance([investor.account.address, friend.account.address]);
console.log("Allowance:", cViem.formatEther(allowance)); // 300

Friend acts on that allowance — pulls 100 MET from Investor's balance:

const tokenAsFriend = await viem.getContractAt("MyToken", tokenAddress, { client: { wallet: friend } });
await tokenAsFriend.write.transferFrom([investor.account.address, friend.account.address, cViem.parseEther("100")]);

const finalAllowance = await token.read.allowance([investor.account.address, friend.account.address]);
const finalFriendBalance = await token.read.balanceOf([friend.account.address]);

console.log("Remaining allowance:", cViem.formatEther(finalAllowance)); // 200
console.log("Friend final balance:", cViem.formatEther(finalFriendBalance)); // 600

Final state:

Owner: 50,000 MET (pre-mint)
Investor: 1,500 MET (bought 2000, transferred 500)
Friend: 600 MET (received 500 + pulled 100 via transferFrom)
Remaining allowance: 200 MET

All ledger arithmetic balanced. The approve + transferFrom pattern is exactly how staking contracts work — the staking contract gets approved, then calls transferFrom to lock your tokens. Day 5 will use this exact flow.

What's Next

Day 5: Staking — locking tokens in a contract to earn rewards over time. The approve + transferFrom pattern from today is exactly what makes it work.

GitHub: github.com/alena-dev-soft

Follow the journey on Telegram: t.me/dotnetToWeb3

Stage: Dinosaur 🦕 — going deeper into the bedrock. Day 4 of 7.

A .NET Dinosaur in Web3. Day 15 - DAO Voting

Olena — Thu, 28 May 2026 12:00:00 +0000

🗳️ Challenge Day 3 of 7: Arrays, Mappings, and the Gas Limit Trap

Day 3 was about storage design — when every action with data has a real cost.

I think what helped me here is that I have some background from high school in low-level programming. A long time ago I learned how to write code for microcontrollers — my first programming language was Assembly, then BASCOM, C, and C++.

Life Without LINQ: The Cost of Loops in Solidity

In the .NET world we have many options for managing collections. In Solidity we have just a couple of mechanisms to work with them, and all of them must be implemented very carefully.

In Solidity we have mapping — looks similar to Dictionary<K,V> — but behaves completely differently.

A Solidity mapping has no .Count. No .Keys. No .Values. You cannot iterate it with foreach. It's a virtual hash table where every possible key in the universe pre-exists and defaults to zero. The EVM computes keccak256(key) and points directly to a 32-byte storage slot. That's it.

There is no collection. There is no enumeration. There is just a key and a slot.

Is Solidity More Limited Than C++?

Yes.

Coming from C/C++, you had vectors, lists, maps, full iterator support, exceptions with catch hierarchies, floating point, recursion, full pointer control. Solidity has none of that — because of the execution model:

C++ / C#  →  CPU + RAM + OS  →  resources are cheap
Solidity   →  EVM  →  every operation = real money

When SLOAD (reading from storage) costs ~2,100 gas, the language can't afford conveniences that hide cost. Syntactic sugar that obscures what's expensive is dangerous.

⚠️ The most striking example: no floating point. All financial logic uses integers:

// "1.5 tokens" = 1_500_000_000_000_000_000
uint256 price = 1.5 ether; // compiler expands to 10^18

The reason is determinism. Every node in the network must produce byte-for-byte identical results. IEEE 754 floating point gives platform-dependent rounding — unacceptable for a consensus system.

Feature	C++ / C#	Solidity
Collection iteration	foreach, iterators	for by index only, if you track length yourself
Dynamic structures	vector, list, map	mapping (not iterable), array (dangerous in loops)
Exceptions	full try/catch hierarchy	revert / require — no hierarchy
Floating point	float, double	absent entirely
Recursion	free	stack depth limit = 1024, gas explodes
String type	full object	primitive — no `.length`, no `==` comparison

I also looked into Rust and what we have in the Solana network — and my next priority will be a deeper investigation of Solana.

These limitations are specific to the EVM. Rust is used for smart contracts on Solana and NEAR — and there the story is different. Those chains compile to WebAssembly (WASM), where Rust's zero-cost abstractions, ownership model, and low-level memory control are a natural fit. Writing a Solana program in Rust looks like systems programming — you work with raw account bytes directly. The expressive power is much greater, but the entry bar is significantly higher.

Solidity is a language designed for mathematically auditable contracts where:

convenience is sacrificed for predictability
syntactic sugar is sacrificed for cost transparency
flexibility is sacrificed for auditability

The Architectural Crime: Dynamic Arrays in Loops

Because mappings can't be iterated, junior developers often reach for dynamic arrays to track participants, then loop through them to compute results — and commit a crime:

// ❌ GAS LIMIT DoS VULNERABILITY
function countVotes(uint256 proposalId) external {
    for (uint256 i = 0; i < voters[proposalId].length; i++) {
        // some counting logic...
    }
}

In .NET, iterating 10,000 items is microseconds of CPU time. In the EVM, every iteration reads from storage — that's an SLOAD opcode, and it costs real gas. Write operations inside a loop are worse — SSTORE can cost 5,000 to 20,000+ gas per slot.

With 2,000 voters, calling countVotes() would exceed Ethereum's Block Gas Limit. The transaction becomes physically impossible to mine. The contract freezes permanently. Votes are locked forever. This is a Gas Limit DoS Attack — written into the contract at design time, not introduced later by an attacker.

Worth noting: the vulnerability doesn't require hitting the gas limit today. An unbounded loop that's safe with 100 voters becomes dangerous with 10,000. The state grows; the gas cost grows with it.

The Solution: O(1) Everything

The fix is architectural: track state at the moment it changes, not after the fact.

Instead of storing voters and counting later, increment counters at vote time. One voter votes → one counter increments. Loops — NEVER ❌

What Actually Clicked

storage vs memory — the correct mental model.

Proposal storage proposal = proposals[_proposalId] creates a reference to the actual storage slot. It doesn't copy the struct into transient memory — it points directly to where the data lives on-chain. When you write proposal.votesFor += 1, that change persists.

Proposal memory proposal = proposals[_proposalId] creates a copy. Changes to that copy disappear when the function returns. Nothing is written to the blockchain. The data is silently discarded.

The performance note is more subtle than "storage saves gas on writes." storage pointers are useful when you need to access the same slot multiple times in one function — they avoid redundant lookups. But writes to storage (SSTORE) are among the most expensive operations in the EVM. The storage keyword doesn't make writes cheaper; it makes them possible and avoids unnecessary copies when reading.

CEI applies here too.

The order inside vote() matters:

if (hasVoted[_proposalId][msg.sender]) revert AlreadyVoted(); // Check
hasVoted[_proposalId][msg.sender] = true;                      // Effect
proposal.votesFor += 1;                                        // Effect

State is updated before any counters change. Checks-Effects-Interactions, same principle as Day 2's withdraw().

Nested mappings for O(1) duplicate detection.

mapping(uint256 => mapping(address => bool)) public hasVoted — proposalId maps to a voter address maps to a boolean. Any double-vote check is a single storage lookup, regardless of how many proposals or voters exist.

The Sybil Attack Problem

One voter, one vote sounds fair. In practice, it's fragile.

An attacker generates 1,000 wallets, funds each with a tiny amount for gas, and votes 1,000 times. The contract can't distinguish them from 1,000 real participants.

This is the Sybil Attack — the same identity problem that came up earlier in this series when building the voting contract from scratch. I covered it in detail in Day 3 of the original series. The problem is unsolved at the protocol level. Most production solutions still route back to Web2 identity providers.

The architectural response in real DAOs is token-weighted voting: instead of votesFor += 1, use votesFor += tokenContract.balanceOf(msg.sender). Controlling 1,000 empty wallets doesn't help if voting power requires holding tokens.

block.timestamp — The Honest Picture

The contract uses block.timestamp to enforce voting deadlines. The honest picture after PoS is more nuanced than the usual "validators can manipulate timestamps" warning.

After The Merge, Ethereum time is divided into strict 12-second slots. Each validator is assigned a slot and is expected to produce a block at that slot's designated time. They cannot arbitrarily drift the timestamp by seconds — the timestamp must be greater than the parent block's timestamp and consistent with the slot timing. The "15-second manipulation window" that existed under Proof-of-Work no longer applies.

The realistic manipulation vector in PoS is a validator skipping a slot — which shifts the timestamp by 12 seconds. For DAO voting periods that run for days or weeks, this is completely irrelevant. A 12-second drift doesn't change the outcome of a vote that closes in 7 days.

Timestamp manipulation becomes a real concern only for hyper-sensitive financial logic — MEV opportunities, flash loans, contracts where a single block matters. For governance and voting, block.timestamp is the correct and standard approach.

The advice to use block.number instead is outdated. In PoS, skipped slots mean block numbers don't map reliably to real-world time — gaps accumulate over long periods. block.timestamp is more accurate.

Testing The Contract

After a clean deploy, the full happy path in the console:

npx hardhat console --network localhost

const { viem } = await network.create();
const [deployer, voter1, voter2] = await viem.getWalletClients();

// Connect to the contract
const daoAddress = "0x5FbDB2315678afecb367f032d93F642f64180aa3";
const dao = await viem.getContractAt("SimpleVotingDAO", daoAddress);

// 1. Create a proposal - duration: 24 hours 86400 sec
await dao.write.createProposal(["Should we officially declare 2026 the year of Hardhat 3?", 86400n]);

// 2. switch the account and vote
const daoAsVoter1 = await viem.getContractAt("SimpleVotingDAO", daoAddress, { client: { wallet: voter1 } });
await daoAsVoter1.write.vote([0n, true]);

// 3. checking the poposal state of index 0
await dao.read.proposals([0n]);

Testing Time-Dependent Logic

Testing deadline enforcement requires moving the blockchain clock forward. Hardhat's local network supports this:

// In Hardhat 3, networkHelpers.time.increase() shifts the local chain forward
await context.networkHelpers.time.increase(65); // advance 65 seconds

This is the blockchain equivalent of mocking DateTime.UtcNow via ITimeProvider in .NET — same problem, different mechanism. The underlying local node (npx hardhat node) exposes evm_increaseTime and evm_mine RPC commands. Hardhat wraps them in a clean API.

What's Next

Day 4: ERC-20 Token — the standard interface that powers most of DeFi, and what implementing a standard looks like in Solidity.

GitHub: github.com/alena-dev-soft

Follow the journey on Telegram: t.me/dotnetToWeb3

Stage: Dinosaur 🦕 — going deeper into the bedrock. Day 3 of 7.

A .NET Dinosaur in Web3. Day 14 — Pull Pattern vs Dangerous Push Payments

Olena — Wed, 27 May 2026 12:00:00 +0000

🧐 Challenge Day 2 of 7: Why Push Payments Will Ruin Your dApp (Pull-over-Push & Escrow)

Today's learning topic left me confused — in the best possible way. It was hard, but interesting and genuinely challenging, because it starts to touch real risks and real money. The main question of the day: how do you get funds out of a contract safely?

The answer is less obvious than it looks.

The Problem

In smart contracts, automatically distributing ETH to external addresses within core state-changing functions is called the Push Pattern. In reality, it's a dangerous architectural flaw.

If a contract attempts to push funds to an external address and that address fails to accept the transfer, the entire transaction reverts. In a naive implementation, a single failed transfer blocks the administrative function — causing a Denial of Service (DoS) condition and permanently locking everyone's assets inside the contract.

// ❌ BAD — Push Pattern
function release() external onlyArbiter {
    (bool success, ) = seller.call{value: balance}("");
    require(success, "Transfer failed");
    // If seller's contract reverts, this entire function is blocked forever
}

The Contract: SimpleEscrow

Three participants: a buyer, a seller, and an arbiter. The buyer deposits ETH. The arbiter either releases funds to the seller or refunds the buyer. Nobody pushes anything — the seller and buyer pull their own funds when they're ready.

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

contract SimpleEscrow {
    error OnlyArbiter();
    error InvalidState();
    error TransferFailed();
    error NothingToWithdraw();

    enum State { AwaitingPayment, AwaitingDelivery, Completed, Refunded }

    address public immutable buyer;
    address public immutable seller;
    address public immutable arbiter;

    uint256 public immutable amount;
    State public currentState;

    mapping(address => uint256) public balanceOf;

    event Deposited(address indexed buyer, uint256 amount);
    event Released();
    event RefundedToBuyer();
    event Withdrawn(address indexed payee, uint256 amount);

    modifier onlyArbiter() {
        if (msg.sender != arbiter) revert OnlyArbiter();
        _;
    }

    constructor(address _seller, address _arbiter, uint256 _amount) {
        buyer = msg.sender;
        seller = _seller;
        arbiter = _arbiter;
        amount = _amount;
        currentState = State.AwaitingPayment;
    }

    function deposit() external payable {
        if (msg.sender != buyer) revert InvalidState();
        if (currentState != State.AwaitingPayment) revert InvalidState();
        if (msg.value != amount) revert InvalidState();
        currentState = State.AwaitingDelivery;
        emit Deposited(buyer, msg.value);
    }

    function release() external onlyArbiter {
        if (currentState != State.AwaitingDelivery) revert InvalidState();
        currentState = State.Completed;
        balanceOf[seller] += amount;
        emit Released();
    }

    function refund() external onlyArbiter {
        if (currentState != State.AwaitingDelivery) revert InvalidState();
        currentState = State.Refunded;
        balanceOf[buyer] += amount;
        emit RefundedToBuyer();
    }

    function withdraw() external {
        // 1. Checks
        uint256 payment = balanceOf[msg.sender];
        if (payment == 0) revert NothingToWithdraw();

        // 2. Effects — zero out BEFORE sending
        balanceOf[msg.sender] = 0;

        // 3. Interactions — low-level call, no gas limit
        (bool success, ) = msg.sender.call{value: payment}("");
        if (!success) revert TransferFailed();

        emit Withdrawn(msg.sender, payment);
    }
}

Pull-over-Push: The Bulkhead Pattern

Coming from an enterprise .NET background, the natural instinct is to reach for fault tolerance patterns. But there's an important distinction to make here.

Circuit Breaker (via Polly in .NET) stops all traffic to a failing downstream service globally. If the payment gateway breaks, the Circuit Breaker opens — no requests go through for anyone until it recovers.

Bulkhead is different. It isolates resources so a failure in one compartment doesn't sink the ship. Inspired by watertight compartments in a ship's hull: if one section floods, the bulkhead contains it. The rest of the ship stays dry.

Pull-over-Push is a Bulkhead implementation:

release() and refund() only modify internal state — balanceOf[user]. This is a guaranteed EVM storage operation. Nothing external, nothing that can fail.
The actual ETH movement is deferred to withdraw(), executed independently by the payee.
If a recipient's contract is broken, the failure is strictly contained within their transaction. Other participants and core contract logic are completely unaffected.

Why `.transfer()` Is Dead

Tutorials recommend payee.transfer(amount) because it limits forwarded gas to 2,300 units, theoretically preventing reentrancy. But this is wrong — and the Istanbul hardfork of 2019 shows the concrete reason why.

Ethereum core developers increased the gas cost of the SLOAD opcode (storage reads). Overnight, thousands of production contracts using .transfer() broke — because honest recipient contracts suddenly needed more than 2,300 gas.

Gnosis Safe is the canonical example. It's a multi-signature corporate wallet where transactions require approval from multiple signers. When receiving ETH, it runs internal verification checks — storage reads. After Istanbul, those checks cost more than 2,300 gas. Every .transfer() to a Gnosis Safe wallet started failing with Out of Gas.

The bad idea was the hardcoded gas limit. Tying runtime gas expectations into deployed bytecode violates loose coupling. The EVM evolves; contracts with hardcoded gas assumptions become bricks.

The correct approach:

(bool success, ) = target.call{value: amount}("");
if (!success) revert TransferFailed();

.call forwards all remaining gas. The EVM can change opcode pricing; the contract adapts.

One critical note: .call does not revert on failure — it returns a boolean. The if (!success) revert check is mandatory. Omitting it means the Effects step has already zeroed the balance with no automatic rollback.

Checks-Effects-Interactions (CEI)

The withdraw() function enforces CEI strictly to prevent reentrancy:

Checks — validate that the caller has a positive balance
Effects — zero out storage state before initiating the transfer
Interactions — trigger the external call

A natural question: if we zero out the balance first and then .call fails, does the user lose their money?

No — and this is where EVM atomicity comes in. The blockchain equivalent of ACID database transactions: if any part of a transaction reverts, all state changes within that transaction are rolled back. The zeroed balance reverts to its previous value.

But this only applies if the failure actually causes a revert. Since .call returns a boolean instead of reverting, you must check it and revert manually. Without if (!success) revert TransferFailed(), the balance stays zeroed and the ETH never moves. CEI without the explicit failure check is broken.

Testing the Contract

⚠️ Do not make the same mistake I did.

When testing this contract on a local node, my first attempts kept failing. The cause: I had been running the local node continuously, and after redeploying — with different parameters during experimentation — Ignition was using cached state from a previous run. The contract on-chain had amount set to something different from what the console session expected.

The fix: reset everything.

# Stop the running node (Ctrl+C), then restart it fresh
npx hardhat node

# Deploy with --reset to force Ignition to ignore its journal
npx hardhat ignition deploy ignition/modules/SimpleEscrow.ts --network localhost --reset

After a clean deploy, the full happy path in the console:

npx hardhat console --network localhost

const { viem } = await network.create();
const [buyer, seller, arbiter] = await viem.getWalletClients();

const escrowAddress = "0x5FbDB2315678afecb367f032d93F642f64180aa3";
const escrow = await viem.getContractAt("SimpleEscrow", escrowAddress);

// Buyer deposits exactly 1 ETH
await escrow.write.deposit([], { value: 1000000000000000000n });

// State should be 1 (AwaitingDelivery)
await escrow.read.currentState();

// Arbiter releases funds — only updates balanceOf, no ETH moves yet
const escrowAsArbiter = await viem.getContractAt("SimpleEscrow", escrowAddress, { client: { wallet: arbiter } });
await escrowAsArbiter.write.release();

// Seller pulls their funds
const escrowAsSeller = await viem.getContractAt("SimpleEscrow", escrowAddress, { client: { wallet: seller } });
await escrowAsSeller.write.withdraw();

// Seller's balance inside the contract should now be 0n
await escrow.read.balanceOf([seller.account.address]);

The sequence maps exactly to the Pull-over-Push design: release() only changes numbers in a mapping, withdraw() is where ETH actually moves — initiated by the seller, on their own terms.

What's Next

Day 3: DAO Voting — dynamic arrays, struct mappings, and on-chain governance logic.

Repo: Day 2 of 7: Escrow contract

Follow the journey on Telegram: t.me/dotnetToWeb3

Stage: Dinosaur 🦕 — going deeper into the bedrock. Day 2 of 7.

A .NET Dinosaur in Web3. Day 13 — Access Control

Olena — Tue, 26 May 2026 13:00:00 +0000

🆕 New Challenge. Day 1 of 7: Access Control & Vault Management

After building two MVPs around smart contracts, I wanted to go deeper into the contracts themselves. Not just use them — understand them.

🙈 7 days.
😉 7 contracts.
💪 7 articles.

The Problem

By default, every function in a deployed smart contract is public. Anyone on the network can call anything. If you leave administrative functions — like changing rates, withdrawing funds, pausing the contract — without protection, anyone can call them. It's how real exploits happen.

The Contract: AccessControlledVault

The concept is straightforward: one address is the owner, set at deployment. Certain functions are restricted to that address only. Final version of this contract:

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

contract AccessControlledVault {
    // Owner address
    address public owner;

    // Rate variable
    uint256 public conversionRate;

    // Custom error for gas optimization
    error NotAnOwner();

    // Event emitted when the rate changes
    event RateChanged(uint256 newRate);

    event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);

    // Constructor — sets the deployer as the owner
    constructor() {
        owner = msg.sender;
    }

    // Modifier using custom error instead of require
    modifier onlyOwner() {
        if (msg.sender != owner) {
            revert NotAnOwner();
        }
        _;
    }

    // Apply the modifier and emit the event
    function setRate(uint256 _newRate) public onlyOwner {
        conversionRate = _newRate;
        emit RateChanged(_newRate);
    }

    function renounceOwnership() external onlyOwner {
        emit OwnershipTransferred(owner, address(0));
        owner = address(0);
    }
}

What Actually Clicked

Some things I'd learned before, but some I'd missed or hadn't gone deeper into. Some are just reminders, some were genuinely new.

Already knew — nothing new:

constructor runs exactly once at deployment. msg.sender at that moment is the deployer's address. Capture it then and it's stored permanently on-chain. There's no other moment to do this cleanly.

The .NET analogy: a static initialiser that runs before anything else, with access to who triggered the class load.

New things:

modifier is a reusable wrapper. Without modifiers, every protected function needs its own require or if check. With a modifier, the check is defined once and applied by name. onlyOwner reads like a type annotation on the function — the intent is immediately visible.

The _; placement matters. The underscore marks where the function body executes relative to the modifier's checks. Put _; before the check, and the function runs first — the check happens after. In a function that transfers funds, this is a critical security vulnerability: the money moves before the authorisation check fires.

Custom errors vs require strings. revert NotAnOwner() costs less gas than require(msg.sender == owner, "Not an owner"). The string in require gets stored and returned on every failed call. A custom error is just a 4-byte selector. At scale, the difference adds up.

Modifiers

In .NET there's no direct analogy to Solidity modifiers, but there are a couple of things that can help a .NET developer understand the concept:

[Authorize] — a decorator that restricts access. And Middleware — you can inject custom access restriction logic at any point in the runtime pipeline. _; and await _next(context) are conceptually the same thing: pass control to what comes next. That's where the similarity ends.

A Solidity modifier is the logic. It wraps the function, controls entry, can control exit. It's active behaviour, not a passive label.

Solidity modifiers are compile-time macros. The compiler takes the modifier code and physically inlines it into every function that uses it, replacing _; with the function body. There is no runtime pipeline. There is no shared instance. Just flat bytecode.

This has a practical consequence: EIP-170. Ethereum limits deployed contract bytecode to 24,576 bytes. If your modifier contains complex logic and you apply it to 15 functions, that logic is duplicated 15 times in the bytecode. Contracts can fail to deploy because they're too large.

The fix: extract heavy logic into an internal function. The modifier then inlines only a function call — a single jump instruction — not the full check:

function _validateAccess() internal view {
    require(msg.sender == owner, "Not owner");
    require(isActive, "Not active");
}

modifier onlyOwner() {
    _validateAccess(); // only the jump is inlined
    _;
}

So: middleware is the right mental model for what modifiers do. But the how is nothing like middleware — it's a compiler feature.

Local Node — No Testnet Needed

When I first started with Web3, my testing environment was... my MetaMask wallet, hunting for Sepolia ETH from faucets, and struggling with Remix IDE. Alchemy was part of the setup too.

Turns out Hardhat has a built-in local node:

npx hardhat node

This spins up a local blockchain with 20 test accounts, each pre-funded with 1,000 ETH. No faucets, no limits — very useful. The network exists only while the process runs.

To deploy inside the local network:

npx hardhat ignition deploy ignition/modules/AccessControlledVault.ts --network localhost

Then the Hardhat console lets you interact with the live contract directly:

npx hardhat console --network localhost

const { viem } = await network.create();
const vault = await viem.getContractAt("AccessControlledVault", "0x5FbDB...");

// Read owner
await vault.read.owner();

// Change rate as owner
await vault.write.setRate([420n]);
await vault.read.conversionRate(); // → 420n

// Try as non-owner — should revert
const [owner, addr1] = await viem.getWalletClients();
const vaultAsAddr1 = await viem.getContractAt("AccessControlledVault", "0x5FbDB...", { client: { wallet: addr1 } });
await vaultAsAddr1.write.setRate([999n]); // → ContractFunctionExecutionError: NotAnOwner

The revert fires. The custom error name appears in the output. Access control works.

One More Thing: renounceOwnership

After writing the contract, an architectural question came up: what happens to the owner role at the end of the contract's life? Can ownership be revoked permanently?

It can. And in production Web3, it often should be.

In .NET systems, there's always a super-admin — someone who can access the database directly in an emergency. In Web3, that kind of absolute power is a red flag for users and investors. If the contract manages significant funds and the owner holds a setRate or withdraw function, two risks exist: the private key gets stolen, or the developers pull the funds themselves.

The solution: renounceOwnership(). When the project is live and all settings are locked, the owner calls this function. It permanently overwrites the owner variable with the zero address — address(0). No one controls the contract after that. Not even its creator.

/**
 * @notice Leaves the contract without owner.
 * @dev It will not be possible to call `onlyOwner` functions anymore.
 * Can only be called by the current owner.
 */
function renounceOwnership() external onlyOwner {
    emit OwnershipTransferred(owner, address(0));
    owner = address(0);
}

The event is important — analytics services like Etherscan use it to display that the contract has no owner.

What's Next

Day 2: Escrow & Pull-over-Push Pattern.

Repo: github.com/alena-dev-soft

Follow the journey on Telegram: t.me/dotnetToWeb3

Stage: Dinosaur 🦕 — going deeper into the bedrock. Day 1 of 7.

A .NET Dinosaur in Web3. Day 11-12. Two projects, One Stack and What’s Next

Olena — Mon, 25 May 2026 13:00:00 +0000

A .NET Dinosaur in Web3 — Days 11–12: Two Projects, One Stack, and What's Next

While building WishList Chain, I decided to dive deeper into transaction flows within decentralised trading systems and build something completely different. Initially, I wasn't sure about making this second project public, as building a commercial product wasn't my goal. However, I eventually decided to share it because it turned out to be a very good example of how vastly different development paths can be hidden behind the magical umbrella term "Web3."

Another Direction

While WishList Chain is a fun, game-like project focused heavily on on-chain interactions — contracts, goals, and donations — the second project approaches the space from a completely different angle. It is far more practical, real-time, and closely tied to trading and finance. The "serious stuff."

The core idea is straightforward: you follow a specific wallet, and the moment it makes a move, you get notified. Right now it can track any wallet, but the long-term vision is to track "smart money" wallets and understand patterns behind their moves, get real-time alerts on potential issues, or gain insights into why someone made a specific move.

Smart Money Tracker AI

The MVP is intentionally simple. Since this is uncharted territory for me, I focused purely on the foundational flow.

A Telegram bot monitors Ethereum wallets and fires alerts on new transactions. Instead of serving raw, cryptic data, every transaction passes through an AI layer that interprets what actually happened and why it matters.

🐋 Smart wallet activity

Wallet: 0xd8da...6045 (Ethereum)
Type: Swap · Value: ~$45,200

🤖 AI Insight: This wallet rotated a large ETH position into stablecoins.
Combined with three similar moves this week, this looks like a risk-off
signal — possibly bracing for macro uncertainty.

⚠️ Risk: Medium
💡 Actionable info: If you're holding a sizable long ETH position,
this is worth watching closely.

The bot is live and completely free.

Web: smart-money-tracker-ai-web.vercel.app

Same Stack — Different System

Both projects leverage almost identical tech stacks: Next.js, Supabase, Alchemy, Telegram, and the Claude API. However, their architectural blueprints are very different.

Feature	WishList Chain	Smart Money Tracker
Core Mechanic	Users create goals and receive donations	System monitors wallets and fires alerts
Blockchain Role	Backend — reads and writes state	Data source — listens to events only
AI Role	Generates commentary on donations	Analyses transactions with risk context
Queue System	None needed	BullMQ on Upstash Redis
Trigger	User-initiated actions	On-chain events
Status	Testnet MVP	Live on Ethereum Mainnet

Shifting Perspectives

My biggest takeaway was realising that Web3 is far from a single, standardised tech stack. It's an expansive, often chaotic ecosystem where you can design fully on-chain systems, launch hybrid architectures, or treat the blockchain merely as an immutable data feed. Navigating these fluid standards felt like entering uncharted territory.

Yet, to my surprise, my .NET background proved highly transferable. The same engineering principles still apply — event-driven design, separation of concerns, modularity. The syntax required an evolution. The core architectural patterns did not.

Current State

Both projects are functional MVPs, but still quite raw.

WishList Chain — on-chain goals, donations, DreamPower mechanics. What's next: donation history, analytical dashboards, refined DreamPower logic.

Smart Money Tracker — real-time wallet tracking, AI commentary, Telegram alerts. What's next: multi-chain support (Base + Arbitrum + Solana), smart wallet discovery, weekly digest summaries.

I won't stop working on either — both deserve to grow. The plan is to ship new features for each project roughly twice a week.

Next Step — Back to Contracts

After building infrastructure around contracts, I want to go deeper into the smart contracts themselves. The next chapter: 7 days — 7 contracts — 7 articles.

Day 1 — Access Control (Ownable, Modifiers)
Day 2 — Escrow & Pull-over-Push Pattern
Day 3 — DAO Voting Systems
Day 4 — ERC-20 Token Implementation
Day 5 — Staking Mechanisms
Day 6 — ERC-721 NFT Basics
Day 7 — Reentrancy Protection & Security

All repositories are open source: github.com/alena-dev-soft

Follow the journey on Telegram: t.me/dotnetToWeb3

Stage: Dinosaur 🦕 — two systems live. Now going deeper into the bedrock.

A .NET Dinosaur in Web3. Day 9–10 — MVP of WishList Chain

Olena — Sat, 23 May 2026 18:00:00 +0000

"It's alive!!! It's alive!!!"

Days 9 and 10 were about infrastructure — building the bridge between the smart contract and the real world. Supabase, Drizzle, Claude API, a Telegram bot, and a Vercel deploy are classic Web2 tools. But the magic ingredient was Alchemy webhooks — the definitive Web3 piece that connected the blockchain straight into my traditional stack. All of it was new to me.

And honestly… that was the most interesting part.

What Got Built

The full pipeline:

Donation → Sepolia → Alchemy webhook →
Next.js API → Claude AI → Supabase →
Telegram Bot → notification to owner

Live at wish-list-chain.vercel.app

The app is running on Sepolia (testnet). To try it, make sure your wallet is connected to Sepolia and use test ETH only.

How to set up Sepolia correctly and get test funds: github.com/alena-dev-soft/wish-list-chain/blob/main/GETTING_STARTED.md

Supabase + Drizzle

I've worked with .NET EF (Core and Framework) for years. Drizzle is the closest thing to it in the TypeScript ecosystem — and I got familiar with it much faster than I expected.

The schema is just TypeScript:

export const donations = pgTable('donations', {
  id: uuid('id').defaultRandom().primaryKey(),
  goalId: uuid('goal_id').references(() => goals.id).notNull(),
  donorAddress: text('donor_address').notNull(),
  amount: numeric('amount').notNull(),
  txHash: text('tx_hash').notNull().unique(),
  aiComment: text('ai_comment'),
  createdAt: timestamp('created_at').defaultNow().notNull(),
});

Then npx drizzle-kit generate produces a SQL migration file. npx drizzle-kit migrate runs it against the database. That's it. Very simple.

The .NET analogy is exact: dotnet ef migrations add followed by dotnet ef database update. Same mental model, different syntax.

Supabase also has a Schema Visualizer that automatically draws relationships between tables after migration. Small thing — but satisfying.

Alchemy Webhooks — The Blockchain Calls You

This was the conceptual shift of the sprint.

Instead of polling for changes — asking "did something happen?" on a schedule — the system becomes event-driven. With Alchemy webhooks, the blockchain effectively calls you.

Every time a DreamPowerIncreased event fires on the contract, Alchemy sends a POST request to our API route with the raw log data. We decode it with viem's decodeEventLog, extract the donor address, goal index, and amount, and write it to Supabase.

The GraphQL filter in Alchemy is precise — we only listen for logs from our specific contract address. Everything else on Sepolia is ignored.

Testing locally required ngrok. This is a pattern that comes up in any webhook development — your localhost is not publicly accessible. ngrok solves it by giving you a public HTTPS URL that forwards to your local port. One command, done.

One thing worth noting: if the webhook fires and the handler throws an error, the transaction still happened. The ETH moved. The event was emitted. The blockchain doesn't care that your API crashed. Your handler needs to be idempotent — onConflictDoNothing() on the donations insert handles duplicate deliveries.

Claude API — AI Comments on Donations

Each donation triggers a call to Claude with the goal name and amount. It returns a short encouraging comment, which gets saved and later included in the Telegram notification.

The integration itself is straightforward — one API call, structured prompt, short response. At this scale, cost is negligible (around $0.002 per comment), so it's not a concern for MVP.

Telegram Bot — grammY

The bot is intentionally minimal — just outbound notifications for now. When a donation happens, it sends a message with the goal, amount, sender, and the AI-generated comment. grammY is clean and easy to work with.

Vercel — Not Just Hosting

I didn't have much experience with Vercel before this. Coming from an Azure background, I expected another cloud platform with configuration overhead.

It turned out to be much simpler. Connect a GitHub repo, set environment variables, deploy. Vercel detects Next.js automatically, builds it, and gives you a working URL. The whole process took just a few minutes.

One thing that came up during deployment:

Direct Postgres connections can behave unexpectedly in a serverless environment. It's not that they don't work — but they're not designed for short-lived execution. Each function invocation may try to establish a new connection, which doesn't always play well with how serverless functions scale. Using Supabase's transaction pooler solved the issue immediately.

This is less about Vercel specifically and more about the execution model. Instead of a long-running process managing connections, you have short-lived functions that start, execute, and stop. It's a small detail — but one that can be confusing if you approach it with a traditional backend mindset.

The Moment It All Connected

There's a point where things stop feeling like separate pieces and start behaving like a system.

For me, it was surprisingly simple.

Open the app. Connect MetaMask. Click "Donate". Confirm the transaction. Wait a bit.

And then — a Telegram notification arrives.

Just because everything is connected.

It's a strange feeling to see even a small project come alive in the cloud. You can open it, connect your wallet, send a donation to a goal — and it just works. The contract, the frontend, the notifications — all reacting to each other.

Right now everything is still pretty raw. Over the next few days I want to add:

a proper donations list
maybe some simple dashboards
and rethink how DreamPower actually grows as more donations come in

Because if the chain is supposed to reflect collective support, then the way this "power" is calculated should probably evolve as well.

What This Sprint Taught Me

The Web3 part of this project — the contract, wallet connection, on-chain reads and writes — was actually done a few days ago. What followed was everything around it. Infrastructure. Integrations. Small details that make the system usable.

And that's probably the most honest picture of what building a dApp looks like. The contract handles trust and transparency. Everything else — storage, notifications, AI, hosting — is still very much traditional engineering.

The .NET dinosaur is still needed. Just… in a slightly different ecosystem.

Repo: github.com/alena-dev-soft/wish-list-chain

Follow the journey on Telegram: t.me/dotnetToWeb3

Stage: Dinosaur 🦕 — MVP shipped. Testnet live. The system works.

A .NET Dinosaur in Web3. Day 8 — Reading & Writing — WishList Chain

Olena — Thu, 21 May 2026 16:30:00 +0000

Long time no see.

The dinosaur was a bit busy finishing a module on .NET Windows Forms. To be honest, it's not my favourite stack — I'm much more into web development — but it's part of the job.

Now that I'm done with those tasks, I can finally get back to my favourite projects and the whole learn-in-public vibe.

Intro

Day 8 of trying to get into Web3 turned out to be an amazing experience.

It didn't feel like just another step where you "add a feature and move on." It felt more like a point where the system actually starts behaving like a system.

From Reading to Writing

Reading from the blockchain feels almost like calling a regular API. You ask for data, you get data, you render it.

Writing introduces a completely different flow.

Now there's a wallet involved. The user has to confirm the action. The transaction is sent to the network, included in a block, and only then reflected in the UI — and you don't control that timeline anymore.

At that point it became obvious that building a UI for Web3 is not just about displaying data. It's about handling uncertainty, delays, and state that lives somewhere outside of your application.

Weird Environment Reality

It seems I might need a more modern laptop — my MacBook almost gave up because of Turbopack. I used it initially, but it was consuming far more resources than expected.

Nothing critical — I switched back to good old webpack.

But if you're working on an older machine, it's definitely something to be aware of.

Reality of Building UI

The UI is no longer just reactive — it becomes dependent on external events:

the user confirms the transaction (or not)
the network processes it
the block is mined
the state becomes available And only then can your UI reflect what actually happened.

This introduces a different kind of thinking. You're not just updating state — you're waiting for the system to converge.

Things That Actually Matter

There was a moment where the transaction clearly went through — MetaMask confirmed it — but the UI still showed "No goals yet."

The contract state had changed, but nothing triggered a refetch on the frontend. From the UI perspective, nothing happened.

And then there was the more serious one.

At some point I realised I was sending transactions to the wrong contract address.

Everything looked correct. MetaMask confirmed the transaction. No errors. No warnings.

And that's exactly the problem.

In Web3, if you send a transaction to the wrong address — it doesn't fail in a helpful way. It just… succeeds somewhere else.

There's no backend validation, no "wrong destination" error. The transaction goes through, and from the system's perspective — everything is fine.

But your funds are gone.

In my case it was just a test transaction — nothing critical — but it was a very clear reminder: double-check addresses. Every time.

The Moment

And then it all came together.

First goal created. First donation sent. DreamPower increased.

Balance changed. Progress updated. State reflected in the UI.

End-to-end:

MetaMask → smart contract → Sepolia → frontend

At that point it stopped feeling like a collection of separate parts and started feeling like a real system.

What Clicked

The biggest shift for me was understanding that in this setup, the blockchain is not just another service.

It is the backend.

There's no API layer translating requests. The frontend talks directly to the contract, and that removes an entire layer of abstraction I'm used to in .NET systems.

It also means that things like latency, consistency, and state management behave differently — and you have to design with that in mind.

One More Question

At some point I also started thinking about limits.

How many users can this support? How many goals can a contract realistically store?

Technically — a lot. Practically — every write costs gas, and large reads eventually hit limits. It's not something that matters right now, but it's definitely something that will matter later.

Stage: Dinosaur 🦕 — first full interaction. Not just reading. Not just UI. A system that reads, writes, and reacts.

Repo: github.com/alena-dev-soft/wish-list-chain

Follow the journey on Telegram: t.me/dotnetToWeb3

A .NET Dinosaur in Web3. Day 7 — First connect

Olena — Sat, 16 May 2026 18:00:00 +0000

Intro

This day is a bit different from the previous ones. Initially, the idea was simple — one contract per day. But Web3 is not just about contracts and blockchain. There are other layers — UI, integration, the way everything connects together. At some point it became obvious: it makes more sense to start structuring the project early, instead of treating each part in isolation. As a developer who is getting close to an architect level — and someone who enjoys microservice architecture — I got curious: how are these projects actually structured?

A contract is just one piece. A dApp is a system. I assume the same principles apply here — some form of clean architecture, separation of concerns, clear boundaries. And for something like WishList Chain, it felt important to start thinking about the structure from the beginning.

At that point, I started thinking not just about the contract itself, but about the structure of the whole project. Because Web3 is clearly not only about writing smart contracts. There is always a frontend, some kind of interaction layer, maybe scripts or bots, and potentially even a backend later on. All of these parts are connected, whether you plan for it or not.

So the question became less about "what to build next" and more about "how to structure it properly from the beginning."

That's where the idea of using a monorepo came in.

Why Monorepo?

I decided to approach this a bit differently. Usually, I create separate repositories by responsibility (the "S" in SOLID), but not this time.

Here the picture is clearer. The contract and the frontend are tightly connected. Any change in the contract — new fields, updated logic, even a different address — will require changes in multiple places. That means more manual work, more context switching, and more chances to break something.

Better to keep things as simple as possible.

So instead of splitting things too early, I decided to keep everything in one place. A single repository, but clearly separated layers inside it:

wish-list-chain/
├── apps/
│   └── web/       ← Next.js 15
├── contracts/     ← Hardhat
├── package.json
└── .env

From a structural point of view, it already feels closer to a real system rather than a set of experiments.

I know this goes a bit against how I usually structure things. Normally, I prefer to separate repositories by responsibility — the "S" in SOLID. It keeps boundaries clear and makes scaling easier later. But in this case, it felt like the separation would introduce more friction than value. The responsibilities are still separated — just not at the repository level.

Project Stack

Before the code — a quick map of what we're working with and why.

Tool	Role	.NET analogy
Next.js 15 (App Router)	Frontend framework	ASP.NET Core MVC
wagmi 2	React hooks for blockchain	SDK wrapper for Web3 calls
viem 2	Low-level Ethereum client	HttpClient for the blockchain
RainbowKit	Wallet connection UI	OAuth login button
@tanstack/react-query	Async state management	No direct equivalent
WalletConnect / Reown	Multi-wallet protocol	OAuth provider

Theory — A Little Bit

wagmi sits on top of viem. viem handles the low-level blockchain calls. wagmi provides React hooks like useAccount, useReadContract, useWriteContract. You can drop down to viem when you need more control, but most of the time wagmi is enough.

RainbowKit is just a UI layer on top of wagmi — the modal, the button, the wallet list. It doesn't do any blockchain work itself.

What Clicked

Next.js 15 App Router makes everything a Server Component by default. wagmi hooks rely on React state and browser APIs — they can't run on the server. Any component that calls useAccount, useReadContract, or renders <ConnectButton /> needs 'use client' at the top. Otherwise, the code looks correct — but simply doesn't work.

ConnectKit doesn't support React 19 yet.

I actually started with ConnectKit — clean UI, good docs, everything looked straightforward. It failed immediately. Peer dependency error: it requires React 17 or 18, while Next.js 15 already ships with React 19. So that path just… stopped there.

This is the current state of the Web3 frontend ecosystem: some libraries are ahead, some are behind. Check React version compatibility before installing anything.

Downgrading React didn't feel right. So I kept React 19 and aligned the rest of the stack around it — wagmi 2.x ended up being the stable choice.

RainbowKit requires wagmi 2. wagmi 3 is out but RainbowKit hasn't released a compatible version yet. Pinning wagmi to version 2 for now. This will resolve eventually — until then, mixing versions breaks the dependency tree.

The Result

<ConnectButton /> renders. Click it — RainbowKit modal opens with MetaMask, WalletConnect, and others. Connect MetaMask — wallet address and balance appear.

That's a Next.js 15 app reading live data from the Sepolia blockchain through a connected wallet. No backend. No API. The blockchain is the data source.

Next: read totalDreamPower directly from the WishlistV3 contract using useReadContract.

Repo: github.com/alena-dev-soft/wish-list-chain

Stage: Dinosaur 🦕 — frontend connected. Blockchain is the backend.

A .NET Dinosaur in Web3. Day 6 - Wishlist or… “Dream Coins True”?

Olena — Fri, 15 May 2026 15:07:18 +0000

There's something that happened between Day 5 and Day 6 during brainstorming about project ideas. Day 6 wasn't just a deploy session — it was the first day of building something real.

Intro

Brainstorming started as a strategy question — I needed a practice project. Something to learn the full modern Web3 stack and something I could build in public.

I already have another idea that I've started building, but until the MVP is ready — I decided to keep it under wraps.

The idea was simple: pick something "common", but complex enough to cover real technical ground.

Well… I'm a dreamer. So the wishlist idea just felt right.

I started thinking — is it possible to build something interesting around it? Maybe the idea isn't new. It doesn't really matter… I just like it.

Take a wishlist, let people make each other's dreams come true and… maybe build something on-chain around it.

The base Wishlist contract was already written. It was already there — a working smart contract with a React frontend deployed on Sepolia.

So why not just build something on top of it?

Multi-user goals, ETH donations for specific goals, a Telegram bot for notifications. A proper monorepo with contract, Supabase, Drizzle, Next.js, and more.

And then the idea shifted.

What if every donation increases the "strength" of something?

A global counter. An on-chain kind of energy. A number that grows every time someone believes in someone else's dream enough to send ETH.

The working name became WishList Chain (WSHL) — not a token, at least not yet. An on-chain power score. totalDreamPower in the contract. Every donation adds to it. Every goal has its own dream power.

(DreamCoin, the name I originally wanted, is apparently already taken — so I had to rethink pretty quickly.)

Is it a real product? Possibly. Is it a learning project? Definitely. Is the idea somewhat ridiculous? Yes, and that's exactly why it might work in crypto.

The project is at github.com/alena-dev-soft/wish-list-chain — open source.

Day 6 was about laying the foundation for all of it.

The Goal

Write the core contract for WishList Chain — version 3 of the original Wishlist.sol.

Multi-user goals, ETH donations, dreamPower accumulation per goal, totalDreamPower globally, and a DreamPowerIncreased event for future Alchemy webhooks. Deploy with Hardhat. Verify on Etherscan.

The Contract

WishlistV3 is a different architecture from V2. V2 was one owner, one wishlist. V3 is a shared contract where every wallet has its own goals.

The .NET analogy:

// V2
List<WishItem> wishes;

// V3
Dictionary<address, List<Goal>> goals;

In Solidity: mapping(address => Goal[]) public goals

struct Goal gained financial fields:

struct Goal {
    string name;
    uint256 targetAmount;
    uint256 currentAmount;
    uint256 dreamPower;
    bool isFulfilled;
    uint256 createdAt;
}

donate() is the core function. Two things worth noting:

It must be payable — without that modifier, Solidity won't accept ETH. The keyword is required, not optional.

Goal storage goal = goals[_owner][_goalIndex] — storage means you're working with the actual on-chain data, not a copy. Change it, and the state changes. Use memory instead, and you're editing a local copy that disappears after the function returns. This distinction doesn't exist in .NET — it's specific to the EVM execution model.

The event:

event DreamPowerIncreased(
    address indexed owner,
    uint256 indexed goalIndex,
    uint256 addedPower,
    uint256 newTotalPower
);

indexed parameters are searchable in logs. They become filter keys — Alchemy webhooks can listen for specific owners or goal indices without scanning every event. The non-indexed parameters are just data payload.

Hardhat

Moving from Remix to Hardhat is the next step in my Web3 journey. Remix is a great tool for exploration. Hardhat provides everything needed out of the box, including a proper build pipeline.

The setup that actually works with Hardhat 3 + viem:

npm install --save-dev hardhat@latest @nomicfoundation/hardhat-toolbox-viem@latest

I really like this part — deploy and verify in one command:

npx hardhat ignition deploy ignition/modules/WishlistV3.ts --network sepolia --verify

Fair warning: getting there involved the usual package dependency hell — wrong versions, renamed config keys, cached artifacts. Nothing mysterious, just the standard tax you pay any time you touch a stack that lives and dies by npm. Read the error codes, fix one thing at a time.

The Project

WishlistV3 is not just a learning exercise. It's the core contract for something that's being built. The donate() function, the DreamPowerIncreased event, the multi-user architecture — all of it is designed for a real use case that will be revealed when the MVP is ready.

Two-week sprint. This was the foundation.

Contract address: 0x90de4a1934d0B062423adAEeDEe37Bb6fD12D0Ca

Verified: sepolia.etherscan.io/address/0x90de4a1934d0B062423adAEeDEe37Bb6fD12D0Ca

Stage: Dinosaur 🦕 — dependency hell survived. Foundation is live.

DEV Community: Olena

A .NET Dinosaur in Web3. Day 19 - Upgradeable Contracts

🏁 Day 7 of 7: Proxy Patterns, EVM Assembly, and Hot-Swapping Logic in Production

The Problem: Immutability Is Not Always a Feature

The Proxy Pattern: Splitting State From Logic

The Critical Trap: Storage Slot Collisions

The Contracts

Console: Hot Upgrade in Action

7 Days. 7 Contracts. What Actually Happened.

What's Next

A .NET Dinosaur in Web3. Day 18 - Automated Market Maker

🏦 Day 6 of 7: Building a Mini Uniswap in 80 Lines of Solidity

Why an Order Book Doesn't Work on a Blockchain

x · y = k — The Formula That Broke Finance

The Contract: SimpleAMM

Where You Can Step on a Rake

Console Verification Flow

What This Day Actually Meant

What's Next

A .NET Dinosaur in Web3. Day 17 - Staking

Day 5 of 7: Lazy Updates, Time Travel, and Earning Rewards Without Loops

The Problem With Naive Staking

The Contract: SimpleStaking

What Actually Clicked

Testing: Time Travel in Hardhat

Console Use Case: Full Staking Cycle

What's Next

A .NET Dinosaur in Web3. Day 16 - ERC-20 Token & ICO

A .NET Dinosaur in Web3. Day 16 - ERC-20 Token & ICO

What Is ERC-20?

Multiply. Multiply. Multiply. Then — and only then — divide.

No floating point - ever.

SafeMath is dead.

approve — The OAuth2 of Web3

The Approve Race Condition

Testing in Console: Full Use Case

What's Next

A .NET Dinosaur in Web3. Day 15 - DAO Voting

Life Without LINQ: The Cost of Loops in Solidity

Is Solidity More Limited Than C++?

The Architectural Crime: Dynamic Arrays in Loops

The Solution: O(1) Everything

What Actually Clicked

The Sybil Attack Problem

block.timestamp — The Honest Picture

Testing The Contract

Testing Time-Dependent Logic

What's Next

A .NET Dinosaur in Web3. Day 14 — Pull Pattern vs Dangerous Push Payments

🧐 Challenge Day 2 of 7: Why Push Payments Will Ruin Your dApp (Pull-over-Push & Escrow)

The Problem

The Contract: SimpleEscrow

Pull-over-Push: The Bulkhead Pattern

Why .transfer() Is Dead

Checks-Effects-Interactions (CEI)

Testing the Contract

What's Next

A .NET Dinosaur in Web3. Day 13 — Access Control

The Problem

The Contract: AccessControlledVault

What Actually Clicked

Modifiers

Local Node — No Testnet Needed

One More Thing: renounceOwnership

What's Next

A .NET Dinosaur in Web3. Day 11-12. Two projects, One Stack and What’s Next

A .NET Dinosaur in Web3 — Days 11–12: Two Projects, One Stack, and What's Next

Another Direction

Smart Money Tracker AI

Same Stack — Different System

Shifting Perspectives

Current State

Next Step — Back to Contracts

A .NET Dinosaur in Web3. Day 9–10 — MVP of WishList Chain

What Got Built

Supabase + Drizzle

Alchemy Webhooks — The Blockchain Calls You

Claude API — AI Comments on Donations

Telegram Bot — grammY

Vercel — Not Just Hosting

Why `.transfer()` Is Dead