Audit deliverables
Smart Contract Security Glossary: Definitions That Point to Evidence
Security terms become useful when their scope and evidence are clear. This smart contract security glossary defines the objects, authorities and methods readers encounter in reports, then points to the next technical check instead of treating a label as proof of safety.

Key facts
- Original corpus census
- 67 of 199 exact Ethereum glossary labels matched
- Corpus boundary
- 44 native articles before this publication batch
- Unmatched labels
- 132 labels had no exact match; synonyms were not expanded
- Interpretation
- A lexical mention is not a definition or adequate topic coverage
Terms A-Z with definitions and related articles
A smart contract security glossary is useful when a definition changes what a reader checks next. The terms below connect vocabulary to review boundaries: a proof has assumptions, an audit has a scope and an administrator has specific powers. Read the example or linked guide before treating the word as an assurance claim.
The vocabulary also depends on context. An oracle in a test is an expected-result rule; an oracle in a lending market supplies data. A nonce in an account transaction is not automatically the same counter used by a permit contract. Naming the object prevents an otherwise correct definition from being applied to the wrong system.
Our original corpus check matched 67 of 199 exact Ethereum glossary labels against the 44 native articles that existed before this batch. A match means a lexical mention, not a complete explanation. The measurement below shows why definitions and dedicated guides should be evaluated separately.
A to C: authority and review objects
- Access control
- Rules that determine which callers may perform an operation. Review both the check and the way authority is assigned or changed. A correctly written role modifier does not establish that the deployed role belongs to the intended account. See administrator authority and keys.
- Allowance
- An amount a token owner authorizes a spender to use under the token's rules. It is distinct from a completed transfer. Review the spender, amount and later execution path. A transaction that only changes an allowance can create authority exercised in a separate transaction.
- Application Binary Interface
- The encoding interface, commonly abbreviated ABI, used to describe callable functions and data structures. A matching interface helps software form a call but does not prove the target implements the expected behavior. Verify the deployed address and implementation as well as the method signature.
- Audit scope
- The defined code, revision, components and assumptions included in a review. A report can be accurate while excluding a component that matters to the reader. Start with the report scope and status fields before interpreting its finding count.
- Audit finding
- A documented issue or observation within a review. Its meaning depends on the evidence, severity method and status. A finding marked accepted has not necessarily been fixed. A proposed patch has not necessarily been reassessed. Read the detailed record rather than only the summary label.
- Backdoor
- A hidden or misleading path that grants behavior or authority outside the expected design. The label requires evidence of the path and its significance, not merely the presence of an owner role. The backdoor analysis guide separates authority from allegations about intent.
- Block finality
- The condition under which a chain's history is treated as settled under its consensus model. Finality assumptions affect bridges and applications that react to source-chain events. A transaction receipt and a finality guarantee are different evidence objects. Define the condition the integration actually requires.
- Bridge
- A system that carries authenticated information or represents assets across chains under a particular trust model. Message verification, delivery and application authorization are separate layers. The bridge integration checklist connects those layers to route configuration and recovery behavior.
- Bytecode
- The executable representation deployed or executed by a virtual machine. Source code and an audit report need a verified connection to the deployed program. Compiler settings, linked libraries and proxy indirection can affect that connection even when the project name and repository remain unchanged.
- Circuit breaker
- A control that restricts activity when a defined condition is met, often through limits or an emergency state. Its scope is the operations it actually guards. A limit on one function does not establish a protocol-wide loss bound without examining alternate paths and assumptions.
- Collateral
- An asset accepted to secure an obligation under a protocol's rules. Its risk depends on valuation, liquidity, liquidation behavior and administrative powers, not just token transfer correctness. The lending protocol audit guide joins these assumptions to solvency and accounting checks.
- Compiler version
- The specific compiler release used to translate source into executable code. Version and configuration belong in a reproducible review record. A source file's version range does not identify the exact compiler used for a deployment, and a successful build is not a security assessment.
C to I: models and execution
- Contract invariant
- A property expected to remain true across the operations and states included in its model. An invariant must identify its assumptions and scope. The invariant specification guide explains why "funds are safe" is too vague to serve as a testable property.
- Delegatecall
- An EVM operation that executes another address's code in the caller's storage context. This distinction is central to proxy and storage-layout review. Knowing the code address alone is insufficient. The reviewer must understand the caller's state and the authority controlling the implementation choice.
- Denial of service
- A condition that prevents intended operations from completing or being available. In contracts, the cause can involve resource bounds, a reverting dependency or state that blocks progress. The security question includes whether users can still reduce risk or recover, not only whether funds move.
- Domain separation
- Binding an authorization or cryptographic operation to a particular context so the same data is not accepted unintentionally elsewhere. EIP-712 provides a typed-data domain mechanism. The application must still define replay protection and verify that the chosen domain represents its actual authorization boundary.
- Economic attack
- An action that exploits the protocol's incentives, pricing or accounting assumptions rather than necessarily violating a low-level coding rule. A transaction can be valid under the implementation while producing an unintended economic result. Review the product model and dependencies alongside the code.
- Emergency guardian
- An actor authorized to perform a defined emergency operation. The role should state whether it can pause, resume, change limits or only trigger a narrow stop. The pause design guide separates emergency authority from recovery and general administration.
- Flash loan
- A loan whose repayment condition is enforced within the transaction flow defined by the lending mechanism. It can supply temporary capital for legitimate operations or an attack against another weakness. A flash loan is a financing mechanism. It is not itself proof of an exploit.
- Formal verification
- A method for establishing a specified property under a formal model and assumptions. The proof's scope matters as much as its result. It does not automatically establish that the specification matches the product intent or that external dependencies behave as modeled. See formal verification boundaries.
- Fuzzing
- Testing with generated inputs or operation sequences to search for violations of a defined property. A useful result records the harness, seed or reproducible counterexample and execution limits. A large input count without a meaningful property does not establish broad security coverage.
- Gas
- The execution resource accounting unit used by the EVM. Gas behavior affects whether operations can complete under the applicable limits. An unbounded loop or unexpectedly expensive dependency can create an availability problem. A gas estimate concerns the estimated execution, not a promise about future state.
- Governance attack
- Use or manipulation of a governance mechanism to obtain an unintended outcome or authority. The review needs to identify voting power, proposal rules, execution permissions and timing assumptions. A governance-approved transaction can still violate the expectations users were told the system would preserve.
- Honeypot token
- A token or trading setup that permits an attractive entry while preventing or severely restricting the expected exit under relevant conditions. Detection depends on the tested route, caller and state. The honeypot detection guide explains why a failed simulation can remain unknown.
- Implementation contract
- The code component used by a proxy or similar indirection mechanism. Its address can differ from the address users call. A review must connect the implementation revision, proxy state and upgrade authority. Inspecting the implementation in isolation can miss the live configuration.
- Initialization
- The process that establishes a contract instance's starting state and authority. Upgradeable patterns can use initializer functions rather than a conventional constructor for instance state. Review who can invoke the path, whether it can repeat and whether the deployed instance was initialized as intended.
L to P: permissions and cryptographic context
- Liquidity lock
- A contract arrangement that restricts access to a particular liquidity asset or position under defined conditions. It does not automatically restrict token minting, transfer taxes or implementation upgrades. Verify the locked object, amount, beneficiary and release rule separately from the token's other authorities.
- Merkle proof
- Evidence that a leaf belongs to a tree committed by a root under the specified hashing scheme. Membership does not establish that the dataset is correct or fair. The airdrop claim guide separates allocation generation, proof verification and consumption state.
- Multisignature wallet
- An account arrangement that requires a defined set or threshold of approvals for an action. Its security depends on configuration, signer custody and any modules or alternate execution paths. Several signatures do not prove operational independence or guarantee that responders will be available.
- Nonce
- A value used to distinguish transactions or authorizations in a particular scheme. Its meaning depends on the protocol: an account transaction nonce and an application permit nonce need not be interchangeable. Review when it is checked, consumed and invalidated, including failed and repeated attempts.
- Oracle
- A mechanism that supplies data or assertions used by a system. A price oracle introduces assumptions about source data, freshness and manipulation resistance. The oracle manipulation guide explains why a valid interface response can still be unsuitable for the protocol's decision.
- Pause
- A state or control that restricts specified operations. A flag does nothing to an unguarded path, and an internal pause mechanism needs an authorized callable management path in the application. Resume behavior and recovery operations must be specified independently of the initial stop.
- Permit
- A signature-based authorization pattern that can allow an action without the owner submitting the corresponding on-chain transaction directly. Review the signed fields, domain, nonce, expiry and consuming contract. A signature request may create meaningful authority even when it does not immediately transfer assets.
- Proxy
- A contract that forwards or delegates behavior to another implementation under a particular design. The user-facing address can stay constant while behavior changes. The upgradeable contract audit guide covers the implementation, storage and authority boundaries that this indirection introduces.
R to S: findings and failure mechanisms
- Reentrancy
- A call-flow condition in which an external interaction permits execution to return into relevant code before the original operation has completed as assumed. The risk depends on shared state and the affected paths. The reentrancy guide connects callbacks to concrete accounting and authorization failures.
- Remediation review
- A follow-up assessment of a proposed or implemented fix. Its record should identify the changed revision and what was re-examined. A developer saying an issue is fixed is different from a reviewer verifying the change, and neither automatically expands the original audit scope.
- Replay attack
- Reuse of a valid authorization or message in a context where another effect should not be permitted. Protection can require consumption state and domain checks. The replay analysis guide distinguishes repeated use within one contract from reuse across deployments or chains.
- Rug pull
- A term used for harmful withdrawal, confiscation or abandonment behavior by project controllers. It should be tied to a specific mechanism and evidence rather than used as an unsupported allegation. A broad administrative permission can create exposure without proving that its holder intends to abuse it.
- Severity
- A label for an issue's assessed importance under a stated methodology. Different reviewers can use different impact and likelihood rules. A severity label is most useful when the report explains the failure condition and affected scope. The word alone is not a comparable numerical measurement.
- Simulation
- Execution of a transaction or call against a selected state and configuration without the same commitment effect as sending the intended transaction. The result is conditional on those inputs. The transaction simulation guide explains state, validation and future-ordering limits.
- Slippage limit
- A constraint on the acceptable execution result, commonly used to bound how much a trade outcome may differ from an expected quote. It does not establish that the token, router or approval is safe. Review the actual bound and the path that enforces it.
- Static analysis
- Inspection of program structure or modeled behavior without executing the full application in every possible real-world state. Detector scope and run status matter. The static analysis guide distinguishes a completed check with no finding from an incomplete or failed analysis.
- Storage layout
- The organization of contract state in storage. It matters when delegated code or upgrades interpret existing slots. A new implementation can be syntactically valid while reading old state under an incompatible layout. Review the transition and deployed proxy state, not only the new source.
- Sybil resistance
- Properties of an identity or allocation process that limit one actor's use of multiple apparent identities. A wallet address is not proof of a unique person. Evaluate the selection policy and its errors separately from the cryptographic mechanism used to distribute or verify entitlements.
T to Z: models and administrative boundaries
- Test oracle
- The rule or evidence source used to decide whether an asserted result is correct in a test or assessment context. In software testing, a faulty expected value can reward incorrect code. Distinguish this use of oracle from an on-chain price feed or data provider.
- Threat model
- A structured account of assets, adversaries, trust boundaries and unacceptable outcomes. It guides which properties and scenarios a review should test. The threat modeling guide explains why a tool list cannot replace assumptions about who can do what.
- Timelock
- A mechanism that delays a defined action under specified rules. Its value depends on which actions it covers, who can schedule or cancel them and whether an alternate path bypasses the delay. A delay helps only if relevant observers can detect and respond to the pending action.
- Total value locked
- A reported measure, often abbreviated TVL, of assets attributed to a protocol or set of positions under a data provider's method. It is not a direct security measure or a guaranteed recoverable amount. Compare definitions, valuation time and treatment of nested positions before comparing totals.
- Upgrade authority
- The actor or mechanism able to change a system's implementation or behavior through its upgrade path. This authority can dominate narrower function permissions. A token with restricted minting may still depend on an administrator who can replace the implementation and alter those restrictions.
- Zero-knowledge proof
- A cryptographic proof system with a privacy property concerning what the verifier learns beyond the asserted statement, under the scheme's assumptions. The security review still needs the exact statement, verifier implementation and setup assumptions. The label does not automatically make the surrounding application private or correct.
Use the security tools hub to connect review methods with their actual inputs and outputs. The Pharos Production member profile provides one service reference. A provider description should be read alongside the scope and evidence of a particular engagement.
| Pair | Difference | What to inspect |
|---|---|---|
| Audit and formal verification | A review engagement and a proof method have different evidence boundaries | Scope, methods, properties and assumptions |
| Pause and timelock | One restricts selected operations. The other delays defined actions | Guarded effects and delayed authority paths |
| Simulation and execution | A preview uses selected state. An included transaction commits its actual result | State reference, validation and final transaction record |
| Severity and status | Importance is separate from whether an issue was fixed or accepted | Methodology and remediation evidence |
- Identify whether the term refers to code, authority, a method or a result.
- State the scope and assumptions that give the term its meaning.
- Open the artifact that supports the particular claim being made.
- Follow the unresolved condition into a focused review or guide.
Original vocabulary census across the existing article corpus
Method
- Source and selection
- Extract all unique h4 glossary labels from the fetched Ethereum glossary and match each exact label, case-insensitively with word boundaries, against all pre-batch native article bodies and metadata. Retain parenthetical abbreviations in the label. Count lexical mentions only.
- Retrieved
- Observation
- 199 unique h4 term labels matched against all 44 pre-batch native article bodies and metadata; 24 archived articles excluded.
Results
| Exact Ethereum glossary label | Articles with a mention |
|---|---|
| State | 38 |
| Token | 34 |
| Account | 31 |
| Address | 31 |
| Smart contract | 29 |
| Transaction | 29 |
| Key | 24 |
| Block | 21 |
| Oracle | 19 |
| Wallet | 19 |
The exact-label search found 67 labels in at least one article and no match for 132. Common labels such as state and token appeared frequently, but their presence alone does not establish that an article defines them or covers their security implications.
Parenthetical abbreviations were retained in each glossary label. This means the method can miss a page that uses only an abbreviation or a shorter synonym. The result is a reproducible lexical map, not a knowledge-coverage score. It helps identify where a manual definition or linking review should begin; it does not decide that a missing exact phrase is a content gap.
Limits
- Frozen corpus before these ten articles; subsequent publications change the population.
- Exact wording misses synonyms and some abbreviation forms, while broad words can match incidental mentions.
- No ranking, search demand or reader comprehension was measured.
The reproducible record is kept in the repository: seo/research/articles-42-51-2026-09-06/surveys.py and seo/research/articles-42-51-2026-09-06/survey-50.json. These file paths are not public downloads.
Frequently asked questions
Which definition should control when an audit report uses a term differently?
Use the report's explicit methodology for interpreting that report, then document the difference when comparing it with another source. A glossary should expose ambiguity rather than override a defined contractual or technical meaning.
Should every acronym be repeated in full throughout a report?
Expand it at first use and keep the meaning consistent. Repeat the expansion when a section is intended to stand alone or when the same acronym could refer to different objects.
How should a new term be added to an internal security glossary?
Record its definition, scope, primary reference and an example of a mistaken interpretation. Add a link to the evidence or procedure that the term is meant to help a reviewer inspect.