Forem: Alena

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

Alena — 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

Alena — 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

Alena — 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”?

Alena — 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.

Alena — 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

Alena — 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

Alena — 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

Alena — 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. 🚀

A .NET Dinosaur in Web3. Day 1 - First Smart Contract

Alena — Sun, 03 May 2026 09:37:47 +0000

I've been writing .NET for many years. Today I deployed my first smart contract.
Here's what actually happened.

I'd like to share my journey into Web3 — every single day.
Maybe it'll be helpful for someone out there.

I love what I do — really. I'm a .NET Dinosaur and Azure-passionate developer,
but let's be honest — the .NET niche isn't exactly overflowing with money 💵.
I've been meaning to try something new for a while. Something with a cool and
live market. Something different. So I chose Web3.

The Setup: I Built Myself an AI Mentor

Instead of drowning in YouTube tutorials and boring courses, I did something
a little different. Well — I have ADHD. And I know my brain. It needs dopamine
to stay focused (weird combo, ADHD person and software engineer — but for me,
coding is my dopamine). My brain needs a clear win every single day, not a
promise of understanding. So I configured Claude as my personal AI mentor:
one goal per day, theory only when it's actually needed, and an honest debrief
of where I got stuck.

Think of it as a personal trainer who never judges you for asking "stupid"
questions, and is available 24/7.

So — today was Day 1.

The Goal

Deploy your first smart contract to a test network and see its address
on the blockchain.

Simple, concrete — and I received detailed instructions, step by step.

What I Actually Did

Set up MetaMask. "Piece of cake" — really. I already had an account,
but I'd forgotten my keys (things happen). So I had to create a new one.
Switched to the Sepolia test network. A staging environment where
everything works exactly like the real Ethereum network — but you're not
using real money.
Got free test ETH. ETH is needed for "gas" — the fee you pay for
every piece of code the blockchain executes. It's free, but finding a working
faucet with an empty wallet took 3 attempts.
(I'm a beginner — I don't have funds for that yet 😅)
Wrote my first Solidity contract in Remix IDE. Solidity, by the way,
reads really easily — like other typed languages. For a .NET brain, it's
immediately familiar: classes, constructors, typed fields, public methods.
Deployed it. One click, one MetaMask confirmation, 30 seconds of
waiting — and pure happiness when I received a contract address.

Where I Got Stuck

MetaMask's UI has changed. Sometimes my AI mentor provided instructions
for the old version, so finding things took a little more time than expected.

Three faucets, one winner. Getting free test ETH required more tries
than expected:

Faucet	Result
sepoliafaucet.com	❌ Requires conditions I didn't meet
faucets.chain.link/sepolia	❌ Asks for LINK tokens
Google Web3 Faucet	✅ Worked immediately

Day 1 Score: 9/10

Easier than expected, honestly. The .NET background helps more than I thought —
typed languages, deployment concepts, staging vs production thinking. It all
maps over. I played with the code and the environment.

Solidity feels like home. A strange, decentralised, immutable home — but home.

Stage: Dinosaur 🦕 — mapping the terrain.

See you on Day 2. 🚀

Hello!

Alena — Sun, 03 May 2026 09:31:21 +0000

I'm a .NET dinosaur. And I'm done being one.

Senior .NET and Azure backend developer, also former Tech Lead. Years of enterprise systems, clean architecture, corporate backend at scale. It's a solid career. It's also, if I'm being honest - started to feel like the same hallway walked in circles.

So I'm changing direction. Slowly and deliberately.
Not because .NET is bad or I don't like it anymore. But the work got repetitive, the market got crowded, and somewhere along the way the technology stopped feeling like a frontier.
My new space is blockchain. The execution model is different. The trust model is different. The economics are different. And unlike most of my .NET career - the output is visible, verifiable, and lives on a public ledger forever.
So I'm learning Solidity from scratch. Publicly.

The series "A .NET Dinosaur in Web3" will contain real code, real mistakes, real "naive" thoughts, .NET analogies where they help - and honest notes on what it actually takes to make this switch.

I started writing on another platform - and will gradually move my "historic" articles here.

Stage: Dinosaur 🦕 - mapping the terrain.