BTA CBDE common mistakes
BTA CBDE · Understand the traps and how to avoid them.
Treating 'gas' and 'gas price' (or 'gas limit') as interchangeable in explanations and calculations, so answers about transaction cost or out-of-gas failures describe the wrong variable.
Everyday usage conflates the fee with the unit of work; candidates memorize a single formula string without mapping each term to what it measures, and the exam deliberately probes the distinction.
What to do instead
Write the cost equation once as gas used × effective gas price, then define each term separately: gas as computational units, gas limit as the cap the sender authorizes, base fee as protocol-set and burned, priority fee as the tip. Re-derive any numeric answer from these definitions before selecting an option.
Assuming that setting a contract's state variable or sending ETH to an address takes effect immediately for the caller, ignoring that state changes are only final after the transaction is mined and that a revert rolls everything back.
Reading Solidity like sequential application code hides the asynchronous, atomic transaction model; candidates picture the EVM executing line by line with no rollback.
What to do instead
For each scenario, trace the transaction lifecycle explicitly: signed transaction, mempool, execution, revert-or-commit, receipt. Practice questions by stating what an external observer sees at each stage and which effects survive a revert (logs and state do not; ETH transfers revert with the call).
Mixing up storage, memory, and calldata when predicting behavior of function parameters, return values, and struct copies, especially expecting a memory copy to alias the original storage slot.
The keywords look like optional annotations, and candidates learn them by pattern-matching examples rather than by the copy semantics each one implies.
What to do instead
Build a small reference table: storage is persistent and reference-like, memory is a per-call mutable copy, calldata is a non-modifiable reference to input data. Then reason about aliasing: assigning a storage struct to a memory variable copies, while a storage pointer shares. Test each case in a scratch contract.
Applying visibility and mutability keywords incorrectly, such as marking a function that writes state as view, or leaving an internal helper public, and then failing questions about compiler errors or external attack surface.
Beginners copy modifiers from tutorials without knowing which operations each one permits, and the compiler error messages are not part of the mental model they built.
What to do instead
Memorize the constraints: view forbids state writes, pure forbids both reads and writes of state, payable is required to receive ETH, external is callable only from outside. For each function you write, justify its visibility by listing its intended callers, and compile to confirm.
Confusing the roles of Hardhat, Foundry, Truffle, and Ganache, or answering framework questions with commands that belong to a different toolchain.
Tutorials blend tools, and candidates learn a workflow (compile, test, deploy) without attaching each step to its specific CLI and configuration file.
What to do instead
Create a matrix of tool versus task: compilation, local node, test runner language, deployment scripting, and console. Then practice one end-to-end flow in each major framework so the command names and config files are anchored to a concrete session.
Misreading the purpose of a lockfile and package configuration, so answers about dependency pinning, reproducible builds, or plugin registration describe the wrong file.
Configuration files are edited rarely and copied wholesale; candidates never internalize which file controls versions versus which controls project settings.
What to do instead
For one project, list every config file and write one sentence on what it governs. Deliberately change a dependency version and observe which file changes and which file pins the resolved tree, then revert.
Describing a DApp architecture as if the frontend talks directly to a smart contract over HTTP, omitting the wallet/provider layer and the JSON-RPC node in between.
The user-visible flow feels like a website calling an API, and the injected provider is invisible in most diagrams candidates have seen.
What to do instead
Draw the request path from browser to chain: UI, wallet or injected provider, RPC endpoint, node, EVM. Then annotate where signing happens, where the private key lives, and which steps require user approval, and answer questions from that diagram.
Treating an on-chain event as a reliable delivery mechanism for backend or UI state, or assuming a transaction receipt implies the application's off-chain database is updated.
Event logs look like webhooks, so candidates import a push-based mental model into a pull-based system where logs must be queried and reorgs can undo them.
What to do instead
State the rule plainly: events are append-only logs readable by querying, not messages pushed to subscribers. For any integration question, identify who polls or subscribes, how confirmations are counted, and how a reorg is handled by re-querying from a known block.
Answering security questions by naming a vulnerability class without identifying the concrete pattern in the described code, for example calling any external call a reentrancy bug regardless of state-update ordering.
Candidates memorize a list of buzzwords and match on keywords instead of reading the control and data flow the question describes.
What to do instead
For each classic class (reentrancy, access control, integer issues, oracle manipulation, front-running), write the minimal code shape that exhibits it and the specific line that fixes it. Practice classifying short snippets by pattern, not by vocabulary.
Treating a passing test suite as proof of correctness, skipping edge cases such as zero amounts, unauthorized callers, and revert expectations, and ignoring coverage of failure paths.
Happy-path tests are quick to write and turn green, which reinforces the habit; revert assertions require extra syntax that candidates avoid.
What to do instead
Adopt a checklist per function: authorized and unauthorized caller, boundary values, expected revert with reason, and state after failure. Require at least one negative test per external function and review coverage reports for untested branches before answering testing questions.