Smart Contract and DApp Security

Introduction

Decentralized applications (DApps) replace or reduce reliance on central intermediaries by combining blockchain-based smart contracts with user interfaces, wallets, off-chain services, and external data sources. This architecture creates distinctive security conditions. A smart contract may hold valuable assets, execute automatically, and remain difficult or impossible to alter after deployment. A minor programming error can therefore become a permanent and publicly exploitable financial vulnerability.

DApp security is broader than contract correctness. It includes authorization, economic incentives, oracle assumptions, transaction ordering, arithmetic, denial-of-service resilience, bridge architecture, key management, front-end integrity, governance, monitoring, and incident response. Security must be treated as a lifecycle discipline: requirements are modelled before coding, assumptions are tested during implementation, and deployed systems are continuously monitored.

This chapter develops a threat-modelling and control framework for identifying and managing major smart-contract and DApp risks, with particular attention to reentrancy, authorization, oracle manipulation, front-running, arithmetic faults, denial of service, and cross-chain bridges.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Explain the security properties and trust assumptions of smart contracts and DApps.
2. Apply threat modelling to identify assets, actors, attack surfaces, and failure modes.
3. Identify and mitigate reentrancy, authorization, oracle, front-running, arithmetic, denial-of-service, and bridge risks.
4. Combine secure coding, testing, auditing, monitoring, governance, and incident response.
5. Critically evaluate the limitations of security controls and the responsibilities of DApp operators.

1. The DApp Security Context

A typical DApp contains several interacting layers:

• User layer: browsers, mobile applications, wallets, and signing devices.
• Interface layer: web servers, JavaScript code, APIs, and content delivery systems.
• Contract layer: deployed bytecode, storage, access control, and callable functions.
• Protocol layer: consensus, virtual-machine execution, transaction propagation, and block production.
• Data layer: price feeds, randomness services, event indexing, and off-chain computation.
• Cross-chain layer: bridges, relayers, custodians, light clients, and message-passing protocols.

The blockchain can provide strong integrity for state transitions that have been accepted by consensus, but it does not guarantee that the program is correct, that input data is truthful, or that users understand what they are signing. The central security question is therefore not simply “Is the blockchain secure?” but “Which assumptions are delegated to which component, and what happens when an assumption fails?”

Important security properties include:

• Confidentiality: usually limited because transaction data and contract state are publicly observable.
• Integrity: unauthorized or invalid state changes must be prevented.
• Availability: legitimate users should be able to call the system when required.
• Authenticity: actions must be attributable to authorized keys or accounts.
• Non-repudiation: signed transactions provide evidence of authorization, although legal interpretation varies.
• Economic safety: an attacker should not profit by exploiting protocol incentives or market structure.

A secure design also defines invariants. An invariant is a condition that should remain true after every valid state transition. For example, a token contract may require that total balances equal total supply, or that a withdrawal cannot exceed a user's recorded deposit.

2. Threat Modelling for Smart Contracts

Threat modelling is a structured method for discovering threats before they become incidents. A useful process is:

1. Define scope: identify contracts, interfaces, bridges, oracles, administrators, and supporting services.
2. Inventory assets: include tokens, collateral, governance rights, private keys, user data, and availability.
3. Identify trust boundaries: mark transitions between users, contracts, chains, oracles, relayers, and administrators.
4. Enumerate actors: ordinary users, privileged operators, malicious contracts, miners or validators, compromised relayers, and external attackers.
5. State assumptions: for example, an oracle quorum is honest, a multisignature threshold is not compromised, or a bridge finality rule is reliable.
6. Model abuse cases: describe how an attacker could violate an invariant or gain an advantage.
7. Rank risk: assess likelihood, impact, detectability, and time to recovery.
8. Select controls: prevent, detect, contain, and recover from the threat.
9. Validate: use tests, static analysis, formal reasoning, audits, and operational exercises.

A compact risk model can be expressed as:

Likelihood and impact are ordinal assessments rather than physical measurements. The model is useful for prioritization, but it does not produce an objective probability. A high-impact bridge failure may deserve urgent controls even when its estimated likelihood is low.

A practical threat register should record the asset, threat, precondition, consequence, existing control, residual risk, owner, and response plan. Security teams should also distinguish loss of funds, loss of control, incorrect protocol state, and temporary unavailability, because these require different responses.

Security Invariants and Checks-Effects-Interactions

A contract should specify properties that must hold before and after execution. Consider a vault. If shares represent claims on assets, the implementation should define how deposits, withdrawals, rounding, and donations affect the relationship between shares and assets. Tests should verify both normal cases and adversarial sequences.

The checks-effects-interactions pattern is a widely used reentrancy defence:

1. Checks: validate permissions, balances, limits, and conditions.
2. Effects: update internal state.
3. Interactions: call external contracts or transfer assets last.

The pattern reduces risk but is not a complete security model. It does not prevent cross-function reentrancy, read-only reentrancy, malicious token callbacks, or errors in accounting.

3. Reentrancy

Reentrancy occurs when a contract makes an external call and the receiving contract calls back before the first invocation has completed. If state has not been updated, the callback may observe and exploit an inconsistent state.

A vulnerable withdrawal sequence is conceptually:

1. Check that the user has sufficient credit.
2. Send funds to the user.
3. Reduce the user's credit.

A malicious receiver can re-enter at step 2 and pass the same check repeatedly. The safer sequence updates credit before transferring funds. A mutex or reentrancy guard can provide an additional defence by ensuring that a protected function cannot be entered recursively.

Reentrancy may arise through explicit low-level calls, token hooks, NFT receiver callbacks, arbitrary external contracts, or seemingly harmless view functions that expose transient state. Cross-function reentrancy is particularly important: a callback into a different function may bypass a guard applied only to the original function.

Controls include:

• update state before external interaction;
• minimize external calls;
• use pull payments, allowing users to withdraw rather than pushing funds to them;
• apply carefully scoped reentrancy guards;
• avoid assuming that token transfers are passive;
• test malicious receiver contracts and callback sequences;
• verify accounting invariants after nested calls.

A guard is not a substitute for correct accounting. It may also reduce composability if applied too broadly.

4. Authorization and Privilege Risk

Authorization determines who may perform an action and under what conditions. Common failures include missing access checks, incorrect role assignments, confused ownership, unprotected initialization, signature replay, and misuse of tx.origin instead of the immediate caller.

A sound authorization design distinguishes:

• Authentication: proving who submitted or signed a request.
• Authorization: determining whether that actor may perform the requested action.
• Capability scope: limiting what an authorized actor can do.
• Accountability: recording and reviewing privileged actions.

The principle of least privilege requires that each role receive only the permissions necessary for its function. A treasury operator should not automatically be able to upgrade every contract or change every oracle. High-impact actions should use multisignature approval, timelocks, transaction simulation, and independent monitoring.

Signature-based approvals require domain separation, nonces, expiry times, chain identifiers, and explicit operation details. Without these controls, a valid signature may be replayed on another chain, for another contract, or more than once.

Upgradeability introduces an additional trust assumption. A proxy may allow bug fixes, but the upgrade administrator becomes a powerful authority. Users should know whether upgrades are immediate, delayed, vetoable, or impossible. Initialization functions must be protected so that an attacker cannot claim ownership before legitimate initialization.

5. Oracle and Data-Integrity Risk

Smart contracts cannot independently observe real-world prices, interest rates, weather, identity, or off-chain events. Oracles transmit such information, creating a trust boundary. Oracle attacks may involve stale data, manipulated prices, insufficient liquidity, compromised reporters, incorrect decimal conversion, or a failure to distinguish a temporary market movement from an invalid observation.

An oracle design should specify:

• data sources and their independence;
• update frequency and acceptable staleness;
• aggregation method;
• deviation thresholds;
• decimal precision and units;
• circuit breakers and emergency states;
• behaviour when data is unavailable;
• governance over reporter membership.

A simple median of reported values can resist some outliers, but it does not guarantee truth if a majority of reporters collude or share the same source. Time-weighted prices may reduce the effect of a short manipulation, while liquidity-weighted prices can still be distorted in thin markets.

Contracts should reject stale or incomplete observations and should not silently substitute a default value. Risk parameters such as loan-to-value ratios, liquidation thresholds, and maximum exposure should reflect oracle confidence and market liquidity. Oracle assumptions must be included in formal threat models rather than treated as external implementation details.

6. Front-Running and Transaction-Ordering Risk

Transactions may be visible in a public mempool before confirmation. An observer can copy, reorder, or insert transactions to profit from information. This is commonly called front-running, although the broader issue is transaction-ordering dependence or maximal extractable value (MEV).

Examples include:

• purchasing an asset immediately before a revealed trade;
• inserting transactions around a large decentralized-exchange swap;
• copying a profitable liquidation;
• exploiting a public bid before an auction commitment is revealed;
• changing transaction order to affect a protocol outcome.

Mitigations depend on the application:

• Commit–reveal: submit a commitment first, then reveal the underlying action later. The commitment should include a nonce, domain, and secret, and unrevealed commitments need expiry handling.
• Slippage limits: reject trades if execution differs excessively from the user's intended price.
• Deadlines: reject transactions that remain pending beyond the user's acceptable time.
• Batch auctions: clear orders collectively to reduce ordering advantage.
• Private transaction mechanisms: reduce public mempool exposure, although they introduce provider and censorship assumptions.
• Frequent-batch or fair-ordering designs: constrain the value of sequencing power.

No mitigation eliminates all MEV. A protocol should explicitly analyse who controls ordering, what value can be extracted, and whether users receive adequate disclosure.

7. Arithmetic, Precision, and Economic Logic

Arithmetic vulnerabilities include integer overflow and underflow, truncation, division-by-zero, incorrect decimal scaling, rounding direction, unsafe casting, and flawed formula order. Modern compiler checks can revert on many overflows, but unchecked arithmetic remains dangerous and economic logic can be wrong even when every operation is within range.

Token amounts are often integers in the smallest denomination. If a token has d decimal places, a displayed amount q corresponds to base units:

The value must be an integer in the contract representation. Conversion errors occur when a system mixes tokens with different decimal conventions or treats a human-readable amount as base units.

Integer division truncates. For non-negative integers a and b, where b > 0, the quotient stored by integer division is:

The discarded remainder can create systematic value loss or, if rounding is directed incorrectly, allow users to obtain excess value. Protocol designers must define whether rounding benefits the user, the pool, or the protocol, and should prevent repeated operations from amplifying rounding gains.

For example, if a fee is 0.3% and an amount is 10,000 base units, the exact fee is 30 base units. If the amount is 101 base units, the exact fee is 0.303 base units; an integer implementation must choose a rounding policy. That policy should be explicit and tested at boundary values.

Controls include compiler-checked arithmetic, bounded inputs, safe casting, explicit scaling constants, invariant tests, fuzzing, differential testing against a reference model, and economic simulation. Mathematical correctness must be assessed together with incentive correctness.

8. Denial of Service and Availability

A denial-of-service vulnerability prevents legitimate execution. In smart contracts, common causes include unbounded loops, block gas limits, storage growth, malicious recipients that reject transfers, griefing deposits, excessive computation, and reliance on a single administrator or oracle.

A loop over a user-controlled or ever-growing array is unsafe because execution cost may eventually exceed the block gas limit. Safer approaches include pagination, bounded batches, pull-based processing, queues, and off-chain computation with on-chain verification.

A contract should avoid requiring every participant to act successfully for one global operation to complete. For example, a reward distribution that loops through all users can be blocked by scale. A pull model allows each user to claim independently. Failed recipients should not necessarily prevent unrelated users from progressing.

Availability analysis should consider gas-price spikes, congestion, chain reorganizations, oracle outages, administrative key loss, and dependency failure. Rate limits, circuit breakers, graceful degradation, and documented emergency procedures reduce operational risk. A pause mechanism can contain an exploit, but it also creates centralized power and may itself be abused. Its authority, scope, duration, and governance should be explicit.

9. Bridge and Cross-Chain Risk

Bridges transfer value or messages between environments that do not share one native state machine. A bridge commonly uses a lock-and-mint, burn-and-release, liquidity, or message-verification model. Each model introduces assumptions about custody, proof verification, finality, relayers, validator thresholds, and replay prevention.

Major bridge risks include:

• forged or incorrectly verified messages;
• compromised validator or multisignature keys;
• replayed deposits or withdrawals;
• incorrect chain identifiers or message domains;
• premature reliance on probabilistic finality;
• supply inflation caused by duplicate minting;
• relayer censorship or liveness failure;
• smart-contract upgrade compromise;
• mismatched token representations and decimal units.

A secure message should be bound to the source chain, destination chain, bridge instance, nonce, sender, recipient, payload, and relevant version. It should be accepted once only. Verification should be independent of the relayer: a relayer may transport a proof, but it should not be able to create a valid proof.

Bridge risk is systemic because an apparently secure application may depend on an external wrapped asset whose backing is insecure. DApp risk assessments must therefore include the security of every bridged asset and message dependency, not merely the local contract.

10. Secure Development, Testing, and Auditing

Security begins with requirements. The development team should document invariants, trust assumptions, privileged actions, failure states, and economic boundaries before implementation.

A layered assurance process includes:

• peer review and secure coding standards;
• unit tests for normal and boundary cases;
• integration tests across contracts and tokens;
• fuzz testing with generated sequences and values;
• invariant and property-based testing;
• static analysis for suspicious patterns;
• symbolic execution or formal verification for critical properties;
• testnet and fork testing using realistic state;
• independent audits;
• bug bounties and responsible disclosure;
• deployment verification and change management.

An audit is a point-in-time assessment, not a security certificate. It may miss economic attacks, integration failures, newly discovered compiler issues, or risks introduced after the audit. Multiple auditors can improve coverage, but independence and scope matter more than the number of logos on a report.

Formal verification is especially valuable for clearly stated properties such as authorization invariants or conservation of token supply. It cannot prove that the specification reflects the user's real interests, that an oracle is truthful, or that governance keys will remain secure.

11. Monitoring and Incident Response

Prevention must be supported by detection and recovery. Monitoring should track unusual withdrawals, balance changes, privilege changes, oracle deviations, failed transactions, bridge messages, contract upgrades, and anomalous gas patterns. Alerts should be actionable and assigned to named responders.

An incident-response plan normally includes:

1. Preparation: maintain contacts, permissions, runbooks, backups of deployment information, and communication channels.
2. Detection and triage: confirm whether the event is real, identify affected contracts and assets, and preserve evidence.
3. Containment: pause vulnerable functions where authorized, revoke compromised permissions, limit oracle exposure, or stop bridge operations.
4. Eradication and remediation: patch, upgrade, migrate, or replace affected components after careful validation.
5. Recovery: restore safe service, reconcile balances where possible, and communicate limitations honestly.
6. Post-incident review: identify technical, governance, and process failures and track corrective actions.

Blockchain incidents create special challenges because transactions are often irreversible and public. Communications should distinguish confirmed facts from hypotheses, avoid encouraging copycat attacks, and address users, regulators, auditors, and counterparties consistently. Evidence should include transaction hashes, contract versions, logs, privileged actions, oracle observations, and relevant off-chain records.

12. Applied Case: Illustrative Lending-Protocol Incident

Background

Consider an illustrative protocol named HarborLend. It accepts a bridged stablecoin as collateral and allows users to borrow a native stablecoin. Prices are supplied by three external reporters, and an administrator can upgrade the contracts through a two-signature wallet.

Problem

A trader acquires a large quantity of the bridged asset in a thin market and submits transactions that temporarily increase its reported price. The oracle accepts the abnormal observation. The trader deposits the inflated collateral, borrows more than the collateral is economically worth, and attempts to withdraw the borrowed funds. At the same time, a callback in the token implementation enables reentrant interaction with a withdrawal function. The bridge administrator notices the anomaly but has no documented emergency procedure.

Analysis

Threat modelling identifies several connected failures:

• oracle dependence on a manipulable low-liquidity market;
• no maximum price-deviation or staleness check;
• insufficient collateral concentration limits;
• reentrancy in an asset-transfer path;
• excessive upgrade authority concentrated in two keys;
• no tested pause and communication process;
• failure to assess the security of the bridged collateral.

The incident is not one isolated coding mistake. It is a chain of failures across data integrity, contract logic, economic design, governance, and operations.

Approach and Solution

The emergency team pauses new borrowing and collateral deposits, preserves logs, and blocks further bridge minting. It confirms the affected markets and computes the protocol's liabilities. The oracle is replaced with a design using independent, liquid sources, deviation limits, freshness checks, and a fail-closed state. Withdrawal logic follows checks-effects-interactions and uses a carefully tested guard. Collateral caps and conservative liquidation parameters are introduced for bridged assets. Upgrades are moved behind a timelock and a larger multisignature threshold, with public monitoring of proposed changes.

Before reopening, the team performs adversarial tests, reviews the revised economic model, conducts an independent audit, and runs an incident simulation. Users receive a factual report explaining affected balances, recovery options, and unresolved risks.

Outcome and Learning Points

The protocol resumes gradually, beginning with limited deposits and borrowing. The principal lesson is that secure smart-contract operation requires defence in depth. A correct reentrancy fix would not have solved oracle manipulation; a better oracle would not have solved excessive administrative power. Security controls must cover technical, economic, cross-chain, and organizational dependencies.

13. Governance, Ethics, and Regulation

Security decisions distribute risk. An emergency pause may protect users but prevent legitimate withdrawals. A protocol may choose to reimburse victims, but reimbursement can create moral hazard and governance disputes. Operators should disclose material risks, privileged powers, dependencies, audit scope, and incidents in language users can understand.

Regulatory obligations differ across jurisdictions and may concern custody, consumer protection, market manipulation, sanctions, data protection, financial promotion, and operational resilience. Immutability does not remove legal responsibility. Teams should obtain appropriate legal advice and maintain records of decisions, controls, and incidents.

Ethically, security researchers should follow responsible disclosure, avoid extracting unnecessary value during testing, protect personal information, and distinguish proof of vulnerability from exploitation. Governance should not use emergency powers as a permanent substitute for transparent design.

14. Contemporary Developments and Best Practices

Current security practice increasingly combines automated analysis with human review. Fuzzers can explore large input spaces, symbolic tools can identify paths to assertion failures, and machine-learning systems can help classify anomalous transactions or prioritize code review. These tools remain assistants: generated findings require expert validation, and an absence of an alert is not evidence of safety.

Account abstraction, modular execution, restaking, rollups, shared sequencers, zero-knowledge proofs, and cross-chain messaging expand the design space and the attack surface. Developers must ask whether a new mechanism changes finality, censorship, ordering, data availability, upgradeability, or the identity of trusted operators.

A professional minimum standard includes:

• explicit threat models and security invariants;
• least-privilege roles and protected initialization;
• safe external-call and arithmetic patterns;
• oracle freshness, diversity, and circuit breakers;
• bounded computation and graceful failure;
• replay-resistant, independently verified bridge messages;
• adversarial tests and independent review;
• monitored deployments with tested incident runbooks;
• transparent disclosure of assumptions and residual risk.

Chapter Summary

Smart-contract and DApp security is a lifecycle and systems problem. Threat modelling identifies assets, actors, trust boundaries, assumptions, and failure modes before implementation. Reentrancy is controlled through sound state ordering, restricted interactions, pull payments, and testing of callbacks. Authorization requires least privilege, protected initialization, replay-resistant signatures, and accountable upgrade governance. Oracle security depends on source diversity, freshness, unit correctness, deviation controls, and fail-safe behaviour.

Front-running and MEV arise from public transaction visibility and ordering power; commitments, slippage limits, deadlines, batching, and private submission can reduce but not eliminate them. Arithmetic security requires correct bounds, scaling, casting, rounding, and economic invariants. Availability requires bounded work, pagination, pull models, rate limits, and tested emergency controls. Bridges add risks involving proof verification, key thresholds, replay, finality, and wrapped-asset backing.

Audits, formal methods, fuzzing, monitoring, and incident response are complementary rather than interchangeable. Effective security combines technical controls with governance, ethical disclosure, operational readiness, and continuous reassessment of changing dependencies.

Key Terms

Threat model: Structured representation of assets, actors, assumptions, threats, and controls.

Security invariant: A property that should remain true across valid state transitions.

Reentrancy: Re-entry into a contract before an earlier invocation has completed.

Checks-effects-interactions: A design pattern that validates conditions, updates state, and then performs external calls.

Authorization: Determination of whether an authenticated actor may perform an action.

Least privilege: Granting only the permissions necessary for a role.

Upgradeability: Ability to change contract logic after deployment.

Oracle: Mechanism that supplies external data to a blockchain application.

Staleness: Condition in which an oracle observation is older than the permitted freshness period.

Front-running: Benefiting from advance knowledge of a pending transaction by acting before or around it.

MEV: Value extracted through transaction inclusion, ordering, or exclusion.

Commit–reveal: Two-stage process that hides an action until a later reveal.

Integer overflow: A result exceeding the representable numeric range.

Rounding error: Difference caused by converting or truncating a numerical result.

Denial of service: Prevention or disruption of legitimate system use.

Circuit breaker: Control that restricts or pauses operation when abnormal conditions occur.

Bridge: Protocol that transfers value or messages between blockchain environments.

Replay attack: Reuse of a valid message or signature more than once or in an unintended domain.

Invariant testing: Testing that checks a property across many generated sequences or states.

Residual risk: Risk remaining after controls are applied.

Review Questions

Short Answer Questions

1. Why is a DApp threat model broader than the smart contract alone?
2. Explain the checks-effects-interactions pattern.
3. What is oracle staleness, and why is it dangerous?
4. Give two causes of denial of service in smart contracts.
5. Why must bridge messages include domain and replay protection?

Long Answer Questions

1. Compare reentrancy guards with the checks-effects-interactions pattern, including their limitations.
2. Explain how authorization, upgradeability, multisignature control, and timelocks interact in protocol governance.
3. Analyse the security requirements of a price oracle used by a lending protocol.
4. Discuss arithmetic, precision, rounding, and economic-logic risks in token contracts.
5. Explain why a smart-contract audit cannot be treated as a guarantee of security.

Analytical / Application Questions

1. Design a threat model for a DApp that uses a bridged collateral token, an external price oracle, and an upgradeable lending contract. Identify at least six assets or assumptions and map each to a control.
2. A protocol distributes rewards by looping over every participant. Analyse the availability risk and propose a replacement architecture.
3. An administrator detects abnormal oracle prices and a suspected reentrancy exploit. Construct a prioritized incident-response plan covering containment, evidence, communication, remediation, and reopening criteria.

Multiple Choice Questions with Answers

Question 1

Which sequence best represents the checks-effects-interactions pattern?

A. External call, state update, permission check

B. Permission check, state update, external call

C. State update, external call, permission check

D. Permission check, external call, state update

Correct Answer: B. Permission check, state update, external call

Question 2

Which condition is most directly associated with a reentrancy exploit?

A. A contract uses a timelock

B. A contract updates state only after an external call

C. A contract rejects stale oracle data

D. A contract limits array size

Correct Answer: B. A contract updates state only after an external call

Question 3

What is the main purpose of a nonce in a signed authorization?

A. To increase token decimals

B. To prevent repeated use of the same authorization

C. To improve oracle liquidity

D. To reduce block size

Correct Answer: B. To prevent repeated use of the same authorization

Question 4

Which oracle control addresses data that is too old?

A. A freshness or staleness check

B. A larger user interface

C. A higher token supply

D. A longer contract name

Correct Answer: A. A freshness or staleness check

Question 5

Which technique hides a user's intended action until a later stage?

A. Pull payment

B. Commit–reveal

C. Static analysis

D. Pagination

Correct Answer: B. Commit–reveal

Question 6

For non-negative integers a and b, with b > 0, integer division stores which result?

A. The exact real-number quotient in all cases

B. The rounded-up quotient in all cases

C. The floor of a divided by b

D. The remainder only

Correct Answer: C. The floor of a divided by b

Question 7

Which design most directly reduces denial-of-service risk from an expanding participant list?

A. An unbounded loop over all participants

B. Pagination or bounded batch processing

C. Removing all input validation

D. Allowing only one participant forever

Correct Answer: B. Pagination or bounded batch processing

Question 8

Which bridge property prevents a valid cross-chain message from being processed repeatedly?

A. Replay protection using a unique message identifier or nonce

B. Increasing token decimals

C. Using a public web interface

D. Removing destination-chain information

Correct Answer: A. Replay protection using a unique message identifier or nonce

Question 9

Why are slippage limits useful in decentralized-exchange transactions?

A. They guarantee profit

B. They prevent execution beyond the user's specified price tolerance

C. They eliminate all oracle risk

D. They make private keys unnecessary

Correct Answer: B. They prevent execution beyond the user's specified price tolerance

Question 10

Which statement best describes a smart-contract audit?

A. A permanent guarantee that no vulnerability exists

B. A point-in-time assessment whose scope and limitations must be considered

C. A replacement for incident response

D. Proof that all economic assumptions are correct

Correct Answer: B. A point-in-time assessment whose scope and limitations must be considered