What Is Starknet? A Developer's Guide to Cairo and the L2

Starknet is a layer 2 network built on Ethereum. It batches transactions, executes them off-chain, and posts a cryptographic proof to Ethereum showing that the resulting state changes are correct. Because Ethereum verifies the proof, the network inherits Ethereum's settlement security without every node re-executing every transaction. This design is called a validity rollup, or ZK-rollup.

StarkWare created the underlying technology, and the network is permissionless: anyone can deploy contracts and send transactions. Starknet has a native token, STRK, used in governance and staking and accepted for fees alongside ETH. Check the official documentation for the current fee and staking rules, as these have changed over time.

What makes it different from most other L2s:

• It uses STARK proofs, which rely on hash functions rather than a trusted setup.
• It does not run the Ethereum Virtual Machine. Contracts run on the Cairo VM.
• Every account is a smart contract, so account abstraction is built into the protocol.
• Its proof system is designed to prove general programs written in Cairo, not only token transfers.

Who it suits: teams that want Ethereum-level settlement with low per-transaction costs, and developers who are willing to learn a new language in exchange for a proving system built around it. If you need to port existing Solidity code with no changes, an EVM-equivalent rollup such as Arbitrum is the lower-friction route. The rest of this guide explains what you give up and gain by choosing Starknet.

A Starknet transaction goes through a sequencer, which orders transactions, executes them and produces blocks. Users see fast confirmations from the sequencer, but final settlement happens only once a proof covering those blocks has been verified on Ethereum.

The pipeline in plain steps:

1. You sign and submit a transaction to the network through an RPC node.
2. The sequencer orders and executes it, updating Starknet's state.
3. Execution traces from many blocks are given to a prover, which generates a STARK proof that the computation followed the rules.
4. A verifier contract on Ethereum checks the proof.
5. State updates and related data are posted to Ethereum, so anyone can reconstruct the L2 state from L1.

Proof generation can be shared across many blocks and even across applications, which spreads the fixed cost of verification over a lot of activity. This is why a validity rollup becomes more efficient as usage grows.

Why STARKs: STARK proofs need no trusted setup, and they are built from hash functions that are generally considered resistant to quantum attacks, unlike pairing-based schemes. The trade-off is that proofs are larger than some alternatives.

What to check live: how decentralized the sequencer and provers currently are, and the network's present block time and upgrade status. These parts of Starknet have been evolving, so rely on the official docs and the community governance forums rather than any static article, including this one.

If you come from Solidity, most mental models still apply: contracts hold storage, expose functions, emit events and call other contracts. The differences sit in the execution environment and the account model.

Area	Ethereum / EVM L2s	Starknet
Language	Solidity, Vyper	Cairo
Virtual machine	EVM	Cairo VM
Accounts	EOAs plus contract accounts	All accounts are contracts
Proofs	Optimistic or ZK, depending on chain	STARK validity proofs
Basic data unit	256-bit word	felt252 field element
Deployment	Bytecode creates a contract	Declare a class, then deploy an instance
Tooling	Hardhat, Foundry	Scarb, Starknet Foundry

Practical consequences:

• Existing Solidity contracts must be rewritten, not recompiled. Plan time for a full audit of the Cairo version.
• Some Ethereum conventions differ. Addresses are field elements, not 20-byte values, and hashing uses Poseidon or Pedersen in many places rather than keccak alone.
• Libraries and standards are built separately. Starknet has its own token and account standards, and the OpenZeppelin Cairo library covers many of them.
• Optimistic rollups such as Arbitrum and Linea-style zkEVMs keep EVM tooling familiar. Starknet asks you to adopt new tooling in return for a proving system designed around Cairo.

Choose Starknet when you value validity proofs, native account abstraction or provable Cairo programs. Choose an EVM chain when ecosystem compatibility is the priority.

Cairo is a language for writing provable programs. Cairo 1.0 and later versions use a Rust-inspired syntax, with strong static typing, traits, generics, pattern matching and enums. If you have written Rust, much will look familiar, though Cairo is a distinct language with its own rules.

Compilation path: Cairo source compiles to Sierra, an intermediate representation designed so that every valid program can be proven, including ones that fail at runtime. Sierra is then compiled to CASM, the assembly that the Cairo VM runs. This safe-compilation design lets the network charge for failed transactions without a prover getting stuck on them.

Concepts to learn first:

• felt252: the base type, an element of a large prime field. Arithmetic wraps modulo that prime, so it behaves differently from integer types.
• Integer types: u8 up to u128 are checked, and u256 is stored as two 128-bit parts, which affects storage layout and calldata.
• Ownership and mutability: values are moved or copied, and memory is write-once at the VM level, so arrays are append-only and dictionaries use a dedicated type.
• No floating point: use fixed-point maths for prices and rates.

A contract is a module marked with the starknet contract attribute. It declares a Storage struct, an interface trait, an implementation block and optional events. Keep contracts small, import audited components, and write unit tests from the start. The Cairo Book and the Starknet documentation remain the authoritative references, since syntax and attributes have evolved between compiler versions.

On Ethereum, a normal wallet is an externally owned account controlled by a single private key, and a contract is something else entirely. On Starknet, every account is a smart contract that implements a standard interface. Account logic, not the protocol, decides what counts as a valid signature.

The two core entry points are a validate step, which checks the transaction's signature and rules, and an execute step, which performs the calls. Because the account validates itself, wallets can offer features without separate infrastructure.

What this enables in practice:

• Different signature schemes, including those used by hardware or device-based keys.
• Multicall by default, so several actions run in one transaction and succeed or fail together.
• Social recovery, spending limits and multisig behaviour inside the account.
• Session-style permissions and sponsored fees, depending on what the wallet and ecosystem support.

What it changes for you as a developer:

• An account must be deployed before it can send ordinary transactions. Its address can be computed in advance, funded, and then activated with a deploy-account transaction.
• Do not assume the caller is a person or a single key. Check for the account's behaviour through its interface rather than by guessing.
• Use established account implementations, such as OpenZeppelin's, when building your own, and audit any custom validation logic carefully. A flawed validate step can leave funds open to theft.

Wallets such as Argent (now branded Ready) and Braavos each add their own features on top of this model, so test your app with more than one.

A typical Starknet environment has a few components, most of which install quickly.

Core tools:

• Scarb: the Cairo package manager and build tool. It creates projects, manages dependencies and compiles contracts.
• Starknet Foundry: a testing and deployment toolkit. Its test runner executes unit and integration tests, and its deployment tool declares, deploys and invokes contracts.
• A version manager: Starknet tooling is often installed through a version manager so that you can pin compiler versions per project.
• A local devnet: a local Starknet node for fast iteration without spending testnet funds.

Setup steps:

1. Install the version manager, then Scarb and Starknet Foundry, and check that their versions are compatible.
2. Create a new project with Scarb and review the generated manifest, which lists dependencies and the target type.
3. Add the OpenZeppelin Cairo packages for tokens, access control and upgrades.
4. Write your contract and tests, and run the test suite locally.
5. Create an account on the Sepolia test network, fund it with test tokens from a faucet, and deploy there first.

Tips: pin exact versions in your manifest, because Cairo has changed quickly between releases. Keep the code editor's Cairo language server updated for accurate diagnostics. Run tests in continuous integration so that compiler upgrades do not silently break your project. Always confirm the current install commands in the official docs, as they change more often than the concepts do.

Starknet separates the code of a contract from its deployed instances. This is one of the first things that surprises Solidity developers.

Key terms:

• Contract class: the compiled code, identified by a class hash. Declaring it registers it on the network.
• Contract instance: a deployed contract with its own address and storage, created from a class.
• Declare transaction: publishes a class.
• Deploy: creates an instance, usually through a deployer or the universal deployer contract, with constructor arguments.
• Invoke transaction: a state-changing call to a function.
• Call: a read-only request that costs nothing and changes nothing.

Why it matters: many instances can share one class, which saves resources for factory-style apps. Upgrades work through a replace-class function: an instance is switched to a new class hash while keeping its address and storage. Only expose this behind strict access control, because anyone who can call it can replace your logic.

A typical flow:

1. Build with Scarb.
2. Declare the class from your funded account on Sepolia.
3. Deploy an instance with constructor arguments.
4. Invoke functions and read state, then verify the class on a block explorer such as Voyager or Starkscan so users can inspect the source.
5. Repeat on mainnet after testing.

Store class hashes and addresses per network in a config file. Treat mainnet deployment keys with the same care as any production signing key.

Your app talks to Starknet through an RPC node, and the standard JSON-RPC specification is shared across providers. Node access is available from public endpoints, from infrastructure companies and from self-hosted nodes. Ankr is one multichain RPC provider that developers consider; confirm that it currently serves Starknet before relying on it, and compare rate limits, archive access and pricing across providers.

Client libraries:

• starknet.js for JavaScript and TypeScript frontends and scripts.
• starknet.py for Python tooling and backends.
• starknet-rs for Rust services.
• Starknet React for hooks and wallet connection in React apps.

Frontend checklist:

• Support several wallets, and test the connect, sign and fee flows in each.
• Display amounts using the token's decimals, and handle u256 values as two parts when decoding calldata or events.
• Estimate fees before sending, and show clear errors on failure.
• Let users choose the network, and never default to mainnet in test builds.

Data and indexing: events are the primary way to track contract activity. For dashboards, history and analytics, use an indexer or build one that reads events from blocks, rather than polling storage. Explorers are useful for debugging, but do not use them as your application's data source.

Because the RPC specification and library versions move together, update your libraries when the network upgrades and read release notes before bumping major versions.

Most users and liquidity reach Starknet from Ethereum, so bridging is part of the developer experience. Starknet has an official bridge for assets moving between Ethereum and Starknet, and many users also arrive through centralized exchanges that support withdrawals to Starknet addresses. Third-party bridges and intent-based protocols such as Across may offer routes too, so check their supported-chains list before you point users at them.

L1-L2 messaging: Starknet has a native message-passing system. A contract on Ethereum can send a message that triggers a handler on Starknet, and a Starknet contract can send a message back to be consumed on Ethereum. Messages from L2 to L1 only become consumable after the relevant proof is verified, which means a delay compared with L2 confirmation. Design your UX with this timing in mind.

Cross-chain messaging protocols: general-purpose systems such as LayerZero V2 and Chainlink CCIP serve developers who want to connect several chains. Support for any particular chain varies and changes, so verify Starknet support in each protocol's own documentation before designing around it.

Bridge-related security habits:

• Prefer canonical or well-audited routes for large amounts.
• Verify token addresses on Starknet, because bridged versions of the same asset can exist side by side.
• Test the full deposit and withdrawal path on testnet.
• Tell users clearly how long withdrawals to Ethereum take, and where to track their status.

Cairo removes some classic Solidity pitfalls but adds new ones. Security work should begin during design, not after the code is finished.

Defensive practices:

• Reuse audited components. Start from OpenZeppelin's Cairo contracts for tokens, ownership and upgrades rather than writing them from scratch.
• Guard felt252 arithmetic. Field elements wrap around, so use checked integer types for balances and amounts.
• Lock down upgrades. Restrict replace-class to a multisig or timelock, and publish who holds that power.
• Validate every external call. Reentrancy is still possible through cross-contract calls, so update state before interacting with other contracts.
• Review account logic closely. A mistake in a custom validate function can be catastrophic.
• Handle u256 correctly. Check how amounts are split and recombined across calldata and storage.

Process:

1. Write thorough unit and integration tests, including negative cases.
2. Add fuzz testing where your tooling supports it.
3. Get an independent audit from a firm with Cairo experience. Firms such as Sherlock offer audits and contests for onchain teams; confirm that they currently cover Cairo before engaging them.
4. Run a bug bounty after launch.
5. Monitor events and set up alerts for unusual activity.

Secure your deployer keys with hardware or multisig setups, and separate testnet and mainnet keys. Never paste seed phrases or private keys into scripts that are committed to version control.

Some details about Starknet shift often, and a static guide cannot be trusted for them. Verify these in primary sources before you commit to a design or promise anything to users.

Check before building:

• Fees and fee tokens: current resource pricing and which tokens are accepted.
• Decentralization status: who runs the sequencer and provers today, and what the roadmap states.
• Compiler and network versions: the latest Cairo, Scarb and Starknet Foundry releases, and any breaking changes.
• Ecosystem support: whether the wallets, bridges, oracles and RPC providers you need support Starknet right now.
• Liquidity and usage: TVL, volume and active users, available from analytics dashboards such as DefiLlama.
• Governance and grants: current programs and proposals on the official forums.

Where to look: the official Starknet documentation, the Cairo Book, the community forum, the GitHub release pages for your tools, and the status pages of your infrastructure providers.

A sensible first project: write a small ERC-20-style token or a vault in Cairo, add tests, deploy it to Sepolia, and build a minimal frontend that connects two wallets. That exercise touches declaration, deployment, account abstraction and events, which covers most of what you need for larger applications.

If your product involves trading, betting or other regulated activity, check the laws that apply to you and your users, and keep any age restrictions in place.