DEV Community: Ali Nasirlou

5 Solidity Mistakes I Made While Learning Smart Contract Development

Ali Nasirlou — Mon, 31 Aug 2026 18:09:30 +0000

5 Solidity Mistakes I Made While Learning Smart Contract Development

When I started learning Solidity, I thought smart contract development was mainly about learning syntax and writing functions.

I was wrong.

Solidity looks simple at first, but building secure contracts requires a completely different mindset.

Here are five mistakes I made while learning smart contract development.

1. Thinking "it works" means "it is correct"

One of my biggest mistakes was focusing only on functionality.

If a function executed successfully, I considered it done.

But smart contracts are not normal applications.

A small mistake can lead to:

Lost funds
Unauthorized access
Broken state
Unexpected behavior

Now, after writing a function, I don't only ask:

"Does this work?"

I ask:

"What happens if someone tries to abuse this?"

2. Ignoring access control

At first, access control seemed like a simple topic.

Something like:

require(msg.sender == owner);

But in real projects, authorization is much more important.

You need to carefully think about:

Who can call this function?
Who can change important variables?
Who can withdraw funds?
Who can update contract settings?

A missing access control check can completely compromise a contract.

3. Not thinking about state transitions

Smart contracts are basically state machines.

Every transaction changes the state.

For example:

Active Listing
|
↓
Purchased Listing
|
↓
Completed

A good contract should carefully control how states can change.

Questions I now ask:

Can this state be reached incorrectly?
Can a function be called twice?
What happens after failure?

4. Writing tests only for successful scenarios

When I started testing, I mostly tested:

"User does something correctly → Contract works"

But security testing requires another mindset.

You should also test:

Invalid inputs
Unauthorized users
Repeated calls
Edge cases
Unexpected behavior

The best tests are often the ones that try to break your contract.

5. Learning security after development

This was probably my biggest mindset change.

At first, I thought:

Build the contract
Finish the features
Check security

Now I think:

Design with security in mind
Build carefully
Test possible attack scenarios

Security is not a final step.

It is part of development.

Final Thoughts

Learning Solidity changed the way I think about programming.

A smart contract is not just code that runs on the blockchain.

It is code that manages value.

That means every decision matters.

The more I learn about Solidity and smart contract security, the more I realize:

Writing smart contracts is easy. Writing secure smart contracts is the real challenge.

I'm continuing my journey into smart contract development, security research, and auditing.

More lessons coming soon.

3 Things I Learned Building a Smart Contract Project with Foundry

Ali Nasirlou — Wed, 26 Aug 2026 11:19:35 +0000

When I started building my NFT marketplace in Solidity, my main goal was simple:

Make it work.

But as the project grew, I realized that writing Solidity code that works is only part of the job.

Here are three things I learned while building the project with Solidity, Foundry, and OpenZeppelin.

1. Working code doesn't mean secure code

A function can work perfectly and still be vulnerable.

For example, a marketplace purchase function may look simple:

function buy(uint256 listingId) external payable {
    Listing storage listing = listings[listingId];

    require(msg.value == listing.price);

    // Transfer NFT
    // Transfer payment
    // Update listing
}

But then you have to ask:

What if the listing was already purchased?
What if the seller no longer owns the NFT?
What if approval was revoked?
What happens during an external call?
Can the function be reentered?

This changed the way I approach smart contracts.

I don't just ask:

"Does this function work?"

I also ask:

"How could someone break it?"

2. Architecture becomes important very quickly

At the beginning, putting everything into one contract seems fine.

But an NFT marketplace can eventually include:

Listings
Purchases
Offers
Auctions
Rentals
Fees
Administration
Queries

Putting all of this into one huge contract quickly becomes difficult to maintain.

For my project, I started separating responsibilities into different components:

MarketCore.sol
MarketAdmin.sol
MarketValidation.sol
MarketEvents.sol
MarketErrors.sol
MarketQuery.sol
MarketplaceStorage.sol

The important lesson wasn't simply "use more contracts."

It was:

Give each part of the system a clear responsibility.

This makes the code easier to understand, test, and audit.

3. Testing shouldn't only prove that things work

With Foundry, it's easy to write tests for the happy path:

Create listing
↓
Buy NFT
↓
NFT transferred

But smart contract testing should go further.

I also want to know what happens when:

Wrong payment
Unauthorized caller
Invalid listing
Revoked approval
Already purchased NFT
Repeated calls
Failed external call

This is where testing starts becoming security research.

Instead of only testing:

"Can a user do this?"

I try to test:

"Can a malicious user make this behave differently than intended?"

Final Thoughts

Building this project taught me that smart contract development isn't just about writing Solidity.

It's about thinking about:

Architecture → State → Edge cases → Testing → Security

And the biggest lesson I've learned so far is:

A smart contract isn't good just because it works. You need to understand how it behaves when someone tries to break it.

I'm continuing to improve the project and dive deeper into smart contract security and auditing.

More experiments and lessons coming soon.