DEV Community: Olena

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.

A .NET Dinosaur in Web3. Day 5 - First dApp.

Olena — Tue, 12 May 2026 07:24:31 +0000

⚠️ Honest disclaimer: Yes, this one is late. The dinosaur went travelling, then came back and started building something. Both count.

Day 5 was about wiring the WishList contract to a real frontend — React, TypeScript, ethers.js, MetaMask. But somewhere between the travel and the code, a project idea formed. Two-week sprint, MVP target. It stays under wraps for now — but the daily insights don't stop.

Today: the dApp. Soon: something real.

The Goal

Take the WishList contract from Day 4 and make it usable in the real world. (If someone feels like fulfilling one of my wishes — I'm not stopping you.)

Solidity: github.com/alena-dev-soft/solidity-learn/contracts/05day/
UI: github.com/alena-dev-soft/wishlist-dapp

What I Built

WishlistV2 — an upgraded contract plus a React dApp on top of it.

Contract additions:

createdAt: block.timestamp — creation timestamp. Like DateTime.UtcNow in C# but in Unix seconds, written permanently on-chain.
deleteWish(uint _index) — removes a wish. The trick: swap the target with the last element, then pop(). Cheaper than shifting the entire array. This breaks the original order — acceptable here, but something to be aware of.

The frontend stack: Vite + React + TypeScript + ethers.js.

What Actually Clicked

ABI is just an interface.

To call a smart contract from JavaScript, you need its ABI — the list of function signatures. The mental model for .NET developers:

ABI = interface IWishlist in C#

It describes what exists. Not how it works. The frontend doesn't need the implementation — just the signatures.

provider vs signer — the key distinction.

provider reads from the blockchain — no permissions needed, no gas. signer represents an account that can authorize transactions. If something changes state, it must be signed.

Blockchain is not a REST API.

In a normal React app — button click, data saves in 50ms, UI updates instantly. In Web3 — the transaction goes to network nodes, gets included in a block, block gets confirmed. On Sepolia that takes 10–15 seconds. await tx.wait() literally waits for the block. This is not a bug. This is the execution model.

isOwner flag — access control in the UI.

The contract enforces owner-only rules on-chain. But the UI should also reflect them — no point showing "Delete" to someone who can't delete. Solution: load owner() from the contract, compare with the connected wallet, set an isOwner flag. Owner sees all controls. Everyone else sees a read-only list.

A Few Things That Can Waste Your Time

TypeScript doesn't know about MetaMask out of the box. window.ethereum isn't part of the default typings. Quick fix: declare it as any. Good enough for now.

Vite creates a nested folder structure by default. If you run it inside an existing project directory, you end up one level too deep. Easy to miss, costs a few minutes.

Testnet latency is real. Sepolia blocks roughly every ~12 seconds. Even after tx.wait() resolves, the updated state might not be immediately visible. A small delay or refetch avoids reading stale data.

The Project

The days off weren't wasted. An idea formed — something that combines what I'm learning with a real use case. Two-week sprint, MVP target. The project stays under wraps for now, but the daily learning logs continue. The insights will keep coming. Just with a different backdrop.

Stage: Dinosaur 🦕 — first dApp live. Backend meets frontend. Something is forming.

A .NET Dinosaur in Web3. Day 4 - Writing My First Contract From Scratch

Olena — Sun, 03 May 2026 15:58:16 +0000

Three days of guided exercises. Today — no template, no "here's the complete code, just copy and paste." Just a brief: based on what you know — build your WishList contract.

The Task

A personal WishList where only the owner can fulfill a wish. Small enough to finish in one session. Not so small that the decisions made themselves.

Code: github.com/alena-dev-soft/solidity-learn/contracts/04day/

What Actually Clicked

The first thing I got tripped up on wasn't syntax — it was initialization. In .NET, almost everything needs to be explicitly initialized, especially array-related types. In Solidity:

WishItem[] public wishes;

That's it. The array exists, it's empty, push() works immediately. The EVM assigns default values at deployment — uint256 is 0, bool is false, address is the zero address.

Worth noting though: arrays in Solidity aren't free the way they are in .NET. Every push() is a state change with a gas cost. And "EVM handles defaults" is not the same as "no initialization needed" — that distinction matters once you're working with memory arrays, nested structs, or upgradeable contracts.

The next decision was identification. Every wish needs some kind of handle — otherwise how do you reference the one you want to fulfill? My instinct was to reach for something explicit, maybe even overcomplicate it. The options in Solidity are straightforward:

Array index — simplest, no overhead
Manual counter — more control, slightly more code
mapping(uint256 => WishItem) — keyed table, most flexible

Went with array index. fulfillWish(uint _index) takes the position. For a contract this size, there's no reason to reach for more than you need.

⚠️ Fair warning: array index works as an identifier only as long as the array is append-only and items are never removed or reordered.

On Validation — Index Safety

Nothing in Solidity protects you unless you do it explicitly. Using an array index as an identifier is clean and simple — but only if you validate it first.

Calling fulfillWish(uint _index) without a boundary check is asking for trouble. At minimum:

require(_index < wishes.length, "Invalid index");

Without this, you're relying on implicit behavior and risking unexpected reverts. In .NET you often get guardrails for free. In Solidity — you build them yourself, or they don't exist.

On Access Control — There Is No Default Security

The requirement was simple: only the owner can fulfill a wish. What clicked is that in Solidity this isn't a built-in rule — it's just code you have to write.

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

Without this line, anyone can call your function. Solidity doesn't assume intent. It executes what's written — nothing more, nothing less.

One Tooling Trap Worth Knowing

I use Edge, and I tend to keep tabs open for days. After a two-day gap — life happens — I came back to Remix with MetaMask still connected from before.

Here's the gotcha: switching to Sepolia in the top network dropdown isn't enough. The wallet panel at the bottom has its own network selector, and it needs to match. If they silently disagree, you get a gas estimation error with null revert data. Looks exactly like a contract bug. Isn't one.

Web3 tooling fails loudly and explains itself poorly. File that under "features, probably."

What's Next

Solidity alone is a backend with no front door. The next step is wiring this contract to something a human can actually use — ethers.js, React, TypeScript. The blockchain as a data layer, with a real interface on top.

That's Day 5.

Stage: Dinosaur 🦕 — first contract, no scaffolding.

A .NET Dinosaur in Web3. Day 3 - Voting, Sybil Attacks and Identity

Olena — Sun, 03 May 2026 09:51:21 +0000

Day 3 was the first day that felt like actual software engineering rather than syntax tourism. The task: write a voting contract. Simple enough on the surface - until you start poking at the security model and realize the whole thing has serious gaps in its logic.

What looked like a toy example turned out to be a good proxy for real system design problems.

The Contract

Instead of dumping a wall of code here, I moved the full contract and instructions to GitHub. This post is about what actually matters - how it works.

GitHub: github.com/alena-dev-soft/solidity-learn/contracts/03day/

What Actually Clicked

struct → record in C#
Not a class. No methods, no behavior - pure data container. Closer to record
in C# than anything else.

mapping(address => bool) → Dictionary<address, bool>
Exact mental model. The key is a wallet address, the value is whether they've
voted. Lookup is O(1), there's no iteration - same tradeoffs as Dictionary
in .NET.

view modifier → read-only, free to call
Methods marked view don't write to state, so they don't cost gas. The EVM
equivalent of a GET endpoint versus a POST. This clicked immediately because
the cost model maps directly to why you'd separate reads from writes in
any system.

require() → guard clauses + exception in one
require(condition, "message") is exactly if (!condition) throw new Exception("message") - except when it reverts, the entire transaction is reverted. No state is changed, but gas is still spent. Closer to a database transaction abort than a simple exception.

Key Insight

At some point I stopped and asked myself a simple question.

How does the contract know that "Alice" is actually Alice?

The answer was a little unsettling - because I've spent years designing systems where knowing who the user is was fundamental. Authentication, authorization, identity verification. That was always the baseline.

In Web3 there is no baseline like that.

The contract sees only an address. Just a string starting with 0x. No name, no history, no face. If the same person creates 10 wallets - congratulations, they now have 10 votes.

This is just how the system works.

And once that clicks, it quietly rewires how you think about everything else: access control, fairness, "one person = one vote." All the assumptions we carry from Web2 - where identity is tied to accounts, emails, phone numbers - simply don't apply here.

Ownership of a wallet is not identity. It's just… ownership of a wallet.

The fix exists, of course. Several of them, actually.

Whitelist - the owner manually approves addresses. Simple, but it requires trusting whoever manages the list. And it scales terribly.

NFT / Token gating - only wallets holding a specific token can participate. Think of it as a membership card. Still doesn't prove who the person is - just that they own the token.

Proof of Humanity - on-chain verification that a real human stands behind the address. Technically elegant. Still a largely unsolved problem at scale.

And then there's the quiet irony: most production solutions still route back to Web2 identity providers - Google, Binance, Microsoft and others. Web3 solved decentralized execution beautifully - identity remains outsourced to the old world.

So no, dinosaurs aren't extinct yet. Apparently we're still needed. 🦕 (like me 🙃)

Side Observations

Etherscan shows bytecode by default. The contract is there, but unreadable - same as looking at compiled IL instead of C# source. To expose the actual Solidity code, you need to verify the contract: upload the source, match the compiler version exactly. One wrong version number and it fails silently.

Remix doesn't persist deployed contracts across page reloads. After a refresh, the contract still exists on-chain - but Remix has no memory of it. Recovery is straightforward: find the contract address on Etherscan, use "At Address" in Remix to reattach. Good to know before it happens in a less forgiving context.

Testing multi-wallet scenarios requires either Remix VM or separate wallets with testnet ETH. Browser Extension mode only sees what MetaMask sees. Not a problem - just a constraint to know upfront.

Conclusion

Day 3 changed something in how I think about system design in Web3.

In Web2, identity is assumed. You build on top of it. In Web3, identity is your problem to solve - and every solution is either a tradeoff or a dependency on something outside the chain.

The contract works. The logic is sound. The gaps are in the model, not the code.

Stage: Dinosaur 🦕 - mapping the terrain. Starting to see where the edges are.

Day 4 incoming. 🚀

A .NET Dinosaur in Web3. Day 2 - Access Control

Olena — Sun, 03 May 2026 09:44:52 +0000

New day, new challenge...
Counter.sol - a little better than "Hello World", right?

The goal: write a simple Counter contract - increment, decrement, reset -
with real access rules.

The Contract

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

contract Counter {
    uint256 public count;
    address public owner;

    constructor() {
        owner = msg.sender;
        count = 0;
    }

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

    function decrement() public {
        require(count > 0, "Already zero");
        count -= 1;
    }

    function reset() public {
        require(msg.sender == owner, "Only owner can reset!");
        count = 0;
    }
}

GitHub: github.com/alena-dev-soft/solidity-learn/contracts/02day/

What Actually Clicked

In the .NET world we use HttpContext.User to know who's making a request. In Solidity it's msg.sender - the wallet address of whoever called the method. No login system, no JWT, no sessions. Just a cryptographically verified address. The contract knows exactly who you are. Always.

The next thing - calling count to check the current value is free.Simple rule: no transaction, no gas.

But there's a warning that almost everyone forgets - which makes it kind of dangerous for your budget. If you forget to switch from the real network to the test network, those transactions will cost you actual money. Every single one.

The .NET → Solidity Map (So Far)

Solidity	.NET equivalent
`msg.sender`	`HttpContext.User`
`require()`	Guard clause + exception
`uint256`	`uint` (unsigned)
`address`	No direct equivalent — wallet ID

Day 2 Score: 10/10

Everything is mapping cleanly to .NET concepts. The mental model is familiar, the syntax is new.

Tomorrow I want something with real-world application - not a toy example, but a contract that actually does something useful.

Stage: Dinosaur 🦕 - mapping the terrain.

Day 3 incoming. 🚀

DEV Community: Olena

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

The Moment It All Connected

What This Sprint Taught Me

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

Intro

From Reading to Writing

Weird Environment Reality

Reality of Building UI

Things That Actually Matter

The Moment

What Clicked

One More Question

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

Intro

Why Monorepo?

Project Stack

Theory — A Little Bit

What Clicked

The Result

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

Intro

The Goal

The Contract

Hardhat

The Project

A .NET Dinosaur in Web3. Day 5 - First dApp.

The Goal

What I Built

What Actually Clicked

A Few Things That Can Waste Your Time

The Project

A .NET Dinosaur in Web3. Day 4 - Writing My First Contract From Scratch

The Task

What Actually Clicked

On Validation — Index Safety

On Access Control — There Is No Default Security

One Tooling Trap Worth Knowing

Why `.transfer()` Is Dead