Blockchain Developer interview questions

The invariant defines valid swap outcomes, while reserve and fee accounting define who owns the resulting balances.

• In a constant-product pool, the net input after the swap fee moves the price along the x times y curve and bounds the output.
• If the fee stays in the pool, the actual reserve product normally grows after a swap, so the invariant does not mean the numeric value of k is forever fixed.
• Stored reserves, token balances, and LP supply can diverge after a donation or rebase, so the protocol must define explicitly when balances are synchronized and how that value reaches LPs.

LP shares should preserve each provider's proportional claim and round so the pool never gives away unaccounted value.

• For an established pool, minted shares are usually the minimum of each deposit amount times total supply divided by its reserve, while a burn returns the holder's fraction of both reserves.
• The first deposit needs separate logic, such as geometric-mean shares with a small permanently locked amount, because there is no existing exchange rate.
• Share outputs and withdrawal outputs round down, while any input quoted for an exact share amount rounds up, preventing repeated dust operations from extracting value.

Concentrated liquidity turns one pool-wide LP claim into many price-range positions whose liquidity becomes active at tick boundaries.

• Each initialized tick stores a net liquidity change, and crossing it adds or removes that liquidity from the amount currently used by swap math.
• A position records its owner, lower tick, upper tick, and liquidity, often as an NFT, because two providers can choose different ranges and no longer own interchangeable shares.
• Fees are calculated from global fee growth and growth outside the two boundaries, so a position earns only while the price is inside its range.
• Narrow ranges improve capital efficiency, but they require active management and make swaps that cross many initialized ticks more expensive.

LTV limits how much a user may borrow initially, while the liquidation threshold marks when the resulting position is no longer sufficiently collateralized.

• Borrow capacity is based on oracle-valued collateral multiplied by each asset's LTV, so a deposit worth 100 with an 80 percent LTV supports at most 80 of debt.
• Solvency uses liquidation-adjusted collateral against current debt, commonly exposed as a health factor that becomes liquidatable below 1.
• The gap between LTV and the liquidation threshold is a safety buffer for price movement and accrued interest, not extra liquidity the borrower can withdraw freely.

The model should make borrowing progressively more expensive as utilization rises, with a sharp increase near the point where withdrawals become hard to serve.

• Utilization is typically borrowed assets divided by available cash plus borrowed assets, using the protocol's exact reserve treatment consistently.
• A kinked curve rises gently below a target such as 80 percent, then steeply above it to encourage repayment and attract supply.
• Supplier yield is derived from the borrow rate, utilization, and reserve factor, so it is lower than the headline borrow rate.
• High rates price scarce liquidity but do not create cash immediately, so withdrawal and reserve design must not assume the curve guarantees availability.

The incentive pays liquidators for restoring solvency, while the close factor limits how much debt one liquidation may repay.

• A liquidator repays debt and receives collateral worth the repayment plus a bonus, which must cover gas, price movement, and execution risk without needlessly stripping collateral.
• A 50 percent close factor prevents one call from closing the whole debt, but it can also leave a fast-falling position exposed across several liquidations.
• Bad debt appears when the remaining collateral, after accounting for the liquidation bonus and market price, cannot cover the remaining debt.
• The protocol then needs an explicit loss path, such as reserves, insurance, or supplier loss, because a larger bonus cannot recover value that no longer exists.

I would choose isolation when limiting contagion from one collateral, oracle, or market matters more than maximum capital efficiency.

• In an isolated market, a shortfall is contained to that market's suppliers and reserves instead of consuming liquidity that backs unrelated assets.
• Shared liquidity improves utilization, borrow depth, and cross-collateral access, but one weak asset can create losses or frozen withdrawals across the common pool.
• Isolation also fragments liquidity and requires separate caps, rate curves, and oracle configuration, so mature low-risk assets may justify a shared pool while new collateral does not.

It converts newly emitted rewards into a global cumulative amount per staked token and settles each user only when that user interacts.

• On a checkpoint, the contract adds new rewards times a precision scale divided by total stake to the accumulator.
• A user's pending reward is their stake times the accumulator divided by the precision scale, minus their reward debt, so rewards must be settled before changing that stake.
• After a deposit, withdrawal, or claim, reward debt is reset to the user's new stake times the current accumulator divided by the same scale.
• The design must define what happens while total stake is zero and retain enough precision that integer dust cannot become a repeatable extraction path.

Unbonding keeps stake slashable long enough for misconduct to be observed and finalized before the validator can withdraw it.

• The delay should cover the evidence, challenge, and chain-finality window, and pending withdrawals must remain slashable throughout that period.
• Slash conditions should be objectively provable and bounded, with stronger penalties for safety violations such as equivocation than for short downtime.
• Starting unbonding must not detach stake from the period in which an offense occurred, so later evidence can still slash it before the proof window closes.
• A longer delay improves accountability but increases capital lockup and liquid-staking pressure, so it should follow the protocol's real detection latency.

After the callback, the lender must have recovered the principal plus the agreed fee or revert the entire transaction.

• The lender records its balance, transfers the asset, invokes the receiver, then either checks the final balance or pulls the exact amount plus fee under an approved standard such as ERC-3156.
• A successful callback return value is not proof of repayment, so the balance or transfer result must be verified independently of the receiver's internal accounting.
• The receiver should authenticate the lender and initiator before acting, because an arbitrary caller must not be able to trigger approvals or privileged callback logic.
• Any failed repayment reverts the transfer and every nested action atomically, which is what makes unsecured one-transaction borrowing possible.

I would draw boundaries around invariant ownership and authority, not around business nouns alone.

• One module should own each critical accounting fact, such as total debt or share supply, and expose narrow commands rather than writable shared state.
• A cross-module operation should have one atomic coordinator that validates preconditions and applies every related transition, with explicit invariant checkpoints and reentrancy rules around any required callback.
• Interfaces should state units, rounding, trust assumptions, and failure behavior so a caller cannot reinterpret another module's values.
• Dependency direction, upgrade authority, and pause scope should follow the same boundary, limiting the state and privileges affected by a faulty module.

I would choose from the protocol's promised trust model, expected change, and credible migration path rather than make upgradeability the default.

• Immutability fits a small, settled core when users can verify fixed rules and move assets to a replacement without depending on privileged migration.
• Upgradeability fits components whose integrations or risk parameters must evolve, but it adds storage constraints and an authority that can replace all delegated logic.
• A hybrid can keep custody and core accounting immutable while routing configurable policy or integrations through tightly scoped replaceable modules.
• The deployed design should make upgrade scope, delay, rollback limits, and the user's exit opportunity visible because these are protocol guarantees, not implementation details.

I would choose the pattern from fleet size, upgrade granularity, deployment cost, and who is trusted to change code.

• UUPS suits independently upgraded instances with small proxies, provided every implementation preserves compatible upgrade logic and strongly authorizes upgrades.
• Transparent proxies suit independent instances when a distinct ProxyAdmin and sender-based admin separation are worth the larger deployment surface.
• Beacon proxies suit a homogeneous fleet that should move together through one beacon, accepting that one beacon upgrade has fleet-wide blast radius.
• Minimal clones suit many cheap instances whose implementation is fixed; if instances need coordinated upgrades, a beacon fleet is usually the clearer model rather than adding hidden mutability to clones.

A diamond maps routed function selectors to facets and delegates those calls so facet code operates on the diamond's identity and storage.

• Immutable functions execute directly in the diamond, while fallback resolves other msg.sig values to facets, forwards calldata with delegatecall, and returns or reverts with the facet's data.
• diamondCut applies selector additions, replacements, and removals atomically, then may delegatecall initialization needed by the new composition.
• Loupe functions expose facets and selector mappings so clients and tooling can inspect the current interface.
• The diamondCut authority is therefore code-change authority over the whole diamond and should receive the same protection as a proxy upgrade.

I would treat storage namespaces and selector mappings as permanent schemas that every cut must validate.

• Each facet domain can anchor a storage struct at a unique deterministic slot, while fields inside that namespace remain append-only and type-compatible across upgrades.
• State shared by facets should have one canonical accessor and representation so separate facets cannot create competing copies of the same invariant.
• A cut must reject adding an existing selector, replacing it with the same facet, removing an absent selector, or leaving required interface selectors unreachable.
• The cut manifest should compare old and new selector ownership, storage layouts, interface support, and initialization effects before applying all changes atomically.

I would model roles as narrow capabilities with explicit administration edges and keep operational power separate from power to grant it.

• Roles should map to bounded actions and resources, such as pausing one market or updating one oracle, instead of broad operator access across the protocol.
• A high-trust root should administer role managers but hold no routine operational role, and only deliberately governed self-administration should remain after bootstrap.
• Grant, revoke, upgrade, treasury, and emergency powers should have distinct paths, with delays or expiry where immediate persistent access is unnecessary.
• The complete graph should be machine-checkable from every external function to its role and from every role to the principals that can create or revoke it.

I would give each mechanism one job: the multisig authenticates a threshold, the timelock delays normal changes, and the guardian only limits damage.

• Upgrades, treasury transfers, and durable parameter changes should execute through the timelock after authorized proposal and review delay, not directly from signer keys.
• The multisig can own proposer or administrative roles, but its threshold and signer diversity do not replace a public execution delay.
• The guardian may pause a bounded surface or cancel a queued action, but it should not upgrade code, move user funds, or bypass the timelock.
• Unpause and restoration of normal authority should follow a more deliberate path so compromising the fastest key cannot create persistent control.

I would pause risk-increasing actions while preserving the safest path to reduce exposure and exit.

• Pause controls should be granular by module and action, blocking borrowing, leverage, risky trades, and unsafe withdrawals while preserving repayments, claims, cancellations, and collateral additions where possible.
• An exit path should use conservative accounting and avoid optional dependencies that the same emergency can disable, such as a mutable integration or fresh risky oracle read.
• The guardian can activate a bounded pause quickly, while unpause and any extension of restrictions require stronger delayed authority.
• If immediate withdrawal would violate solvency or ordering invariants, the protocol needs a predesigned pro rata redemption or delayed escape mechanism rather than an unlimited freeze.

I would derive all three from historical voting power and tune them to participation and concentration rather than current token balances.

• Delegation checkpoints should fix each account's voting power at the proposal snapshot so transfers during voting cannot duplicate or move votes.
• A nonzero voting delay gives delegates time to respond and places the snapshot after proposal creation under an explicit clock based on blocks or timestamps.
• Quorum should be a documented fraction of historical eligible supply, with clear treatment of abstentions, so supply changes do not rewrite an active proposal's requirement.
• The proposal threshold should deter spam while still permitting credible minority proposals, and changing either threshold or quorum should itself pass delayed governance.

I would make voting power costly to acquire over time and limit what a temporary or captured majority can execute immediately.

• Votes and proposal eligibility should read checkpoints from before activation, with enough voting delay that tokens borrowed and returned in one transaction cannot create usable power.
• If voting tokens are widely borrowable, staking age, lock duration, or time-weighted voting power can address short-lived positions that a simple block snapshot still permits.
• Quorum and proposal thresholds should use the same historical vote source, while delegation concentration and wrapper contracts must be included in the capture model.
• A timelock, bounded guardian cancellation, immutable limits on critical powers, and a user exit window contain malicious proposals, but they cannot make a genuinely purchased majority honest.