3 Things I Wish I Knew When I Started Writing Cairo Contracts

When I first started writing smart contracts with Cairo, it was still in its earliest form — what we now call Cairo 0.x.

It had a Python-inspired syntax, a sprinkle of cryptic low-level logic, and a whole lot of “what does this even mean?” moments. Then came Cairo 0.1, and just like that, the syntax shifted. Suddenly, it looked more like Rust than Python. And I won’t lie — I was tempted to walk away.

But I didn’t.
Because something about zero-knowledge proofs and StarkNet’s fast-growing infrastructure intrigued me too much to let go. Even though there were barely any tutorials at the time (nothing like what we have now), I kept digging, building, and learning.

Looking back, here are three things I wish someone had told me before I started writing Cairo contracts — especially if you’re stepping into this zk-powered world now.

1. Cairo is NOT Solidity — Don’t Force It

When I first jumped in, I thought, “I know Solidity. I’ve built dApps. How different could Cairo be?”

Yeah… no.
Cairo is a completely different beast.

Especially back then, in Cairo 0.x, there were no mappings, no msg.sender, and absolutely no EVM-style comfort zones. Even after the shift to Cairo 0.1, the learning curve only steepened — with stricter typing, manual control over memory and storage, and a whole new architecture to understand.

What I wish I knew is that Cairo isn’t trying to be Solidity — because it’s solving a completely different problem.

Cairo is built for provable computation. Every line you write is part of a trace that will be cryptographically verified. You’re not just coding logic — you’re coding proofs of correctness.

It forces you to think differently — and in hindsight, that’s a good thing.

2. Storage in Cairo Will Confuse You — Then It’ll Amaze You

One of the first things that tripped me up was storage.

Coming from Solidity, I was used to simple mappings like mapping(address => uint). But in Cairo? You write accessor functions using decorators like:

#[storage_read]
fn get_user_score(user: ContractAddress) -> u256 {
    // ...
}

At first, it felt like I had to build a house just to open a door.

But Cairo’s storage model is designed for zero-knowledge efficiency. It’s based on Merkle trees, where storage keys are hashed into paths. This structure makes it highly scalable and provable — but also more complex.

What I wish I knew early:

• You need to manually define storage access
• Composite keys are real — and they’ll haunt you (until you master them)
• Everything is deliberate, and that gives you power

Once you wrap your head around how storage works, you’ll start seeing just how intentional and elegant the system really is.

3. Testing Isn’t Optional — It’s Your Best Friend

At the beginning, I treated testing like a side quest.

I just wanted to deploy contracts and see things work. But Cairo isn’t forgiving when it comes to guesswork. Without proper tests, you’re basically walking blindfolded through a ZK jungle.

Enter snforge — Cairo’s modern testing framework.

Now, I use it to:

• Simulate contract deployments
• Call functions and assert outcomes
• Test storage and state transitions

What I wish I knew from day one is that testing early will save you hours of pain. And with tools like snforge, writing tests in Cairo is actually kind of fun (okay, mostly fun).

In a language this low-level and powerful, tests are your safety net.

A Look Back: The First Iteration of Cairo

For anyone curious — the first version I used was Cairo 0.x, the OG iteration built by StarkWare in 2021.

Here’s what it looked like:

func main():
    alloc_locals
    let a = 5
    let b = 6
    let c = a + b
    return ()
end

Yes, that’s Python-ish, but under the hood it was low-level, stack-based, and — let’s be honest — a little intimidating.

Today’s Cairo 1.x is a massive improvement:

• Rust-style syntax
• Strong typing
• Safer architecture
• Better tooling (scarb, snforge, etc.)

If you’re starting with Cairo now, you’re lucky. You’re entering a maturing ecosystem with actual docs, tutorials, and a thriving community.

Final Thoughts

Starting out with Cairo felt like being handed a sharp sword and told, “Good luck.” The docs were scattered. The syntax was shifting. The ecosystem was still finding its footing.

But I stayed. And I’m glad I did.

Because now I see what Cairo is becoming: a powerful, developer-friendly, zero-knowledge smart contract language that’s leading the charge into a more scalable future.

If you’re on that same journey — welcome. You’re right on time.

TL;DR

• Cairo ≠ Solidity. Approach it like a new paradigm.
• Learn how storage and accessors work early.
• Write tests — don’t wing it.

Let’s Talk

Are you just getting started with Cairo?
Did you also go through the Cairo 0 → 1 transition?
Or maybe you’re struggling to get your first contract deployed?

Let’s share stories — drop a comment or connect with me on X. I’ve got more Cairo articles and stories coming soon.

Together, we’ll build a better Layer 2 future. 💫

3 Things I Wish I Knew When I Started Writing Cairo Contracts was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.