Top 35 Blockchain & Web3 Interview Questions 2026 — Complete Guide with Solutions

Web3 engineers are among the highest-paid developers globally. Mid-level Solidity devs earn ₹20-40 LPA in India; senior protocol engineers command ₹40-80 LPA; and top ZK/cryptography researchers pull $150K-$300K+ USD working remotely. The talent shortage is extreme — there are more funded Web3 companies than qualified engineers to staff them.

Polygon (AggLayer), CoinDCX, WazirX, Mudrex, and dozens of funded DeFi startups are hiring aggressively. With Layer 2 rollups maturing (Optimism, Arbitrum, zkSync, Polygon zkEVM), ERC-4337 account abstraction going mainstream, and ZK proofs entering real applications, the interview bar has risen significantly. This guide covers 35 battle-tested questions across every layer of the stack — from blockchain fundamentals to advanced Solidity security to ZK cryptography — compiled from real interviews at Polygon, CoinDCX, Trail of Bits, and top DeFi protocols.

Related: Cybersecurity Interview Questions 2026 | Golang Interview Questions 2026 | TypeScript Interview Questions 2026

---

Web3 Engineering Roles in 2026

Role	Core Skills	Companies
Smart Contract Engineer	Solidity, Foundry, security, gas optimization	Polygon, Uniswap, Aave
Protocol Engineer	Cryptography, ZK proofs, consensus design	StarkWare, zkSync, Aztec
Blockchain Backend	Ethers.js/viem, indexing (TheGraph), RPC nodes	CoinDCX, WazirX, DeFi protocols
Web3 Frontend	wagmi, RainbowKit, wallet integration	All Web3 product companies
Security Researcher	Smart contract auditing, formal verification	Trail of Bits, OpenZeppelin

---

BEGINNER LEVEL (Questions 1–10)

Q1. How does a blockchain work? Explain the fundamentals.

A blockchain is a distributed, append-only ledger where data is stored in cryptographically linked blocks.

Block structure:

Block N:
┌──────────────────────────────────────────────┐
│ Block Header                                  │
│   Previous Hash: 0x8f3a...                   │
│   Merkle Root: 0xd4e2...                     │
│   Timestamp: 1711720800                       │
│   Nonce: 3984720 (PoW) / Validator Sig (PoS) │
│   Block Number: N                             │
├──────────────────────────────────────────────┤
│ Transactions: [tx1, tx2, tx3, ...]           │
│ (ordered by gas price / MEV)                 │
└──────────────────────────────────────────────┘
         │
         └── Hash of Block N → Previous Hash of Block N+1

Why it's tamper-resistant: Changing data in Block N changes its hash, which invalidates Block N+1's Previous Hash, cascading through the entire chain. An attacker would need to recompute all subsequent blocks AND control 51%+ of the network simultaneously.

Key properties:

• Decentralization: No single controlling entity
• Immutability: Historical records cannot be altered
• Transparency: All transactions publicly verifiable
• Consensus: Nodes agree on the canonical chain state

---

Q2. What is Proof of Work vs Proof of Stake?

	Proof of Work (PoW)	Proof of Stake (PoS)
Consensus method	Computational puzzle (hash below target)	Validators stake collateral
Energy	High (electricity)	Low (~99.95% less than PoW)
Security model	51% hash rate attack	51% staked ETH attack
Finality	Probabilistic	Economic (slashing)
Hardware	ASICs, GPUs	Any computer
Examples	Bitcoin	Ethereum (post-Merge), Solana, Cardano
Block reward	Mining reward	Staking reward

Ethereum's Merge (September 2022): Ethereum transitioned from PoW to PoS, reducing energy consumption by 99.95%. Validators stake 32 ETH to participate in consensus. Slashing penalizes validators for equivocation or downtime.

Delegated PoS (DPoS): Token holders vote for validators (delegates). Used by EOS, TRON. More centralized but higher throughput.

---

Q3. What is a smart contract?

A smart contract is self-executing code stored on a blockchain that automatically enforces and executes agreement terms when predetermined conditions are met.

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

// A simple escrow contract
contract Escrow {
    address public buyer;
    address public seller;
    address public arbiter;
    uint256 public amount;
    bool public released;

    constructor(address _seller, address _arbiter) payable {
        buyer = msg.sender;
        seller = _seller;
        arbiter = _arbiter;
        amount = msg.value;
    }

    function release() external {
        require(msg.sender == buyer || msg.sender == arbiter, "Not authorized");
        require(!released, "Already released");
        released = true;
        payable(seller).transfer(amount);
    }

    function refund() external {
        require(msg.sender == arbiter, "Only arbiter");
        require(!released, "Already released");
        released = true;
        payable(buyer).transfer(amount);
    }
}

Properties:

• Deterministic (same input → same output, always)
• Transparent (code is on-chain, visible to all)
• Trustless (no intermediary needed)
• Immutable (once deployed, code cannot change — unless using proxy patterns)

---

Q4. What is Ethereum's account model?

Ethereum has two account types:

	Externally Owned Account (EOA)	Contract Account
Controlled by	Private key	Smart contract code
Can initiate tx	Yes	No (only respond)
Has code	No	Yes
Gas for creation	Cheap	Expensive
Examples	MetaMask wallet	Uniswap, Aave

Account state:

• balance: ETH in Wei
• nonce: number of transactions sent (prevents replay)
• codeHash: keccak256 of contract bytecode (EOA has empty hash)
• storageRoot: Merkle root of contract storage

Transaction fields: nonce, gasPrice/maxFeePerGas, gasLimit, to, value, data, signature (v, r, s).

---

Q5. What is the EVM (Ethereum Virtual Machine)?

The EVM is a stack-based virtual machine that executes smart contract bytecode. It is:

• Deterministic: same input → same output on all nodes
• Sandboxed: isolated from the host system
• Turing-complete: can compute any computable function (bounded by gas)
• 256-bit word size: all stack items are 32 bytes

Gas: unit measuring computational effort. Every EVM opcode has a fixed gas cost. SSTORE (write to storage) is expensive (~20,000 gas). ADD is cheap (3 gas). Gas prevents infinite loops.

EIP-1559 (London fork): Split gas price into baseFee (burned, set by protocol) + priorityFee (tip to validator). Made fee estimation predictable.

---

Q6. What are the main Solidity data types and storage locations?

pragma solidity ^0.8.20;

contract DataTypes {
    // Value types — stored by value
    uint256 public count;          // 0 to 2^256-1
    int256 public temperature;     // negative to positive
    bool public active;
    address public owner;
    bytes32 public hash;

    // Reference types — need storage location
    uint256[] public numbers;      // dynamic array
    mapping(address => uint256) public balances;
    string public name;

    // Storage locations:
    // storage: persistent on blockchain (expensive)
    // memory: temporary, within function call (cheap)
    // calldata: read-only, function parameters from external call (cheapest)

    function processArray(uint256[] calldata input) external pure
        returns (uint256[] memory output)
    {
        output = new uint256[](input.length);
        for (uint i = 0; i < input.length; i++) {
            output[i] = input[i] * 2;
        }
    }

    // Custom types
    enum Status { Pending, Active, Closed }
    struct Order {
        address buyer;
        uint256 amount;
        Status status;
    }
    Order[] public orders;
}

---

Q7. What is an ERC-20 token?

ERC-20 is the standard interface for fungible tokens on Ethereum.

// Core ERC-20 interface
interface IERC20 {
    function totalSupply() external view returns (uint256);
    function balanceOf(address account) external view returns (uint256);
    function transfer(address to, uint256 amount) external returns (bool);
    function allowance(address owner, address spender) external view returns (uint256);
    function approve(address spender, uint256 amount) external returns (bool);
    function transferFrom(address from, address to, uint256 amount) external returns (bool);

    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed owner, address indexed spender, uint256 value);
}

ERC-20 vs ERC-721 vs ERC-1155:

	ERC-20	ERC-721	ERC-1155
Token type	Fungible	Non-fungible (NFT)	Multi-token (fungible + NFT)
Uniqueness	Identical units	Each token unique	Mix of both
Examples	USDC, WETH, UNI	CryptoPunks, Bored Apes	Gaming items
Gas	Efficient	Higher	Most efficient for batch

---

Q8. What is gas optimization in Solidity?

Gas optimization reduces the cost of deploying and using smart contracts.

// GAS OPTIMIZATION TECHNIQUES

// 1. Pack storage variables (same slot = 32 bytes)
// BAD: 3 separate slots
contract Unoptimized {
    uint256 a;  // slot 0
    uint128 b;  // slot 1
    uint128 c;  // slot 2
}

// GOOD: b and c share a slot
contract Optimized {
    uint256 a;  // slot 0
    uint128 b;  // slot 1
    uint128 c;  // slot 1 (packed with b!)
}

// 2. Use calldata instead of memory for read-only params
// BAD
function sum(uint256[] memory numbers) external pure returns (uint256) { }
// GOOD
function sum(uint256[] calldata numbers) external pure returns (uint256) { }

// 3. Cache storage reads
// BAD: reads from storage twice (expensive SLOAD)
function bad() external {
    if (balances[msg.sender] > 100) {
        emit Log(balances[msg.sender]);
    }
}
// GOOD: single SLOAD, cached in memory
function good() external {
    uint256 balance = balances[msg.sender]; // one SLOAD
    if (balance > 100) {
        emit Log(balance);
    }
}

// 4. Use custom errors instead of strings
// BAD: string stored in bytecode, expensive
require(balance >= amount, "Insufficient balance");

// GOOD: 4 bytes selector only
error InsufficientBalance(uint256 available, uint256 required);
if (balance < amount) revert InsufficientBalance(balance, amount);

// 5. Short-circuit logic (cheap check first)
require(amount > 0 && balances[msg.sender] >= amount); // wrong order
require(amount > 0 && balances[msg.sender] >= amount); // amount > 0 is cheap MLOAD

---

Q9. What are Ethereum Layer 2 solutions?

Layer 2 (L2) solutions scale Ethereum by processing transactions off-chain and posting proofs to Layer 1.

Type	How it works	Finality	Trust assumption	Examples
Optimistic Rollup	Assume valid; 7-day fraud proof window	~1 week (challenge period)	1 honest validator	Optimism, Arbitrum
ZK Rollup	Cryptographic validity proof	Minutes (proof generation)	Math (no trust needed)	zkSync Era, StarkNet, Polygon zkEVM
State Channel	Off-chain bilateral txs, settle on L1	Instant	Counterparty online	Lightning Network (BTC)
Plasma	Child chains with fraud proofs	Days	Operator honest	Mostly deprecated
Validium	ZK proof + off-chain data	Minutes	Data availability operator	StarkEx

ZK Rollups are winning in 2026: better security guarantees, faster finality, and increasingly competitive prover costs due to hardware acceleration.

---

Q10. What is DeFi? Explain key protocols.

DeFi (Decentralized Finance) is financial services built on public blockchains without centralized intermediaries.

Protocol	Category	Mechanism
Uniswap v4	DEX (AMM)	Constant product formula x*y=k, hooks
Aave v3	Lending	Overcollateralized loans, interest rate model
Compound	Lending	cTokens, algorithmic rates
Curve	Stablecoin AMM	StableSwap invariant for low slippage
MakerDAO	CDP/Stablecoin	ETH collateral → DAI stablecoin
Lido	Liquid Staking	stETH: liquid representation of staked ETH
Pendle	Yield trading	Separate yield from principal

AMM formula (Uniswap v2):

x * y = k  (constant product)

Price of token X = y / x
After swap of dx:
(x + dx) * (y - dy) = k
dy = y - k/(x + dx) = y*dx/(x + dx)

Slippage increases as dx approaches x (pool liquidity)

---

Solid on Q1-Q10? You understand blockchain better than 80% of "Web3 developers" out there. The intermediate section covers the Solidity security, DeFi mechanics, and L2 knowledge that actual hiring managers test for.

INTERMEDIATE LEVEL — Proven Interview Questions (Questions 11–25)

Q11. What are common smart contract vulnerabilities?

Reentrancy (most famous — caused the DAO hack, $60M, 2016):

// VULNERABLE
contract VulnerableVault {
    mapping(address => uint256) public balances;

    function withdraw() external {
        uint256 amount = balances[msg.sender];
        require(amount > 0, "No balance");

        // External call BEFORE state update — attacker can re-enter!
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success);

        balances[msg.sender] = 0; // Too late! Already drained
    }
}

// SECURE: Checks-Effects-Interactions pattern
contract SecureVault {
    mapping(address => uint256) public balances;
    bool private locked;

    modifier nonReentrant() {
        require(!locked, "Reentrant call");
        locked = true;
        _;
        locked = false;
    }

    function withdraw() external nonReentrant {
        uint256 amount = balances[msg.sender];
        require(amount > 0, "No balance");

        balances[msg.sender] = 0;  // Effect FIRST

        (bool success, ) = msg.sender.call{value: amount}(""); // Interact LAST
        require(success, "Transfer failed");
    }
}

Other critical vulnerabilities:

Vulnerability	Example	Mitigation
Integer overflow	Balance wraps from 0 to max	Solidity 0.8+ checks by default; use unchecked carefully
Front-running	Attacker sees pending tx, submits higher gas	Commit-reveal scheme, private mempools
Tx.origin auth	require(tx.origin == owner)	Use msg.sender
Uninitialized storage	Proxy storage collision	OpenZeppelin storage layout patterns
Signature replay	Reuse valid signature across chains	Include chainId, nonce in signed message
Oracle manipulation	Flash loan to manipulate price → liquidate	TWAP oracles, Chainlink price feeds
Access control	Missing onlyOwner on sensitive function	OpenZeppelin AccessControl

---

Q12. What is a proxy pattern and why is it used?

Smart contracts are immutable by default. Proxy patterns enable upgradeable smart contracts.

User → [Proxy Contract] → delegatecall → [Implementation Contract]
         (stores state)                   (contains logic)

delegatecall: executes callee's code in caller's context (uses caller's storage, msg.sender, msg.value).

// Minimal ERC-1967 Transparent Proxy
contract TransparentProxy {
    // ERC-1967 storage slot for implementation address
    bytes32 private constant IMPLEMENTATION_SLOT =
        0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;

    constructor(address _impl, bytes memory _data) {
        _setImplementation(_impl);
        if (_data.length > 0) {
            (bool success,) = _impl.delegatecall(_data);
            require(success, "Init failed");
        }
    }

    fallback() external payable {
        address impl = _getImplementation();
        assembly {
            calldatacopy(0, 0, calldatasize())
            let result := delegatecall(gas(), impl, 0, calldatasize(), 0, 0)
            returndatacopy(0, 0, returndatasize())
            switch result
            case 0 { revert(0, returndatasize()) }
            default { return(0, returndatasize()) }
        }
    }
}

Proxy patterns:

• Transparent Proxy: admin calls proxy, users get delegated to impl
• UUPS (ERC-1822): upgrade logic in implementation (gas efficient)
• Beacon Proxy: multiple proxies share one beacon, upgrade all at once
• Diamond/EIP-2535: multiple implementation contracts (facets)

---

Q13. What is MEV (Maximal Extractable Value)?

MEV is the maximum value that can be extracted from block production beyond standard block rewards, through inclusion, exclusion, or reordering of transactions.

MEV strategies:

Strategy	Description	Example
Arbitrage	Exploit price differences between DEXs	ETH cheaper on Uniswap than Curve → buy/sell
Liquidations	Liquidate undercollateralized loans first	Aave liquidation bonuses
Sandwich attack	Front-run + back-run a large DEX swap	See large swap → buy before, sell after
JIT Liquidity	Add/remove LP just around one transaction	Concentrated Uniswap v3 position

Sandwich attack example:

1. Attacker sees victim's tx: swap 100 ETH for USDC
2. Attacker front-runs: buy USDC with ETH (raises price)
3. Victim's tx executes at higher price (bad for victim)
4. Attacker back-runs: sell USDC back to ETH (profit)

MEV mitigations:

• Flashbots/MEV Blocker: private mempools for users
• Slippage tolerance limits
• Commit-reveal ordering
• PBS (Proposer-Builder Separation) in Ethereum post-Merge

---

Q14. What is ERC-4337 (Account Abstraction)?

ERC-4337 enables smart contract wallets without changing the Ethereum protocol. It removes the requirement for EOAs to initiate transactions.

Core components:

• UserOperation: a pseudo-transaction object (not a real L1 tx)
• Bundler: collects UserOperations and submits them as a regular tx
• EntryPoint: singleton contract that validates and executes UserOps
• Paymaster: sponsors gas fees on behalf of users
• Account: the smart contract wallet itself

// Simplified UserOperation structure
struct UserOperation {
    address sender;           // smart account address
    uint256 nonce;
    bytes initCode;           // deploy new account if needed
    bytes callData;           // what to execute
    uint256 callGasLimit;
    uint256 verificationGasLimit;
    uint256 preVerificationGas;
    uint256 maxFeePerGas;
    uint256 maxPriorityFeePerGas;
    bytes paymasterAndData;   // optional paymaster
    bytes signature;          // user's authorization
}

What account abstraction enables:

• Social recovery: recover account with guardian approvals instead of seed phrase
• Batch transactions: approve + swap in one click
• Gas sponsorship: dApp pays gas for users (onboarding)
• Session keys: limited-time keys for gaming
• Multi-sig UX: arbitrary signature schemes (passkeys, biometrics)
• Spending limits: built into wallet

---

Q15. Explain ZK Proofs in the context of blockchain.

A Zero-Knowledge Proof (ZKP) lets a prover convince a verifier that a statement is true without revealing any information beyond the statement's truth.

Properties:

• Completeness: honest prover can always convince verifier
• Soundness: dishonest prover cannot convince verifier (with negligible probability)
• Zero-knowledge: verifier learns nothing beyond the statement's truth

ZK proof systems:

System	Proof size	Verification time	Trusted setup	Used in
Groth16	~200 bytes	~10ms	Yes	Tornado Cash, ZCash
PLONK	~500 bytes	~50ms	Universal	zkSync, Aztec
STARKs	~40-200KB	~100ms	No	StarkNet, Polygon Miden
FRI-based	Variable	Variable	No	StarkWare

Applications:

// ZK Rollup verification (simplified)
// Prover (off-chain): I executed 1000 transactions correctly
// Proof: here is a 200-byte proof that this is true
// Verifier (on-chain): verifies proof in ~300,000 gas instead of ~100M gas
// Result: 333x cheaper on-chain verification

Real-world ZK applications:

• Private transactions (Tornado Cash, Aztec)
• Identity (Proof of humanity without revealing identity)
• ZK Rollup batch verification
• zkBridge (cross-chain with cryptographic security)
• zkML (prove ML model inference was done correctly)

---

Q16. What is a reentrancy guard and the Checks-Effects-Interactions pattern?

Already covered in Q11. CEI pattern is the most important defense pattern:

function withdraw(uint256 amount) external {
    // 1. CHECKS — all validation first
    require(amount > 0, "Amount must be positive");
    require(balances[msg.sender] >= amount, "Insufficient balance");

    // 2. EFFECTS — update state before any external calls
    balances[msg.sender] -= amount;
    totalSupply -= amount;
    emit Withdrawal(msg.sender, amount);

    // 3. INTERACTIONS — external calls last
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success, "ETH transfer failed");
}

OpenZeppelin's ReentrancyGuard provides nonReentrant modifier as belt-and-suspenders defense alongside CEI.

---

Q17. What are flash loans and how are they used?

Flash loans let you borrow any amount of assets with zero collateral, as long as you repay within the same transaction.

// Aave v3 flash loan interface
interface IFlashLoanReceiver {
    function executeOperation(
        address[] calldata assets,
        uint256[] calldata amounts,
        uint256[] calldata premiums,
        address initiator,
        bytes calldata params
    ) external returns (bool);
}

contract FlashLoanArbitrage is IFlashLoanReceiver {
    IPool public aavePool;

    function executeArbitrage(address token, uint256 amount) external {
        aavePool.flashLoan(
            address(this),
            token,
            amount,
            abi.encode(/* params for our executeOperation */)
        );
    }

    function executeOperation(
        address[] calldata assets,
        uint256[] calldata amounts,
        uint256[] calldata premiums,
        address,
        bytes calldata
    ) external override returns (bool) {
        // We have `amounts[0]` of `assets[0]` now
        // Execute arbitrage: buy on Uniswap, sell on Curve
        uint256 profit = _doArbitrage(assets[0], amounts[0]);

        // Must repay amounts[0] + premiums[0] by end of this tx
        uint256 repayAmount = amounts[0] + premiums[0];
        require(profit > premiums[0], "No profit");

        IERC20(assets[0]).approve(address(aavePool), repayAmount);
        return true;
    }
}

Legitimate uses: arbitrage, self-liquidation, collateral swaps. Attack uses: price manipulation, governance attacks (borrow → vote → repay).

---

Q18. What is Uniswap v4 and what are hooks?

Uniswap v4 (released late 2024) introduced major architectural changes:

Hooks: custom logic that executes at specific pool lifecycle points.

// Hook points
interface IHooks {
    function beforeInitialize(address, PoolKey calldata, uint160) external returns (bytes4);
    function afterInitialize(address, PoolKey calldata, uint160, int24) external returns (bytes4);
    function beforeAddLiquidity(address, PoolKey calldata, IPoolManager.ModifyLiquidityParams calldata, bytes calldata) external returns (bytes4);
    function afterAddLiquidity(...) external returns (bytes4, BalanceDelta);
    function beforeSwap(address, PoolKey calldata, IPoolManager.SwapParams calldata, bytes calldata) external returns (bytes4, BeforeSwapDelta, uint24);
    function afterSwap(...) external returns (bytes4, int128);
    // + remove liquidity hooks, donate hooks
}

Hook use cases:

• Dynamic fees (increase fee during volatility)
• TWAP oracles built into the pool
• Limit orders (execute when price reaches target)
• Custom liquidity shapes
• Automated liquidity rebalancing (like Arrakis)
• Protocol-owned liquidity

Singleton architecture: all Uniswap v4 pools live in one contract (PoolManager), reducing gas for multi-hop swaps by ~40%.

Flash accounting: ERC-6909 claim tokens settle net balances at end of transaction.

---

Q19. What is the AggLayer (Polygon 2.0)?

Polygon's AggLayer is a decentralized protocol for aggregating ZK proofs from multiple chains, enabling near-instant cross-chain interoperability with unified bridge security.

Architecture:

Chain A (ZK proof) ─┐
Chain B (ZK proof) ──┤→ AggLayer → Aggregated Proof → Ethereum L1
Chain C (ZK proof) ─┘

Key innovation: pessimistic proof — the aggregated proof validates that no chain can drain more assets than it deposited, even if individual chain proofs are wrong. This provides Ethereum-level security for cross-chain transfers without requiring each chain to trust others.

---

Q20. Explain the Ethereum roadmap: Danksharding and Proto-Danksharding.

EIP-4844 (Proto-Danksharding, Cancun upgrade, 2024):

• Introduced blob-carrying transactions
• Blobs: large (128 KB) data fields that are cheap to post but expire after ~18 days
• Reduced L2 data costs by ~10x
• L2 rollups use blobs to post compressed transaction data

Without EIP-4844: L2 posts data as calldata → 1 byte = 16 gas
With EIP-4844: L2 posts data as blob → 1 byte ≈ 1-2 gas

Full Danksharding (future):

• 64 blobs per block (vs 3-6 in EIP-4844)
• Data availability sampling (DAS): light nodes verify availability without downloading all data
• Will enable millions of TPS across all L2s combined

---

Q21–Q25: Quick Intermediate Round

Q21. What is a multisig wallet and why are they used? A multisig (multiple signature) wallet requires M-of-N signatures to execute a transaction. Example: 3-of-5 means any 3 of 5 key holders must sign. Used by DAOs, protocol treasuries, and exchanges to prevent single point of failure. Gnosis Safe is the standard. With ERC-4337, multisig logic is native to smart account wallets.

Q22. What is slippage and how does Uniswap handle it? Slippage is the difference between expected and actual price in an AMM trade, caused by pool depth relative to trade size. Uniswap allows setting amountOutMinimum — if the actual output is below this, the transaction reverts. The formula: slippage% = tradeSize / (poolReserve * 2).

Q23. What are ERC-721 royalties (EIP-2981)? EIP-2981 is a standard for on-chain royalty information. NFT contracts return (receiver, royaltyAmount) for a given tokenId and sale price. However, enforcement is off-chain — marketplaces choose whether to honor it. Blur's rise highlighted this weakness as it made royalties optional.

Q24. What is a DAO and how does governance work? A DAO (Decentralized Autonomous Organization) is governed by token holders via on-chain proposals and voting. Flow: proposal creation (requires minimum tokens) → voting period (e.g., 3 days) → if quorum met and passes → timelock delay (e.g., 48 hours) → execution. Compound's Governor Bravo is the reference implementation.

Q25. What is the difference between IPFS and Arweave for NFT storage? IPFS is content-addressed peer-to-peer storage — content is identified by its hash, but availability depends on nodes pinning it (ephemeral unless pinned). Arweave is permanent, pay-once storage with a cryptoeconomic endowment model. NFT projects should use Arweave for truly permanent metadata. Filecoin adds economic incentives to IPFS.

---

If you can answer Q1-Q25 confidently, you're hireable at most Web3 companies. The advanced section is where ₹50 LPA+ protocol engineer and security researcher offers are decided — ZK proofs, MEV extraction, and smart contract auditing.

ADVANCED LEVEL — The Protocol Engineer Round (Questions 26–35)

Q26. How do you audit a smart contract?

Audit process:

1. Scope review: understand the protocol's intended behavior, read docs, whitepaper
2. Static analysis: Slither, Mythril, Semgrep for Solidity
3. Manual review: line-by-line with these categories:
   • Access control: who can call what?
   • State transitions: can state get into invalid/stuck states?
   • Arithmetic: over/underflow, precision loss
   • External calls: reentrancy, return values checked?
   • Oracle dependencies: manipulation resistant?
   • Economic attacks: flash loan attack surfaces?
4. Invariant testing: fuzz with Foundry/Echidna
5. Formal verification: Certora Prover, Halmos (symbolic execution)

// Invariant testing with Foundry
contract VaultInvariantTest is Test {
    Vault vault;

    function setUp() public {
        vault = new Vault();
        targetContract(address(vault));
    }

    // Invariant: sum of all user balances == contract's ETH balance
    function invariant_solvency() public {
        assertEq(vault.totalDeposits(), address(vault).balance);
    }

    // Invariant: user can never withdraw more than they deposited
    function invariant_noOverWithdraw() public {
        assertGe(address(vault).balance, 0);
    }
}

---

Q27. What is the EigenLayer restaking protocol?

EigenLayer allows ETH stakers to "restake" their staked ETH (or LSTs) to provide security to other protocols (Actively Validated Services — AVS) and earn additional rewards.

Architecture:

ETH stakers stake → restake via EigenLayer → provide security to:
  - EigenDA (data availability layer)
  - zkBridge verifiers
  - Oracle networks
  - Cross-chain bridges
  - Decentralized sequencers

Key innovation: pooled security — new protocols can borrow Ethereum's economic security (~$50B staked ETH) without bootstrapping their own validator set. The trade-off: slashing conditions multiply (get slashed by ETH PoS AND the AVS).

---

Q28. How do Optimistic vs ZK Rollups handle fraud/validity proofs?

Optimistic Rollup (Arbitrum, Optimism):

1. Sequencer posts state root to L1 (optimistically assumed valid)
2. 7-day challenge period
3. Anyone can submit fraud proof:
   - Point to the specific step that's wrong
   - L1 re-executes that single step
   - If verifier finds fraud: slashes sequencer, rolls back state
4. After 7 days with no challenge: finality

ZK Rollup (zkSync, StarkNet):

1. Prover generates SNARK/STARK proof of correct execution
2. Proof submitted to L1 verifier contract
3. L1 verifies proof (~300K gas for any batch size)
4. Immediate cryptographic finality

Why ZK is winning for new L2s:

• No 7-day withdrawal delay
• Mathematical security (no honest challenger required)
• Better for high-frequency use cases (gaming, trading)
• But: higher proving costs, longer latency per batch

---

Q29. What is Chainlink and how do price oracles work?

Oracles bring off-chain data on-chain. Price manipulation via oracles is responsible for hundreds of millions in DeFi exploits.

// Chainlink Data Feed — production-safe price oracle
import "@chainlink/contracts/src/v0.8/interfaces/AggregatorV3Interface.sol";

contract PriceConsumer {
    AggregatorV3Interface internal priceFeed;

    constructor() {
        // ETH/USD on Ethereum mainnet
        priceFeed = AggregatorV3Interface(0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419);
    }

    function getLatestPrice() public view returns (int256) {
        (
            uint80 roundId,
            int256 price,
            uint256 startedAt,
            uint256 updatedAt,
            uint80 answeredInRound
        ) = priceFeed.latestRoundData();

        // Staleness check — don't use stale prices
        require(updatedAt >= block.timestamp - 3600, "Price is stale");
        require(answeredInRound >= roundId, "Stale round");
        require(price > 0, "Invalid price");

        return price; // 8 decimals
    }
}

// TWAP oracle — manipulation resistant for on-chain use
// Uniswap v3 TWAP: cumulative price sum / time window
// Hard to manipulate (need to hold price across multiple blocks)

---

Q30. What are ZK-SNARKs vs ZK-STARKs?

	zk-SNARKs	zk-STARKs
Full form	Succinct Non-interactive Arguments of Knowledge	Scalable Transparent ARguments of Knowledge
Proof size	~200 bytes	40–200 KB
Verification	Fast	Fast
Prover time	Fast	Faster (no pairing ops)
Trusted setup	Required (toxic waste)	Not required
Quantum resistant	No (relies on elliptic curves)	Yes (hash functions)
Used by	Groth16: Tornado Cash; PLONK: zkSync	StarkNet, Polygon Miden

Trusted setup concern: SNARKs require a trusted setup ceremony. If the "toxic waste" (secret parameters) is not destroyed, the prover could forge proofs. PLONK uses a universal trusted setup (one ceremony for all circuits of any size).

---

Q31. Real-World Scenario: Design a cross-chain bridge with ZK proofs.

Architecture:

Source Chain (Ethereum)
    ↓ User locks tokens in Escrow contract
    ↓ Emits event with: amount, recipient, nonce, chainId

ZK Prover (off-chain)
    ↓ Receives event data
    ↓ Generates proof: "I know a valid inclusion proof for this event
       in the source chain's state tree at block N"

Destination Chain (Polygon)
    ↓ Verifier contract checks ZK proof
    ↓ If valid: mint wrapped tokens to recipient
    ↓ Nonce stored to prevent replay

Security considerations:

• Include destination chainId in the ZK circuit inputs (prevent replay across chains)
• Liveness: what if prover goes offline? Need fallback sequencer
• Block finality: wait for sufficient finality on source chain before generating proof
• Emergency pause: admin pause in case of critical bug

---

Q32–Q35: Advanced Quick Fire

Q32. What is Verkle Trees and why Ethereum is migrating to them? Verkle Trees replace Ethereum's Merkle Patricia Trie in the Verge upgrade. They use polynomial commitments (KZG) instead of hash-based Merkle proofs. Key benefit: witness size drops from ~3MB (Merkle) to ~200KB (Verkle), enabling stateless clients. Light nodes can verify state without storing the full state trie.

Q33. What is EIP-3074 vs ERC-4337? EIP-3074 added two new EVM opcodes (AUTH and AUTHCALL) that let an EOA authorize a smart contract to act on its behalf, enabling batched transactions and gas sponsorship without deploying a new account. However, it was superseded by EIP-7702 (Pectra upgrade) which allows EOAs to temporarily set their code, achieving similar goals more cleanly. ERC-4337 remains the standard for full smart account functionality.

Q34. How does Tornado Cash work and why was it sanctioned? Tornado Cash is a non-custodial privacy protocol using zk-SNARKs. User deposits exactly 1 ETH and gets a cryptographic note. Later (from a fresh address), they provide a ZK proof that they possess a valid note without revealing which deposit it corresponds to. OFAC sanctioned the protocol's smart contract addresses in 2022 — a precedent-setting action that conflated immutable code with money laundering. The case highlighted unresolved legal questions around open-source code and protocol-level privacy.

Q35. What is the future of Web3 in India — opportunities and challenges? Opportunities: CBDC infrastructure (digital rupee), asset tokenization (SEBI framework emerging), Web3 gaming (significant Indian developer base), KYC/identity on-chain (Aadhaar ZK proofs research). Challenges: regulatory uncertainty (RBI stance, crypto taxation at 30%+1%), lack of institutional on-ramps, talent pipeline thin for ZK/cryptography. Best bets for 2026: protocol-agnostic infrastructure (oracles, data availability, bridges), identity solutions, and exchanges expanding into DeFi.

---

Common Smart Contract Mistakes and Attack Patterns

Mistake	Impact	Fix
Missing access control	Critical — anyone can call admin function	onlyOwner, AccessControl
Reentrancy	Critical — drain funds	CEI pattern + ReentrancyGuard
tx.origin auth	High — phishing attack	Use msg.sender
Unsafe external call	High — silent failure	Check return values
Integer overflow (pre-0.8)	High	SafeMath or Solidity 0.8+
Incorrect event emission	Medium — off-chain data wrong	Always emit on state change
Hardcoded gas	Medium — breaks after EIPs	Don't hardcode gas amounts
Front-running vulnerability	Medium — sandwich attacks	Commit-reveal, slippage limits
Centralization risk	Medium — admin key	Multi-sig, timelock
Missing pause mechanism	Medium	Emergency pause for critical bugs

---

FAQ — Your Web3 Career Questions, Answered Honestly

Q: Do I need to know Rust for blockchain development? For Solana/Near/Polkadot substrate development, yes — Rust is primary. For Ethereum/EVM development, Solidity is primary, Vyper as alternative. Knowing Rust is a huge plus for protocol engineering roles.

Q: What is the best way to learn smart contract security? Study all past major hacks (rekt.news). Practice on Ethernaut (OpenZeppelin), Damn Vulnerable DeFi. Read all OpenZeppelin audit reports. Then attempt Code4rena or Sherlock contest audits.

Q: Is it worth getting certifications in blockchain? For India, certifications matter less than a public portfolio. Contribute to open source (OpenZeppelin, Protocol repos), participate in audit contests (Code4rena, Sherlock), write a technical blog. A finding in a public audit is worth more than any certification.

Q: What tools should a Solidity developer know? Foundry (testing + fuzzing + deployment), Hardhat (JavaScript-friendly alternative), OpenZeppelin Contracts (standard implementations), Slither (static analysis), Tenderly (debugging, monitoring), Etherscan (verification), IPFS/Arweave (storage).

Q: What is the salary for blockchain engineers in India? Junior Smart Contract Dev: ₹12–20 LPA. Mid-level: ₹20–40 LPA. Senior Protocol Engineer: ₹40–80 LPA. Top ZK/protocol researchers: $150K–$300K+ (USD, remote from Indian companies).

Q: What is the difference between a token and a coin? A coin (ETH, BTC, SOL) is the native currency of a blockchain. A token is built on top of a blockchain using smart contracts (ERC-20 tokens like USDC, UNI on Ethereum). Tokens don't have their own blockchain.

Q: How do you handle private keys in production Web3 applications? Never hardcode private keys. Use hardware signing (AWS KMS, HashiCorp Vault + HSM) for server-side signing. For non-custodial apps, keys never leave the user's device. Use EIP-712 structured data signing to be transparent about what users are signing.

Q: What is the gas cost of common Solidity operations? SSTORE (new value): 20,000 gas. SSTORE (update existing): 2,900 gas. SLOAD: 2,100 gas (cold) / 100 (warm). Transfer (simple ETH send): 21,000 gas. ERC-20 transfer: ~45,000 gas. ETH/USDC Uniswap v3 swap: ~100,000–150,000 gas.

---

Preparation path: Read Mastering Ethereum → complete Ethernaut → build a DeFi clone (Uniswap v2, Aave simplified) from scratch → participate in Code4rena audits → contribute to EIPs or protocol repos. The best blockchain engineers build things in public.

Web3 is still early innings. The engineers who master these fundamentals now will be the CTOs and protocol leads of 2030. Bookmark this, build in public, and start your audit contest journey.

Related Articles:

• Cybersecurity Interview Questions 2026 — smart contract security is cybersecurity
• TypeScript Interview Questions 2026 — Web3 frontends run on TypeScript + wagmi
• Golang Interview Questions 2026 — blockchain node implementations use Go
• System Design Interview Guide 2026