Smart-contract risk
Smart-contract risk is the possibility that deployed code, configuration, or execution behavior violates the financial rules users rely on.
Category: RiskWarning cross category cue
System record
Start with the economic purpose, participants, resources, and entitlements before studying implementation detail.
Why it exists
DeFi moves custody and financial state transitions into programs, so code defects or unsafe assumptions can directly misroute assets, create false claims, or block valid exits.
Traditional-finance analogy
Operational and software-control risk in financial infrastructure is the closest comparison recorded for this concept.
Where the analogy stops
- Public smart contracts can be called atomically by anyone and composed with adversarial code, making execution paths and failure speed unlike many permissioned back-office systems.
- Immutable deployment can limit repair, while upgradeable deployment adds a separate authority and change-control risk.
Main actors
- ActorUser or claim holder
- ActorContract developer and deployer
- ActorExternal caller, integrator, or adversary
- ActorAuditor, monitor, guardian, or governance authority
Assets and claims
Assets — controlled or transformed resources
Assets are resources the mechanism moves, holds, values, or transforms.
- AssetAssets held or authorized by contracts
- AssetProtocol reserves and fees
Claims — entitlements and corresponding dependencies
Claims are rights to value, repayment, redemption, control, or another party's performance; each depends on an obligation or system that must honor it.
- ClaimToken balances, shares, debts, and withdrawal entitlements governed by code
Smart-contract risk is the possibility that deployed code or configuration does something different from the financial rule users depend on.
Why it exists
Section titled “Why it exists”DeFi contracts hold assets, issue claims, record debt, value positions, and authorize exits. A defect in authorization, arithmetic, callbacks, state transitions, initialization, or configuration can therefore become a direct asset or claim failure. Correct code can still be economically unsafe when its specification omits an adversarial state or user expectation.
Traditional-finance analogy
Section titled “Traditional-finance analogy”Operational and software-control risk in a payment, exchange, or accounting system is the closest analogy. Public contracts can be called by arbitrary and adversarial programs in one atomic transaction, often without an operator able to reverse settlement. Immutable code limits repair; upgradeable code adds an authority that can change the rules.
Actors, assets, and claims
Section titled “Actors, assets, and claims”| Element | What is exposed |
|---|---|
| User or claim holder | Assets, approvals, balances, shares, debt, and exit rights |
| Contract developer or deployer | Specification, implementation, initialization, and configuration |
| External caller or integrator | Call ordering, callbacks, token behavior, and composed state |
| Governance or guardian | Pause, recovery, parameter, and upgrade authority |
The primary assets are contract-controlled balances and authorized allowances. The primary claims are the token balances, shares, debts, and withdrawal rights whose meaning is defined by the program.
Mechanism and flows
Section titled “Mechanism and flows”- A user or protocol authorizes a contract to hold or move value.
- The contract reads state, validates conditions, updates accounting, and calls other code.
- An omitted path, unsafe assumption, or configuration causes an invalid transition.
- Capital moves incorrectly, a claim is created or destroyed incorrectly, or a valid exit becomes unavailable.
- The loss reaches users, liquidity providers, reserves, or downstream protocols that accepted the affected claim.
Capital flow is the unauthorized or blocked asset movement. Claim flow is the incorrect balance, debt, share, or entitlement. Return flow can be redirected as fees, rewards, or extracted value. Risk flow continues through every protocol that trusts the contract’s output.
State and loss allocation
Section titled “State and loss allocation”| Before failure | Invalid transition | After failure |
|---|---|---|
| Assets and claims reconcile | Authorization, accounting, or call-order rule is violated | Assets, claims, or access no longer reconcile |
| User can exercise a documented exit | Exit reverts, transfers too much, or transfers too little | Loss or lock remains with users or a backstop |
Smart-contract code creates no economic return. Fees or incentives may pay for operation and security work, but the defect’s loss is borne by the party whose assets or claim value fall unless a reserve, insurer, or recovery process pays.
Protocol and engineering context
Section titled “Protocol and engineering context”The Solidity documentation’s security considerations describe language-level hazards such as reentrancy and emphasize that external calls can re-enter through more than Ether transfer. These are engineering patterns, not a certification that any deployed protocol is safe. The documentation was reviewed 2026-08-10.
An engineer or auditor should define assets and liabilities, role boundaries,
state-machine invariants, call-order assumptions, unusual-token behavior,
initialization, pause and recovery states, and the exact deployment revision.
Tests, audits, and formal verification should state which properties and
assumptions they cover and preserve proof, counterexample, and unknown.
Common misunderstandings
Section titled “Common misunderstandings”- “An audit makes the contract safe.” An audit has a code version, scope, time, methods, assumptions, and unresolved findings.
- “No code change means no new risk.” Configuration, integrations, market state, keys, and upstream contracts can change behavior.
- “A bug is always accidental.” Authorized code can faithfully execute an economically unsafe or malicious rule.
See how code risk combines with integration risk, accounting risk, and upgrade risk.
Machine-readable model
Key equations
Canonical expressions come from the structured concept record. KaTeX renders the notation, while the plain-text expression and variable table keep its meaning and units inspectable without JavaScript. Read the narrative above for the model's domain, assumptions, and rounding rules.
This concept does not require one canonical equation. Its mechanism and state transitions remain the authoritative explanation; do not invent a formula merely to make the topic look quantitative.
Assurance contract
Security properties
These structured statements define desired behavior. Their stable IDs can bind tests, invariants, specifications, audit findings, or proof results without turning descriptive review advice into an assurance claim.
Desired · not evaluated: No test, audit, or proof result is implied until scoped evidence is linked to this property.
Every asset-moving state transition preserves authorization, conservation, accounting, and claim-entitlement rules under adversarial call ordering
External calls, callbacks, reentrancy, unusual token behavior, and transaction failure cannot create an unauthorized intermediate or final state
Initialization, configuration, pause, recovery, and privileged actions have explicit one-time, role, scope, and lifecycle constraints
Audit, testing, or formal verification claims identify the reviewed code, assumptions, properties, result status, and deployment revision rather than implying absolute safety
Knowledge check
Quiz
Answer in your own words, then open the model answer.
What problem does Smart-contract risk exist to address?
Model answer
DeFi moves custody and financial state transitions into programs, so code defects or unsafe assumptions can directly misroute assets, create false claims, or block valid exits.