Blockchain Developer interview questions

Single-function reentrancy repeats the same entry point, while cross-function reentrancy enters a different function that depends on the same unfinished state.

• In single-function reentrancy, a callback invokes a function such as withdraw again before its balance update is complete.
• In cross-function reentrancy, the callback reaches another entry point such as transfer or borrow that reads the same balance or limit.
• Locking only withdraw does not protect transfer if both functions rely on an invariant that the first call has not restored.
• The security boundary is the shared invariant across all external entry points, not the body of one function in isolation.

Cross-contract reentrancy follows a callback into another contract, while read-only reentrancy exposes a transient value without directly writing the vulnerable state.

• In a cross-contract path, contract A calls an external contract that calls contract B, and B reads or changes state coupled to A.
• A mutex in A does not automatically protect B because each contract has separate storage and may enforce a shared invariant differently.
• In read-only reentrancy, a callback queries a view such as getPrice while one accounting field is updated and another is still stale.
• The view modifier prevents state writes through that function, but it does not guarantee that the value represents a consistent point in the transaction.

Checks-effects-interactions reduces the callback window and ReentrancyGuard blocks reentry into guarded paths, but neither is a blanket proof of safety.

• CEI validates inputs first, commits all related accounting effects next, and performs external calls only after the invariant is restored.
• ReentrancyGuard uses a storage mutex that rejects a second entry into a function protected by the same guard during the first call.
• CEI is incomplete if one field is updated while related fields or state in another contract remain inconsistent before the interaction.
• A guard does not cover unguarded entry points, another contract's storage, or inconsistent values exposed by view functions.

An ERC-777 transfer can execute sender or recipient hook code, so a token operation is also an external control transfer.

• The tokensToSend hook runs before token balances change, while tokensReceived runs after they change, giving hooks distinct callback points.
• A recipient hook can call the integrating protocol again before that protocol finishes its own deposit, withdrawal, or reward accounting.
• A contract accepting arbitrary ERC-20-compatible assets cannot assume transfer or transferFrom has no callback behavior.
• SafeERC20 handles return-value and call compatibility, but it does not block hooks, so CEI and appropriately scoped reentrancy guards are still needed.

A DEX spot price reflects current pool reserves, which an attacker can distort temporarily with liquidity borrowed for one transaction.

• A flash loan supplies enough capital to trade heavily against a pool without requiring the attacker to hold that capital beforehand.
• If a protocol reads the shifted reserve ratio before the attacker reverses the trade, it can misprice collateral, shares, or swaps.
• The attacker can unwind the position and repay within the same transaction, so profit only needs to exceed price impact, swap fees, gas, and the flash-loan fee.
• A single instantaneous quote from one pool is therefore weaker than a time-weighted or independent aggregate with liquidity and deviation checks.

A TWAP averages prices over a window, forcing an attacker to sustain distortion over time at the cost of slower response to real market moves.

• Manipulating several observations or blocks usually requires more capital and exposes the attacker to arbitrage between blocks.
• A longer window raises that burden but makes the oracle lag legitimate rapid price changes.
• Attack cost also depends on pool depth, observation spacing, and whether the attacker can influence consecutive blocks, not only on window length.
• A thin or inactive source can remain cheap to manipulate, because averaging low-quality observations does not create liquidity.

A sandwich attacker trades before and after a pending swap to capture the price movement that the victim permits through slippage tolerance.

• The attacker sees the victim's swap in the public mempool and submits a front-running trade in the same direction to move the pool price.
• The victim then executes at a worse price as long as the result still satisfies minAmountOut or maxAmountIn.
• The attacker reverses the first trade after the victim and keeps the captured price difference minus pool fees and transaction costs.
• Looser slippage creates more extractable room, while tighter limits can force a revert and private order flow can hide the transaction from public searchers.

A role's administrator can grant or revoke that role, so control of the admin role can be more powerful than direct membership in the managed role.

• In OpenZeppelin AccessControl, DEFAULT_ADMIN_ROLE administers all roles by default and is also its own administrator.
• Compromising one default-admin key can therefore grant minting, upgrading, pausing, or treasury roles even if those operational keys remain safe.
• Self-administered roles, admin cycles, and missing revocation paths can make privilege removal or recovery unexpectedly difficult.
• Separating operational roles from a multisig or timelocked administrator and using a two-step admin transfer reduces single-key escalation risk.

delegatecall runs another contract's bytecode against the caller's address, balance, and storage while preserving the caller's current msg.sender and msg.value.

• Storage reads and writes use raw slots in the calling contract, so proxy and implementation layouts must remain compatible.
• address(this) is the caller, and external calls made by the delegated code originate from the caller with its authority and assets.
• Untrusted or incorrectly upgraded code can overwrite ownership or implementation slots, change arbitrary state, or transfer assets held by the caller.
• delegatecall provides code reuse rather than isolation, so validating the implementation and protecting initialization and upgrades are part of its security boundary.

A signature can be replayed whenever the contract verifies the signed data but does not bind it to one use and one execution domain.

• Same-contract replay occurs when an accepted payload can be submitted repeatedly because it lacks a nonce or consumed-digest check.
• Cross-chain replay occurs when the same signature is valid on another deployment because the signed domain omits the chain identifier.
• The contract must verify and consume a signer-specific nonce or digest before external calls, with a deadline when authorization should expire.
• An EIP-712 domain containing chainId and verifyingContract separates chains and contracts, while the signed struct binds the intended action, recipient, and amount.

The proxy forwards a call with delegatecall so the implementation's code runs against the proxy's state.

• The proxy fallback passes the original calldata to the implementation address and does not make a normal external call.
• During execution, address(this), storage, and the ETH balance belong to the proxy, so state writes change proxy slots.
• delegatecall preserves the original msg.sender and msg.value, which lets implementation access control see the actual caller.
• The proxy returns the implementation's returndata or bubbles its revert data back to the caller.

EIP-1967 gives proxy metadata standardized storage locations that are unlikely to collide with implementation variables.

• The implementation slot is bytes32(uint256(keccak256("eip1967.proxy.implementation")) - 1), and OpenZeppelin uses that exact constant.
• The standard similarly defines separate slots for the proxy admin and beacon, although a proxy pattern may not use all three.
• Block explorers and clients can read these known slots with eth_getStorageAt without relying on a proxy getter.

A transparent proxy chooses between upgrade dispatch and implementation fallback according to the caller.

• Every non-admin call is delegated to the implementation, even when its selector equals upgradeToAndCall.
• The admin may invoke only upgradeToAndCall; any other admin call reverts with ProxyDeniedAdminAccess instead of reaching the implementation.
• In OpenZeppelin 5.x, each proxy deploys a dedicated ProxyAdmin whose initial owner is supplied to the proxy constructor.

UUPS keeps upgrade logic in the implementation and uses proxiableUUID to reject implementations that target an incompatible storage slot.

• upgradeToAndCall runs through the proxy under onlyProxy, which checks delegatecall context and that the proxy currently points to this implementation.
• The implementation's _authorizeUpgrade override must approve the caller before any implementation slot is changed.
• The upgrade calls proxiableUUID on the new implementation and requires the EIP-1967 implementation slot; proxiableUUID itself uses notDelegated to prevent calls through a proxy.

Transparent proxies place upgrade dispatch in the proxy, while UUPS proxies place it in every upgradeable implementation.

• TransparentUpgradeableProxy deploys a dedicated ProxyAdmin and includes sender-based dispatch, which costs more deployment gas than a plain ERC1967Proxy.
• UUPS leaves the proxy small, but each new implementation must retain correct upgrade authorization and ERC-1822 compatibility.
• Transparent dispatch prevents its admin from accidentally calling implementation functions, while UUPS has no separate admin fallback rule.

A constructor initializes the implementation's own storage, so proxy state must be configured through a protected initializer executed by delegatecall.

• An initializer consumes version 1 and normally runs once in the proxy's storage context.
• Passing encoded initializer calldata to the proxy constructor makes deployment and initialization one atomic transaction.
• A reinitializer with a higher version configures state introduced by a later upgrade, and each version can be consumed only once.
• Reinitializers cannot be nested, and inherited initializer calls must be ordered manually so a parent is not initialized twice.

_disableInitializers permanently locks the implementation's initialization state so nobody can take over that standalone contract.

• OpenZeppelin sets the initialized version to the maximum uint64 value, causing later initializer and reinitializer calls to revert.
• It is normally called in the implementation constructor, which affects the implementation's storage rather than the proxy's storage.
• The proxy remains initializable because delegatecall reads and writes the proxy's separate initialization slot.
• This lock does not replace initializing the proxy promptly, preferably through constructor calldata in the same deployment transaction.

An upgrade must preserve every existing storage location because the new implementation interprets state already stored in the proxy.

• Do not reorder, remove, or change the type of existing state variables; add new variables only after the compatible existing layout.
• Solidity inheritance linearization contributes to slot order, so reordering base contracts or inserting variables into a base can shift storage used by child contracts.
• Reserved __gap slots let an inherited contract add variables later by reducing the gap by the same number of consumed slots.
• OpenZeppelin 5.x upgradeable contracts use ERC-7201 namespaced storage to reduce inheritance collisions, but each namespace still needs a compatible validated layout.

The transparent pattern resolves proxy and implementation selector clashes by combining the selector with the caller's admin status.

• A selector is only the first four bytes of a function signature hash, so unrelated signatures can share it.
• A non-admin call is always delegated, including a call matching upgradeToAndCall, so the implementation function remains reachable to users.
• An admin call reaches only the proxy's upgrade dispatch, and every other selector reverts instead of falling back to the implementation.
• OpenZeppelin warns against adding external functions to TransparentUpgradeableProxy because a new function can override the implicit upgrade selector and make upgrades inaccessible.

The proxy pattern defines where authorization is checked, while a timelock can make an authorized upgrade wait through a public delay.

• UUPS delegates authorization to _authorizeUpgrade, commonly protected by onlyOwner or a dedicated role.
• Transparent upgrades are authorized by the owner of ProxyAdmin, so that ownership can belong to a governance contract rather than an individual account.
• TimelockController separates proposer, executor, and canceller roles and requires a scheduled operation to satisfy its minimum delay before execution.
• A timelock limits who can upgrade and when, but it does not prove storage compatibility or implementation correctness, which still require technical validation.