Web3 Security Glossary
Short definitions of 257 smart contract, DeFi, key management and offchain security terms. Each one links to the full article.
42 terms
Smart contract vulnerabilities
The bug classes behind most audit findings, from reentrancy to rounding.
Access control vulnerability
Also called missing access control, broken access control, authorization bug
An access control vulnerability is a missing or bypassable permission check that lets an unauthorized caller run a privileged function, such as an upgrade, withdrawal or mint. A UUPS contract that guards upgradeTo but not _authorizeUpgrade can be upgraded by anyone through upgradeToAndCall.
Full article 5 Upgradeable Contract Vulnerabilities to Check
Attack vector
Also called attack vectors, attack path
An attack vector is a path an attacker can use against a system, such as front-running, an untrusted external call, a weird ERC-20 token or a manipulable price. Auditors keep a list of known vectors and check each one against every new codebase.
Related article Smart Contract Vulnerabilities List: 22 to Check First
Blocked liquidation
Also called liquidation DoS, unliquidatable position, liquidation revert
A blocked liquidation is a liquidation that a position owner can force to revert, for example by holding the position from a USDC-blacklisted address so the leftover collateral transfer fails. The position closes only once insolvent, and the protocol or its LPs absorb the loss.
Full article 13 Liquidation Vulnerabilities Every DeFi Auditor Must Know
Centralization risk
Also called centralization finding, admin risk
Centralization risk is the risk that a trusted party, such as an owner or admin key, acts maliciously or makes a mistake. Audits usually rate it medium at most, but an admin update attackers can front-run, such as removing a collateral token, can be high.
Checks-Effects-Interactions (CEI)
Also called checks effects interactions, CEI pattern, check-effects-interactions
Checks-Effects-Interactions (CEI) is a function ordering pattern: validate inputs and state first, then update state and emit events, and only then make external calls. No state is outdated when control passes to another address, which removes the root cause of reentrancy.
Full article Reentrancy Attacks Explained: Every Type and How to Find It
Code smell
Also called code smells, smart contract code smell
A code smell is a pattern that is not necessarily a bug but suggests something is wrong, such as parallel data structures, input arrays of different lengths or a function that takes an amount while also reading msg.value. Auditors dig deeper wherever they find one.
Cross-contract reentrancy
Also called cross contract reentrancy, multi-contract reentrancy
Cross-contract reentrancy uses a callback to enter another contract of the same system that relies on state the first contract has not updated. Each contract's nonReentrant flag lives in its own storage, so per-contract guards miss it; a global guard or Checks-Effects-Interactions closes it.
Full article Reentrancy Attacks Explained: Every Type and How to Find It
Cross-function reentrancy
Also called cross function reentrancy
Cross-function reentrancy re-enters a different function of the same contract while state is outdated, for example calling transfer during withdraw's ether send to duplicate a balance. A nonReentrant guard on withdraw alone does not stop it, because transfer is still open.
Full article Reentrancy Attacks Explained: Every Type and How to Find It
DeFi accounting vulnerability
Also called reward accounting vulnerability, accounting bug, accounting error
A DeFi accounting vulnerability is a flaw in how a protocol tracks balances, shares, debt, fees or rewards, so value goes to the wrong party or disappears. Many come from stepwise jumps, such as a donated reward or a rate change applied without a checkpoint.
Full article DeFi Reward Accounting Vulnerabilities: Stepwise Jumps
Denial of service (DoS)
Also called DoS attack, denial-of-service, DoS in smart contracts
Denial of service (DoS) in a smart contract is an attack that makes a required transaction revert or exceed the block gas limit, so withdrawals or liquidations cannot run. Common causes are reverting callees, blacklisted recipients, rejected ether and malformed return data.
Full article External Call Vulnerabilities in Solidity: 4 Attacks
Dirty bytes (Solidity compiler bug)
Also called dirty bytes arrays bug, bug when copying dirty bytes arrays to storage
Dirty bytes is a Solidity compiler bug where copying a bytes array from memory or calldata to storage can leave leftover data in the slot, which a later empty .push() reveals instead of a zero byte. The Solidity team disclosed it in June 2022.
Full article Solidity Compiler Bugs: Dirty Bytes Arrays in Storage
Division before multiplication
Also called divide before multiply, multiplication after division
Division before multiplication is a precision bug where code divides before it multiplies, as in a / b * c, so the error from truncation is scaled up. Writing (a * c) / b keeps the precision if the product cannot overflow.
Related article Rounding Errors in Solidity: Causes and Real Bugs
ERC-721 and ERC-777 reentrancy
Also called ERC-721 reentrancy, ERC-777 reentrancy, callback reentrancy, onERC721Received reentrancy
ERC-721 and ERC-777 reentrancy happens when a token transfer hands control to a user mid-transaction: safeTransferFrom calls onERC721Received on a contract recipient, and ERC-777 tokens call hooks on the sender or recipient. Treat each such transfer as an untrusted external call.
Full article Reentrancy Attacks Explained: Every Type and How to Find It
Gas griefing
Also called gas griefing attack
Gas griefing is an attack where an untrusted callee burns the gas forwarded to it, up to 63/64 of what remains, at the sender's expense. If the remaining 1/64 cannot finish the function, the transaction reverts and griefing becomes denial of service; cap forwarded gas.
Full article External Call Vulnerabilities in Solidity: 4 Attacks
Hash collision (abi.encodePacked)
Also called abi.encodePacked collision, encodepacked hash collision
An abi.encodePacked hash collision occurs when two dynamic values, such as two arrays or strings, are packed side by side before hashing, so different inputs give the same bytes and the same hash. Use abi.encode, which keeps offsets and lengths.
Full article Smart Contract Vulnerabilities List: 22 to Check First
Integer overflow and underflow
Also called overflow, underflow, arithmetic overflow, integer underflow
Integer overflow and underflow happen when an arithmetic result goes above a type's maximum or below its minimum. Since Solidity 0.8, checked arithmetic reverts instead of wrapping, so the risks shift to underflow reverts that block required actions and to downcasts, which still overflow silently.
Full article Smart Contract Vulnerabilities List: 22 to Check First
Liquidation vulnerability
Also called liquidation bug, liquidation exploit
A liquidation vulnerability is a bug that stops a liquidation from happening on time or makes it settle wrongly, such as a revert on a blacklisted or zero-amount transfer, uncollected fees or a revert once the position is insolvent. Late liquidations cause bad debt.
Full article 13 Liquidation Vulnerabilities Every DeFi Auditor Must Know
msg.value reuse in multicall
Also called multicall msg.value bug, msg.value in a loop, payable multicall
msg.value reuse in multicall is a bug where a payable multicall delegatecalls the contract once per sub-call, and every sub-call sees the same msg.value. One payment is then credited once per iteration; a payable multicall, or msg.value read inside any loop, is a red flag.
Full article 21 Sneaky Solidity Bugs to Catch Before You Deploy
Off-by-one error
Also called off by one, fencepost error
An off-by-one error is a boundary mistake where a loop, index or formula is one step too high or too low, such as a stray + 1 that selects an NFT ID that was never minted. It is among the most common smart contract bugs.
Parallel data structures
Also called parallel data structure, duplicated state tracking
Parallel data structures are two storage variables, such as a mapping and an array, that track the same objects in different ways. An update that changes one but not the other, like a swap-and-pop removal that leaves a stale index, can lock user funds.
Parallel state (multi-contract)
Also called parallel withdrawal state, cross-contract state desync
Parallel state is a multi-contract design flaw where two contracts each track the same object, such as a pending withdrawal, separately. If anyone can act on one copy directly, the other goes stale, and funds can be trapped in a contract with no way out.
Full article 3 Critical Smart Contract Vulnerabilities Explained
Pull over push
Also called pull payments, pull over push pattern, withdrawal pattern
Pull over push is the pattern of letting each recipient claim their own share instead of sending tokens or ether to every recipient in a loop. A push loop has unbounded gas, and one recipient that rejects the transfer can block it.
Full article 21 Sneaky Solidity Bugs to Catch Before You Deploy
Read-only reentrancy
Also called read-only reentrancy attack, view reentrancy, cross-system reentrancy
Read-only reentrancy is reentrancy through a view function: during an external call, a third-party protocol reads a contract's not-yet-updated state, such as a pool price or a balance, and acts on the stale value. Exploits of protocols reading Curve pool prices made it well known.
Full article Reentrancy Attacks Explained: Every Type and How to Find It
Reentrancy
Also called reentrancy attack, re-entrancy, reentrancy vulnerability
Reentrancy is a vulnerability where a contract hands control to an external address while some of its state is outdated, and the callee calls back in to exploit it. The way back in can be any function, another contract or a view.
Full article Reentrancy Attacks Explained: Every Type and How to Find It
Reentrancy guard (nonReentrant)
Also called nonReentrant modifier, reentrancy lock, global reentrancy guard, mutex
A reentrancy guard is a modifier, usually nonReentrant, that sets a flag on entry and reverts any second entry into a guarded function of the same contract. It misses unguarded functions and other contracts, which a global guard in a shared data store covers.
Full article External Call Vulnerabilities in Solidity: 4 Attacks
Return data bomb
Also called returnbomb, return bomb, return data gas griefing
A return data bomb is a gas griefing attack where a callee returns a huge payload that a high-level Solidity call copies into memory, at quadratically growing cost, outside the call's gas cap. An assembly call with an output size of zero avoids the copy.
Full article External Call Vulnerabilities in Solidity: 4 Attacks
Rounding error (precision loss)
Also called precision loss, truncation error, rounding down
A rounding error is a wrong result caused by Solidity's truncating integer division, which drops any remainder and rounds toward zero. Attackers pick inputs that round in their favor, so each division should round against the user and handle a zero denominator.
Full article Rounding Errors in Solidity: Causes and Real Bugs
Self-liquidation
Also called self liquidation, forced self-liquidation
Self-liquidation is when a user can push their own position into a liquidatable state, then liquidate it to collect the liquidator fee or shed losses. The Euler Finance exploit combined a donate function, self-liquidation and flash loans; any action that lowers health should re-check it.
Full article 13 Liquidation Vulnerabilities Every DeFi Auditor Must Know
Signature malleability
Also called ECDSA malleability, malleable signature
Signature malleability is the ability to turn a valid ECDSA signature into a second valid one for the same message and signer, on secp256k1 by replacing s with n - s. OpenZeppelin's ECDSA library prevents it by rejecting any s above n / 2.
Signature replay
Also called signature reuse, cross-chain signature replay
Signature replay is a vulnerability where a contract accepts a valid signature more than once, or one meant for another chain or contract, because the message omits a nonce, chain ID or contract address. Tracking used signatures by their bytes fails against malleable signatures.
Single-function reentrancy
Also called classic reentrancy, single function reentrancy
Single-function reentrancy is the classic reentrancy attack: a function sends ether before clearing the caller's balance, and the attacker's receive function calls the same function again until the contract is drained. Clearing the balance before the call stops it.
Full article Reentrancy Attacks Explained: Every Type and How to Find It
Solidity compiler bug
Also called compiler bug, solc bug
A Solidity compiler bug is a flaw in a specific compiler version that makes correct-looking source compile to bytecode that behaves differently. Auditors check the pragma's version against the Solidity team's published bug disclosures and look for each bug's trigger pattern.
Full article Solidity Compiler Bugs: Dirty Bytes Arrays in Storage
Stale oracle price
Also called stale price, price freshness check, Chainlink stale price
A stale oracle price is a feed answer that has not updated within its expected heartbeat, for example because the oracle or an L2 sequencer is down. Check updatedAt against the heartbeat, check sequencer uptime on L2s, and fall back to another source.
Full article 21 Sneaky Solidity Bugs to Catch Before You Deploy
Stepwise jump
Also called stepwise jumps, step change in value
A stepwise jump is a value, such as a share price, reward per share or reward rate, that changes all at once in one transaction instead of smoothly. Attackers deposit just before and withdraw just after, or accounting applies the new rate to past periods.
Full article DeFi Reward Accounting Vulnerabilities: Stepwise Jumps
tx.origin authentication
Also called tx.origin phishing, tx.origin vs msg.sender
tx.origin authentication is a bug where a contract authorizes the original transaction sender instead of msg.sender. A malicious contract the user interacts with can then call the system and pass the check as the user, a form of phishing; authorize msg.sender instead.
Full article 21 Sneaky Solidity Bugs to Catch Before You Deploy
Unbounded loop
Also called unbounded for loop, loop DoS, block gas limit DoS
An unbounded loop is a loop over data users can grow, such as a list of holders, so its gas cost can pass the block gas limit. Minting one wei to thousands of fresh addresses, for example, can make a dividend payout fail permanently.
Full article 6 Critical DeFi Vulnerabilities From Real Audits
Uncaught revert (try/catch)
Also called catch Error(string), uncaught custom Error, try/catch panic
An uncaught revert is a failure a try/catch is meant to handle but does not, often because catch Error(string) only catches reverts with a reason string. Custom errors and panics bubble up instead, which can let users keep orders alive and pick when they execute.
Unchecked return value
Also called unchecked call return value, unchecked low-level call, unchecked transfer
An unchecked return value is a bug where code ignores the success flag from a low-level call or from an ERC-20 transfer, transferFrom or approve, so a failed operation is treated as a success. Require the call's success and use SafeERC20 for tokens.
Full article Weird ERC-20 Tokens: 12 Edge Cases and a Checklist
Unhealthy liquidation
Also called health score decreases after liquidation, worse health after liquidation
An unhealthy liquidation is a partial liquidation that leaves a position less healthy than before, usually by seizing high-LTV collateral first from a multi-collateral basket, which lowers its average LTV. Liquidating the lowest-LTV assets first keeps health from falling.
Full article 3 Critical Smart Contract Vulnerabilities Explained
Unsafe downcast
Also called downcasting overflow, unsafe cast, silent truncation
An unsafe downcast is a cast from a larger integer type to a smaller one, such as uint256 to uint128, that silently truncates instead of reverting, even in Solidity 0.8. Packed storage slots are where it hides; OpenZeppelin's SafeCast makes the cast revert.
Full article 21 Sneaky Solidity Bugs to Catch Before You Deploy
Untrusted external call
Also called external call, arbitrary external call, external call vulnerability
An untrusted external call is a call from a contract to an address it does not control, such as a user, a callback contract or an arbitrary token. Each one carries four risks to check: reentrancy, denial of service, gas griefing and unsafe return data.
Full article External Call Vulnerabilities in Solidity: 4 Attacks
Zero-amount transfer
Also called 0 amount transfer, zero value transfer, zero-amount withdrawal
A zero-amount transfer is a transfer, withdrawal or redemption of zero tokens, which passes allowance checks without any approval. Attackers use it to change another user's state, such as resetting a withdrawal cooldown; some tokens also revert on zero transfers, which can block liquidations.
Full article 3 Critical Smart Contract Vulnerabilities Explained
21 terms
Attacks and exploits
How attackers turn a bug or a market into profit: MEV, oracle manipulation, flash loans and governance attacks.
Back-running
Also called backrunning, back running
Back-running is placing a transaction immediately after a target transaction to act on the state it leaves, such as unstaking right after a reward compound. Combined with front-running, it forms the sandwich attack.
Full article Smart Contract Vulnerabilities List: 22 to Check First
Block reorg attack
Also called reorg attack, chain reorganization attack
A block reorg attack exploits a design that breaks when recorded blocks are reorganized, such as pool addresses derived only from a global nonce. After a reorg, the attacker's pool can take the nonce, and the address, that users already funded.
Full article Smart Contract Vulnerabilities List: 22 to Check First
Donation attack
Also called direct transfer attack, balanceof inflation
A donation attack is a transfer of assets to a protocol, without shares or credit in return, made to move a value it computes, such as a balanceOf-based share price. It drives the ERC-4626 inflation attack and was part of the Euler Finance exploit.
Full article Smart Contract Vulnerabilities List: 22 to Check First
Exploit
Also called exploit vs vulnerability, smart contract exploit, hack
An exploit is the concrete attack, a sequence of transactions or an attack contract, that turns a vulnerability into harm such as stolen funds, bad debt or frozen withdrawals. The vulnerability is the flaw; auditors show it is exploitable with a proof of concept.
Related article How to Find Critical Vulnerabilities in Smart Contracts
Flash loan
Also called flashloan, flash borrow
A flash loan is an uncollateralized loan borrowed and repaid, usually with a small fee, within one transaction, which reverts if it is not repaid. It gives anyone large temporary capital, so attacks that need capital for only one transaction cost almost nothing.
Full article Smart Contract Vulnerabilities List: 22 to Check First
Flash loan attack
Also called flash loan exploit, flash-loan attack
A flash loan attack is an exploit funded by a flash loan, where borrowed capital moves a price, balance or vote within one transaction before the loan is repaid. It breaks protocols that assume attackers lack capital, such as those that read spot prices.
Full article Oracle Manipulation Attacks: From Spot Price to TWAP
Flash loan governance attack
Also called flash-loaned voting power, flash loan voting attack, beanstalk exploit
A flash loan governance attack borrows governance tokens, votes and executes a proposal, then repays the loan in one transaction. Beanstalk lost over $180 million this way through an emergency commit path, so voting and execution must never share a transaction.
Full article DAO Governance Attacks: How Proposals Get Hijacked
Front-running
Also called frontrunning, front running, front-running attack
Front-running is placing a transaction ahead of a pending one, usually by watching the public mempool and paying a higher priority fee. Attackers use it to capture a coming value change, such as a reward jump, or to make the victim's transaction revert.
Full article Front Running Smart Contracts: How the Attacks Work
Gas manipulation
Also called gas manipulation attack, unbounded swap path
Gas manipulation is using an order's gas cost to control whether a keeper can execute it, for example with a swap path sized just over the block gas limit. Once prices move, the attacker cuts the callback's gas and executes at the old price.
Full article 6 Critical DeFi Vulnerabilities From Real Audits
Governance attack
Also called DAO attack, DAO governance attack, malicious proposal
A governance attack exploits a DAO's voting or execution logic to pass a proposal most holders would reject, such as one sending the treasury to the attacker. Common causes are reusable votes, flash-loaned votes and buggy or backdoored proposal contracts.
Full article DAO Governance Attacks: How Proposals Get Hijacked
Griefing attack
Also called griefing, grief
A griefing attack harms users or a protocol without an obvious profit for the attacker, who may even pay to cause it. Examples are erasing other users' bids, burning a keeper's gas or blocking withdrawals; griefing that locks every user's funds is critical.
Maximal extractable value (MEV)
Also called MEV, miner extractable value
Maximal extractable value (MEV) is the value that can be extracted from block production, beyond the block reward and gas fees, by including, excluding or reordering transactions in a block. Sandwich attacks, DEX arbitrage and liquidations are common sources.
Related article Front Running Smart Contracts: How the Attacks Work
Price oracle manipulation
Also called oracle manipulation, oracle manipulation attack, price manipulation
Price oracle manipulation is an attack that moves a price a protocol computes from onchain values, such as a pool's spot price or a vault's balance over supply, within the transaction that uses it. The attacker borrows against overvalued collateral and walks away.
Full article Oracle Manipulation Attacks: From Spot Price to TWAP
Replay attack
Also called transaction replay, cross-chain replay
A replay attack resubmits a signed message or transaction that was already valid, so the authorized action runs again on the same contract, another contract or another chain. Binding each signature to a used nonce, the chain ID and the verifying contract prevents it.
Full article Smart Contract Vulnerabilities List: 22 to Check First
Reward compound sandwich
Also called reward compounding sandwich, sandwiched reward compound, reward front-running
A reward compound sandwich stakes just before a function adds rewards to a shared pool in one step, then unstakes right after, often in the same block. The attacker takes rewards owed to long-term stakers; smooth accrual, a fee or a lockup removes the gain.
Full article 6 Critical DeFi Vulnerabilities From Real Audits
Risk-free trade
Also called risk free trade, delayed order execution attack
A risk-free trade is an exploit where a trader can choose, after prices move, whether an order executes at an earlier price, so only winning trades go through. It usually comes from forcing execution to revert, then flipping a switch, and is generally rated critical.
Sandwich attack
Also called sandwich trading, sandwiching
A sandwich attack is a front-running attack on an AMM swap: the attacker trades just before the victim to move the price, then trades back right after. A tight slippage limit, set as a minimum output amount, makes the victim's swap revert instead.
Full article Sandwich Attacks in Crypto and Slippage Protection
Spot price manipulation (slot0)
Also called slot0 manipulation, spot price oracle, reserve manipulation
Spot price manipulation is moving an AMM pool's current price, read from Uniswap V3's slot0 or raw reserves, with a large swap, often flash-loaned, then using a protocol that reads it before swapping back. Pricing from slot0 or raw reserves is almost always a finding.
Full article Oracle Manipulation Attacks: From Spot Price to TWAP
Sybil attack
Also called Sybil, multi-account farming
A Sybil attack splits funds or activity across many accounts to earn more than one account could, such as extra incentives or rewards. It is usually visible in reward code, and it can be combined with front-running a reward compound.
Full article Smart Contract Vulnerabilities List: 22 to Check First
TWAP manipulation
Also called TWAP oracle manipulation, multi-block manipulation
TWAP manipulation is holding a pool's price at a manipulated level across several blocks so that a time-weighted average price oracle records it. Flash loans cannot do it, but a block proposer controlling consecutive blocks can, and it gets cheaper in low-liquidity pools.
Full article Oracle Manipulation Attacks: From Spot Price to TWAP
Unliquidatable hedge
Also called unliquidatable long and short
The unliquidatable hedge is an attack on PnL-based protocols: open a long and a short on the same token, with a knob that blocks liquidation until a position is insolvent. Each side's loss is capped at its collateral while the other side's gain is not.
Full article 13 Liquidation Vulnerabilities Every DeFi Auditor Must Know
18 terms
Tokens and token standards
ERC-20 and the token behaviors that break integrations, plus vaults and permits.
Approval race condition
Also called approve front-running, ERC-20 approve race, allowance double spend
The approval race condition is a front-running attack on ERC-20 approve: when an owner changes an allowance from one nonzero value to another, the spender spends the old allowance first, then the new one. USDT requires a reset to zero, so nonzero-to-nonzero approvals revert.
Full article Weird ERC-20 Tokens: 12 Edge Cases and a Checklist
ERC-20
Also called ERC20, EIP-20, fungible token standard
ERC-20 is Ethereum's fungible token standard, defining functions such as transfer, transferFrom, approve and balanceOf, with transfer, transferFrom and approve declared to return a boolean. Many deployed tokens deviate from it, so integrations must handle weird ERC-20 behavior.
Related article Weird ERC-20 Tokens: 12 Edge Cases and a Checklist
ERC-721
Also called ERC721, NFT standard, non-fungible token standard
ERC-721 is the non-fungible token standard, where each token ID has a single owner. Its safeTransferFrom calls onERC721Received on a contract recipient, which hands that contract control and can enable reentrancy or a reverting transfer, and ownerOf reverts for an unminted ID.
Related article Reentrancy Attacks Explained: Every Type and How to Find It
ERC-777
Also called ERC777, ERC-777 hooks, tokens with callbacks
ERC-777 is a token standard whose transfers call hooks on the sender, the recipient or both, handing control to those addresses during the transfer. Treat every ERC-777 transfer as an external call that can re-enter the system while its state is outdated.
Full article Weird ERC-20 Tokens: 12 Edge Cases and a Checklist
ERC-2612 permit
Also called permit, EIP-2612, ERC-20 permit, gasless approval
ERC-2612 is an ERC-20 extension that adds permit, which sets an allowance from the owner's signed EIP-712 message instead of an approve call. Each permit carries a nonce and a deadline, and anyone can submit it, so a front-runner can use it first.
Related article Smart Contract Vulnerabilities List: 22 to Check First
ERC-4626 inflation attack
Also called first depositor attack, vault inflation attack, share inflation attack
An ERC-4626 inflation attack front-runs a vault's first deposit: the attacker mints one wei of shares, then donates assets to inflate the share price, so the victim's shares round to zero. The attacker then redeems the victim's deposit.
Full article ERC-4626 Inflation Attack: 3 Red Flags and 2 Fixes
ERC-4626 tokenized vault
Also called ERC4626, tokenized vault standard, vault shares
ERC-4626 is the tokenized vault standard: depositors receive ERC-20 shares in a pool of an underlying asset and later redeem them at the vault's current exchange rate. Share math that rounds down and prices from balanceOf can expose a vault to the inflation attack.
Full article ERC-4626 Inflation Attack: 3 Red Flags and 2 Fixes
ERC-7631 (DN404)
Also called DN404, dual nature token pair, semi-fungible token
ERC-7631 is a proposed token standard that pairs an ERC-20 contract with an ERC-721 contract, so moving enough fungible base tokens also moves mirrored NFTs. DN404 implements it, and a 2024 review of DN404 found high-severity NFT theft bugs.
Fee-on-transfer token
Also called FoT token, transfer tax token, burn-on-transfer token
A fee-on-transfer token deducts a fee from each transfer, so the recipient gets less than the amount sent. Protocols that credit the sent amount overstate balances; measure the contract's balance before and after the transfer and credit the difference.
Full article Weird ERC-20 Tokens: 12 Edge Cases and a Checklist
Flash-mintable token
Also called flash mint, flash minting
A flash-mintable token, such as DAI, lets anyone mint a very large amount within one transaction as long as it is repaid, plus a small fee, by the end. Supply on that scale is a knob for manipulating any system that uses the token.
Full article Weird ERC-20 Tokens: 12 Edge Cases and a Checklist
Missing return value token
Also called no return value token, USDT return value, non-standard return values
A missing return value token, such as USDT on Ethereum mainnet, returns nothing from transfer, transferFrom and approve, although IERC20 declares a boolean. Calling it through the standard interface reverts on decoding, so integrations use SafeERC20 instead.
Full article Weird ERC-20 Tokens: 12 Edge Cases and a Checklist
Pausable token
Also called pausable ERC-20, token pause
A pausable token lets a trusted address halt transfers for a period, so every transaction that moves the token reverts. Integrators take on that counterparty risk, and a pause can block withdrawals or liquidations much like a blacklist.
Full article Weird ERC-20 Tokens: 12 Edge Cases and a Checklist
Rebasing token
Also called rebase token, elastic supply token
A rebasing token changes holders' balances as its supply adjusts, outside transfers or during them, so a balance a contract recorded can drift from what it holds. Rebasing breaks most accounting, so many protocols exclude these tokens or verify the amount actually received.
Full article Weird ERC-20 Tokens: 12 Edge Cases and a Checklist
SafeERC20 (safeTransfer)
Also called safeTransfer, safeTransferFrom, SafeERC20
SafeERC20 is OpenZeppelin's library whose safeTransfer and safeTransferFrom revert whenever an ERC-20 call fails, including for tokens that return false instead of reverting, while still supporting tokens that return no value. It gives every token the same failure behavior.
Full article Weird ERC-20 Tokens: 12 Edge Cases and a Checklist
Token blocklist
Also called token blacklist, blacklistable token, USDC blacklist, blocklist token
A token blocklist lets a privileged role blacklist addresses so the token rejects their transfers; USDC reverts any transfer to or from a blacklisted address. A blacklisted recipient can then make a must-succeed transfer revert, such as returning collateral in a liquidation.
Full article Weird ERC-20 Tokens: 12 Edge Cases and a Checklist
Token decimals mismatch
Also called decimals mismatch, token decimals, decimal scaling bug
A token decimals mismatch is a bug where math assumes every token has 18 decimals, or scales amounts wrongly, although USDC has 6 and YAM V2 has 24. Misscaled amounts misprice collateral or lose precision, so normalize each token's decimals explicitly.
Full article Weird ERC-20 Tokens: 12 Edge Cases and a Checklist
Weird ERC-20 token
Also called weird ERC20, non-standard ERC-20, ERC-20 edge cases
A weird ERC-20 token is a token whose behavior departs from what integrating protocols assume, such as fees on transfer, rebasing balances, callbacks, missing return values, blacklists, strict approval rules or unusual decimals. Protocols that accept arbitrary tokens must handle each one.
Full article Weird ERC-20 Tokens: 12 Edge Cases and a Checklist
21 terms
Proxies and upgradeability
How contracts change after deployment, and the storage and access bugs that come with it.
_authorizeUpgrade (unprotected UUPS upgrade)
Also called _authorizeUpgrade, unprotected UUPS upgrade, UUPS upgrade access control, upgradeToAndCall
_authorizeUpgrade is the internal hook in OpenZeppelin's UUPSUpgradeable that upgradeToAndCall calls before switching implementations, and it has no access control by default. If a UUPS implementation does not override it with onlyOwner or similar, anyone can upgrade the proxy to code of their choosing.
Full article 5 Upgradeable Contract Vulnerabilities to Check
Beacon proxy
Also called upgradeable beacon, beaconproxy, beacon pattern
A beacon proxy is a proxy that reads its implementation address from a shared beacon contract, so one upgradeTo call on the beacon upgrades every proxy pointing at it. Proxies with different upgrade histories can hold different storage layouts, which makes storage migrations error-prone.
Full article Upgradeable Smart Contracts Explained: 5 Patterns
CREATE2
Also called CREATE2 opcode, deterministic deployment, deterministic contract address
CREATE2 is the EVM opcode that deploys a contract to an address computed from the deployer, a salt and the creation code's hash. If that creation code loads runtime code from another contract, different code can reappear at the address after a self-destruct.
Full article Metamorphic Contracts and the Tornado Cash Exploit
Delegatecall
Also called delegate call, delegatecall opcode
Delegatecall is an EVM call that runs another contract's code in the caller's context: msg.sender, msg.value and address(this) stay the same, and every storage write lands in the caller. Proxies are built on it, and it is the root of storage collisions and selector clashes.
Full article Upgradeable Smart Contracts Explained: 5 Patterns
Diamond proxy (EIP-2535)
Also called diamond standard, diamond pattern, ERC-2535, multi-facet proxy, facet, diamond cut
A diamond proxy (EIP-2535) is a proxy that maps each function selector to one of several implementation contracts, called facets, and delegatecalls the matching one. A diamond cut adds, replaces or removes routes, allowing per-function upgrades at the cost of complexity and storage collision risk.
Full article Upgradeable Smart Contracts Explained: 5 Patterns
EIP-1967 storage slots
Also called ERC-1967, EIP1967, proxy storage slots, implementation slot
EIP-1967 (ERC-1967) standardizes the storage slots where a proxy keeps its implementation, admin and beacon addresses, each the keccak-256 hash of a label such as eip1967.proxy.implementation, minus 1. Pseudo-random slots keep the implementation's own variables from overwriting them.
Full article Upgradeable Smart Contracts Explained: 5 Patterns
EIP-6780
Also called EIP6780, SELFDESTRUCT only in same transaction
EIP-6780 changed SELFDESTRUCT so it only deletes a contract when called in the transaction that created it; in any later transaction it just sends the contract's ether to the target. It shipped in Ethereum's Dencun upgrade in March 2024 and curtails metamorphic contracts.
Full article Metamorphic Contracts and the Tornado Cash Exploit
Eternal storage
Also called eternal storage pattern, data store pattern
Eternal storage is an upgradeability pattern with no proxy or delegatecall: one data contract holds all state, and permissioned logic contracts read and write it. Upgrades swap a logic contract, so the risks are setters missing access control and retired logic contracts keeping write access.
Full article Upgradeable Smart Contracts Explained: 5 Patterns
Function selector clash
Also called selector clashing, function selector collision, proxy selector clash
A function selector clash occurs when a proxy and its implementation each have a function with the same four-byte selector, so calls meant for the implementation run the proxy's function instead. The compiler detects clashes within one contract, but not across the two.
Full article Smart Contract Vulnerabilities List: 22 to Check First
Implementation contract
Also called logic contract, implementation
An implementation contract (logic contract) holds the code a proxy delegatecalls into, while the proxy holds the live state. Its own storage does not matter to the application, so its constructor should call _disableInitializers to stop anyone initializing it directly.
Full article Upgradeable Smart Contracts Explained: 5 Patterns
Initializer
Also called initialize function, initializer modifier, _disableinitializers, onlyinitializing
An initializer is the function an upgradeable contract uses in place of a constructor, run once through the proxy so values such as the owner land in the proxy's storage. It needs the initializer modifier and must call each upgradeable parent's init function.
Full article 5 Upgradeable Contract Vulnerabilities to Check
Metamorphic contract
Also called metamorphic smart contract, metamorphosis attack
A metamorphic contract is a contract whose code can change while its address stays the same: it self-destructs, then different code is redeployed there with CREATE or CREATE2. It enabled the Tornado Cash governance takeover; since EIP-6780 it needs the self-destruct in the creation transaction.
Full article Metamorphic Contracts and the Tornado Cash Exploit
Namespaced storage (ERC-7201)
Also called ERC-7201, EIP-7201, storage namespace, custom:storage-location
Namespaced storage (ERC-7201) keeps a contract's state variables in a struct at a slot derived from the hash of a namespace string, far from the slots the compiler assigns in order. OpenZeppelin's upgradeable contracts use it from version 5.0 instead of storage gaps.
Full article 5 Upgradeable Contract Vulnerabilities to Check
Proxy contract
Also called proxy, upgradeable proxy, delegating proxy
A proxy contract is a contract that holds an application's state and forwards each call by delegatecall to a separate implementation contract, so changing the stored implementation address upgrades the logic. Because the implementation writes to the proxy's storage, layout mistakes cause storage collisions.
Full article Upgradeable Smart Contracts Explained: 5 Patterns
SELFDESTRUCT
Also called SELFDESTRUCT opcode, self-destruct, suicide opcode
SELFDESTRUCT is the EVM opcode that sends a contract's whole ether balance to a target and, when it runs in the contract's creation transaction, deletes its code and storage. Before EIP-6780 it deleted the account in any transaction, which made metamorphic contracts possible.
Full article Metamorphic Contracts and the Tornado Cash Exploit
Storage collision
Also called storage clash, storage layout collision, proxy storage collision
A storage collision occurs when two contracts sharing one storage space assign different variables to the same slot, usually because an upgrade inserted or reordered state variables behind a proxy. The added variable reads the old one's value, which almost always causes a critical bug.
Full article 5 Upgradeable Contract Vulnerabilities to Check
Storage gap
Also called __gap, storage gap array, storage padding
A storage gap is a fixed-size array, usually named __gap, at the end of an upgradeable base contract that reserves slots for future variables. Without one, adding a variable to the base shifts every inheriting contract's slots and corrupts state on upgrade.
Full article 5 Upgradeable Contract Vulnerabilities to Check
Transparent proxy
Also called transparent upgradeable proxy, transparentupgradeableproxy, ProxyAdmin
A transparent proxy is a proxy that holds its own admin and upgrade logic: admin calls can only upgrade, and all other calls are delegated to the implementation. Because the admin cannot use the application, OpenZeppelin assigns that role to a ProxyAdmin contract.
Full article Upgradeable Smart Contracts Explained: 5 Patterns
Unprotected initializer
Also called uninitialized proxy, uninitialized implementation, missing initializer modifier
An unprotected initializer is an initialize function anyone can still call, because it lacks the initializer modifier or the implementation never disabled it, so the caller becomes owner. On chains without EIP-6780, an owner of a UUPS implementation can self-destruct it and brick every proxy.
Full article 5 Upgradeable Contract Vulnerabilities to Check
Upgradeable smart contract
Also called upgradeable contract, smart contract upgradeability, upgradeability pattern
An upgradeable smart contract is a contract whose logic can be changed while its address and state stay the same. The five main patterns are eternal storage, transparent proxies, UUPS proxies, beacon proxies and diamonds, and each trades simplicity, gas and flexibility differently.
Full article Upgradeable Smart Contracts Explained: 5 Patterns
UUPS proxy
Also called Universal Upgradeable Proxy Standard, ERC-1822, EIP-1822, UUPSUpgradeable
A UUPS proxy (Universal Upgradeable Proxy Standard, ERC-1822) is a proxy whose upgrade logic lives in the implementation, not the proxy. The implementation must override _authorizeUpgrade with access control, and upgrading to an implementation without upgrade logic leaves the proxy unable to upgrade again.
Full article Upgradeable Smart Contracts Explained: 5 Patterns
15 terms
EVM and Solidity internals
The machine underneath: stack, memory, calldata, storage and encoding.
ABI encoding
Also called abi.encode, contract ABI, head and tail encoding, dynamic type
ABI encoding is the Solidity ABI's format for call arguments and return data in 32-byte words. Static values sit in place; each dynamic value, like bytes or a string, has a head holding an offset to its tail, counted from the enclosing tuple's start.
Full article Ethereum Calldata Explained: Decoding a Real Multicall
Calldata
Also called call data, input data, transaction input
Calldata is the read-only input of a call: a four-byte function selector followed by ABI-encoded arguments in 32-byte words. Because it cannot be written, reading it is cheaper than memory, so parameters a function never modifies should be declared calldata.
Full article Ethereum Calldata Explained: Decoding a Real Multicall
Ethereum Virtual Machine (EVM)
Also called EVM, Ethereum Virtual Machine
The Ethereum Virtual Machine (EVM) is the stack-based machine that executes smart contract bytecode as a sequence of opcodes, moving 32-byte words between the stack, memory, calldata and storage. Only storage persists after a transaction, and it is the most expensive place to keep data.
Full article How the EVM Works: Stack, Memory, Calldata and Storage
EVM memory
Also called memory, Solidity memory layout, memory expansion, scratch space, zero slot
EVM memory is the temporary area a transaction reads and writes in 32-byte words at offsets such as 0x00, 0x20 and 0x40. Solidity reserves 0x00 to 0x3f as scratch space, 0x40 for the free memory pointer and 0x60 as the zero slot.
Full article How the EVM Works: Stack, Memory, Calldata and Storage
EVM stack
Also called stack, EVM stack machine
The EVM stack is a last-in, first-out area of 32-byte words where opcodes take their inputs and leave their results, such as uints, addresses and pointers into memory or storage. Like memory and calldata, it does not persist after the transaction.
Full article How the EVM Works: Stack, Memory, Calldata and Storage
Free memory pointer
Also called FMP, 0x40 free memory pointer
The free memory pointer is the word at memory offset 0x40 that holds the first unused memory address, initially 0x80. High-level Solidity updates it automatically, but mstore in inline assembly does not, so Solidity code that runs afterward can overwrite what the assembly wrote.
Function selector
Also called method id, selector, 4-byte selector, msg.sig
A function selector is the first four bytes of the keccak-256 hash of a function's signature, such as multicall(bytes[]), placed at the start of calldata to say which function to run. The contract's dispatcher compares it with each function's selector and jumps to the match.
Full article How the EVM Works: Stack, Memory, Calldata and Storage
Gas
Also called gas fee, gas price, priority fee, gas limit
Gas is the unit that measures the computation an EVM transaction uses: every opcode has a cost, and the sender pays gas used times the base fee plus a priority fee. On a public mempool, front-runners land first by outbidding a pending transaction's priority fee.
Full article Front Running Smart Contracts: How the Attacks Work
Immutable variable
Also called immutable, Solidity immutable
An immutable variable is a Solidity state variable set once in the constructor and written into the contract's bytecode rather than storage. That saves gas, but when a proxy upgrades its implementation, the old bytecode's immutable values do not carry over.
Full article 21 Sneaky Solidity Bugs to Catch Before You Deploy
Inline assembly
Also called assembly block, Solidity inline assembly
Inline assembly is Yul code inside an assembly { } block of a Solidity function, used to work with memory, storage and calldata directly. It bypasses several Solidity safety checks, so reviewers should confirm it updates the free memory pointer and leaves Solidity's memory intact.
msg.value
Also called msg value, callvalue
msg.value is the amount of wei sent with the current call. It stays fixed for the whole call, across every loop iteration and every delegatecall, so code that credits it inside a loop or a multicall counts a single payment several times.
Full article 21 Sneaky Solidity Bugs to Catch Before You Deploy
Multicall
Also called multicall function, batched calls
A multicall is a function that executes a list of calldata items in one transaction, usually by delegatecalling its own contract with each. If it is payable, msg.value stays the same in every iteration, so functions that read it can count one payment many times.
Full article Ethereum Calldata Explained: Decoding a Real Multicall
Opcode
Also called EVM opcode, EVM instruction
An opcode is a single EVM instruction, such as ADD, MSTORE or SLOAD, encoded as one byte in a contract's bytecode. PUSH1 to PUSH32 carry 1 to 32 bytes of data inline, so the byte 0x7F followed by 32 bytes pushes a full word.
Full article How the EVM Works: Stack, Memory, Calldata and Storage
Storage slot
Also called contract storage, storage layout, SLOAD, sstore
A storage slot is one 32-byte word of a contract's persistent storage, keyed by a 256-bit number and accessed with SLOAD and SSTORE. Solidity assigns state variables to slots in declaration order, which is why reordering variables in an upgrade corrupts a proxy's state.
Full article How the EVM Works: Stack, Memory, Calldata and Storage
Yul
Also called Yul assembly, Solidity assembly
Yul is the low-level intermediate language Solidity uses for inline assembly, giving direct access to EVM memory, storage and calldata. The compiler will not stop Yul from writing to reserved memory, and mstore does not update the free memory pointer.
40 terms
DeFi mechanics
AMMs, lending, CDPs, perps and oracles, and where each one's security edges are.
App-specific rollup (appchain)
Also called appchain, app chain, application-specific rollup
An app-specific rollup (appchain) is a rollup built for one application, so its team controls the execution environment, captures the value it creates and can tune latency, as onchain order books do for market makers. Users then rely on that rollup's sequencer for ordering.
Related article 21 Sneaky Solidity Bugs to Catch Before You Deploy
Automated market maker (AMM)
Also called AMM, automated market maker, AMM DEX
An automated market maker (AMM) is a smart contract exchange that prices trades from its own token reserves using a formula such as the constant product, not an order book. Each swap moves the pool's price, which spot price manipulation and sandwich attacks exploit.
Full article The Constant Product AMM: Swaps, LPs and Impermanent Loss
Bad debt
Also called protocol bad debt, uncovered debt
Bad debt is debt a protocol cannot recover because a position's collateral is worth less than it owes, so the borrower walks away. MakerDAO records it as sin in the Vow contract and covers it by minting and selling MKR.
Collateralization ratio
Also called collateral ratio, c-ratio, liquidation ratio
A collateralization ratio is a position's collateral value divided by its debt, with a minimum set per collateral type, such as 1.5 for ether in MakerDAO. Below the minimum the position can be liquidated; the margin above 1 absorbs price gaps and late liquidations.
Collateralized debt position (CDP)
Also called CDP, collateralized debt position, vault
A collateralized debt position (CDP) is a loan in which a user locks collateral and borrows a stablecoin worth less than it, such as DAI from MakerDAO or MIM from Abracadabra Money. If the collateral falls past the protocol's threshold, the position is liquidated.
Full article What Is a CDP in Crypto? Abracadabra Money Explained
Concentrated liquidity
Also called range-bound liquidity, Uniswap V3 liquidity, concentrated liquidity AMM
Concentrated liquidity is the Uniswap V3 design in which liquidity providers supply liquidity only between two chosen ticks, not across the whole price curve. The same capital earns more fees and cuts price impact, but a position goes inactive once price leaves its range.
Constant product formula (x * y = k)
Also called x*y=k, XYK, constant product AMM
The constant product formula, x * y = k, keeps the product of a two-token pool's reserves constant during a swap. A trader adding dy of token y receives dx = x - k / (y + dy) before fees; only added liquidity raises k.
Full article The Constant Product AMM: Swaps, LPs and Impermanent Loss
DAI
Also called DAI stablecoin, MakerDAO, multi-collateral DAI
DAI is MakerDAO's overcollateralized stablecoin, borrowed against collateral locked in vaults at a set ratio, such as $1.50 of ether per DAI. Its peg rests on stability fees, the DAI Savings Rate, debt ceilings and borrowers repaying $1 of debt with DAI bought below $1.
DAI Savings Rate (DSR)
Also called DSR, DAI Savings Rate
The DAI Savings Rate (DSR) is the yield MakerDAO pays to anyone who deposits DAI into its savings contract, with no lockup. Governance raises it to increase demand for DAI and lift its price, and lowers it to do the reverse.
Debt ceiling
Also called borrow cap, debt cap
A debt ceiling is a cap on how much of a stablecoin can be borrowed, for example against one collateral type in MakerDAO, and is one of the levers governance uses on DAI's supply. Abracadabra's Cauldrons enforce a similar cap on total borrows.
DeFi primitive
Also called DeFi building block, DeFi archetype, money lego
A DeFi primitive is a basic protocol design that other applications reuse, such as an AMM, a lending market, a perpetuals exchange, an optimizer vault or cross-chain infrastructure. Knowing how each is usually built lets auditors gain context faster and spot familiar bugs.
Related article GMX V2 Explained: Inside the Synthetics Exchange
Dutch auction liquidation
Also called Dutch auction, descending price auction
A Dutch auction liquidation sells a liquidated position's collateral at a price that starts high and falls over time, until bids raise enough to repay the debt plus a liquidation fee. MakerDAO liquidates vaults this way and returns any leftover collateral to the vault owner.
Funding rate
Also called funding fee, funding payment
A funding rate is the periodic payment between the two sides of a perpetual futures market; in GMX V2, the dominant side, longs or shorts, pays the minority side. Liquidation checks must deduct pending funding fees, or a position that should be liquidatable looks healthy.
Related article 13 Liquidation Vulnerabilities Every DeFi Auditor Must Know
GM pool (GMX V2)
Also called GM pool, GM token, GMX V2 market, market token, index token
A GM pool is a GMX V2 market: a contract holding backing long and short tokens that pay out profitable trades on an index token, which need not exist onchain. Its balance mixes deposits, trader collateral and the impact pool, which a DataStore tracks separately.
Full article GMX V2 Explained: Inside the Synthetics Exchange
Health factor
Also called health score, position health
A health factor is a lending position's collateral value, often weighted by each token's LTV, divided by its debt, with the position liquidatable below 1. A liquidation should never lower it, yet seizing the highest-LTV collateral first can leave a position less healthy.
Full article 3 Critical Smart Contract Vulnerabilities Explained
Impermanent loss
Also called divergence loss, IL
Impermanent loss is the loss a liquidity provider takes, relative to holding, when the prices of a pool's two tokens diverge. Swaps leave LPs holding more of the token that fell; in one example, 5 ether and 25,000 DAI ended about 2,777 DAI short.
Full article The Constant Product AMM: Swaps, LPs and Impermanent Loss
Insolvent position
Also called insolvency, underwater position, insolvent liquidation
An insolvent position is one whose collateral can no longer cover its debt or losses, unlike a liquidatable position, which has only crossed the safety threshold. Every dollar owed beyond the collateral's value is bad debt, so auditors should always test the insolvent liquidation path.
Full article 13 Liquidation Vulnerabilities Every DeFi Auditor Must Know
Interest rate swap
Also called IRS, fixed for floating swap
An interest rate swap is a contract in which two parties exchange interest payments on a notional amount that never changes hands, usually one paying a fixed rate and the other a floating rate. It lets a borrower move from floating to fixed without refinancing.
Related article DeFi Reward Accounting Vulnerabilities: Stepwise Jumps
Keeper
Also called keeper bot, liquidation bot, order keeper
A keeper is an offchain bot that sends transactions a protocol needs but cannot trigger itself, such as executing queued GMX V2 orders or starting MakerDAO liquidations. If a user can make keeper execution revert until prices suit them, they may get a risk-free trade.
Full article GMX V2 Explained: Inside the Synthetics Exchange
Lending protocol
Also called money market, lending market, borrow and lending protocol
A lending protocol is a DeFi market where users deposit collateral and borrow other assets against it, up to a loan-to-value limit per collateral token, as in Aave and Compound. Positions past that limit must be liquidated on time, or bad debt remains.
Full article 13 Liquidation Vulnerabilities Every DeFi Auditor Must Know
Leverage looping
Also called looping, recursive borrowing, leveraged loop
Leverage looping is building a leveraged position by repeatedly borrowing against collateral, buying more of the collateral asset and depositing it again, as with ether in a MakerDAO vault. Each loop adds exposure and moves the position closer to its liquidation threshold.
Liquidation
Also called liquidate, forced closure, liquidation bonus
Liquidation is the forced closing of a position whose collateral, or collateral plus PnL, has fallen below the protocol's threshold, often by a third party paid a bonus. Anything that makes it revert, like a blacklisted recipient, blocks it and risks bad debt.
Full article 13 Liquidation Vulnerabilities Every DeFi Auditor Must Know
Liquidity pool
Also called pool, AMM pool
A liquidity pool is a smart contract holding reserves of two or more tokens that traders swap against, funded by liquidity providers who receive LP tokens. Pricing assets from its raw reserves or spot price is a red flag, since one transaction can move both.
Full article The Constant Product AMM: Swaps, LPs and Impermanent Loss
Loan-to-value (LTV)
Also called LTV, LTV ratio, loan-to-value ratio
Loan-to-value (LTV) is the maximum share of a collateral's value that can be borrowed against it, set per collateral token, such as 70% for wrapped ether in an Abracadabra Cauldron. A position past its LTV is liquidatable while solvent, before it leaves bad debt.
Full article What Is a CDP in Crypto? Abracadabra Money Explained
LP token
Also called liquidity provider token, pool share token
An LP token is a token minted to a liquidity provider in proportion to their deposit's share of a pool, and burned to withdraw that share of each reserve. In the Beanstalk exploit, LP tokens from flash-loaned liquidity granted governance power.
Full article The Constant Product AMM: Swaps, LPs and Impermanent Loss
Money streaming
Also called token streaming, payment streaming, Superfluid stream
Money streaming is the continuous transfer of tokens at a per-second rate, with balances computed in real time instead of one transaction per payment, as in Superfluid. Superfluid holds a buffer deposit and lets sentinels close streams whose sender runs out.
Related article DeFi Reward Accounting Vulnerabilities: Stepwise Jumps
Open interest
Also called OI
Open interest is the total size of open positions in a perpetuals market, for example $3,000 when one trader holds a $1,000 position and another $2,000. On every increase, GMX V2 checks that the backing tokens could pay out that open interest if it profits.
Full article GMX V2 Explained: Inside the Synthetics Exchange
Overcollateralization
Also called overcollateralized, overcollateralised
Overcollateralization is the requirement to post more collateral than the value borrowed, such as $1.50 per $1 of debt. The buffer exists because prices can gap and liquidations can be late; at 1:1, a small price wick leaves debt the collateral cannot cover.
Perpetual futures (perps)
Also called perps, perpetual swap, perpetuals exchange, perp DEX
Perpetual futures (perps) are leveraged long or short positions on an asset's price with no expiry, closed whenever the trader chooses to realize profit or loss. Onchain perps exchanges such as GMX track each position's collateral plus PnL and liquidate it past a threshold.
Full article GMX V2 Explained: Inside the Synthetics Exchange
Price impact
Also called market impact, execution price impact
Price impact is how far a trade moves an AMM pool's price, making the trader's average execution price worse than the quoted one. In a worked constant product example, 5,000 DAI into a pool quoting 5,000 DAI per ether filled at about 6,000.
Full article The Constant Product AMM: Swaps, LPs and Impermanent Loss
Price oracle
Also called oracle, onchain oracle, price feed
A price oracle is the source a protocol reads to value assets: a feed aggregated offchain and pushed onchain, like Chainlink, or a price computed from onchain state, like a DEX pool. An onchain-computed price can be manipulated in the transaction that uses it.
Full article Oracle Manipulation Attacks: From Spot Price to TWAP
Rollup
Also called layer 2 rollup, L2 rollup, rollups
A rollup is a layer 2 chain that executes transactions off Ethereum and posts their data to Ethereum, where layer 1 consensus settles the results. Contracts on it depend on its sequencer; if the sequencer is down, oracle prices are likely stale.
Related article 21 Sneaky Solidity Bugs to Catch Before You Deploy
Slippage
Also called price slippage, slippage tolerance
Slippage is the difference between the price a trader expects when submitting a swap and the price it actually executes at, caused by the trade's own price impact and by transactions that execute first. MEV searchers profit from swaps that accept unlimited slippage.
Full article Sandwich Attacks in Crypto and Slippage Protection
Slippage protection (minimum output)
Also called slippage control, slippage limit, minimum amount out, amountoutmin
Slippage protection is a limit on the worst price a swap will accept, usually a minimum output amount, below which it reverts. A missing minimum, or one hard-coded to one wei, lets sandwich attackers take almost all the swap's value.
Full article Sandwich Attacks in Crypto and Slippage Protection
sqrtPriceX96
Also called sqrt price x96, slot0 price
sqrtPriceX96 is the value a Uniswap V3 pool stores in slot0 for its current price: the square root of token0's price in token1, multiplied by 2^96. Decode it by dividing by 2^96 and squaring; since any swap moves it, it is unsafe as an oracle.
Stability fee
Also called MakerDAO stability fee, DAI borrow rate
A stability fee is the interest rate a MakerDAO vault pays on the DAI it borrows. Governance raises it to push DAI's price up, because borrowers repay and supply shrinks, and lowers it to bring the price down.
Tick (Uniswap V3)
Also called Uniswap V3 tick, tick index, initialized tick
A Uniswap V3 tick is one of the discrete prices that divide the price curve, with price = 1.0001^tick, so neighboring ticks sit one basis point apart. Positions span two ticks, and a swap crossing an initialized tick adds or removes that position's liquidity.
TWAP oracle
Also called time-weighted average price, TWAP, Uniswap TWAP
A TWAP oracle reports a time-weighted average of a pool's price over a window, such as 30 minutes, rather than the spot price. That defeats single-transaction flash loan manipulation, but a block proposer controlling consecutive blocks can still move it, especially in shallow pools.
Full article Oracle Manipulation Attacks: From Spot Price to TWAP
Vat, ilk and urn (MakerDAO)
Also called vat, ilk, urn, frob, dog.bark, MakerDAO naming
Vat, ilk and urn are MakerDAO's terse names for its core CDP database contract, a collateral type and a vault. Liquidation is bark and bad debt is sin; the names cut verbosity and assumptions and ease formal verification, but slow reviews down.
37 terms
Audits and testing
How a smart contract audit is scoped, run and graded, and the testing methods behind it.
Attacker mindset
Also called attacker's mindset, adversarial mindset, adversarial thinking
The attacker mindset is an auditor's habit of looking for ways to invalidate code rather than confirm it works, assuming every function holds a critical bug. A developer's mindset validates; trusting that the developers covered every edge case is a common way to miss vulnerabilities.
Full article Smart Contract Audit Mistakes: 27 Ways to Miss Bugs
Attack knob
Also called knob, attacker knob
An attack knob is any behavior an attacker controls that could help cause a bug, such as an arbitrary external call, a division that rounds to zero or reverts, or a subtraction that can underflow. High-impact findings often combine two or more knobs.
Full article How to Audit a Smart Contract: A Complete System
Audit contest
Also called competitive audit, audit competition, security contest
An audit contest is a time-boxed competitive review in which many independent researchers examine the same code and are paid only for valid findings. It adds breadth, while a private audit's dedicated team adds depth and accountability.
Audit report
Also called security audit report, audit findings report
An audit report is the deliverable of a security review: the scope, then each finding with severity, location, proof of concept, recommended fix and resolution status. Read the status as well as the count, since an acknowledged finding has no recorded fix.
Full article How to Audit a Smart Contract: A Complete System
Audit scope
Also called scope, in-scope code, audit scoping
Audit scope is the exact set of contracts, files and commit an audit covers, usually sized in lines of code. Cost scales with the lines in scope, and anything outside it, including later changes, integrations and offchain systems, gets no assurance from the report.
Related article What Top Auditors Charge: OpenZeppelin Audit Cost and More
Audit tag (@audit)
Also called @audit tag, @audit comment, audit comment
An audit tag is a code comment marked @audit that an auditor leaves when a question or attack idea comes up, so they keep gaining context instead of chasing it. Grepping for the tags later turns them into a work list.
Full article How to Audit a Smart Contract: A Complete System
Bug bounty
Also called bug bounty program, bounty program, vulnerability reward program
A bug bounty is a standing program that pays outside researchers for vulnerabilities they find and disclose in live code, with rewards scaled by severity. Running one well means hosting it, triaging every submission, validating impact, settling severity disputes and getting fixes shipped.
Code freeze
Also called audit code freeze, frozen commit
A code freeze is the point before an audit after which the team stops changing the code under review, ideally after internal review. The last code written tends to be the most vulnerable, and many exploits trace to late or remediation changes.
Critical severity
Also called critical finding, critical vulnerability, critical bug
A critical-severity finding is one that lets an attacker easily take a significant share of a protocol's value, roughly 20% or more, or causes loss for every user, such as a denial of service trapping all deposits. Criticals are usually guaranteed and fast.
Duplicate finding
Also called duplicate, dupe, same root cause finding
A duplicate finding is one that reports the same root cause as another finding. The usual test is whether the most straightforward fix for one also fixes the other: if it does, they are one finding; if not, they are two.
Echidna
Also called Echidna fuzzer
Echidna is a smart contract fuzzer from Trail of Bits that calls a contract's functions in random sequences to break user-defined invariants and assertions. Its runs start at block.timestamp 1524785992 and block.number 4370000, not 1, which matters for time-dependent tests and Foundry reproducers.
False positive
Also called false alarm, invalid finding
A false positive is a reported finding or alert that is not a real issue, such as a suspected exploit that a validation elsewhere makes revert. PoCs and a second reviewer filter them from audits; in monitoring, one can trigger a needless pause.
Full article Smart Contract Audit Mistakes: 27 Ways to Miss Bugs
Fix review
Also called remediation review, mitigation review, remediation round, retest
A fix review is the follow-up in which auditors confirm each finding was actually resolved and the changed code added no bugs. Fixes are changes too: remediation rounds in 125 published audit reports surfaced 18 further Criticals and 119 Highs.
Full article Smart Contract Upgrade Bugs: What 49 Update Reviews Found
Formal verification
Also called formal methods, formal verification of smart contracts
Formal verification is mathematical proof that specified properties hold for every possible input, not just the inputs a test happens to try. Tools translate code into logical formulas for an SMT solver, and the guarantee is only as strong as the specification.
Full article Formal Verification of Smart Contracts: A Guide
Fuzzing
Also called fuzz testing, fuzz test, smart contract fuzzing
Fuzzing is automated testing that calls code with large numbers of random or semi-random inputs to find cases that break an assertion or revert unexpectedly. A fuzz test varies one function's inputs; invariant fuzzing also randomizes the order of calls across the whole protocol.
GTDA method (Goals, Tags, Diagram, Attack)
Also called GTDA, Goals Tags Diagram Attack
GTDA (Goals, Tags, Diagram, Attack) is a four-step auditing method: walk each feature's code path as a goal, tag questions with @audit instead of chasing them, diagram complex call paths, then attack with a toolbox of bug classes once the code is understood.
Full article How to Find Critical Vulnerabilities in Smart Contracts
High severity
Also called high finding, high-severity vulnerability
A high-severity finding is one with large consequences that is not straightforward to exploit: it needs significant capital that cannot be flash loaned, special conditions or time, or it harms users without profiting the attacker. TWAP manipulation is a typical high.
Impact and likelihood
Also called severity matrix, risk matrix, likelihood and impact matrix
Impact and likelihood are the two axes most severity matrices use: how bad an outcome is, and how probable or easy it is to cause. On a three by three grid, a medium-likelihood, high-impact issue usually rates high, though judging each axis stays subjective.
Informational finding
Also called informational, QA finding, gas optimization finding, non-critical finding
An informational finding is an audit note with no direct security impact, such as a documentation typo, a code-quality suggestion or a gas optimization. Some firms report informational, QA and gas findings as separate tiers; others fold them into low severity.
Invariant
Also called protocol invariant, safety property, property
An invariant is a property that must hold after every transaction, such as user balances never summing to more than the contract's token balance. Auditors try to break documented invariants on purpose, because a broken one almost always means a critical vulnerability.
Full article How to Audit a Smart Contract: A Complete System
Invariant testing
Also called invariant fuzzing, invariant tests, invariant suite
Invariant testing is a method that writes a protocol's core properties as executable assertions, then fuzzes millions of random but targeted call sequences to check they hold in every reachable state. The suite reruns on every change, catching regressions in fixes and upgrades.
Low severity
Also called low finding, low-severity issue
A low-severity finding is one with no material impact, or one that needs a user's or trusted admin's own mistake, such as a floating pragma, a missing zero-address check or a gas optimization. The test: would it be fine if never fixed?
Manual review
Also called manual analysis, manual code review, line-by-line review
Manual review is line-by-line reading of code by researchers who first learn what the protocol should do, finding logic errors and edge cases that tools and checklists miss. It is prone to human error, so it pairs with fuzzing and cross-checking.
Full article How to Find Critical Vulnerabilities in Smart Contracts
Medium severity
Also called medium finding, medium-severity vulnerability
A medium-severity finding is one with real but limited impact: a few dollars per user, a significant impact that is extremely rare, or a risk an attacker could build on later. Centralization risks are usually capped at medium.
Mutation testing
Also called mutant testing, mutation analysis, mutation coverage
Mutation testing is a way to test a test suite: it plants one small bug in each of many contract copies, such as turning == into !=, and runs the tests on each. A surviving mutant reveals a blind spot, even at 100% line coverage.
Full article Mutation Testing in Solidity With Gambit and Vertigo
Normalized source lines of code (nSLOC)
Also called nSLOC, normalized lines of code, normalized SLOC
Normalized source lines of code (nSLOC) is a codebase size measure, excluding comments and trivial lines with functions collapsed, used to scope and price audits. As of 2024, firms often reviewed about 1,000 nSLOC of Solidity a week, at $20,000 to $30,000 a week.
Post check
Also called post-condition check, in-contract invariant check, balance check
A post check is an invariant check in a contract that runs at the end of every action and reverts on failure, for example requiring accounted token amounts to sum to no more than the real balance. It is a last line of defense.
Proof of concept (PoC)
Also called PoC, exploit PoC, proof-of-concept exploit
A proof of concept (PoC) is a test that reproduces a suspected vulnerability and shows how severe it is, for example by making a liquidation revert or an accounting check fail. Writing PoCs keeps false positives out of audit reports.
Severity level
Also called finding severity, vulnerability severity, severity classification, audit severity levels
A severity level is the rank an audit gives a finding, usually critical, high, medium or low, judged from its impact and likelihood. No deterministic formula exists; some firms add informational, QA and gas tiers, and contest platforms have used fewer levels.
Smart contract audit
Also called smart contract security audit, security review, code audit
A smart contract audit is a time-boxed security review of a protocol's contract code at a fixed commit, reporting vulnerabilities by severity with recommended fixes, then checking the fixes. It covers that commit only, not keys, offchain systems or later updates.
Full article How to Audit a Smart Contract: A Complete System
SMTChecker
Also called Solidity SMTChecker, solc model checker
The SMTChecker is a formal verification tool built into the Solidity compiler that converts a contract to SMT-LIB for a solver such as Z3. It proves assertions or returns a counterexample, and can also check overflow, underflow, division by zero and out-of-bounds access.
Full article Formal Verification of Smart Contracts: A Guide
SMT solver
Also called satisfiability modulo theories solver, Z3
An SMT (satisfiability modulo theories) solver is a program that decides whether some assignment of variables makes a logical formula true. Formal verification proves a property by asking a solver such as Z3 whether its negation is satisfiable; if not, it always holds.
Full article Formal Verification of Smart Contracts: A Guide
Stateful fuzzing
Also called stateful fuzz testing, handler-based fuzzing
Stateful fuzzing is fuzzing that calls a protocol's functions in random sequences, keeping state between calls, and checks invariants after each step. Handler functions bound random inputs to valid values, snapshot state before and after each action, and assert the expected change.
Static analysis
Also called static analyzer, static code analysis
Static analysis is inspection of source code without running it, flagging known bug patterns and code smells. Running a tool such as Slither or Aderyn before an audit clears surface-level issues, leaving reviewers more time for protocol logic that pattern matching cannot judge.
Test coverage
Also called code coverage, line coverage, branch coverage
Test coverage is a measure of which lines or branches of code a test suite executes, for example with forge coverage. It shows blind spots but not how many bugs the tests would catch: a suite at 100% line coverage can still miss planted mutants.
Full article Mutation Testing in Solidity With Gambit and Vertigo
Threat model
Also called threat modeling, threat modelling
A threat model is a map of every path an attacker could take to a system's assets, and who can walk each. For a protocol, it covers the contracts holding funds, the roles that can move them, and keys and signers behind each role.
Update review
Also called upgrade audit, post-launch review, delta audit, diff audit
An update review is a security audit of the changes a protocol ships after its first audit, read against the audited commit. In 49 published update reviews, 59% found a Critical or High, and small diffs still held Criticals.
Full article Smart Contract Upgrade Bugs: What 49 Update Reviews Found
20 terms
Keys, signatures and cryptography
The keys and signatures that authorize every transaction, and how they are held.
Blind signing
Also called blind sign, blind-signing
Blind signing is approving or signing a transaction without reviewing its content, often an opaque hex blob the wallet cannot decode. It is how signers end up approving disguised transactions, and Hong Kong's SFC requires licensed platforms to put measures in place against it.
Clear signing
Also called clear sign, clear-signing, what you see is what you sign
Clear signing is a signing flow in which the device decodes a transaction and shows its real, human-readable details before approval, so the signer need not trust a possibly compromised computer screen. It counters blind signing and pairs with EIP-712 typed data.
Full article Wallet Frontend Security: Signing Interfaces After Bybit
Digital signature (v, r, s)
Also called Ethereum signature, v r s, signature components
A digital signature is proof the holder of a private key approved a message. An Ethereum signature has three parts: r, the x coordinate of a temporary curve point; s, from the hash and private key; and v, which picks between two candidate points.
ecrecover
Also called ecrecover precompile, signature recovery
ecrecover is Solidity's precompile-backed function that returns the signer's address for a message hash and its v, r and s. It returns the zero address for invalid signatures and accepts malleable ones, so raw use without OpenZeppelin's ECDSA library is a red flag.
Full article Smart Contract Vulnerabilities List: 22 to Check First
EIP-712 typed data signing
Also called EIP-712, EIP712, typed structured data signing, signTypedData
EIP-712 is the Ethereum standard for hashing and signing typed structured data, so wallets can show human-readable fields instead of an opaque hex blob. Its domain separator binds each signature to one contract and chain, so it cannot be reused elsewhere.
Full article Crypto Wallet Penetration Testing: What to Test
Elliptic curve cryptography (ECC)
Also called ECC, elliptic curve crypto
Elliptic curve cryptography (ECC) is public-key cryptography built on the group of points on an elliptic curve over a finite field. Its security rests on the elliptic curve discrete logarithm problem: multiplying a point by a number is easy, reversing it practically impossible.
Full article What Is secp256k1? Ethereum's Elliptic Curve Explained
Elliptic Curve Digital Signature Algorithm (ECDSA)
Also called ECDSA, ECDSA Signature
The Elliptic Curve Digital Signature Algorithm (ECDSA) is the signature scheme Ethereum uses with secp256k1. Each signature uses a fresh secret random value k to derive r and s; without that randomness, an observer could work back to the private key.
Hardware security module (HSM)
Also called HSM, hardware security module
A hardware security module (HSM) is a physical, tamper-evident device that safeguards and manages cryptographic keys and performs operations with them. Hong Kong's SFC expects licensed platforms to keep keys, where practicable, in a secure environment such as a certified HSM.
Hardware wallet
Also called hardware signer, signing device
A hardware wallet is a dedicated device that keeps private keys off the computer and signs transactions itself. It protects against a compromised browser only if the signer clear-signs, reading the decoded transaction on the device instead of trusting the web page.
Full article Wallet Frontend Security: Signing Interfaces After Bybit
Keccak-256
Also called keccak256, keccak, keccak hash
Keccak-256 is the hash function Ethereum uses, exposed in Solidity as keccak256, which returns a 32-byte digest. A function selector is the first four bytes of a function signature's Keccak-256 hash, and an address is the last 20 bytes of a public key's hash.
Related article Ethereum Calldata Explained: Decoding a Real Multicall
Multi-party computation (MPC)
Also called MPC wallet, MPC custody, secure multi-party computation
Multi-party computation (MPC) is a key setup that splits a private key into shares on separate parties or devices, a threshold of which cooperate to sign. It removes the seed phrase's single point of failure but moves risk into share handling and recovery.
Full article Crypto Wallet Penetration Testing: What to Test
Multisig
Also called multi-signature wallet, multisig wallet, m-of-n wallet
A multisig is a wallet that executes a transaction only after a threshold of its signers approve, such as 3 of 5. It removes a single point of failure but is only as safe as what signers check, as Bybit's 2025 loss showed.
Full article What Is Web3 MDR? Managed Detection and Response for Crypto
Nonce
Also called number used once, account nonce, signature nonce
A nonce is a number used once, such as a counter in a signed message that makes each signature valid only one time and blocks replay. On Ethereum, each externally owned account also has a nonce counting the transactions it has sent.
Related article Web3 Pentest Findings in DeFi Backends, Keepers and Cloud
Private key
Also called secret key, signing key
A private key is the secret number that controls an Ethereum account: it signs transactions and messages, and the account's public key is derived from it by elliptic curve multiplication. It is 64 hex characters, and whoever holds it can move the funds.
Full article What Is secp256k1? Ethereum's Elliptic Curve Explained
Public key
Also called Ethereum public key
A public key is a point on the secp256k1 curve, K = k × G: the private key k times the generator point G. It can be shared because recovering k is infeasible; an Ethereum address is the last 20 bytes of its Keccak-256 hash.
Full article What Is secp256k1? Ethereum's Elliptic Curve Explained
Safe (multisig wallet)
Also called Safe, Safe{Wallet}, gnosis Safe, Safe multisig
Safe is a smart contract multisig for EVM chains that executes a transaction once a threshold of owners sign, with optional modules and guards. Safes hold many DeFi admin powers, and the Safe{Wallet} interface was the entry point of the 2025 Bybit theft.
Related article Wallet Frontend Security: Signing Interfaces After Bybit
secp256k1
Also called secp256k1 curve, Ethereum elliptic curve
secp256k1 is the elliptic curve Ethereum uses for keys and signatures: y² = x³ + 7 over integers modulo a large prime p. Its group order n is prime, and a public key is the private key times the shared generator point G.
Full article What Is secp256k1? Ethereum's Elliptic Curve Explained
Seed phrase
Also called recovery phrase, mnemonic phrase, secret recovery phrase, BIP-39 mnemonic
A seed phrase is a list of 12 to 24 words, standardized in BIP-39, that encodes the random entropy from which a wallet derives all its keys. Whoever holds it controls the funds, so it must never reach logs, backups or the clipboard.
Full article Crypto Wallet Penetration Testing: What to Test
Sign-In with Ethereum (SIWE)
Also called SIWE, EIP-4361, wallet login, wallet-signature login
Sign-In with Ethereum (SIWE, EIP-4361) is a standard message format for logging in to an offchain service by signing with an Ethereum account. Servers must issue a fresh nonce per session and check expiry, URI, domain and chain ID, or logins can be replayed.
Full article Best Web Application Pentesting Firms for Crypto and Fintech
Threshold signature scheme (TSS)
Also called TSS, threshold signing, threshold signatures
A threshold signature scheme (TSS) is a protocol that lets any t of n key-share holders jointly produce one signature offchain, so the chain sees a single signer, not a contract multisig. Flawed share handling can let a compromised subset sign transactions it should refuse.
27 terms
Offchain security and OpSec
The apps, cloud, keys and people around the contracts.
API pentest
Also called API penetration testing, API security testing
An API pentest is a security test of an application's endpoints that measures what each credential can reach and what a stolen one is worth: key scoping and revocation, per-object authorization, rate limits, replay protection and endpoints that trigger onchain transactions.
Attack surface
Also called threat surface, attack surface area
An attack surface is every point where an attacker can reach or influence a system: a protocol's state-changing functions, integrations and privileged roles, plus the domains, frontends, APIs, cloud accounts and keys around them. Each extra state-changing function multiplies the paths.
Browser extension pentest
Also called browser extension penetration testing, wallet extension pentest
A browser extension pentest is a security review of an extension, such as a wallet, from both directions: what a hostile site can extract through content scripts and messaging, and what a malicious update could do with permissions users already granted.
DPRK crypto threat
Also called Lazarus Group, tradertraitor, North Korean hackers, APT38, bluenoroff
The DPRK crypto threat is digital asset theft by North Korean state-sponsored hackers, tracked by industry as Lazarus Group and by the FBI as TraderTraitor. They target keys and people more than code, and the FBI attributed the roughly $1.5 billion Bybit theft to them.
Full article Wallet Frontend Security: Signing Interfaces After Bybit
External attack surface management (EASM)
Also called EASM, attack surface management, external exposure monitoring
External attack surface management (EASM) is continuous discovery and testing of everything an organization exposes to the internet, found from the outside with no inventory assumed: subdomains, hosts, open ports, public storage, certificates and unpatched software. The forgotten asset usually hurts most.
Frontend attack
Also called DNS hijack, frontend hijack, domain hijack, front-end attack
A frontend attack is a change to what users load from a protocol's website, leaving its contracts untouched: a hijacked registrar or DNS record, a bundle swapped at the CDN, or an injected script. Users then sign on what looks like the real site.
Infrastructure pentest
Also called cloud pentest, cloud penetration testing, infrastructure penetration testing
An infrastructure pentest is a test that attacks a team's cloud accounts, CI/CD pipelines, containers and vendor consoles the way an intruder escalates toward something that signs. It asks what one stolen access key unlocks and whether a compromised pipeline can ship or sign code.
Keeper and relayer pentest
Also called offchain automation pentest, keeper pentest, bot security pentest
A keeper and relayer pentest is a security test of offchain automation that holds privileged keys and acts unattended, such as keepers, relayers, liquidation bots and threshold signers, run with hostile inputs and part of the set assumed compromised. Source code is required.
MCP server security
Also called Model Context Protocol security, MCP pentesting, MCP security
MCP server security is the protection of Model Context Protocol servers, which expose tools, resources and prompts to AI agents. Attackers can often call a server's tools directly over JSON-RPC, skipping the model, so every tool handler must enforce its own authorization.
Offchain security
Also called off-chain security, Web2 security, offchain risk
Offchain security is the protection of everything around a protocol's contracts that the code trusts: keys and signers, devices, cloud accounts, backends, keepers, frontends and DNS. Offchain compromises caused 72% to 74% of reported hack losses in 2024 and 2025.
Full article Onchain vs Offchain Attacks: Where Hack Losses Came From
Operational security (OpSec)
Also called OpSec, operational security, OpSec audit
Operational security (OpSec) is how a team actually holds, approves and changes control of its funds and systems: key custody, multisig signing, privileged roles, secrets, devices, and access as people join or leave. Audited contracts still lose funds through these gaps.
Penetration test (pentest)
Also called pentest, penetration testing, pentesting, Web3 pentest
A penetration test (pentest) is an authorized attack on a system by testers acting as a real adversary would, to find exploitable weaknesses first. In Web3 it targets the offchain systems around the contracts, asking what each can be made to sign, send or reveal.
Full article Best Web3 Penetration Testing Companies in 2026
Phishing
Also called spearphishing, phishing attack
Phishing is an attack that tricks a person into handing over credentials or approving an action through a fake message, site or prompt. In crypto it often targets developers and signers: phished developer accounts published malicious releases of Ledger Connect Kit and Cyberhaven's browser extension.
Related article Crypto Wallet Penetration Testing: What to Test
Prompt injection
Also called indirect prompt injection, LLM prompt injection
Prompt injection is an attack that plants instructions in content an AI agent reads, such as a tool result, a resource or a GitHub issue, so the model follows the attacker. In May 2025, a malicious GitHub issue made an agent leak private repository data.
Red team test
Also called red team, red teaming, adversary simulation
A red team test is a controlled, intelligence-led simulation of a real threat actor against live production systems, testing detection and response as well as defenses. Under DORA's threat-led penetration testing, active red team testing lasts at least 12 weeks.
Full article DORA Penetration Testing Requirements: Articles 24 to 27
Relayer
Also called transaction relayer, relayer service
A relayer is an offchain service that signs and submits transactions onchain, handling keys, nonces, fees and status. One that can pause, upgrade, mint or move funds holds a privileged key, so its key store, server and RPC providers belong in pentest scope.
Full article OpenZeppelin Defender Alternatives After the 2026 Shutdown
SDK audit
Also called SDK security audit, client library audit
An SDK audit is a security review of a library integrators install, such as a wallet connect kit or transaction builder: the payload it hands to the wallet, how it handles keys and credentials, and whether the published package matches the repository.
Secrets management
Also called secret management, credential management, key and secret handling
Secrets management is how a team stores, scopes, rotates and revokes credentials such as private keys, API keys, RPC keys and bot tokens. Common pentest findings are secrets hard-coded in source, private keys written to logs, and one key shared across roles.
Full article Web3 Pentest Findings in DeFi Backends, Keepers and Cloud
Signing interface compromise
Also called signing UI compromise, wallet frontend compromise, Safe UI attack
A signing interface compromise is an attack that alters the frontend signers use to review transactions, so they approve a malicious payload that looks correct. In the 2025 Bybit theft, script injected into Safe{Wallet}'s hosting showed a correct-looking transaction while a different one executed.
Full article Wallet Frontend Security: Signing Interfaces After Bybit
Subdomain takeover
Also called dangling DNS record, dangling CNAME
A subdomain takeover is an attack in which a DNS record still points at a deprovisioned host or storage that someone else can claim, letting them serve their own content from the victim's domain. Sweeping for forgotten subdomains and dangling records finds them first.
Subresource Integrity (SRI)
Also called SRI, integrity attribute
Subresource Integrity (SRI) is a browser feature that pins a cryptographic hash on each script and stylesheet, so the browser refuses any file that does not match. It does not cover the top-level document, so pair it with a strict Content Security Policy.
Full article Wallet Frontend Security: Signing Interfaces After Bybit
Supply chain attack
Also called software supply chain attack, dependency attack, malicious package
A supply chain attack is the compromise of software a target trusts, such as a dependency, SDK, build pipeline or extension update, so malicious code reaches everyone who installs it. In December 2023, malicious Ledger Connect Kit releases drained users of dApps using it.
Full article Crypto Wallet Penetration Testing: What to Test
Telegram Mini App security
Also called Telegram Mini App pentest, Telegram Web App security, initData validation
Telegram Mini App security is the protection of web apps that Telegram loads in its in-app browser, backed by a bot and backend. Since anyone can alter the client, the backend must validate the signed initData on every request and authorize each value-moving action.
Full article Telegram Mini App Security: A Pentesting Checklist
Tool poisoning (MCP)
Also called MCP tool poisoning, poisoned tool description, MCP rug pull
Tool poisoning is an attack that hides instructions in an MCP tool's description or schema, which the model reads but the user does not, steering the agent to exfiltrate files or misuse other tools. A server can also change a description after approval.
Wallet pentest
Also called crypto wallet penetration testing, wallet penetration test, wallet security audit
A wallet pentest is a security test of crypto wallet software in four areas: key generation and storage, signing flows, the backend and API, and the release chain. Its central check is that what gets signed matches, byte for byte, what the user saw.
Full article Crypto Wallet Penetration Testing: What to Test
Web application pentest
Also called web app pentest, webapp pentest, web application penetration testing
A web application pentest is a security test of a web app and its backend where they decide who is authenticated, what each user may do and whether withdrawals proceed: login and recovery, object-level authorization, value-moving flows, business logic and client-side injection.
16 terms
Monitoring and incident response
Detecting an attack and acting on it before the funds are gone.
Alert triage
Also called triage, alert investigation
Alert triage is the step where a person reviews each monitoring alert, decides whether it is real and how severe it is, and starts the response. Who triages, how fast and by what severity criteria separates a monitoring tool's notifications from managed detection and response.
Incident response
Also called security incident response, exploit response
Incident response is the work of containing, investigating and recovering from a security incident. Onchain, containment means pausing a contract, freezing funds or blocking a transaction, each needing a key or role assigned in advance, because many drains end before the first public alert.
Full article What Is Web3 MDR? Managed Detection and Response for Crypto
Incident response plan
Also called IR plan, incident runbook, emergency response plan, runbook
An incident response plan is the written, rehearsed procedure for a security incident: who is paged, which actions a provider may take alone, who can pause or unpause through which key, how signers are reached at 3 AM, and when to call SEAL 911.
Full article What Is Web3 MDR? Managed Detection and Response for Crypto
Managed detection and response (MDR)
Also called MDR, managed detection & response
Managed detection and response (MDR) is a security service in which an outside team monitors an organization's environment around the clock, triages threats and responds to them. It gives an organization a security operations center's capability without building one; an MSSP generally only sends alerts.
Full article What Is Web3 MDR? Managed Detection and Response for Crypto
Onchain monitoring
Also called smart contract monitoring, blockchain monitoring, onchain threat detection
Onchain monitoring is the continuous watching of deployed contracts and their transactions, alerting or acting when activity matches a rule or looks like an attack: privileged calls, role changes, upgrades, multisig transactions, oracle deviations and large fund movements. Some platforms also scan the mempool.
Pause function
Also called circuit breaker, emergency pause, pausable, kill switch
A pause function is a privileged contract function that halts some or all operations, such as deposits, withdrawals or swaps, during an emergency. It only helps if reachable and tested: when exploited, Seneca's pause functions were internal and Arcadia's pause was in a cooldown.
Full article How Fast Are Crypto Hacks Detected? Data From 30 Exploits
Pause guardian
Also called guardian role, pauser role, pauser, emergency guardian
A pause guardian is an address, often a single key or small multisig, allowed to pause a protocol quickly without a governance vote, often without the power to unpause. Compound's pause guardian can pause, but only the admin can unpause.
Full article Essential Managerial Efforts: Security Work After Launch
Post-mortem
Also called postmortem, incident post-mortem, incident report, root cause analysis
A post-mortem is a team's write-up after a security incident, covering the timeline, root cause, losses, response and fixes. Of 30 exploits studied, six post-mortems stated when the team or its monitoring first knew, at a median of 4 minutes in.
Related article How Fast Are Crypto Hacks Detected? Data From 30 Exploits
SEAL 911
Also called Security Alliance 911, SEAL 911 hotline
SEAL 911 is the round-the-clock crypto incident response service run by the non-profit Security Alliance (SEAL), which teams contact for help during an active exploit. Cork Protocol and Arcadia Finance both contacted it during their 2025 incidents.
Related article How Fast Are Crypto Hacks Detected? Data From 30 Exploits
Security council
Also called Security Council multisig, emergency Council
A security council is a multisig, separate from token governance, that holds emergency, veto or upgrade powers a protocol may need to use quickly. Its signers become targets: in April 2026, Drift's Security Council members were reportedly tricked into pre-signing an admin transfer.
Related article Onchain vs Offchain Attacks: Where Hack Losses Came From
Threat intelligence
Also called cyber threat intelligence, CTI, threat intel
Threat intelligence is information about active attackers, their techniques and freshly disclosed vulnerabilities, used to decide what to monitor, test and patch. For a digital asset team it includes matching advisories to the packages it runs and watching for incidents at peers, vendors and dependencies.
Timelock
Also called timelock controller, timelockcontroller, governance delay, time lock
A timelock is a contract that enforces a minimum delay between queuing a privileged action, such as an upgrade, and executing it, so users can review or exit first. In a census of 25 DeFi protocols, no pause or freeze power waited on one.
Full article Who Controls DeFi? Admin Keys Behind 25 Top Protocols
Time to detection
Also called time to detect, detection time, MTTD, mean time to detect
Time to detection is the time between the first exploit transaction and the first alert. In a sample of 30 exploits from 2024 to 2026, the first public alert came a median of 35 minutes in, and the median pause 88 minutes in.
Full article How Fast Are Crypto Hacks Detected? Data From 30 Exploits
Transaction simulation
Also called pre-signing simulation, transaction preview, tx simulation
Transaction simulation is the execution of a pending transaction against current chain state to preview its effects before it is signed or confirmed. Signers should decode and simulate every admin transaction on a device they control, and some monitoring platforms simulate transactions before signing.
Related article Onchain vs Offchain Attacks: Where Hack Losses Came From
War room
Also called incident war room, incident channel
A war room is the group of engineers, signers and outside responders convened to coordinate decisions while an exploit is under way. Fast teams plan it in advance, deciding who joins and who calls whom; Cork Protocol and Arcadia Finance brought in SEAL 911.
Full article How Fast Are Crypto Hacks Detected? Data From 30 Exploits
Web3 MDR
Also called web3 managed detection and response, crypto MDR, onchain MDR
Web3 MDR is managed detection and response for digital assets: a team watches contracts, keys, multisigs, cloud and domains around the clock, triages every alert and responds, including pausing contracts under authority agreed in advance. A tool detects; MDR adds the people, SLA and response.
Full article What Is Web3 MDR? Managed Detection and Response for Crypto
No terms match that search.
All terms, A to Z
A
B
C
D
- DAI
- DAI Savings Rate (DSR)
- Debt ceiling
- DeFi accounting vulnerability
- DeFi primitive
- Delegatecall
- Denial of service (DoS)
- Diamond proxy (EIP-2535)
- Digital signature (v, r, s)
- Dirty bytes (Solidity compiler bug)
- Division before multiplication
- Donation attack
- DPRK crypto threat
- Duplicate finding
- Dutch auction liquidation
E
- Echidna
- ecrecover
- EIP-712 typed data signing
- EIP-1967 storage slots
- EIP-6780
- Elliptic curve cryptography (ECC)
- Elliptic Curve Digital Signature Algorithm (ECDSA)
- ERC-20
- ERC-721
- ERC-721 and ERC-777 reentrancy
- ERC-777
- ERC-2612 permit
- ERC-4626 inflation attack
- ERC-4626 tokenized vault
- ERC-7631 (DN404)
- Eternal storage
- Ethereum Virtual Machine (EVM)
- EVM memory
- EVM stack
- Exploit
- External attack surface management (EASM)
F
G
H
I
L
M
O
P
- Parallel data structures
- Parallel state (multi-contract)
- Pausable token
- Pause function
- Pause guardian
- Penetration test (pentest)
- Perpetual futures (perps)
- Per-share accounting (reward per share)
- Phishing
- Post check
- Post-mortem
- Price impact
- Price oracle
- Price oracle manipulation
- Private key
- Prompt injection
- Proof of concept (PoC)
- Proxy contract
- Public key
- Pull over push
R
S
- SafeERC20 (safeTransfer)
- Safe (multisig wallet)
- Sandwich attack
- SDK audit
- SEAL 911
- secp256k1
- Secrets management
- Security council
- Seed phrase
- SELFDESTRUCT
- Self-liquidation
- Severity level
- Signature malleability
- Signature replay
- Signing interface compromise
- Sign-In with Ethereum (SIWE)
- Single-function reentrancy
- Slippage
- Slippage protection (minimum output)
- Smart contract audit
- SMTChecker
- SMT solver
- Social engineering
- Solidity compiler bug
- Spot price manipulation (slot0)
- sqrtPriceX96
- Stability fee
- Stale oracle price
- Stateful fuzzing
- Static analysis
- Stepwise jump
- Storage collision
- Storage gap
- Storage slot
- Subdomain takeover
- Subresource Integrity (SRI)
- Supply chain attack
- Sybil attack
T
U
Y
Know the terms. Then test the code.
Guardian audits contracts and pentests the systems around them, with exploit-driven review and proof-of-concept depth.
Social engineering
Also called human hacking, pretexting
Social engineering is manipulating people, rather than code, into giving an attacker access, such as a fake recruiter's coding test that infects a developer's laptop. At Drift in April 2026, Security Council members were reportedly tricked into pre-signing an admin transfer.
Full article Onchain vs Offchain Attacks: Where Hack Losses Came From →
Related Phishing, DPRK crypto threat, Operational security (OpSec)