Scenario-Based Blockchain Interview Questions

Usually no. Employee records are owned by one organisation, change often and contain personal data that must be correctable and deletable under the DPDP Act 2023. A normal database with role-based access and audit logs is cheaper, faster and compliant. I would ask who else needs to trust the data. If several employers or background-check agencies must verify certificates, I would store only hashes of credentials on a permissioned chain and keep the actual data off-chain.

I would use a permissioned or low-cost chain where farmers, transporters, warehouses and retailers are known members. On-chain I would record batch IDs, ownership handovers, timestamps, signer identity and hashes of certificates or sensor data. Large documents, images and IoT streams stay off-chain in object storage or IPFS, referenced by hash. QR codes on packs link consumers to the trail. The main risk is bad input data, so I would add signed device readings and audits.

First check it on a block explorer: if it is not found, it was never broadcast. If pending, the fee is probably below current market rates, or an earlier transaction with a lower nonce is stuck and blocking it. On Ethereum you fix it by sending a replacement with the same nonce and a higher max fee and priority fee, or cancel by sending zero ETH to yourself with that nonce. Then make the wallet estimate fees dynamically.

Do not put personal data on a public chain. Data there is permanent, public and replicated globally, which conflicts with the right to erasure under India's DPDP Act and GDPR, and storage is extremely expensive. Store documents encrypted in off-chain storage, keep only a salted hash or commitment on-chain for integrity, and control access through the application. If the data must be deleted, delete the off-chain copy and the encryption key; the hash alone reveals nothing.

For shared KYC among regulated banks I would lean to a permissioned framework such as Hyperledger Fabric or a private EVM network. Members are known, data is confidential, and regulators expect access control and data residency in India. Fabric channels and private data collections restrict who sees what, and Raft ordering gives fast finality without gas fees. A public chain or L2 fits only if we need open verification, and even then only hashes and attestations would go on it.

Credit deposits only after enough confirmations for the chain's risk profile, and on Ethereum prefer waiting for finalized or at least safe block tags rather than the latest block. Make the deposit indexer reorg-aware: track block hashes, detect when a parent hash changes, roll back credits from orphaned blocks and reprocess. Scale required confirmations with deposit size, and alert on unusually deep reorgs on smaller chains, which can signal a 51 percent attack.

No. In a self-custody wallet, nobody, including the developer, can recover a lost private key; deriving it from the address is computationally impossible. If they still have the seed phrase, the wallet can be restored on any compatible app. To reduce future risk, suggest a hardware wallet, a written seed phrase stored in two safe locations, or a smart contract wallet with social recovery or passkeys, where trusted guardians can rotate the signing key.

Keep a small float, around a few percent of assets, in hot wallets for withdrawals, secured by HSMs or MPC with rate limits, address allowlists and automated monitoring. Keep the rest in cold storage: air-gapped or multisig/MPC with keys held by different officers in different locations, plus time delays. Refill hot wallets through a manual, multi-approver process. Add proof of reserves, regular key ceremonies, insurance, and incident runbooks for freezing withdrawals if anomalies appear.

Use off-chain signed approvals. With EIP-2612 permit, the user signs a typed EIP-712 message granting an allowance, and the dApp submits it with the trade in one transaction, so no separate approve call is needed. For tokens without permit, Permit2-style contracts give the same experience after one approval. EIP-712 shows readable fields in the wallet, reducing phishing risk. Always include a nonce, deadline, chain ID and verifying contract to prevent replays.

Build a Merkle tree off-chain from the allowlisted addresses (hashing each leaf, ideally double-hashed with amounts if needed) and store only the 32-byte root in the contract. Each user submits a proof of about 14 hashes for 10,000 leaves. The contract recomputes the root with OpenZeppelin MerkleProof.verify and compares it. This costs one storage slot instead of 10,000, and you can update the list by changing the root.

Treat the key as compromised immediately, because bots scan GitHub within seconds. Move all funds and tokens to a new secure wallet, revoke token approvals, and if the key owns contracts, transfer ownership or roles to a new multisig. Removing the commit is not enough since history and forks keep it. Then rotate any related API keys, add secret scanning and pre-commit hooks, and load keys from environment variables or a secrets manager.

I would compare candidate rollups on security (proof system live, stage of decentralisation, upgrade keys), EVM compatibility so our Solidity code deploys unchanged, ecosystem fit (wallets, oracles, liquidity, bridges our users already use), fees and throughput, and withdrawal experience. I would deploy to testnets first, measure real costs and latency, and check that our dependencies such as Chainlink feeds exist there. Then migrate gradually, keeping L1 contracts for high-value settlement if needed.

Explain that the seven-day window lets anyone challenge a fraudulent batch; it protects their funds. For faster exits, offer third-party fast bridges or intent-based bridges where a liquidity provider pays them on L1 within minutes for a small fee and later claims the slow withdrawal. Also show the expected timeline clearly in the UI and send a notification when funds are claimable, because most anger comes from uncertainty, not the delay itself.

Bridges hold large pooled funds, so they are top hacking targets. Main risks are compromised validator or multisig keys, faulty message verification, and replay of messages across chains. Prefer verification based on light clients or zk proofs over a small trusted multisig. Use rate limits, per-transfer caps, pausing, monitoring of mint-versus-lock balances, and a delay for large transfers. Get multiple audits, run a bug bounty, and consider established messaging protocols instead of building from scratch.

Raft is crash fault tolerant: fast and simple, but it assumes no node lies, so it fits when all members trust each other's infrastructure. QBFT is Byzantine fault tolerant and tolerates f malicious nodes out of 3f+1, so with four validators it survives one bad actor and gives immediate finality. Since the organisations are separate businesses that may not fully trust each other, I would choose QBFT and run at least four validators, ideally more.

Check that both execution and consensus clients are synced and peering well, since low peer count or a lagging execution client causes missed duties. Look at system clock sync through NTP, CPU, memory and disk I/O, as slow disks often cause delays. Review client logs and metrics in Grafana, check for pending client upgrades before a fork, and verify network ports are open. Never start a second copy of the same validator key as a fix, because that causes slashing.

First see whether the gas limit was too low or the function is genuinely unbounded. Run eth_estimateGas or simulate with cast run or Tenderly to see actual gas used and where it fails. If estimation is fine, raise the limit with a buffer of 10 to 20 percent. If the function loops over a growing array, redesign it with pagination or pull-based patterns, because the block gas limit will eventually make it impossible to call.

Use CREATE2 through a deterministic deployment factory that already exists at the same address on all those chains. Keep the init code identical: same compiler version, optimiser settings, constructor arguments and metadata. Pick a salt, compute the expected address off-chain, then deploy on each chain. Foundry scripts support this by passing a salt. Avoid constructor arguments that differ per chain, or move chain-specific settings into an initialiser restricted to the deployer.

Build or use an indexer. An indexer listens to contract events from a start block, transforms them and stores them in a database like PostgreSQL, so the front-end runs normal fast queries. Options are a subgraph on The Graph, hosted indexing services, or a custom service with ethers and a queue. It must handle reorgs by tracking block hashes, support backfilling, and expose an API. Design events up front with indexed fields that queries need.

The state can change between simulation and inclusion: price moved beyond slippage limits, a deadline passed, another user took the last item, or a bot front-ran the trade. Other causes are a different msg.sender or value in the simulation, a gas limit too low for the real path, block-dependent logic like block.timestamp, or a different block tag. Debug by tracing the failed transaction with cast run or a tracer and comparing inputs and state.

The EIP-170 limit is 24,576 bytes of runtime code. First enable the optimiser and try a lower runs value or via-IR. Replace revert strings with custom errors, move repeated logic out of modifiers into internal functions, and remove unused code. If still too big, split logic into separate contracts or external libraries, or use a modular pattern like the Diamond (EIP-2535). Splitting also often improves clarity and auditability.

Decide early whether upgradeability is needed, because it adds trust and storage risks. Options are a proxy (UUPS or Transparent) controlled by a multisig with a timelock, a parameter-driven design where only settings like fees change through governed setters, or a migration plan to a new immutable version. Whatever you choose, document it for users, protect upgrade rights, keep storage layout append-only, and test each upgrade on a fork before executing.

Unbounded loops eventually exceed the block gas limit. Switch to a pull-based accounting model: maintain a global reward-per-token accumulator that grows when rewards are added, and store each user's last checkpoint. Users claim with reward equals balance times (current accumulator minus their checkpoint). This makes distribution O(1) for any number of users. Alternatively, use a Merkle distributor where rewards are computed off-chain and users claim with proofs.

Prefer pull payments. If a contract pushes ETH in a loop, one recipient that reverts, perhaps a contract without receive, can block everyone, and the loop may exceed the gas limit. With pull payments, the contract records each winner's amount in a mapping and winners call withdraw, which zeroes their balance before sending. This isolates failures and limits reentrancy risk. Push only for small fixed lists using call with a checked result.

Act fast with a prepared runbook. Pause affected contracts through the guardian or multisig, and disable front-end actions. Gather the core team and security partners in a war room. Trace the attack transactions to understand the bug and estimate losses, and check whether a white-hat rescue of remaining funds is needed. Communicate publicly with facts and no speculation, contact exchanges and bridges to flag stolen funds, then fix, audit the fix and publish a post-mortem.

This is centralisation risk: if the key is compromised or misused, users lose funds. Move ownership to a multisig with signers on separate devices, add a timelock so users can see and react to changes, set hard-coded bounds such as a maximum fee, and remove powers that are not needed, like unlimited minting. Use role-based access instead of one all-powerful owner, and document the remaining admin powers publicly.

Spot prices from a single pool can be moved within one transaction by a flash-loaned swap, letting an attacker inflate collateral value and borrow far more than it is worth, or trigger unfair liquidations. Replace it with a robust oracle such as Chainlink price feeds, or a long-window TWAP from deep pools, check staleness and deviation between sources, cap borrow amounts per block, and add circuit breakers for extreme price moves.

Revoke the approval immediately using a token approval checker or by calling approve(spender, 0) from the wallet, because the malicious contract can pull tokens any time. If a drain has started, move remaining assets to a fresh wallet. Check for other suspicious approvals and NFT setApprovalForAll permissions. Going forward, approve exact amounts, read wallet prompts carefully, use a separate hot wallet for new dApps, and prefer wallets that simulate transactions before signing.

Freeze the code at a commit and stop adding features. Write clear documentation: architecture, roles, trust assumptions, invariants and known risks. Reach high test coverage including fuzz and invariant tests, and run Slither and fix its findings. Remove dead code, add NatSpec comments, and make the build reproducible. Share a scope list and a walkthrough call. A clean, well-documented codebase lets auditors spend their limited time on deep logic bugs.

Use a vesting contract that holds allocated tokens and releases them on a schedule, typically a one-year cliff followed by monthly or linear vesting over two to four years. OpenZeppelin VestingWallet gives linear vesting per beneficiary; add a cliff and an owner-controlled revoke for employees who leave, returning unvested tokens. Make schedules public on-chain for transparency, and avoid admin functions that could release tokens early, as that erodes investor trust.

Avoid a first-come public rush. Use an allowlist phase with Merkle proofs or signatures, per-wallet limits, and staggered time slots. Consider a Dutch auction or raffle so price, not gas, decides allocation. Use ERC-721A or efficient batch minting to cut gas. Reveal traits later with Chainlink VRF so bots cannot snipe rare items. Load-test the front-end and RPC, and keep pause functions ready in case something goes wrong.

Activate the risk plan: pause new borrowing against that asset and freeze its use as new collateral through governance or the guardian. Switch its oracle to a market price rather than a hard-coded one dollar, so positions are valued honestly, which may trigger liquidations. Reduce its loan-to-value and supply caps. Communicate clearly with users. Longer term, cap exposure per stablecoin, diversify collateral and model depeg scenarios in risk dashboards.

Set conservative loan-to-value ratios and liquidation thresholds per asset based on volatility and on-chain liquidity. Use supply and borrow caps for illiquid tokens, isolation mode for risky assets, and a liquidation bonus that attracts liquidators without over-penalising users. Allow partial liquidations so positions shrink gradually. Keep reliable oracles, an insurance or reserve fund to absorb bad debt, and run stress tests simulating 30 to 50 percent price drops.

Regulation comes first: fractional real estate is likely a security or collective investment, so SEBI rules, including those for fractional ownership platforms, apply, and crypto-like tokens are taxed as virtual digital assets at 30 percent with 1 percent TDS. Use a permissioned token with KYC-gated transfers, such as ERC-3643, and a legal SPV that holds the property. Keep title documents off-chain, put hashes on-chain, and plan for rent distribution, transfer restrictions and recovery.

Fee-on-transfer tokens deduct a percentage on every transfer, so when your contract calls transferFrom for 100 tokens it may receive only 98. If the code assumes 100 arrived, balances and reserves drift and can be exploited. Fix it by measuring the actual amount received: read the contract's balance before and after the transfer and use the difference. Also decide whether to support such tokens at all and document unsupported token behaviours like rebasing.

Keep it simple for non-crypto users. Use a low-fee Layer 2 or a permissioned chain, and create wallets automatically with account abstraction or embedded wallets linked to phone login, so customers never handle seed phrases. Sponsor gas through a paymaster. Make points a non-transferable or restricted ERC-20 if resale is not intended, to avoid VDA tax and securities issues. Keep customer data off-chain and show points in the brand's normal app.

Large trades in shallow pools suffer price impact, and wide slippage settings let sandwich bots extract extra value. Show the expected output, price impact and minimum received before confirming. Set sensible default slippage, such as 0.5 percent for major pairs, and warn when impact is high. Use a router or aggregator that splits trades across pools, and offer private transaction submission so bots cannot see the swap in the public mempool.

Use snapshot-based voting power: count votes from token balances at a past block, as ERC20Votes does, so tokens acquired in the same transaction have no weight. Add a voting delay before voting starts, a quorum, and a timelock between approval and execution so the community can react or a guardian can veto. Require a proposal threshold, and keep critical actions such as treasury transfers behind additional safeguards like spending limits.

The UI is probably reading cached results or a lagging RPC node. After tx.wait() resolves, explicitly refetch or invalidate the relevant queries, for example with wagmi or TanStack Query invalidation. Show optimistic updates while pending. If you use an indexer, it may lag by a few blocks, so poll until it reaches the receipt's block number. Use the same RPC endpoint for writes and immediate reads, and avoid long caching for balances.

Short term, add a fallback transport with multiple providers so requests fail over automatically, and use retries with backoff. Reduce load: batch calls with multicall, cache read results, use WebSockets instead of tight polling, and move history queries to an indexer. Long term, upgrade the plan, spread traffic across providers or run your own node for critical paths, and monitor error rates and latency with alerts so you learn of issues before users do.

Users sign an EIP-712 meta-transaction or an ERC-4337 UserOperation. The relayer validates the signature, checks business rules and rate limits per user, then submits it, paying gas from a hot wallet or via a paymaster. Contracts must verify the original signer, using ERC-2771 trusted forwarders or account abstraction. Manage nonces carefully with a queue, replace stuck transactions, keep the relayer wallet funded and monitored, and cap daily sponsorship to prevent abuse.

Smart contracts cannot call web APIs, so use an oracle. Options include a decentralised oracle network such as Chainlink Functions to fetch from several sports APIs and aggregate, or an optimistic oracle where results are proposed and can be disputed. Settle only after the match result is final, use multiple data sources, add a dispute window for high-value pools, and handle cancelled matches. Avoid a single back-end key posting results, which is a central point of failure.

Never commit keys or put them in plain environment files. For testnets, use CI secret storage with restricted access. For mainnet, avoid hot keys in CI entirely: have CI produce a transaction proposal that signers approve in a multisig, or use a cloud KMS or HSM signer so the key never leaves secure hardware. Separate deployer and admin roles, transfer ownership to a multisig immediately after deployment, and log and review every deployment.

Hide crypto complexity. Offer login with phone or email using embedded or smart contract wallets, so no seed phrase is needed at first. Sponsor gas with a paymaster so users need no tokens. Show amounts in rupees and plain language, support regional languages, and explain actions in simple terms. Provide account recovery via passkeys or guardians, and let advanced users export to self-custody later. Ensure KYC and tax requirements are clear where money is involved.

USDC uses 6 decimals, but the front-end probably formats every token with 18 decimals, so 100 USDC (100,000,000 base units) displays as 0.0000000001. Read decimals() from each token contract, or from a trusted token list, and use formatUnits and parseUnits with that value. Use bigint for amounts, never JavaScript floats, to avoid precision errors. Add tests with tokens of 6, 8 and 18 decimals.

Track on-chain activity in real time: alert on admin actions, large transfers, unusual withdrawal rates, paused states, oracle deviations and failed transactions. Use monitoring services or custom bots reading events, with alerts to on-call channels. Monitor invariants, such as total assets matching total shares, and automate responses like pausing through a guardian. Also watch the front-end, RPC health and DNS for hijacking. Review alerts weekly to reduce noise and test the incident runbook.