Skip to content
Published on

Web3 & Smart Contract Development 2026 — A Deep-Dive on Hardhat / Foundry / Solidity / Cairo (StarkNet) / Anchor (Solana) / viem / wagmi / OpenZeppelin / Slither / Tenderly

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

Prologue — The "Web3 is Dead" Claim and the 2026 Reality

The 2022 crypto winter, the 2023 FTX wreckage, the 2024 SBF life sentence, and yet another "this time it's real" cycle after 2025's ETF approvals — Web3 has been declared dead every year, and every year the number of builders only grew. In spring 2026, two things are honestly true at the same time.

First, the consumer dApp market is still small. The NFT boom is over, "DeFi summer"-style mania is not coming back, and the model of charging gas fees to regular users is still high-friction even on L2s.

Second, infrastructure and developer tooling have never been better. Foundry finally gave us "Web2-grade DX". viem and wagmi shaved down a huge amount of client-side pain. OpenZeppelin 5.x made ERC standards safely reusable. Slither, Mythril, Echidna, and Halmos turned static analysis, symbolic execution, and fuzz testing into daily practice. RPC competition between Alchemy, Infura, and QuickNode has driven prices down. L2s have settled — Arbitrum, Optimism, and Base hold their seats, while the ZK side (zkSync, Polygon zkEVM, StarkNet) has survived.

The premise of this post is twofold. (1) For anyone seriously writing smart contracts in 2026, lay out honestly which tools to pick. (2) Compare four camps — EVM, Solana, StarkNet, and Stylus (Rust) — on the same axes, instead of looking only at one.

Models converge, but infrastructure makes the difference. Solidity 0.8.x has barely changed in five years, yet working in Hardhat vs Foundry feels like two different worlds.

Prices, features, and performance numbers move fast. Every number here is as of May 2026, and we focus on structural differences. The decision framework should still hold six months from now even if the numbers shift.

1. The 2026 Web3 Dev Map — EVM / Solana / StarkNet / Stylus

The big picture first. In 2026 smart contracts split across four VM/language camps.

Camp 1 · EVM + Solidity/Vyper. Ethereum mainnet and its L2s (Arbitrum, Optimism, Base, zkSync Era, Polygon zkEVM, Linea, Scroll, and so on). Solidity 0.8.x dominates with Vyper as a minority alternative. Tooling is Hardhat or Foundry. Client side is ethers.js v6 or viem. The vast majority of smart-contract TVL lives here.

Camp 2 · Solana + Rust(Anchor) / Move(Sealevel). Anchor laid IDL and boilerplate over Rust, making the chain approachable for developers coming from EVM. Helius grew the Solana-specific RPC space, and Metaplex defined NFT/token standards. Low transaction costs and high TPS attract gaming and payments experiments.

Camp 3 · StarkNet + Cairo. Cairo, the ZK-friendly language from StarkWare. In 2026 Cairo 2.x is the norm and Starknet Foundry brings a Foundry-style workflow. Essentially the only mainstream option for handling ZK proofs natively at the contract level.

Camp 4 · Arbitrum Stylus + Rust/C/C++. Arbitrum attached a WASM-based VM next to the EVM, so contracts written in Rust live and run on the same chain as Solidity contracts and can call each other. Beta in 2024, mainnet in 2025, full adoption hits in 2026. Ten to a hundred times more gas-efficient than Solidity for the right workloads, but the ecosystem is still young.

Camp choice typically follows "which chain are you deploying to". Ethereum mainnet or L2 means EVM/Solidity. Solana means Rust/Anchor. StarkNet means Cairo. Arbitrum plus Rust expertise means Stylus is on the table. The rest of this post walks each camp on a common frame.

One more thing worth emphasizing — same language, different tooling. Solidity is one language but Hardhat and Foundry deliver wildly different development experiences. Rust is one language but Anchor (Solana) and Stylus SDK (Arbitrum) impose different models. Tooling choice often matters more than language choice.

2. Hardhat (Nomic Foundation) — The Classic Solidity Environment

Hardhat is Nomic Foundation's "incumbent standard" for EVM. It ties compilation, testing, deployment, and debugging into a single JavaScript/TypeScript pipeline. It has been around since 2018 and still has the largest user base in 2026.

Core flow.

# New project
npx hardhat init

# Compile
npx hardhat compile

# Tests (Mocha + Chai + ethers/viem)
npx hardhat test

# Local network (HardhatNetwork, supports forking)
npx hardhat node

# Deploy (Ignition)
npx hardhat ignition deploy ./ignition/modules/MyModule.ts

Hardhat's real moat is its plugin ecosystem. Installing @nomicfoundation/hardhat-toolbox alone gives you verify, gas-reporter, coverage, and typechain in one shot. First-class TypeScript support, Chai matchers like expect(tx).to.emit(...), mainnet forking that replays past block states locally, console.log from Solidity — all of these grew up inside the Hardhat ecosystem.

Two big shifts in 2026.

Hardhat 3 (Rust rewrite). Made public in beta in late 2025, Hardhat 3 rewrites the core in Rust and dramatically speeds up build and test. A deliberate attempt to reclaim the "speed" axis Foundry took. The same project compiles and tests two to five times faster than Hardhat 2.

Hardhat Ignition. Replaces imperative deploy scripts (those deploy.ts files full of if/else around deploy order) with declarative modules. Express "this contract needs that contract's address" as a dependency graph and Ignition resolves order, plus resumes from the failure point. It shines in multi-step deployments (e.g., Proxy + Implementation + Initialize).

import { buildModule } from '@nomicfoundation/hardhat-ignition/modules'

export default buildModule('LockModule', (m) => {
  const unlockTime = m.getParameter('unlockTime', 1893456000n)
  const lockedAmount = m.getParameter('lockedAmount', 1_000_000_000n)
  const lock = m.contract('Lock', [unlockTime], { value: lockedAmount })
  return { lock }
})

Honest downsides. (1) Running on Node.js/TypeScript means slow CI — what Foundry compiles in 5 seconds Hardhat 2 sometimes took 30 (Hardhat 3 closes the gap but still trails Foundry). (2) No Solidity-based tests, only TS/JS — the decisive contrast with forge test, which writes tests in Solidity directly. (3) Fuzz testing is weak — not built in, requires a plugin.

Even so, the rich plugins, TypeScript-friendliness, and familiar Node.js ecosystem keep Hardhat strong, especially for teams maintaining "smart contracts + frontend + backend" in a single monorepo.

3. Foundry (Paradigm) — Forge / Cast / Anvil / Chisel

Foundry, built by Paradigm, is the de facto "new standard" in 2026. Written in Rust from the start, it is extremely fast, and a single decision — tests are written in Solidity — reshapes the entire developer experience.

Foundry is four tools.

  • Forge — compile, test, deploy. The Hardhat replacement.
  • Cast — a CLI that talks to chains. cast call, cast send, cast estimate. Think of it as a CLI version of ethers/viem.
  • Anvil — local node and forker. The Hardhat Network replacement.
  • Chisel — a Solidity REPL. An interpreter for running one line at a time.

Install is a single line.

curl -L https://foundry.paradigm.xyz | bash
foundryup

The defining difference is that tests are Solidity.

// test/Counter.t.sol
import { Test } from "forge-std/Test.sol";
import { Counter } from "../src/Counter.sol";

contract CounterTest is Test {
    Counter public counter;

    function setUp() public {
        counter = new Counter();
    }

    function test_Increment() public {
        counter.increment();
        assertEq(counter.number(), 1);
    }

    // Fuzz test — forge generates inputs automatically
    function testFuzz_SetNumber(uint256 x) public {
        counter.setNumber(x);
        assertEq(counter.number(), x);
    }
}

Writing tests in Solidity gives you three wins. (1) Same language as the contract code, so context switching cost drops to zero. (2) Cheatcodes like vm.prank(alice) let you flip caller, time, or block instantly. (3) forge test automatically treats every testFuzz_* function as a fuzz test — by default 256 random inputs each.

And speed. The same 100-test project that takes 30 to 60 seconds under Hardhat finishes in 2 to 5 seconds under Forge. Decisive when CI cost matters.

Cast examples.

# Call a contract function
cast call 0xA0b8... "balanceOf(address)" 0xdeadbeef... --rpc-url $RPC

# Send a transaction
cast send 0xA0b8... "transfer(address,uint256)" 0x123... 1000 \
  --private-key $PK --rpc-url $RPC

# Decode a transaction
cast tx 0x4a3... --rpc-url $RPC

Anvil is a near-Hardhat-Network-compatible local node, and its mainnet fork is fast. anvil --fork-url $MAINNET_RPC pulls mainnet state locally for experimentation. Forking is core to every serious smart-contract workflow.

Honest downsides. (1) Weaker integration with the JavaScript/TypeScript ecosystem — auto-exporting contract types to the frontend is not as smooth as in Hardhat. (2) Smaller plugin ecosystem. (3) Solidity-based tests make it harder to mimic non-EVM logic (e.g., faking external HTTP calls).

Still, in 2026, starting fresh means Foundry by default. Hardhat stays where there are large existing codebases or deep ties to the TS ecosystem.

4. Solidity 0.8.x / Vyper — Language Choice

In the EVM camp, the practical language choice comes down to two.

Solidity 0.8.x has been the stable line since 2021. The biggest change introduced in 0.8.0 is checked arithmetic — overflows and underflows revert automatically. Up through 0.7.x you had to plaster SafeMath everywhere; now it is safe by default. From 0.8.20 the EVM target version is explicit (paris, shanghai, cancun, prague), making per-L2 compatibility easier.

Key additions in 2026.

  • unchecked { ... } — opt out of arithmetic checks explicitly to save gas.
  • Custom errors — error Unauthorized(address caller);. Far cheaper than revert strings.
  • using ... for ... — attach library functions to types. The Solidity confidence trick.
  • Transient storage (0.8.24+, Cancun) — tstore / tload. Storage that lives only for a transaction. Great for reentrancy locks at low gas.
  • require with custom error (0.8.26+) — used to require revert MyError(), now require(cond, MyError()) works.

Solidity 0.9 has no firm date as of May 2026. 0.8.x keeps growing while preserving compatibility for five years now.

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

contract Vault {
    error InsufficientBalance(uint256 requested, uint256 available);

    mapping(address => uint256) public balances;

    function withdraw(uint256 amount) external {
        uint256 bal = balances[msg.sender];
        if (amount > bal) revert InsufficientBalance(amount, bal);
        unchecked { balances[msg.sender] = bal - amount; }
        (bool ok, ) = msg.sender.call{value: amount}("");
        require(ok, "send failed");
    }
}

Vyper is an EVM language borrowing Python syntax. Vitalik gave it some early backing. In 2026 Vyper 0.4.x is the stable line.

Vyper's philosophy is "simple, explicit, auditable". It deliberately removes "powerful but complex" features like function modifiers, inheritance, and inline assembly. Major DeFi protocols like Curve Finance are written in Vyper.

# Vyper 0.4 example
@external
@payable
def deposit():
    self.balances[msg.sender] += msg.value

@external
def withdraw(amount: uint256):
    assert self.balances[msg.sender] >= amount
    self.balances[msg.sender] -= amount
    send(msg.sender, amount)

When Vyper? Honestly, rarely. Solidity is the overwhelming first choice; Vyper is for (a) compatibility with a specific protocol (Curve-style), (b) shrinking audit surface to the absolute minimum. New projects rarely start in Vyper.

5. Cairo (StarkNet) — A ZK-Friendly Language

Cairo is StarkWare's ZK-friendly language. Rather than bolting ZK on top of the EVM, Cairo VM was designed from scratch to optimize ZK proof generation. StarkNet is the L2 running on the Cairo VM.

In 2026 Cairo 2.x is standard. Compared to Cairo 1 the syntax went Rust-flavored (fn, let, traits, enums). The learning curve is steep at first, but feels familiar if you know Rust.

// A simple ERC20-like contract
#[starknet::contract]
mod SimpleToken {
    use starknet::ContractAddress;
    use starknet::get_caller_address;

    #[storage]
    struct Storage {
        balances: LegacyMap<ContractAddress, u256>,
        total_supply: u256,
    }

    #[constructor]
    fn constructor(ref self: ContractState, initial_supply: u256) {
        let caller = get_caller_address();
        self.balances.write(caller, initial_supply);
        self.total_supply.write(initial_supply);
    }

    #[external(v0)]
    fn transfer(ref self: ContractState, to: ContractAddress, amount: u256) {
        let caller = get_caller_address();
        let sender_balance = self.balances.read(caller);
        assert(sender_balance >= amount, 'insufficient');
        self.balances.write(caller, sender_balance - amount);
        let recipient_balance = self.balances.read(to);
        self.balances.write(to, recipient_balance + amount);
    }
}

Two tools matter.

Scarb — Cairo's Cargo. Package management, build. scarb build, scarb test. Extremely familiar for Rust developers.

Starknet Foundry (snforge) — the Cairo version of Foundry. It brings the DX Foundry gave Solidity to StarkNet. snforge test is fast and supports cheatcodes.

scarb new my_starknet_project
cd my_starknet_project
scarb build
snforge test

StarkNet's TVL is smaller than other L2s in 2026, but it is practically the only mainstream option that treats ZK proofs as first-class citizens — strong in privacy apps, in-game verifiable randomness, and bringing off-chain computation on-chain as proofs.

Downsides. (1) Much smaller ecosystem than EVM — OpenZeppelin Cairo exists but library depth is not comparable. (2) Steep learning curve — felt252 (field element) is an unusual primitive, and history between low-level Cairo and Cairo 2.x is messy. (3) Tight hiring market — capable Cairo engineers are scarce.

When Cairo? When verifiable computation via ZK proofs is a hard requirement, or when building protocols native to StarkNet (e.g., pre-v4 dYdX, AVNU, JediSwap).

6. Anchor (Solana) — The Rust Framework

Solana writes contracts (called "programs") in Rust. Writing raw SBF (Solana BPF) programs without a framework drowns you in boilerplate — account serialization/deserialization, permission checks, instruction dispatch all done by hand.

Anchor solves this. It plays roughly the role Hardhat and Truffle played for EVM — macros hide boilerplate, and an IDL (Interface Definition Language) auto-generates the client.

use anchor_lang::prelude::*;

declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS");

#[program]
pub mod my_counter {
    use super::*;

    pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
        let counter = &mut ctx.accounts.counter;
        counter.count = 0;
        Ok(())
    }

    pub fn increment(ctx: Context<Increment>) -> Result<()> {
        let counter = &mut ctx.accounts.counter;
        counter.count += 1;
        Ok(())
    }
}

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(init, payer = user, space = 8 + 8)]
    pub counter: Account<'info, Counter>,
    #[account(mut)]
    pub user: Signer<'info>,
    pub system_program: Program<'info, System>,
}

#[derive(Accounts)]
pub struct Increment<'info> {
    #[account(mut)]
    pub counter: Account<'info, Counter>,
}

#[account]
pub struct Counter {
    pub count: u64,
}

Two model differences if you arrive from EVM. (1) Account model — on Solana all data lives in accounts. The contract is an account, the user is an account, the token balance is an account. Every call must declare which accounts it touches. (2) Stateless programs — code and data are split. One program manipulates data across many accounts.

Anchor workflow.

# New project
anchor init my-project
cd my-project

# Build (Rust to SBF)
anchor build

# Local test (spins up solana-test-validator)
anchor test

# Deploy to devnet
anchor deploy --provider.cluster devnet

Tests are written in TypeScript (Mocha-based). Anchor emits an IDL, and the IDL drives auto-generated TypeScript types and clients.

import * as anchor from '@coral-xyz/anchor'
import { Program } from '@coral-xyz/anchor'
import { MyCounter } from '../target/types/my_counter'

describe('my-counter', () => {
  const provider = anchor.AnchorProvider.env()
  anchor.setProvider(provider)
  const program = anchor.workspace.MyCounter as Program<MyCounter>

  it('Increments', async () => {
    const counter = anchor.web3.Keypair.generate()
    await program.methods.initialize().accounts({ counter: counter.publicKey, user: provider.wallet.publicKey, systemProgram: anchor.web3.SystemProgram.programId }).signers([counter]).rpc()
    await program.methods.increment().accounts({ counter: counter.publicKey }).rpc()
    const account = await program.account.counter.fetch(counter.publicKey)
    console.log('count:', account.count.toString())
  })
})

Downsides. (1) The macros generate opaque error messages. (2) The compatibility matrix between Anchor and Solana CLI versions is finicky — you have to know the difference between 0.31, 0.30, and 0.29. (3) Not every dynamic pattern fits into the IDL.

Even so, on Solana in 2026 Anchor is the default. Raw Solana programs are reserved for very specific cases (e.g., extreme gas optimization).

7. ethers.js v6 vs viem — Client Libraries

Smart contracts are deployed to a chain, but the code that calls them — frontends, backends, bots — is in JavaScript/TypeScript. Client libraries are the bridge.

The two heavyweights in EVM circa 2026.

ethers.js v6 — the classic. Around since 2017 and the de facto winner after the web3.js wars. v6 was a big refactor of v5 released in 2023. ES modules, ESM-friendly, native BigInt. Downsides: subtly weak TypeScript types, hard-to-tree-shake, and a large bundle.

import { ethers } from 'ethers'

const provider = new ethers.JsonRpcProvider('https://eth-mainnet.alchemyapi.io/v2/KEY')
const signer = new ethers.Wallet(privateKey, provider)
const contract = new ethers.Contract(address, abi, signer)

const tx = await contract.transfer(to, ethers.parseEther('1.0'))
const receipt = await tx.wait()
console.log('Block:', receipt.blockNumber)

viem — the wagmi team (wevm) started it in 2022 with explicit intent to fix ethers.js. In 2026 the 2.x line is stable. TypeScript-first (ABI types inferred automatically), tree-shakable, small bundle, standardized RPC calls. It deliberately addresses every ethers pain point.

import { createPublicClient, http, parseEther } from 'viem'
import { mainnet } from 'viem/chains'
import { privateKeyToAccount } from 'viem/accounts'

const client = createPublicClient({ chain: mainnet, transport: http('https://eth-mainnet.alchemyapi.io/v2/KEY') })
const account = privateKeyToAccount('0x...')

// ABI inference narrows transfer's arg and return types automatically
const hash = await client.writeContract({
  account,
  address: '0xA0b8...',
  abi: tokenAbi,
  functionName: 'transfer',
  args: ['0x123...', parseEther('1.0')],
})
const receipt = await client.waitForTransactionReceipt({ hash })

viem's core differences.

  • abitype — infers TypeScript types from ABI. Type functionName: 'transfer' and args narrows to [Address, bigint]. Wrong arguments fail at compile time.
  • Tree-shaking — import only parseEther and only that lands in your bundle. Bundle size feeds Lighthouse scores directly.
  • Function-based API — ethers is class-based, viem is function-based. Code splitting feels natural.
  • Action API — client.readContract, client.writeContract, client.simulateContract share a consistent interface.

In 2026 viem is the default for new projects. ethers stays in maintenance mode for existing codebases or teams who already paid the v5-to-v6 migration cost.

web3.js was sunsetted by ConsenSys in 2024. In 2026 web3.js 4.x is the last line, and the community consensus is to move to viem or ethers.

8. wagmi v2 + ConnectKit / RainbowKit / Web3Modal (Reown)

The client libraries above are at "JS calling a chain" level. If you build a React/Next.js app you want one more layer on top — wallet connect UI, account state, caching, useEffect abstraction.

wagmi v2 fills that role. Built by the wevm team (same as viem), it is a React hooks library. From 2.x onward it sits on viem and drops the 1.x ethers dependency.

import { createConfig, http, WagmiProvider } from 'wagmi'
import { mainnet, base } from 'wagmi/chains'
import { QueryClient, QueryClientProvider } from '@tanstack/react-query'

const config = createConfig({
  chains: [mainnet, base],
  transports: { [mainnet.id]: http(), [base.id]: http() },
})
const queryClient = new QueryClient()

function App() {
  return (
    <WagmiProvider config={config}>
      <QueryClientProvider client={queryClient}>
        <YourApp />
      </QueryClientProvider>
    </WagmiProvider>
  )
}

useAccount, useBalance, useReadContract, useWriteContract, useWaitForTransactionReceipt — every hook rides React Query for caching, retries, and automatic invalidation.

function Balance() {
  const { address } = useAccount()
  const { data: balance } = useBalance({ address })
  return <div>Balance: {balance?.formatted} {balance?.symbol}</div>
}

The wallet-connect UI itself is not in wagmi; you pick one of three libraries.

ConnectKit — built by Family.co (previously part of ZORA), clean UI. Deepest wagmi integration. Minimal design, dark/light, customizable. In 2026 ConnectKit 1.x.

RainbowKit — built by the Rainbow Wallet team, the flashiest UI. The default look-and-feel for trendy NFT/DeFi apps. The rainbow-gradient theme is the visual signature. wagmi v2 compatibility lives in RainbowKit 2.x.

Web3Modal becomes Reown. The former WalletConnect company rebranded as Reown in 2024, and Web3Modal got renamed to AppKit. Widest multi-chain coverage (EVM, Solana, Bitcoin). The most "backend-ish" — 600+ wallets, strong analytics.

// ConnectKit example
import { ConnectKitProvider, ConnectKitButton } from 'connectkit'

function App() {
  return (
    <WagmiProvider config={config}>
      <QueryClientProvider client={queryClient}>
        <ConnectKitProvider>
          <ConnectKitButton />
          <YourApp />
        </ConnectKitProvider>
      </QueryClientProvider>
    </WagmiProvider>
  )
}

Picking.

  • ConnectKit — minimal design, solid dark mode, fast loads.
  • RainbowKit — if you want to look like an NFT/DeFi app. Rainbow tones.
  • Reown AppKit — when Solana ships alongside, or you need 600+ wallets.

All three sit on wagmi so the underlying logic matches — the choice is UI/UX and multi-chain breadth.

9. OpenZeppelin Contracts 5.x — Safe Standard Implementations

Once a smart contract is deployed it is hard to change (upgrade patterns exist, but they are complicated). So standards like ERC20, ERC721, AccessControl, and Pausable are almost mandatory to use from vetted implementations.

OpenZeppelin Contracts holds that seat. Maintained by ConsenSys/OpenZeppelin Security. The 5.x line dropped in 2024.

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

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract MyToken is ERC20, Ownable {
    constructor(address initialOwner) ERC20("MyToken", "MTK") Ownable(initialOwner) {
        _mint(initialOwner, 1000000 * 10 ** decimals());
    }
}

Notable changes in 5.x.

  • Custom errors everywhere — error Unauthorized(); instead of revert "string". Gas savings plus decodability.
  • AccessControl strengthened — permissions modular. DEFAULT_ADMIN_ROLE, MINTER_ROLE and other common patterns.
  • Ownable(initialOwner) — owner specified in the constructor. Previously auto-set to msg.sender.
  • SafeERC20 — wrappers to safely interact with non-standard return tokens like USDT.
  • UUPSUpgradeable, TransparentUpgradeableProxy — upgrade patterns.
  • ERC2771Context — meta-transaction (gasless) support.

Install is a one-liner in npm/Hardhat/Foundry.

# Hardhat / npm
npm install @openzeppelin/contracts

# Foundry
forge install OpenZeppelin/openzeppelin-contracts

What OpenZeppelin does not give you. (1) Business logic — DeFi lending, AMMs, derivatives are still on you. (2) Minimum gas — OpenZeppelin prioritizes safety over gas; gas-optimized libraries like Solady (Vectorized) exist separately.

On Solana the analogue is anchor-spl — the Anchor wrapper over Solana Program Library — providing standard implementations of SPL Token, Associated Token Account, and so on.

10. Security — Slither / Mythril / Echidna / Halmos symbolic

A single bug in a smart contract can cost hundreds of millions. From The DAO in 2016 to Ronin in 2022 to Multichain in 2023 — every major hack could have been caught by better static analysis. The 2026 security toolchain has four pillars.

Slither (Trail of Bits). The best-known static analyzer. Python codebase, walks Solidity AST, and flags known vulnerability patterns. Reentrancy, integer overflow, uninitialized storage, dangerous low-level calls, naming conventions — 80+ detectors.

pip install slither-analyzer
slither contracts/

Trivial to wire into CI. Running it on every PR is standard.

Mythril (ConsenSys Diligence). Symbolic-execution based. Symbolically runs the EVM bytecode and automatically finds inputs that break an assertion. Slower than Slither, but goes deeper.

pip install mythril
myth analyze contracts/MyContract.sol

Echidna (Trail of Bits). Property-based fuzz testing. Declare "this invariant must never be broken" and Echidna throws thousands of random inputs to find the breaker.

// Echidna example
contract VaultTest is Vault {
    function echidna_balance_never_negative() public view returns (bool) {
        return balances[msg.sender] >= 0;  // must always hold
    }
}

echidna contracts/VaultTest.sol --contract VaultTest

Halmos (a16z crypto). A relatively recent (since 2023) symbolic executor. Its core differentiator is running directly on Foundry tests — call halmos instead of forge test and the same test code runs symbolically.

pip install halmos
halmos --contract VaultTest

Foundry forge fuzz. Foundry's built-in fuzzer. Every testFuzz_* function auto-runs with random inputs (default 256). The lightest first line of defense.

function testFuzz_TransferDoesNotLoseValue(uint256 amount) public {
    vm.assume(amount > 0 && amount <= token.balanceOf(alice));
    uint256 before = token.balanceOf(alice) + token.balanceOf(bob);
    vm.prank(alice);
    token.transfer(bob, amount);
    uint256 after = token.balanceOf(alice) + token.balanceOf(bob);
    assertEq(before, after);
}

Slang (Nomic Foundation). Announced by Nomic in 2024 as a Rust-based Solidity compiler frontend. Goal is to be "the next-gen analysis infra replacing Slither". As of 2026 it is still beta but will tightly integrate with Hardhat 3.

A pragmatic workflow.

  1. Every PR — Slither plus Foundry forge fuzz.
  2. Every major release — Echidna plus Mythril.
  3. Contracts with critical invariants — Halmos for symbolic verification.
  4. Before mainnet deployment — external audit (Trail of Bits, OpenZeppelin Security, ConsenSys Diligence, contests on Code4rena).

Automated tools do not "replace audits". They "shrink the surface before the audit starts". Serious projects do both.

11. Tenderly — Monitoring, Simulation, and Debugging

Operating a deployed contract requires its own tooling. Etherscan looks nice but is not enough for debugging why a transaction failed.

Tenderly lives here. Started in 2018 as an EVM transaction debugger and has grown into a full platform.

Core features.

  • Transaction debugger — line-by-line trace of a reverted transaction. Which require failed, which variable held what.
  • Simulator — preview "what happens if I send this transaction" on a mainnet fork before submitting. Gas estimate, state diff, emitted events.
  • Alerts — Slack, email, or webhook notifications on contract events, state changes, or errors.
  • Web3 Actions — trigger-based serverless functions. Auto-run code when an event fires.
  • War Rooms — let teams debug a transaction together in real time during an incident.

API access too.

import { TenderlyConfiguration, Tenderly } from '@tenderly/sdk'

const tenderly = new Tenderly({ accountName: 'me', projectName: 'myproject', accessKey: process.env.TENDERLY_KEY })

const simulation = await tenderly.simulator.simulateTransaction({
  transaction: { from: '0xA...', to: '0xB...', input: '0xa9059cbb...', value: '0', gas: 100000, gasPrice: '0' },
  blockNumber: 'latest',
})
console.log(simulation)

"Simulate before submitting" is a very common pattern in dApp frontends. Saves users from paying gas on doomed transactions.

Alternatives. Phalcon (BlockSec) — similar debugging and monitoring territory. OpenZeppelin Defender — more operations and automation focused. Forta — on-chain threat detection.

Tenderly is the strongest all-in-one package in 2026. Free tier is generous enough for side projects; production sits in the 50 to 500 USD per month range.

12. Alchemy / Infura / QuickNode / Helius — RPC Providers

Talking to a smart contract needs someone running a node. Running your own is expensive — an Ethereum mainnet node needs 2 TB of disk and days of sync time. So the RPC provider market is large.

Alchemy. US-based, San Francisco. Roughly the market leader in 2026. All EVM (Ethereum, Polygon, Arbitrum, Optimism, Base, zkSync, Polygon zkEVM, Starknet, Linea, Scroll) plus Solana. Notify (event webhooks), NFT API, Enhanced APIs (data indexing). Free tier: 300M compute units per month.

Infura. Owned by ConsenSys. One of the oldest RPC providers. MetaMask calls Infura by default — that dependency is effectively the standard. All EVM plus an IPFS gateway. Free tier: 100k requests a day. Outages in the past ("when Infura goes down, web3 goes down") pushed multi-RPC patterns as best practice.

QuickNode. Headquartered in Miami. Supports 30+ chains, including Solana, Cosmos, and Polkadot beyond EVM. A marketplace of add-ons. Usage-based pricing.

Helius. Solana-only RPC. Solana's transaction handling differs sharply from EVM (parallel execution, lamports, slots, etc.), so a Solana-specialized provider has real value. Helius leads share in Solana RPC. Webhooks, DAS (Digital Asset Standard) API, enhanced parsing.

Public RPC. Free public endpoints exist — eth.llamarpc.com, cloudflare-eth.com, rpc.ankr.com/eth. Fine for side projects, not recommended for production (no SLAs, tight rate limits).

Picking.

  • EVM-heavy plus full stack — Alchemy.
  • MetaMask compatibility, simplicity — Infura.
  • Many chains at once — QuickNode.
  • Serious Solana — Helius.
  • Side projects — any free tier.

Multi-RPC pattern — production always uses two or more providers with fallback. viem's fallback transport, ethers's FallbackProvider.

import { createPublicClient, http, fallback } from 'viem'
import { mainnet } from 'viem/chains'

const client = createPublicClient({
  chain: mainnet,
  transport: fallback([http('https://eth-mainnet.g.alchemy.com/v2/KEY1'), http('https://mainnet.infura.io/v3/KEY2')]),
})

When one provider fails the call rolls over automatically.

13. L2 — Arbitrum / Optimism / Base / zkSync / Polygon zkEVM / StarkNet

Ethereum mainnet is expensive and slow. That is why L2s exist. The six mainstream L2s in 2026.

Arbitrum. Operated by Offchain Labs. Optimistic rollup. The TVL leader among L2s — somewhere in the 30 to 50 billion USD range in 2026. EVM-equivalent (mainnet Solidity runs almost as-is). Stylus sits next to the EVM for Rust contracts.

Optimism. Operated by OP Labs. Optimistic rollup. Number two by TVL. Superchain vision — a federation of networks built on the OP Stack. Base, Worldchain, Mode, and others run on OP Stack.

Base. Operated by Coinbase. Built on the OP Stack. Launched 2023 and in 2026 is one of the largest L2s by user count. Direct exposure to Coinbase's 80M users is the moat. Heavy marketing (Onchain Summer) draws dApps.

zkSync Era. Operated by Matter Labs. ZK rollup. EVM-compatible (not fully equivalent but close). Custom compiler (zksolc). Cheap gas, faster finality.

Polygon zkEVM. Operated by Polygon. ZK rollup and very nearly EVM-equivalent. Part of the broader Polygon ecosystem (Polygon PoS, CDK, Miden).

StarkNet. Operated by StarkWare. Validity rollup. Uses Cairo. Not EVM-compatible — a separate ecosystem.

Picking.

  • TVL and ecosystem depth — Arbitrum.
  • OP Stack and Superchain — Optimism, Base, and OP Stack derivatives.
  • Coinbase user exposure — Base.
  • EVM-compatible ZK — zkSync Era or Polygon zkEVM.
  • ZK as first-class — StarkNet.

Gas costs are 10 to 100 times cheaper than mainnet across the board. The decision is trade-offs between gas, finality, and ecosystem.

Smaller L2s also matter — Linea (ConsenSys), Scroll, Mantle (BitDAO), Mode (OP Stack), Blast (yield-native) — each has a niche, and "where to deploy" follows "where your users are".

14. Arbitrum Stylus — Rust Smart Contracts (Same Chain as EVM)

Stylus going mainnet in 2025 is among the biggest changes adoption is digesting in 2026.

The core idea: WASM-based contracts run on the same Arbitrum chain as EVM contracts. A Rust contract lives alongside Solidity contracts and they call each other freely.

// Stylus contract example
extern crate alloc;
use stylus_sdk::{prelude::*, alloy_primitives::U256};

#[storage]
#[entrypoint]
pub struct Counter {
    count: StorageU256,
}

#[public]
impl Counter {
    pub fn count(&self) -> U256 {
        self.count.get()
    }

    pub fn increment(&mut self) {
        let v = self.count.get();
        self.count.set(v + U256::from(1));
    }
}

Deploy flow.

cargo install --force cargo-stylus
cargo stylus new my_counter
cd my_counter
cargo stylus check
cargo stylus deploy --private-key $PK --endpoint $RPC

Advantages.

  • Gas efficiency — WASM is far more efficient than the EVM, so math-heavy contracts save 10 to 100 times the gas.
  • Rust ecosystem — use existing Rust crates (BLS, ZK libraries, big-integer crates).
  • C and C++ too — anything that compiles to WASM, in theory.

Disadvantages.

  • Disconnected from the Solidity ecosystem — pieces like OpenZeppelin Contracts need fresh Stylus implementations.
  • Audit pool — Solidity audits are well-established; Stylus audits are still new territory.
  • Arbitrum-only — porting to other L2s is hard.

When Stylus? Math-heavy contracts (ZK verifiers, on-chain ML inference, large numeric workloads). For generic DeFi/NFT, Solidity is still the standard.

15. Metaplex — Solana NFT Standards

OpenSea briefly added Solana NFT support and then pulled out, but Magic Eden anchors a healthy domestic market. The standards come from Metaplex.

The Metaplex Foundation is a non-profit that defines NFT and token standards on Solana. Two core standards.

Token Metadata Program. A standard program that adds metadata (name, symbol, URI, royalties) on top of the SPL Token. An NFT is essentially an SPL Token with supply = 1 plus Token Metadata.

Token Extensions (Token-2022). The next version of SPL Token. Adds transfer hooks, confidential transfer, interest-bearing accounts, and more. Used in NFTs too.

Tools sit at two levels.

Sugar CLI — CLI for managing a Candy Machine (Metaplex's NFT mint infrastructure). Upload a collection, set allowlists, set prices.

sugar create-config
sugar upload
sugar deploy
sugar mint

Umi (Universal Metaplex Interface). TypeScript SDK that calls Metaplex programs. Conceptually similar in role to wagmi.

import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'
import { createV1, mintV1, TokenStandard } from '@metaplex-foundation/mpl-token-metadata'

const umi = createUmi('https://api.devnet.solana.com')
const mint = generateSigner(umi)

await createV1(umi, {
  mint,
  authority: umi.identity,
  name: 'My NFT',
  uri: 'https://arweave.net/...',
  sellerFeeBasisPoints: percentAmount(5.5),
  tokenStandard: TokenStandard.NonFungible,
}).sendAndConfirm(umi)

The NFT market is smaller in 2026, true, but the value of "a standard for expressing on-chain assets" is not gone. Metaplex standards keep showing up in Solana games, memberships, and Real World Assets.

16. Korea — Kakao Klaytn becomes PIO Network, plus Lambda256

Korean Web3 had a big moment during the 2018-2021 ICO/NFT boom, cooled with stricter KYC, the travel rule, and the LUNA collapse, and is being reorganized in 2024-2026 under the ETF era.

Klaytn becomes PIO Network. The Kakao-built EVM L1 Klaytn merged with LINE's Finschia in 2024 to form PIO Network (a.k.a. Kaia). The combined Kakao plus LINE user base has serious potential across Japan, Southeast Asia, and Korea. In 2026 the dApp ecosystem on PIO/Kaia is reforming. KaiaScan (Etherscan-compatible) and the former Klaytn SDK is now the Kaia SDK.

// Calling Kaia (viem-compatible)
import { createPublicClient, http } from 'viem'
import { kaia } from 'viem/chains'

const client = createPublicClient({
  chain: kaia,
  transport: http('https://public-en.node.kaia.io'),
})

Dunamu and Lambda256. Lambda256 is the blockchain subsidiary of Dunamu (the parent of Upbit). It ran the Luniverse BaaS platform, and in 2026 supplies enterprise token issuance, NFT, and STO (Security Token Offering) infrastructure.

Korean STOs. As of 2026 the regulatory framework for security tokens is being phased in, and an institutional issuance market is forming. Dunamu, Pingo, Shinhan, and NH are positioning STO infrastructure.

Korean dApps. OpenSea Korea, Klip (Kakao), MetaMask plus Kaikas, Upbit NFT (now wound down), and Korean gaming chains (Wemade's Wemix, Com2uS's XPLA, Netmarble's MBX) — gaming chains are a defining axis of Korean Web3, mostly aimed globally because of P2E restrictions at home.

KYC and travel-rule infrastructure at Lambda256, Klip, and Kaia Wallet have tightened significantly since 2024, creating friction for Korean users trying to use dApps. Global dApps frequently include a Korea-specific guide or alternate flow.

17. Japan — Astar Network (Sota Watanabe) and Oasys

Japan, like Korea, cooled from its 2018-2021 boom but the government's Web3 policy stance has been more friendly than Korea's. The Kishida administration's Web3 White Paper, the LDP's Web3 Project Team, and the Digital Agency's NFT guidelines all push the same direction.

Astar Network. Founded by Sota Watanabe as a Polkadot parachain. The largest Japanese-led Web3 project in 2026. ASTR token. Supports both EVM and Wasm. Soneium (a Sony Block Solutions Labs and Astar collaboration) is the L2 that launched in 2024.

// Astar / Soneium (EVM)
import { createPublicClient, http } from 'viem'
import { astar, soneium } from 'viem/chains'

const client = createPublicClient({ chain: astar, transport: http() })

Oasys. A gaming-focused chain that launched in 2022. Its differentiator is a validator set drawn from Japanese game companies — Bandai Namco, Square Enix, Sega, Konami, Gree, double jump.tokyo, and others. Verse-layer design that zeroes gas for game dApps.

JPYC. A Japanese yen stablecoin issued since 2021. In 2026 it sees some real domestic use for payments and remittances.

Differences from Korea. Japan has (1) clear government intent to grow Web3 as an industry, (2) direct participation from LINE, Sony, Bandai, and other large enterprises, (3) gradual rationalization of tax rules (the previous system that taxed unrealized gains has been improved). So for Japan-based builders, Astar, Soneium, and Oasys are larger options than PIO Network.

18. Who Should Pick What — A DeFi / NFT / L2 / ZK Decision Tree

A short, honest decision tree to close.

Q1. Which chain are you deploying to?

  • Ethereum mainnet or EVM L2 (Arbitrum, Optimism, Base, zkSync Era, Polygon zkEVM, Linea, Scroll) means EVM/Solidity, go to chapter 2.
  • Solana means Anchor/Rust, go to chapter 6.
  • StarkNet means Cairo, go to chapter 5.
  • Arbitrum with math-heavy contracts means Stylus/Rust, go to chapter 14.

Q2. Hardhat or Foundry on EVM?

  • New project — Foundry. Fast, Solidity-native tests.
  • Existing project or large monorepo (frontend, backend, contracts) — Hardhat 3. Smoothest TS ecosystem fit.
  • Plenty of teams install both. Forge tests, Hardhat Ignition deploys.

Q3. ethers or viem for JS clients?

  • New project — viem. TypeScript-first, small, fast.
  • Existing code on ethers v6 — keep it. Migration cost is not worth it.
  • Do not start with web3.js. Sunsetted.

Q4. wagmi plus which UI?

  • Minimal and fast — ConnectKit.
  • Flashy design — RainbowKit.
  • Solana plus EVM, 600+ wallets — Reown AppKit.

Q5. How far on security tooling?

  • Side project — Slither plus Foundry forge fuzz.
  • Serious protocol — the above plus Echidna, Mythril, Halmos.
  • Mainnet with big TVL — the above plus one or two external audits plus a contest like Code4rena.

Q6. RPC provider?

  • EVM — Alchemy or Infura. Multi-RPC fallback required.
  • Solana — Helius.

Q7. Doing NFTs?

  • EVM — OpenZeppelin ERC721/ERC1155 plus Magic Eden/OpenSea.
  • Solana — Metaplex plus Magic Eden.
  • "The NFT market died" is fair, but the standards keep getting used in memberships, RWAs, and games.

Q8. Korea or Japan as a market?

  • Korea — build on the global EVM/L2 stack and add a Korea-specific user guide. PIO Network only when Kakao exposure is required.
  • Japan — Astar, Soneium, and Oasys are closer to the local market and the regulatory mood is friendlier.

19. References (Web3 is Volatile)

Caveat — Web3 projects pivot or shut down quickly. The links below are valid as of May 2026, but some (especially smaller L2s or SDKs) may be renamed or gone. Always check primary sources.

EVM development tooling

Solana / StarkNet / Stylus

Clients and frontend

Libraries and standards

Security tooling

Monitoring and RPC

L2

Korea and Japan

Further reading

A smart contract is code where a single line can move hundreds of millions. Choosing the right tool for that responsibility is itself safety. Hardhat or Foundry, Solidity or Cairo or Rust, viem or ethers, which RPC, which L2 — these choices together determine a protocol's fate. The 2026 infrastructure is better than ever. Know the tools honestly and pick well.

Discuss on Twitter • View on GitHub