Curious about a word? Tap a dotted term for its meaning.

A SHARED VOCABULARY

A word is a place to begin.

Short definitions for orientation. Follow any term for the full mechanism, examples, qualifications, and sources.

Find a term

568 terms

A

Abstract ↗: A consumer-focused Ethereum validity rollup associated with the Pudgy Penguins ecosystem; PENGU is a community token and ETH pays network gas.
Account ↗: A record associated with an identity or address. A blockchain account can hold balances, data or program code under network rules; a website or exchange account is a service-managed customer record. Control depends on keys, contracts or the service’s permissions.
Account abstraction ↗: A design that lets accounts use programmable authorization and payment rules instead of relying only on a single ordinary key. It can enable recovery or sponsored fees, but the specific implementation determines who can authorize each action.
Account-based ↗: An accounting model that tracks balances and other data under account identifiers. Transactions update those records. This differs from output-based systems, where a transaction consumes individual unspent outputs and creates new ones.
Accrued interest ↗: Interest that has accumulated over time, whether or not it has been paid or withdrawn. In a loan it can increase the amount owed; a recorded interest balance does not by itself prove cash is available to pay it.
Actor ↗: In Filecoin, a program or account-like component with its own recorded state and callable actions. Actors communicate through messages and implement both core network functions and application behavior. The word here does not refer to a human performer.
ADA ↗: ADA pays fees and participates in staking and governance. Native tokens can coexist in outputs, but they do not automatically have ADA’s consensus role.
Address ↗: A network-specific identifier for an account or spending condition. It tells software where an operation is directed; it does not by itself identify a person. Similar-looking addresses on different networks do not guarantee compatible transfers.
Address blocking ↗: A token issuer or contract mechanism restricting selected addresses or transfers under its rules. Controlling a wallet key does not override those token rules, and a transfer restriction is different from a blockchain-wide outage.
Admin key ↗: A signing authority with special powers over a system, such as upgrading code, pausing transfers or changing settings. It may be one key, several signers or a governance process. Those powers remain relevant even when ordinary transactions are decentralized.
AggLayer ↗: Infrastructure for coordinating cross-chain transfers and accounting among connected chains. Its proofs address specified relationships between those chains. A chain’s use of AggLayer does not automatically mean every transaction on that chain has a conventional validity-rollup execution proof.
ALGO ↗: ALGO pays transaction fees and supports account minimum balances. Participating ALGO stake determines consensus selection and voting weight; an application’s own asset is separate from the network’s native coin.
Algorand ↗: A smart-contract network that selects stake-weighted committees with cryptographic randomness and provides its own virtual machine, asset system, and transaction grouping.
Algorand Virtual Machine ↗: Algorand’s execution environment for smart contracts. Programs compile into its instruction format and operate within defined computation and state-access budgets. These execution rules are separate from the lottery and voting process used to agree on blocks.
Algorithmic stablecoin ↗: A broad label for tokens relying heavily on programmed supply or conversion incentives to pursue a peg. Designs differ; a rule involving a volatile balancing token can fail if demand for that token collapses during redemptions.
Allowance ↗: The token amount an owner has authorized a particular spender to transfer. A remaining allowance can permit later spending without a fresh approval; the transfer must still satisfy the balance and token contract’s rules.
Annual percentage rate ↗: A rate expressed on a yearly basis. In this guide, APR is the simple rate before reinvesting rewards; elsewhere fee inclusion and conventions can differ, so the displayed label alone is not a complete return calculation.
Annual percentage yield ↗: The effective one-year growth rate after a stated compounding schedule. It assumes rewards can be reinvested as modeled; changing rates, fees, token prices or withdrawal conditions can make actual results different.
Annualized rate ↗: A rate restated as a one-year equivalent, sometimes by extending a much shorter observation. It makes time periods easier to compare but does not establish that the rate or reward-token price will persist for a year.
Approval revocation ↗: Changing or removing a previously granted spending permission, often by setting a token allowance to zero. It takes effect when the change is accepted onchain; disconnecting a website alone does not perform this change.
APT ↗: APT pays execution and storage-related fees, supports validator staking and delegation, and participates in protocol governance. Application assets can have different economic rights from the network coin.
Aptos ↗: A proof-of-stake smart-contract network built around Move’s resource model and an execution engine that discovers opportunities to process transactions in parallel.
ARB ↗: ETH pays gas on Arbitrum One. ARB supplies voting power in Arbitrum governance, including treasury and upgrade decisions; holding ARB does not itself validate blocks or remove the need for ETH.
Arbitrage ↗: Trading related assets or routes to capture a price difference, after costs and risk. Such trades can pull prices closer together, but require capital and working execution or redemption routes; a visible difference is not guaranteed profit.
Arbitrum ↗: An Ethereum scaling ecosystem whose flagship chain, Arbitrum One, executes transactions separately and settles its results on Ethereum.
Ask price ↗: A price at which someone offers to sell an asset, together with an available quantity. The lowest ask is the best displayed selling offer; it does not guarantee the same price for an order of any size.
Asset segregation ↗: Keeping assets identified and separated from other funds under a defined custody arrangement. The practical protection depends on accounting, control and legal rights; a separate address alone does not resolve every ownership claim.
ASTER ↗: ASTER supports staking and governance in the ecosystem; its documented token representation includes BNB Chain. Delegation rewards depend on validator activity and lock choices. Ordinary trading is described as gasless, while withdrawal and trading costs still exist.
Aster Chain ↗: Aster Chain is a specialized layer one supporting Aster’s derivatives exchange. It combines trading-specific execution with optional account privacy, rather than serving only as a generic chain on which an unrelated exchange happens to run.
Asynchronous execution ↗: An execution model in which a request and its later response can occur in separate steps or transactions. An application must handle intermediate states and failure. Sending a message does not mean the receiving action has already completed.
ATOM ↗: ATOM is used for staking, transaction fees, and governance. Delegation contributes voting weight to validators and exposes the stake to the network’s staking rules and penalties.
Atomic ↗: An operation treated as one indivisible change: the required actions complete together or their state changes do not take effect. This does not necessarily eliminate fees, and separate transactions on different chains are not automatically atomic.
Attestation ↗: A statement asserting that a specified claim was checked. Validators issue signed statements about chain history; reserve attestation reports assess particular financial information against stated criteria. Neither automatically proves every fact about a system or continuously guarantees its condition.
Aura ↗: A block-production mechanism used in some Substrate-based chains, where an authorized set takes turns under protocol scheduling rules. Producing a block and finalizing accepted history are separate roles; another mechanism such as GRANDPA can supply finality.
Authorized participant ↗: A participant permitted to use a product’s direct creation or redemption process under its rules. Ordinary token holders may instead rely on market trades; permission to hold or transfer a token does not imply direct issuer access.
Automated market maker ↗: A trading mechanism that uses pooled assets and a pricing rule to quote exchanges. Trades alter its inventory and subsequent prices; different AMMs use different curves, weights, ranges and fee rules.
Automatic deleveraging ↗: A venue mechanism that forcibly reduces other traders’ positions when its stated loss-handling conditions are met. It can close a profitable position earlier than intended; selection rules and the role of any insurance fund depend on the venue.
Avalanche ↗: A network architecture with an EVM C-Chain and separately configurable Avalanche L1s.
AVAX ↗: AVAX pays Primary Network fees and supports its staking. An Avalanche L1 can use a different gas asset; the AVAX listing does not describe every chain’s token economics.

B

Backing ↗: The assets or arrangements intended to support a claim’s value or repayment. Recoverable backing concerns what can ultimately meet the obligation, while immediate cash access and a token’s market price are separate questions.
Bad debt ↗: Debt that cannot be recovered from the borrower and available collateral or other resources. A temporary shortage of withdrawal cash is different; bad debt reduces the assets available to support lenders’ claims unless another resource absorbs it.
Balance sheet ↗: A statement of assets, liabilities and the remaining equity at a particular time. For a token issuer or custodian, it helps separate assets held from amounts owed; completeness, valuation and ownership of those assets still matter.
Base fee ↗: In Ethereum’s fee mechanism, the protocol-set charge per gas unit that adjusts with block demand and is destroyed rather than paid to the proposer. Other networks may use the term differently, so their fee rules need separate checking.
Basis ↗: The difference between related prices, often a derivative price and the underlying spot price. Changes in that difference can make a hedge perform differently from a simple model that assumes both prices move together.
Batch ↗: A group of transactions or state updates handled together. Rollups use batches to share publication and verification work across many transactions. A batch can be assembled before the proof or settlement steps needed to accept its results are complete.
BCH ↗: BCH is the native payment and fee asset. BTC and BCH have independent balances, histories and network destinations despite their common ancestry.
BGB ↗: BGB is described by Morph as its core gas, governance and settlement token. That utility does not establish a fixed price or guarantee that fee activity offsets token dilution and market risk.
Bid ↗: An offer to buy an asset at a stated price and quantity. The highest displayed bid is the best currently offered buying price, but only its available quantity can trade there before lower bids may be needed.
Bid-ask spread ↗: The gap between the highest buy offer and lowest sell offer. It affects the cost of immediately buying and selling, but it is separate from trading fees and does not describe depth farther from those prices.
BIP 32 ↗: A specification for deriving a tree of related keys from one starting seed. It lets compatible wallets recreate many accounts from shared recovery material while keeping their individual keys and addresses distinct.
BIP 39 ↗: A Bitcoin improvement proposal describing a common way to turn randomness into recovery words and derive a wallet seed from them. Many wallets use it, but it is not a universal recovery format.
Bitcoin ↗: A public ledger for scarce digital money, secured by proof-of-work rather than an issuer’s repayment promise.
Bitcoin Cash ↗: A Bitcoin-derived payment chain that prioritizes scaling transactions on its base layer.
Bitcoin Script ↗: Bitcoin’s language for expressing conditions that must be satisfied to spend an output. It supports checks such as signatures and time restrictions. Its deliberately limited design differs from the general-purpose application environment used by Ethereum.
Bittensor ↗: Bittensor uses the Subtensor blockchain to coordinate markets for digital work, including inference, predictions and computation. The useful work occurs in subnets; the ledger accounts for participation and incentives.
BitTorrent Chain ↗: An EVM-compatible scaling and interoperability network that connects to TRON, Ethereum, and BNB Chain through its own validators, checkpoints, and bridge mechanisms.
Blob ↗: A packaged quantity of data published under a network’s specific data rules. Ethereum blobs provide temporary data availability used by rollups. Their contents are not ordinary permanent contract storage, and long-term retention requires additional arrangements.
Block ↗: A batch of transactions and related information that a network processes as part of its history. Its contents must satisfy the network’s rules. Being inside a block is a confirmation, but how difficult that history is to reverse depends on consensus.
Block height ↗: A block’s numbered position in a chain, counted from its starting block. Height measures progress through the chain’s history; it is not a timestamp, and the time between successive heights can vary.
Block proposer ↗: The participant selected or competing to assemble a candidate block and submit it to the network. Other participants check and accept it under consensus rules; proposing a block does not make its contents automatically valid or final.
Block space ↗: The limited capacity available for transactions and data in blocks. When users compete for that capacity, fees or waiting times can rise. The limit may concern bytes, computation or other resources, depending on the network.
Block subsidy ↗: New units issued under the protocol’s block-production rules. People often use “block reward” for the subsidy plus transaction fees. The subsidy follows a network-specific issuance schedule; it is separate from money paid by transaction senders.
Block-STM ↗: Aptos’s parallel execution approach that tries transaction work concurrently, detects data dependencies and repeats conflicting work when needed. It aims to produce a result consistent with the agreed transaction order; it is not a substitute for consensus.
Blockchain ↗: A shared record organized into linked batches of transactions. Each batch identifies earlier history, while network rules determine which updates are accepted. The links make changes detectable; independent checking and consensus give the record its practical security.
BNB ↗: BNB pays execution fees and supports staking and governance. Using the same BNB symbol across networks does not make their balances or security models interchangeable.
BNB Smart Chain ↗: An EVM-compatible application chain using elected staked validators and BNB for fees.
BoLD ↗: Arbitrum’s dispute protocol for challenging competing claims about rollup execution. It is part of the optimistic verification process on Ethereum. Receiving a sequencer acknowledgment does not mean that all dispute and settlement conditions have already completed.
BOLD ↗: Liquity V2’s dollar-targeting token created through collateralized borrowing. Its redemption process exchanges tokens for dollar-valued collateral less applicable fees; redemption can affect healthy borrowing positions and is distinct from liquidating an unsafe position.
Bor ↗: The execution and block-production component used by Polygon PoS and some related chains. It runs Ethereum-compatible transaction logic, while a separate validator-coordination layer handles other consensus duties. Its balances and history belong to its own chain.
Borrowing ↗: Receiving assets with an obligation to return the amount owed under the loan’s rules. A collateralized crypto loan also ties up eligible assets, and accumulated interest can increase debt even when no additional tokens are borrowed.
Borrowing capacity ↗: The additional debt a collateral position is permitted to take under the market’s rules. It depends on asset values, entry limits and existing debt; remaining capacity is different from the point where liquidation becomes possible.
Bridge ↗: A system that coordinates assets or messages between separate ledgers. It may lock, release, mint or destroy representations according to verified claims. Its security depends on how those claims are checked and who can control the contracts or signers.
Broadcast ↗: Sending a signed transaction to a network so other nodes can relay and evaluate it. Broadcasting is a request for inclusion, not proof that the transaction has passed every check or become part of accepted history.
BTC ↗: The native asset recorded by the Bitcoin network. It can be transferred under Bitcoin’s spending rules and used to pay transaction fees. Owning BTC does not by itself produce protocol staking rewards or create a claim on an issuer’s reserves.
BTT ↗: BTT is the native gas asset on BTTC and is used for validator and delegator staking. The BitTorrent brand also covers other products; a BTT balance does not imply that every product uses identical network mechanics.
Burn-and-mint transfer ↗: A cross-chain arrangement that destroys units on the source chain and creates corresponding units on the destination after required verification. It needs authorized issuance and reliable message checks; burning alone does not guarantee completion at the destination.
Bytecode ↗: The lower-level instructions a program is compiled into for an execution environment to run. Different virtual machines use different formats, so code compiled for one blockchain is not automatically executable on another.
Byzantine fault tolerance ↗: The ability to preserve specified agreement guarantees even when some participants send false or conflicting information. Every design assumes limits on faulty influence and network behavior. “Fault tolerant” does not mean secure against any number of dishonest participants.

C

Canister ↗: An Internet Computer application unit combining program code with stored state. Canisters can process requests and send messages to one another. Updates and ordinary read queries use different verification paths, so their assurance should not be treated as identical.
Canonical bridge ↗: The bridge treated as the standard route for a particular network or asset system. “Canonical” identifies that relationship, not a universal safety rating. Verification rules, withdrawal delays and administrative controls still need to be understood.
Canton ↗: Canton connects applications through shared synchronization while limiting transaction visibility to the parties entitled to see it. Its Global Synchronizer coordinates activity across participating ledgers.
Cardano ↗: A proof-of-stake smart-contract chain that extends Bitcoin-style outputs with data and scripts.
CashToken ↗: Bitcoin Cash’s native token functionality for creating fungible and non-fungible assets within its output-based transaction model. It adds token capabilities without turning Bitcoin Cash into an Ethereum-style account-based execution environment. Each asset still has its own rules.
CC ↗: CC funds non-transferable traffic credits for Global Synchronizer usage and supports operator incentives. Current validator rewards depend on activity, rather than uptime alone. CC balance and transaction records are publicly visible even though other application contracts can be private.
Celestia ↗: A modular network that orders and publishes application data, allowing separate chains to choose their own execution and settlement systems.
Censorship resistance ↗: The ability to get valid activity processed despite attempts to exclude it. A system can resist some gatekeepers while depending on others, such as sequencers or interfaces. Consensus validity alone does not guarantee timely inclusion.
Centralized exchange ↗: A trading service run by an operator that commonly holds customer assets and records trades in its own accounts. An internal trade may be immediate while an onchain withdrawal still depends on the operator’s assets and systems.
ChainLock ↗: Dash’s quorum-signed commitment to a particular block that nodes use to reject conflicting history under its rules. It adds an explicit locking mechanism to the mined chain, relying on the relevant masternode and quorum assumptions.
Challenge window ↗: The time allowed for contesting a proposed result before a protocol treats it as accepted for specified purposes. Native optimistic-rollup withdrawals often depend on this period. Faster services can add a different intermediary or payment arrangement.
Change output ↗: A new transaction output that returns leftover value to the sender after existing outputs are spent. For example, spending a larger output can create a recipient output, a change output and a fee.
Checkpoint ↗: A selected point in chain history used as a reference for agreement or for reporting state to another chain. Its significance depends on the system. Posting a checkpoint elsewhere does not by itself prove every transaction was executed correctly.
Circulating supply ↗: The number of token units a data publisher considers available in circulation. Treatment of locked, treasury and restricted holdings can differ, so the publisher’s definition matters when comparing market-cap figures.
Claim ↗: Depending on context, a claim is either an assertion that must be checked, such as a proposed blockchain state, or a right to receive assets or performance. A financial claim depends on its actual terms and the ability of the person, institution or contract to fulfill it.
Clarity ↗: The smart-contract language used by Stacks. It expresses asset rules and allowed actions for programs executed on the Stacks ledger. A Clarity contract’s ability to read Bitcoin information does not mean Bitcoin miners execute that contract.
Clique ↗: An authority-based block-production mechanism associated with Ethereum-derived software. A permitted signer set produces blocks under its rules. Using Clique-style production is different from open proof-of-work mining, and the way authorities are selected remains a separate design choice.
Close factor ↗: A limit on how much of an eligible position’s debt may be repaid in one liquidation operation. The applicable rule can vary with health, position size and protocol version; it is not necessarily a universal fixed percentage.
Cold storage ↗: An arrangement that keeps spending keys away from routine internet-connected use. It changes how signing is performed and protected; it does not move coins off the ledger or make recovery material safe to share.
Collateral ↗: Assets pledged to support an obligation, such as a loan. The lending rules can allow their sale or transfer when conditions are breached; their recoverable market value can be lower than the value shown by a price feed.
Collateral vault ↗: A contract-managed position that records pledged assets and debt created or borrowed against them. Its collateral and debt can change independently; repayment, liquidation and any redemption mechanics follow the particular protocol’s rules.
Collateralization ratio ↗: Collateral value divided by debt value, usually expressed as a percentage. It is the reverse of actual loan-to-value: collateral worth 200 supporting debt of 100 gives 200% collateralization and 50% LTV.
Collator ↗: A participant that gathers parachain transactions and prepares candidate blocks for validation in Polkadot. Collators help maintain an application chain, while relay-chain validators perform the shared checking role. These are different responsibilities.
CometBFT ↗: A consensus engine in the Tendermint family that coordinates block proposals and voting among validators. Applications define their own state and rules around it. Sharing CometBFT software does not mean sharing the same validator set or economic security.
Compact language ↗: Midnight’s programming language for applications combining public contract state, private local information and zero-knowledge proofs. Developers decide what information to reveal and what conditions to prove. The language does not remove the network’s validator or governance dependencies.
Composability ↗: The ability to combine existing programs into a larger operation, such as having one contract call another. This enables useful combinations but also connects dependencies: a failure or changed assumption in one component can affect others.
Compounding ↗: Adding earned interest or rewards to the amount that can earn subsequent returns. It can grow the earning base, but real reinvestment may involve fees, exchanges or restrictions and depends on rewards actually being available.
Concentrated liquidity ↗: Liquidity assigned to a selected price interval rather than the whole possible price range. It can support more trading near those prices with the same assets, but its inventory and fee earning change when prices leave the interval.
Confidential amount ↗: A transaction design that hides transferred values while letting verifiers check required balance relationships. Concealing amounts is one privacy property; it does not by itself conceal recipients, network connections or every link between transactions.
Confirmation ↗: Evidence that a transaction has been included in an accepted block. Additional blocks can increase confidence in some systems. Confirmation and irreversible settlement are not universal equivalents; the relevant network and bridge rules determine what remains uncertain.
Consensus ↗: The process participants use to agree on accepted history and updates. It combines validity checks with rules for resolving competing views. Its guarantees depend on assumptions about honest participation, communication and control of relevant resources.
Constant product ↗: A pricing model relating two pool reserves by x × y = k before fees. Removing one asset requires adding the other; retained fees and deposits can change k, and this model does not describe every AMM.
Contagion ↗: The spread of financial or operational stress from one system to others through linked obligations, collateral or infrastructure. For example, a failed receipt can weaken loans using it as collateral; the effect depends on the actual connections.
Contract address ↗: The network-specific address identifying a deployed contract. Together with the network, it helps distinguish a token or application from lookalikes. A familiar name, ticker or address format is not sufficient to establish identity.
Coretime ↗: Access to a share of Polkadot’s validation-processing capacity over a period of time. It is a network resource used by applications or chains, not a guarantee of users, transaction demand or token appreciation.
Correlation ↗: A tendency for values or outcomes to move together. Two token positions can share a price driver, custodian or protocol dependency; an observed relationship can change, and different asset names do not ensure independent risks.
Cosmos Hub ↗: The ATOM-secured blockchain within the wider Cosmos ecosystem, with its own validators, governance, application modules, and connections to other chains through IBC.
Cosmos SDK ↗: A collection of software components for building application-specific blockchains. Developers combine modules for functions such as balances, staking and governance. Using the SDK does not make all resulting chains share validators, balances or security.
CosmWasm ↗: A smart-contract framework used by some Cosmos-based chains, executing contracts compiled to WebAssembly. It lets applications add programmable behavior to a chain; supported functions and contract deployment permissions depend on that chain’s configuration.
Counterparty ↗: The other participant whose performance a financial arrangement depends on, such as a borrower, issuer or trading venue. Counterparty risk is the possibility that this participant fails to pay, deliver assets or meet another obligation.
CRO ↗: CRO pays transaction fees on Cronos EVM and participates in the Cronos POS staking economy. A token’s symbol alone is insufficient to identify where a balance exists or how to send it.
Cronos ↗: Cronos is an ecosystem with two distinct active chains described in current documentation: Cronos EVM and Cronos POS. Sharing CRO does not make their accounts, validators or transaction paths identical.
Cross margin ↗: An arrangement in which multiple positions share a supporting collateral or equity pool under a venue’s rules. This can help offset some exposures, but losses from one position can consume resources supporting others.
Cross-Consensus Messaging ↗: A format for expressing instructions between systems in the Polkadot ecosystem. It describes what a message asks the destination to do. Successful execution still depends on transport, permissions, supported assets and the destination’s rules.
Crypto-backed stablecoin ↗: A token whose target is supported through pledged crypto assets and associated debt or conversion rules. Price feeds, collateral requirements and liquidation or redemption processes connect the claim to its backing; losses can still exceed the buffer.
Cryptocurrency ↗: A digital asset whose ownership and transfers follow cryptographic authorization and a network’s rules. Different assets have different purposes and control arrangements; the label does not promise stable value or a claim on anything outside the network.
Cryptographic commitment ↗: A compact value that binds its creator to particular data so that a later revelation can be checked. Some commitment schemes also hide the data. Committing to information does not establish that an outside claim in it is true.
Cryptographic hash ↗: A fixed-length fingerprint calculated from data. Identical input produces the same fingerprint; a secure design makes deliberate collisions impractical. A matching hash checks consistency with particular bytes, not whether the information is true or trustworthy.
Cryptographic sortition ↗: Selecting participants by a cryptographically verifiable lottery, often weighted by stake. A selected participant can prove eligibility without an administrator choosing the winner. Fairness and security depend on the randomness, weighting and protocol assumptions.
Cryptography ↗: Mathematical techniques for protecting information and checking claims, including signatures, hashes and encryption. Blockchains use them to verify authorization and detect changed data. Cryptography cannot by itself establish that an outside fact is true or that software is bug-free.
Custodial balance ↗: An entry in a service’s records showing the assets it owes or makes available to a customer. It can change through internal trades without a blockchain transaction; withdrawing requires the service to release assets.
Custodian ↗: A person or organization responsible for holding assets or controlling their transfer for someone else. Its duties, withdrawal processes and ability to use the assets depend on the arrangement; an on-screen balance alone does not prove assets are available.
Custody ↗: The arrangement that determines who can authorize movement of assets and how they are kept. A custodial service usually controls spending keys for customers; its account balance records what the customer is entitled to under the service’s terms.

D

DAI ↗: A dollar-targeting token within the Sky protocol’s collateral and stablecoin-conversion system. Its support can involve other tokens and external issuers; converting it to USDS or another stablecoin is different from receiving dollars in a bank.
Daml ↗: A language for expressing contracts, stakeholders and permitted actions in systems such as Canton. Participants validate the parts of a transaction relevant to their role. Those authorization rules are separate from the service that orders encrypted messages.
DAO ↗: An organization coordinated partly through onchain rules and collective decision processes. Its actual powers depend on voting, contracts and administrative arrangements. The label does not establish that it is fully autonomous, widely controlled or a particular legal entity.
Dash ↗: A payment-focused network combining proof-of-work mining with collateralized masternodes that provide transaction locking, chain locking, governance, and additional services. DASH is the payment and fee asset. Masternode operation requires collateral, and the reward system also funds service operators and governance-approved work rather than allocating everything only to miners.
Data availability ↗: The ability to obtain the data needed to check or reconstruct a system’s results. A correct-looking summary or proof does not automatically supply that data. Availability is separate from long-term archival storage and from execution correctness.
Data-availability sampling ↗: Checking randomly selected pieces of encoded block data to gain confidence that the complete data was published. It reduces what a light node downloads, while relying on the encoding scheme, sampling assumptions and enough independent participation.
Debt ↗: An amount owed, including the borrowed principal and any accrued charges. Its denomination matters: owing one token means that token’s changing price can change the debt’s value in dollars or another reporting currency.
Decentralization ↗: The distribution of control and dependence across independent participants. Block production, software development, upgrades and user access can each be distributed differently. A large participant count alone does not show that control is independent or evenly shared.
Decentralized application ↗: An application that uses blockchain programs for some of its behavior or records. Its website, data sources and administrative controls may still depend on particular operators. Calling an app decentralized does not establish that every component is independently verifiable.
Decentralized exchange ↗: A trading system whose exchanges settle through blockchain rules, often using smart contracts. It may use pools, order books or signed quotes; its website, matching services and administrative powers can still involve operated components.
Decentralized finance ↗: Financial activities implemented through blockchain applications, such as exchanging assets and making collateralized loans. Smart contracts carry out parts of the process, but operators, administrators, data providers and outside institutions may still be involved.
Delegated proof of stake ↗: A stake-based arrangement in which holders delegate or vote to select block-producing representatives. Implementations vary in how many representatives operate, how they are replaced and what misconduct can be penalized. Delegating influence differs from operating a validator.
Delegation ↗: Assigning stake or voting influence to a validator under a network’s rules. The validator performs the operational duties. Delegation does not automatically mean transferring ownership, but rewards, withdrawal restrictions and exposure to penalties vary by system.
Deleveraging ↗: Reducing exposure relative to the capital supporting it, often by selling assets and repaying debt or closing contracts. Forced deleveraging during stress can involve unfavorable prices and affect other positions sharing the same liquidity.
Depeg ↗: A departure of a stablecoin’s trading price from its target. It can result from trading conditions, restricted redemption or lost backing; the price move alone does not establish which cause applies or whether it will reverse.
Derivation path ↗: The sequence of choices a wallet uses to derive one account’s key from a shared seed. Different paths can produce different accounts from the same recovery material, which is why compatible recovery settings matter.
Derivative ↗: A financial contract whose value or payments depend on an asset price, rate or event. It can provide exposure without ownership of the underlying token, while adding settlement, collateral and counterparty conditions.
Digital signature ↗: Cryptographic evidence that particular data was authorized using a private key. Other people can check it without knowing the secret. A valid signature does not prove that the signer understood the action or that the proposed transaction is safe.
Dilution ↗: A reduction in a holder’s share of total supply or another defined entitlement when additional units or claims are created. Holding more token units can still coincide with dilution if the overall supply grows faster.
Directed acyclic graph ↗: A structure of records linked in a direction without circular paths. Unlike one simple chain, it can represent multiple parallel branches. A network still needs rules to order or interpret those records and reject conflicting activity.
DOGE ↗: DOGE pays transfers and transaction fees, with ongoing mining issuance. Buying or holding DOGE does not directly earn consensus staking rewards.
Dogecoin ↗: A standalone proof-of-work payment network with meme origins and merged mining.
DOT ↗: DOT participates in staking, governance, fees and resource allocation. Agile Coretime offers bulk or on-demand access to validation capacity. Older accounts of mandatory parachain slot auctions no longer describe the general access model.
Double spend ↗: An attempt to use the same spendable value in conflicting transactions. A ledger’s authorization and consensus rules decide which valid history is accepted, preventing both conflicting spends from being accepted together under those rules.

E

EigenDA ↗: A separate data-availability service used in some modular blockchain designs. It adds its own operator and verification assumptions for publishing required data. It should be distinguished from posting transaction data in Ethereum blobs, including when a deployment is migrating between them.
Encryption ↗: Transforming readable data into a form that requires the appropriate key to read. It protects confidentiality under specific assumptions. Signing proves authorization and hashing fingerprints data; neither operation is automatically encryption.
Encumbrance ↗: A restriction or competing claim on an asset, such as a pledge to another lender. An asset can appear in a balance without being freely available to repay customers because another obligation already has rights over it.
Entropy ↗: Unpredictability in the material used to generate secrets. Cryptographic keys need enough unpredictable randomness to resist guessing. Choosing a memorable pattern or weak random source can undermine security even when the mathematical algorithm is otherwise sound.
Epoch ↗: A protocol-defined period used to organize duties or accounting, often made up of several block opportunities called slots. Different networks use different lengths and purposes, so an epoch is not a universal number of seconds.
Equity ↗: The residual value after subtracting debt and other relevant obligations from assets. In a trading account, venue rules also account for gains and losses; equity can shrink faster than asset prices when the position uses leverage.
ERC-1155 ↗: An Ethereum token interface that can manage multiple token types within one contract, including interchangeable and individually identified types. It also supports grouped operations. The standard describes software behavior rather than the outside rights associated with each type.
ERC-20 ↗: An Ethereum token interface for interchangeable balances, transfers and spending allowances. Many different assets implement it. Sharing the interface does not make two tokens the same asset or guarantee their backing or safety.
ERC-2612 permit ↗: A signed message that can set a token allowance when submitted successfully to an ERC-2612 token contract. Its deadline limits when it can be submitted; it does not make an already established allowance expire at that time.
ERC-721 ↗: An Ethereum token interface for separately identified, non-fungible tokens and their ownership. It helps applications track and transfer individual token IDs, while any rights to artwork, files or outside property depend on additional arrangements.
ETC ↗: ETC pays gas and compensates miners through block rewards and fees. Simply holding ETC does not earn a native proof-of-stake yield. An advertised interest product involving ETC would depend on a separate service or protocol.
Ether ↗: The native asset of Ethereum, used for transaction fees and proof-of-stake commitments. It differs from tokens issued by application contracts on Ethereum. ETH held or represented on another network can involve additional bridge or issuer arrangements.
Ethereum ↗: A shared smart-contract platform whose base layer also settles activity from many rollups.
Ethereum Classic ↗: A proof-of-work smart-contract chain sharing Ethereum’s early history but maintaining its own ledger, development decisions and native ETC asset.
Ethereum Improvement Proposal ↗: A documented proposal for changing or standardizing part of the Ethereum ecosystem. Publishing an EIP is not the same as deploying a change: review, implementation and activation are separate steps.
Ethereum Virtual Machine ↗: The execution environment used by Ethereum to run smart-contract instructions. Other networks can implement compatible behavior, but their consensus, balances, fees and upgrade controls remain separate. Sharing the EVM does not mean sharing Ethereum’s security.
EURC ↗: Circle’s euro-targeting token supported by a euro reserve arrangement. Tracking one euro does not fix its dollar price: that changes with the euro–dollar exchange rate, while redemption and use remain subject to the product’s terms.
EVM-compatible ↗: Able to support Ethereum-style contracts or tools to a defined extent. Compatibility can have exceptions in instructions, deployment or fee behavior. It does not mean balances are shared across chains or that Ethereum validators secure the other network.
EVM-equivalent ↗: Designed to closely reproduce the Ethereum Virtual Machine’s execution rules, so ordinary contracts behave as expected. The precise claim depends on the implementation. Equivalent execution still leaves settlement, fees, data publication and administrative control as separate questions.
Execution ↗: Carrying out an instruction. In a blockchain, execution runs transaction or program rules to update recorded state. In trading, execution means filling an order against available quotes or liquidity; a quote alone is not a completed trade.
Exit liquidity ↗: The buyers, pool inventory or withdrawal funds available to turn a position into usable assets. A displayed value can exceed what an exit actually pays after price impact, limits and fees.
Expected Consensus ↗: Filecoin’s block-production mechanism, using protocol-defined storage power to influence producer selection. Multiple eligible blocks can contribute to the same period’s history. Storage commitments and their proofs are part of this model, rather than ordinary token-weighted staking alone.
Extended UTXO ↗: Cardano’s extension of output-based accounting, allowing outputs to carry data and richer spending conditions. Transactions explicitly identify the outputs they consume. Applications must handle shared state carefully because each output can only be consumed once.

F

Fast Finality in Filecoin ↗: Filecoin’s additional mechanism for finalizing accepted chain history alongside its existing block-production process. Finalization and storage-provider selection are different responsibilities. This does not make every file retrieval immediate or remove application and storage-service dependencies.
Fault proof ↗: Evidence and a verification process used to challenge an incorrect claimed result. In an optimistic rollup, the dispute system determines whether the claim should be rejected. Effective protection also requires access to data and a functioning challenge path.
Federated Byzantine Agreement ↗: An agreement model in which participants choose sets of other participants they rely on. Safe shared decisions depend on suitable overlap and honest behavior within those trust choices, rather than a universal mining-power or token-weighted vote.
Fee sponsorship ↗: An arrangement in which another account or service pays transaction costs for the user, under specified conditions. It can simplify access, but computation still has a cost and sponsorship may be limited, conditional or withdrawn.
FET ↗: Native FET pays network transaction fees and supports staking and services. An ERC-20 representation also exists on Ethereum, so the same ticker does not identify the network or token form being used.
Fetch.ai / ASI Network ↗: A native blockchain within the ASI ecosystem that records payments, staking, and smart-contract activity associated with software agents and decentralized services.
Fiat currency ↗: Money such as US dollars or euros issued within a national monetary system, rather than a blockchain’s native token. A token targeting a fiat currency is a separate instrument with its own backing, control and redemption arrangements.
Fiat-backed stablecoin ↗: A token whose target is supported by an issuer’s reserve arrangement linked to a national currency. Reserves may include deposits and permitted investments; direct redemption, fees and eligibility depend on the issuer’s terms.
FIL ↗: FIL pays network fees and participates in storage-provider collateral, rewards, and storage economics. An application may use additional payment assets without changing FIL’s role in the underlying network.
Filecoin ↗: A storage network and programmable blockchain that uses economic commitments and cryptographic proofs to coordinate providers, data storage, and on-chain services.
Filecoin Virtual Machine ↗: Filecoin’s programmable execution environment for onchain applications, including programs that coordinate storage commitments. Its FEVM component supplies Ethereum-compatible execution. Running a contract and successfully retrieving an externally stored file are separate operations.
Finality ↗: The point or degree at which accepted history is treated as no longer reversible under a network’s assumptions. Some systems use explicit voting; others gain confidence as more work accumulates. A fast acknowledgment is not necessarily final settlement.
Flare ↗: An EVM smart-contract network with native protocols for price data and verification of external events, designed for applications that depend on information beyond their own ledger.
Flash loan ↗: A loan used within one blockchain transaction, normally repaid with any required fee before that transaction completes. If its completion conditions fail, the transaction reverts; some protocols also allow an explicitly authorized debt position instead of immediate repayment.
Flashblock ↗: An early streamed update about transactions during block construction in systems such as Unichain. It gives applications faster feedback than waiting for the complete process, while remaining distinct from a proof, a completed dispute period or finalized Ethereum settlement.
FLR ↗: FLR pays network transaction fees and supports staking. Wrapped FLR enables delegation of data-provider voting power and participation in governance, with the relevant roles governed by each protocol’s rules.
Fork ↗: A branch in blockchain history or a change in its rules. Temporary competing branches can occur without a rule change. A lasting split happens when participants continue following incompatible histories or rule sets.
Fork-choice rule ↗: The rule a node uses to choose between competing valid histories. Examples consider accumulated work or validator votes. This choice is separate from checking whether each candidate history follows the network’s transaction and issuance rules.
Full node ↗: A node that independently checks blocks and transactions against the network’s rules. It can reject invalid activity without trusting a block producer’s claim. Full validation does not necessarily require keeping every old block forever.
Fully diluted valuation ↗: A quoted token price multiplied by a stated future or fully issued supply figure. It is a hypothetical valuation at that price; it does not predict future prices or mean all those units can be sold today.
Funding rate ↗: A rate determining recurring payments associated with a perpetual position. In common designs, one side pays the other to encourage price alignment; direction and amount can change, so receiving funding is not guaranteed income.
Fungible ↗: Interchangeable with another unit of the same asset for the relevant purpose. A balance of ordinary fungible tokens counts units rather than identifying each one separately. Similar tickers do not make different contracts or network representations interchangeable.
Futures contract ↗: An agreement specifying a future delivery or cash-settlement obligation based on an underlying asset. Its expiry, settlement asset and margin rules matter; holding the contract is different from owning the underlying token today.

G

Gas ↗: A unit measuring computation and other resources consumed by transaction execution. The fee depends on the amount used and the applicable price rules. Failed execution can still cost gas because the network performed work before detecting the failure.
Gas limit ↗: The maximum execution-resource budget permitted for a transaction or block. A transaction can fail if its work exceeds its budget. The limit is a resource ceiling, not the same thing as the price paid per gas unit.
Gas price ↗: The amount paid per unit of gas under a network’s fee rules. A transaction’s total fee also depends on how much gas it consumes. Low cost per unit does not guarantee that every transaction will be inexpensive.
GateChain ↗: An independent smart-contract chain using GT for network fees and stake-weighted consensus, distinct from a balance held at the Gate exchange.
Gatemint ↗: GateChain’s consensus design using stake-weighted, verifiable random selection for block proposals and voting committees. The selected participants exchange votes to agree on valid blocks. Cryptographic selection does not remove the need for honest-participation assumptions.
Genesis block ↗: The starting block of a blockchain. Later blocks build on this initial history. A network’s starting rules and allocations form part of its initial conditions, rather than being created by ordinary later transactions.
Geth ↗: An Ethereum execution-client implementation that processes transactions and checks execution rules. Other chains can adapt its code for their own networks. Using Geth-derived software does not make those chains share Ethereum’s consensus, state or upgrade policies.
GHOSTDAG ↗: Kaspa’s method for organizing parallel proof-of-work blocks into an agreed ordering. It lets eligible concurrent blocks contribute to history rather than treating every parallel block as a discarded branch. Nodes still check transactions and resolve conflicting spends.
Gold-backed token ↗: A token representing a specified interest in gold held through a custody arrangement. Its reference is a quantity of gold, whose price changes in dollars; ownership rights, fees and physical-redemption conditions depend on the issuer’s terms.
Gossip ↗: A communication method in which participants repeatedly share information with peers, which then spread it further. It helps distribute transactions or events. Information spreading alone is not consensus about which updates should be accepted.
Governance ↗: The process for deciding and implementing changes to a network or application. It can involve developers, operators, token votes and administrative keys. Governance over the rules is distinct from consensus about transactions under existing rules.
Governance token ↗: A token used to determine voting rights in a specified decision process. Holding it does not necessarily control every system parameter or confer ownership rights. Delegation, participation thresholds and administrator powers affect how decisions are made.
GRAM ↗: GRAM is the native asset for network fees and staking. Older documentation and wallet interfaces may still refer to Toncoin or TON; a ticker match alone is not sufficient asset identification.
GRANDPA ↗: A finality mechanism used in the Substrate ecosystem, where authority votes establish accepted chain history. It can operate alongside a separate block-production mechanism. Its guarantees depend on the authority set and the applicable fault assumptions.
GT ↗: GT pays transaction fees and contributes consensus weight when used in the network’s staking arrangements. Its exchange-related uses are separate: an exchange account entry is an obligation of that custodian, not direct possession of native GT on GateChain.
Gwei ↗: A denomination equal to one billionth of an ether, commonly used to quote Ethereum gas prices. It is a unit of amount, not a separate token or a fixed monetary value.

H

Hard fork ↗: A rule change that allows behavior older rules reject. Participants need compatible software to follow that change. A coordinated hard fork can be an ordinary upgrade; it does not necessarily leave two persistently used networks.
Hardware wallet ↗: A dedicated device that keeps signing keys separated from ordinary computer applications and signs requests internally. It can reduce key exposure, but the user still needs to understand the requested action and verify the destination and permissions.
Hash collision ↗: A collision occurs when different inputs produce the same hash. Collision resistance means finding such a pair should be computationally impractical. This property helps fingerprints detect altered data, but it does not establish who created the data.
Hash rate ↗: The rate at which mining equipment performs hash attempts. More attempts increase a miner’s chances of finding qualifying work under the same rules. Hash rate is a computing measure, not the number of independent operators.
Hashgraph ↗: Hedera’s record of communication events and the consensus method built around it. Participants share events and their ancestry, allowing them to infer voting information. Its agreement guarantees depend on the protocol’s participation and network assumptions.
HBAR ↗: HBAR pays network fees and participates in the staking system. Fees are denominated in US dollars but paid in HBAR; that pricing convention does not make HBAR a stablecoin.
Health factor ↗: A lending risk ratio comparing collateral adjusted by liquidation thresholds with debt value. In the Aave-style model used here, below one means liquidation eligibility; it does not prove collateral is already worth less than the debt.
Hedera ↗: A public distributed ledger using hashgraph consensus and council-operated consensus nodes.
Hedge ↗: A position intended to offset a particular exposure in another position. For example, a short can offset some price changes in an asset held outright; mismatched prices, costs and counterparty failures can prevent a complete offset.
Heimdall ↗: The validator-coordination layer in Polygon PoS and related architectures. It participates in agreement and checkpoint-related duties while Bor handles execution blocks. These roles help connect the system to Ethereum without making it an Ethereum-verified rollup.
Hot wallet ↗: A wallet whose signing arrangement is accessible through an internet-connected environment. This makes frequent use convenient while exposing the signing process to online threats; the exact protection depends on the device, software and authorization rules.
HYPE ↗: HYPE supports consensus staking and pays HyperEVM gas. A leveraged trading balance is a separate position with collateral, margin and liquidation rules.
HyperBFT ↗: Hyperliquid’s consensus system for agreeing on its chain’s state. Both its native trading operations and EVM environment use that consensus. The shared system does not make HyperEVM a rollup whose execution is settled by Ethereum.
Hyperliquid ↗: A finance-focused layer 1 combining native order books with an EVM application environment.

I

ICP ↗: ICP can be locked for governance participation and converted into cycles that fund computation, storage and messaging. Cycles are consumed by canisters and cannot be converted back into ICP through the minting mechanism. Applications can fund these costs for their users.
Impermanent loss ↗: The shortfall of a liquidity-pool position compared with simply holding its starting asset quantities, using the same prices and time period. It can occur even when the position gains in dollar value, and it need not disappear.
Incentive token ↗: A token distributed to encourage specified activity. Its unit count and market value are separate: receiving more reward tokens does not ensure more spendable money, especially if the program ends or buyers are scarce.
Initial margin ↗: The minimum supporting collateral or account value required to open or increase a position. It is distinct from the maintenance requirement used to decide whether an existing position may remain open.
INJ ↗: INJ pays gas, backs staking and supplies governance voting power. Protocol mechanisms also use INJ in fee-related buyback and burn processes. Burning some tokens does not by itself prove that total supply falls or that a holder earns a return.
Injective ↗: A proof-of-stake application chain with native financial modules, including an order book, alongside programmable smart-contract environments.
Insolvency ↗: A condition in which recoverable assets are insufficient to meet obligations. It differs from a temporary outage or withdrawal delay; identifying insolvency requires examining what is owed and what can actually be recovered.
Insurance fund ↗: Assets reserved by a trading system to absorb specified losses, such as gaps left by liquidations. Its role and resources depend on the venue; the label does not imply government insurance or unlimited coverage.
Inter-Blockchain Communication ↗: A protocol for exchanging messages between independent chains through defined connections, channels and verification rules. Applications determine what the messages mean, such as token transfers. Using IBC does not turn separate chains into a single ledger or security system.
Interest rate ↗: The price of using borrowed assets over time, expressed relative to the amount owed. A quoted annual rate needs a time and compounding convention; it may change while the loan remains open.
Interest-rate curve ↗: A rule connecting conditions such as pool utilization to borrowing rates. A steeper rate above a chosen usage level is intended to influence borrowing and supply, but higher rates cannot force cash to return immediately.
Internet Computer ↗: The Internet Computer runs applications called canisters across subnet blockchains. A canister combines executable code and persistent state, allowing a network-hosted service to do more than simply transfer tokens.
Interoperability ↗: The ability for separate systems to exchange usable messages or coordinate actions. It does not merge their ledgers or guarantee identical security. Each connection needs rules for verifying the source, interpreting the message and handling failures.
Isolated margin ↗: A margin arrangement assigning a defined pool of support to a position or market under the venue’s rules. It limits which resources are initially shared, but does not eliminate platform, pricing or liquidation risks.
Issuance ↗: The creation or release of token units under a network’s or issuer’s rules. Newly created rewards increase supply, while paying rewards from an existing treasury moves existing units without necessarily creating any more.
Issuer ↗: The entity responsible for creating an instrument and its associated arrangement or obligations. A stablecoin issuer may control issuance, redemption and some token restrictions; the blockchain recording transfers is a separate part of the system.
Issuer-native token ↗: A token deployment recognized directly by its issuer on a supported network. It differs from a third-party bridge receipt for tokens held elsewhere; here native describes the issuer relationship, not necessarily the network’s gas coin.

K

KAS ↗: KAS is the native payment asset. Transaction senders pay fees in KAS, and miners receive protocol issuance and transaction fees for contributing accepted work.
Kaspa ↗: A proof-of-work payment network that orders parallel blocks in a blockDAG instead of discarding every competing block from a single chain.
KCS ↗: KCS is the native gas asset and is used in the network’s voting and staking arrangements. KCS also has exchange-related uses, but an exchange incentive or custody product should not be described as a KCC consensus reward.
Keypair ↗: A private key and its mathematically related public key. The private part signs; the public part lets others verify. Publishing the public part does not normally reveal the secret, assuming the scheme and key generation are secure.
Kite ↗: A live EVM-compatible network focused on payments by software agents, combining blockchain settlement with a permission system for delegated spending. KITE is the native gas token and supports staking and governance. Agent-facing payments can use stablecoins, and sponsored gas can hide fee handling without making the network’s execution free.
KuCoin Community Chain ↗: KCC is an EVM-compatible public chain using KCS for gas and validator selection; KuCoin exchange accounts are a separate custodial service.

L

Layer 1 ↗: A base blockchain with its own rules for accepting transactions and agreeing on history. Other systems may use it for settlement or data publication. Being a base layer does not imply one particular execution model or security level.
Layer 2 ↗: A system that processes activity separately while deriving specified security or settlement guarantees from a base blockchain. Designs differ in how they prove execution, publish data and permit exits. A connected sidechain does not automatically offer the same guarantees.
Ledger ↗: A record of ownership, balances and transactions. In a blockchain system, participating computers check updates against common rules. A ledger entry can show what the system recognizes without proving that an outside asset or promise really exists.
Lending ↗: Providing assets for others to use in exchange for a repayment or withdrawal claim under defined terms. Borrowers commonly pay interest; the lender still depends on available liquidity, borrower repayment, collateral recovery and the mechanism’s operation.
Leverage ↗: Using borrowing or financial contracts to create exposure larger than the capital supporting it. This amplifies the effect of price changes on that capital, and interest, liquidation and costs can further alter the outcome.
Liability ↗: An amount or duty owed to someone else. A customer’s exchange balance is an asset from the customer’s perspective but an obligation for the exchange; proving some assets exist does not establish all liabilities have been counted.
Light client ↗: Software that checks selected blockchain information using compact evidence instead of processing every transaction. It needs fewer resources than a full node, but its security depends on the specific proof system, available data and trust assumptions.
Lighter ↗: Lighter Core is an Ethereum-settled trading rollup that proves order-book and risk-engine execution, rather than a general-purpose proof-of-stake chain.
Limit order ↗: An order with a price boundary: a buy cannot pay more and a sell cannot receive less than the specified limit. It can remain unfilled or fill only partly if there is insufficient eligible opposing liquidity.
Limited access key ↗: An authorization key restricted to specified actions instead of giving full account control. NEAR supports keys with scoped contract-call permissions. The protection depends on the actual permitted functions and limits; a restricted label alone does not describe every power.
Liquid restaking token ↗: A transferable receipt for a position participating in restaking. It adds a wrapper, accounting and exit process on top of the underlying obligations; an extra receipt does not create more underlying collateral.
Liquid staking ↗: A staking arrangement that provides a transferable receipt for an interest in staked assets. The receipt can move while underlying assets remain committed, but market sale prices and protocol withdrawal timing may differ from its accounting value.
Liquid staking token ↗: A transferable token representing an interest in assets committed to staking and their associated rewards or penalties. It adds receipt contracts and exit rules; trading it on a market does not guarantee the same value as redeeming the underlying assets.
Liquidation ↗: A forced reduction or closure of a position after its rules are breached, often by using collateral to repay debt. A position can become eligible while its assets still exceed its debt, so liquidation does not necessarily mean insolvency.
Liquidation bonus ↗: Extra collateral allocated to a liquidator as an incentive for repaying eligible debt. It comes from the position’s collateral under the rules, so it is a cost to that position rather than free value created by liquidation.
Liquidation threshold ↗: The collateral-value boundary used to determine whether forced debt recovery is allowed. In the simplified lending model, debt above collateral value multiplied by this threshold makes the position eligible; the maximum entry borrowing limit is a separate parameter.
Liquidator ↗: A participant who carries out a protocol’s permitted forced recovery, often repaying part of a borrower’s debt in exchange for collateral. Their ability and incentive to act depend on prices, fees, liquidity and the protocol’s rules.
Liquidity ↗: The availability of assets or willing counterparties for a payment, withdrawal or trade. Trading liquidity means being able to transact meaningful amounts without large price changes; withdrawal liquidity means having assets available to release now.
Liquidity mining ↗: A program that distributes additional rewards to attract liquidity to a market or protocol. These rewards come from an allocation or issuance rule and are separate from the trading fees or interest the supplied assets generate.
Liquidity pool ↗: Assets grouped in a contract for uses such as trading or lending. A trading pool supplies inventory for swaps, while a lending pool supplies loans; the rules governing ownership, returns and withdrawal differ.
Liquidity provider ↗: Someone who supplies assets that other participants can trade or borrow. In an AMM, the provider’s share represents changing pool inventory and may earn trading fees; it is not a promise to return the original token quantities.
Liquidity risk ↗: The possibility that assets cannot be obtained, sold or withdrawn when needed on acceptable terms. It can occur even when enough recoverable assets exist overall; it is different from a permanent shortfall in backing.
LIT ↗: LIT supports ecosystem access and incentives, including staking programs linked to liquidity-pool access and fee-credit benefits. This is not Ethereum validator staking, and LIT should not be presented as mandatory gas for every Core order.
Litecoin ↗: A payment-focused Bitcoin relative using Scrypt mining and optional MWEB privacy functionality.
Liveness ↗: A system’s ability to keep making progress, such as accepting new blocks or finalizing transactions. It depends on the protocol’s participation and communication assumptions. A network can preserve existing records correctly while temporarily failing to make further progress.
Loan-to-value ↗: Debt value divided by collateral value. The same label can refer to a maximum borrowing limit; that entry limit is separate from the liquidation threshold governing when an existing position can be forcibly reduced.
Lock-and-mint bridge ↗: A bridge arrangement that holds an asset on one chain and creates a representation on another. The destination token depends on the custody and verification arrangements behind the locked asset; the original asset has not literally moved between ledgers.
Long position ↗: A position that generally gains from a rise in the referenced asset’s price and loses from a fall. A derivative long need not own the underlying asset, and fees, funding and liquidation can change its net outcome.
Loss socialization ↗: Allocating a shortfall across a wider group of participants under a trading system’s rules, rather than leaving it solely with the position that caused it. The allocation method and any prior buffers are specific to the system.
LP token ↗: A token or accounting share representing a liquidity provider’s interest in a pool. Its underlying asset quantities can change as trades occur; concentrated-liquidity positions may use distinct position records instead of interchangeable pool tokens.
LTC ↗: LTC pays transfers and fees and rewards miners. A maximum supply of 84 million and scheduled halvings define issuance; they do not guarantee purchasing power.

M

Mainnet ↗: The operational version of a blockchain intended for real use and assets under its live rules. The name does not prove maturity or safety. A project can have a live mainnet while participation or features remain restricted.
Maintenance margin ↗: The minimum support required to keep a position open under the venue’s rules. Falling below it can trigger liquidation before account equity reaches zero; the price and collateral valuation used depend on the venue.
Maker ↗: A participant posting quotes or orders that other traders can trade against. Makers supply trading opportunities and bear inventory and price risks; their offers can change, so the label does not promise continuous liquidity.
Mantle ↗: An EVM execution network settling on Ethereum, with a documented transition in both proof verification and data availability.
Margin ↗: Collateral allocated to support potential losses on a trading position. Margin is different from the position’s notional size; losses, fees and funding can reduce the supporting balance and trigger forced closure under the venue’s rules.
Mark price ↗: A calculated reference used by some trading venues to value positions and manage risk. It can differ from the latest trade; the venue’s formula determines how it affects unrealized results and liquidation.
Market capitalization ↗: A quoted token price multiplied by the supply counted as circulating. It is a valuation measure, not the cash invested in a token or the amount holders could receive by selling the entire supply.
Market depth ↗: The quantities available for buying or selling across a range of prices. Deep markets can usually absorb larger orders with less price movement, but displayed offers can disappear and depth says nothing by itself about a custodian’s solvency.
Market neutral ↗: Describes a strategy aiming to offset specified directional price exposure. It does not mean all risks cancel: funding, collateral valuation, mismatched hedges, liquidity and settlement can still cause losses.
Market order ↗: An instruction to trade against available opposing liquidity without the same explicit price boundary as a limit order. Its average execution price depends on the quantities available and the venue’s protections, not just the last displayed trade.
Masternode ↗: A network-specific service or validation node with extra responsibilities and participation requirements. In Dash, collateralized masternodes support transaction and chain-locking mechanisms. The title does not describe one universal role shared by every blockchain.
Matching engine ↗: The system that pairs compatible buy and sell orders under a venue’s rules. It decides which orders trade and in what quantity; custody, withdrawals and settlement are separate functions that must also work.
Maximum supply ↗: The greatest number of units a token’s rules are intended to permit. Whether that ceiling is enforceable depends on issuance rules and any ability to change them; it is separate from the number currently circulating.
MemeCore ↗: MemeCore is a standalone EVM-oriented chain built around meme-token issuance and community incentives. M is its native network asset; individual meme tokens are separate contracts and carry their own supply and control rules.
Mempool ↗: A node’s collection of transactions waiting to be included in a block. Different nodes can see different pending transactions. A transaction appearing here is neither guaranteed inclusion nor already settled.
Merged mining ↗: Using eligible proof-of-work effort to contribute to more than one blockchain’s block production. Each chain still checks its own rules. Sharing mining work does not merge balances, histories or all security assumptions.
Merkle root ↗: A compact hash summarizing a tree of records. A Merkle proof can show that a particular record belongs to the committed collection without sending the entire collection. The root alone does not supply the underlying records.
Midnight ↗: A programmable privacy network where applications combine public state with private information and prove permitted actions without publishing every underlying detail.
Mimblewimble Extension Block ↗: Litecoin’s optional extension for transactions with additional privacy features. It follows a distinct transaction path with its own wallet and integration requirements. Ordinary Litecoin transfers should not be assumed to use that privacy path automatically.
Minimum output ↗: The least output a swap is allowed to deliver. If the contract cannot satisfy this condition, the swap can revert; an accepted failed transaction may still incur network execution fees.
Mining ↗: Producing candidate blocks and competing to satisfy a proof-of-work target. A successful block can earn protocol rewards and transaction fees. Independent nodes still check the block; miners cannot simply change ownership or supply rules by claiming success.
Mining difficulty ↗: A measure of how demanding the proof-of-work search is. Protocol rules adjust the acceptable hash target to influence average block production. Difficulty does not make each individual block arrive on a fixed schedule.
Mining pool ↗: A group of miners that combines work and shares payouts under an agreed scheme. Pooling can make individual payouts less irregular, while concentrating decisions such as block construction in the pool operator.
Mirror node ↗: In Hedera, a service that stores and exposes network history for applications and queries. Running a mirror node does not make its operator a consensus voter. Reading replicated history is a different role from deciding accepted updates.
MNT ↗: MNT pays Mantle gas and supplies voting weight in ecosystem governance. Holding MNT is not the same activity as staking ETH to operate an Ethereum consensus validator, and governance rights do not guarantee a financial return.
Modular blockchain ↗: A design that assigns execution, agreement, settlement or data publication to distinct components. Separating duties can allow specialization, while creating explicit dependencies between them. Each component’s guarantees and failure modes need to be examined.
Monero ↗: A payment network that makes transaction privacy part of ordinary protocol use.
Morph ↗: Morph is an Ethereum layer two focused on payment applications. Its current ecosystem uses BGB for core gas, governance and settlement roles, extending a token many people first encountered through Bitget.
Move language ↗: A programming language and execution model used by chains including Aptos and Sui. It provides rules for representing assets and controlling how values are created, copied or transferred. Each chain adds its own storage, execution and consensus arrangements.
Multisig ↗: An authorization arrangement requiring a specified number of approved signers, such as two of three, before an action is allowed. It distributes control, but recovery, signer independence and any alternative administrative permissions still matter.

N

Namespace ↗: A label that separates one application’s data from another’s within a larger data collection. Celestia uses namespaces to help applications retrieve relevant published data. Separating labels does not itself prove the application executed its transactions correctly.
Native coin ↗: An asset built into a network’s core accounting or fee rules, rather than merely represented by an application contract. Its uses vary by network, and the asset used for gas need not be the same asset used for governance or security.
NEAR ↗: NEAR pays computation and storage-related costs and is used for staking. An application may sponsor a user’s gas, but the underlying resource cost still exists.
NEAR Protocol ↗: A sharded application chain with named accounts, access keys and WebAssembly contracts.
Net return ↗: The overall change in value after the costs and losses included in the calculation. Token-unit rewards and changes in token price are separate components; a positive token yield can coexist with a negative return measured in dollars.
Network Nervous System ↗: Internet Computer’s governance system for decisions such as network configuration and node-provider admission. Participation and voting follow its rules. Voting or locking ICP does not itself turn a user’s computer into a network replica.
NFT ↗: A non-fungible token: a separately identified token whose record can be distinguished from others. Owning it does not automatically transfer copyright, ownership of a referenced object or permanent access to a linked file.
NIGHT ↗: NIGHT generates DUST, a renewable, non-transferable resource used for network transactions. The capital token and the consumed network resource therefore have different roles; holding NIGHT is not the same as paying each fee in NIGHT.
Nitro ↗: Arbitrum’s software architecture for running Ethereum-compatible applications and supporting its rollup protocol. On Arbitrum One, transaction data is published to Ethereum. The sequencer’s local execution remains a separate step from disputes and completed base-chain settlement.
Node ↗: A computer running software that participates in a blockchain network. Nodes may check rules, exchange transactions, retain history or provide data. Running a node does not automatically mean producing blocks or receiving rewards.
Nominal token yield ↗: Rewards measured in token units relative to the token amount committed. This separates the unit increase from changes in market price; earning more units can still leave a position worth less in dollars after prices and costs change.
Nominated proof of stake ↗: Polkadot’s arrangement for selecting and economically backing validators using stake from validators and nominators. Nominating assigns backing rather than running the validation hardware. Selection, rewards and penalties follow the protocol’s particular rules.
Nonce ↗: A number used for a particular cryptographic or protocol purpose. For an Ethereum account, it orders outgoing transactions and helps stop reuse. In mining, a nonce is one field miners vary while searching for a qualifying block hash.
Notional ↗: The reference size of a financial position, often quantity multiplied by a reference price. It measures exposure rather than the capital actually posted; a large notional can be supported by a much smaller margin balance.

O

Object-centric ↗: An application model organized around separately identified objects containing data and ownership rules. In Sui, owned and shared objects have different access patterns. Independent objects can enable parallel work, while shared data still needs coordination.
Offchain ↗: Happening outside a blockchain’s ordinary recorded execution, such as an exchange’s internal accounting or a website request. Offchain activity may later be reported onchain, but that report does not automatically verify every earlier step.
OKB ↗: OKB is the native gas asset. Having ETH on Ethereum does not automatically fund an ordinary X Layer transaction, and an OKB balance on an exchange is not automatically available to a wallet on the chain.
Onchain ↗: Recorded or executed within a blockchain’s accepted state and rules. An onchain record can still refer to outside assets or facts; recording a claim does not independently verify the real-world event behind it.
OP Stack ↗: A software stack for building Ethereum-connected optimistic rollups. The Superchain is an ecosystem of chains built around shared standards and coordination. A particular chain’s deployed proof system, upgrade powers and transaction rules still determine its actual guarantees.
Operating buffer ↗: Resources set aside to absorb specified costs or losses before another claim is affected. Its protection depends on size, availability and allocation rules; a finite buffer can be exhausted and does not guarantee principal repayment.
Optimistic rollup ↗: A rollup that initially accepts proposed results while allowing them to be challenged during a defined period. Security depends on the dispute mechanism and the ability to detect and contest invalid results. Local inclusion can happen before settlement is complete.
Option contract ↗: A contract giving its buyer a specified right, without the same obligation to exercise, under agreed terms. The buyer pays a premium; the seller takes on the corresponding obligation, and the payoff differs from a simple linear token position.
Oracle ↗: A mechanism that supplies information to a blockchain application, such as an asset price. The chain can verify how a value was delivered without proving the outside-world value is accurate, timely or appropriate for the application.
Oracle manipulation ↗: Deliberately influencing the data or market observations a protocol uses to make decisions. Moving a thin market that supplies its price can distort borrowing or liquidation calculations even when the application executes its code correctly.
Oracle price ↗: The price a protocol accepts from its configured data mechanism for calculations such as borrowing limits or liquidation. It can differ from the price actually available when assets are sold in a market.
Order book ↗: A collection of buy and sell offers with quantities and prices. An incoming trade can consume several price levels, and offers may be changed or canceled before execution, so displayed depth is only a snapshot.
Ouroboros ↗: Cardano’s family of proof-of-stake protocols for selecting block producers and agreeing on history. Participation depends on stake and the particular protocol version. Its security rests on assumptions about honest stake and network communication.
Out-of-range position ↗: A concentrated-liquidity position whose market price is outside its selected interval. It ordinarily holds only one of the pool’s assets and stops earning active swap fees; being out of range does not by itself lock withdrawal.
Overcollateralization ↗: Providing collateral valued above the amount owed. The excess is a buffer against losses, not a guarantee: prices can move, selling can incur costs and access to collateral can fail.

P

Parachain ↗: An application-specific chain whose blocks are checked through Polkadot’s shared validation system. It can have its own application rules and state. Sharing validation infrastructure does not mean every parachain supports the same transactions or assets.
Parallel execution ↗: Processing independent pieces of work at the same time. Blockchain systems must still handle transactions that touch the same data and ensure results match the agreed rules. Parallel execution increases processing opportunities; it does not replace consensus.
Partial fill ↗: An execution that completes only part of an order’s requested quantity. The remaining amount may stay open or be canceled according to the instructions; unfilled tokens remain owned rather than becoming sale proceeds.
Passphrase ↗: Additional secret text used by some recovery schemes. In BIP 39, changing the passphrase produces a different seed and different accounts, even when the recovery words are unchanged. It is not necessarily the same as the wallet app’s login password.
PAXG ↗: Paxos’s token representing a specified quantity of allocated gold under its custody arrangement. Its reference is gold, not one dollar, so its dollar value changes with gold; redemption routes and physical delivery have their own conditions.
Payment channel ↗: An arrangement that lets participants update agreed payment balances outside the base chain while retaining an onchain enforcement path. Opening, closing and resolving disputes depend on the channel design; offchain updates do not erase those responsibilities.
Peer-to-peer ↗: A network arrangement in which computers exchange information with other computers directly. In blockchains, peers relay transactions and blocks. This describes communication; it does not prove that all operators are independent or that every participant has equal influence.
Peg ↗: A target exchange relationship, such as one token aiming to equal one US dollar. It identifies the intended reference, while actual market prices and the conditions for exchanging through an issuer can differ.
Peg stability module ↗: A contract route for exchanging a protocol’s stablecoin with supported assets under configured rules. Sky’s LitePSM links DAI or USDS with other stablecoins; this can support price alignment while adding dependence on the assets accepted.
PENGU ↗: PENGU is the ranked Pudgy Penguins community token, available on Abstract and Solana. It is not Abstract’s native gas asset. Abstract’s network currency is ETH, regardless of which application token a transaction transfers.
Performance fee ↗: A charge for managing a strategy, commonly based on assets managed or a defined measure of gains. The fee’s calculation and timing affect net returns; different products can apply different definitions and deductions.
Permissioned ↗: Requiring approval to perform a specified role, such as validating blocks or accessing a service. Restrictions can apply to one part of a system while other parts remain open. Permissioned participation makes the approving authority a relevant dependency.
Permissionless ↗: Open to participation in a specified function without individual approval. A network can be permissionless for sending transactions while restricting validator membership or contract deployment. The relevant function must be identified before drawing conclusions about access.
Permit deadline ↗: The latest time an ERC-2612 permit can be submitted successfully under its rules. Once submission sets an allowance, reaching this deadline does not erase that allowance; other permission standards may define expiry differently.
Perpetual future ↗: A margined price-exposure contract without a routine expiry date. Many designs use recurring funding payments to encourage its price toward a reference; the position can still incur losses, charges or liquidation.
Pessimistic proof ↗: In AggLayer’s design, a proof constraining cross-chain accounting so a chain cannot withdraw more than its accounted entitlement. This protects a particular bridge relationship; it is not automatically a proof that every application transaction executed correctly.
PI ↗: PI is the native transfer and transaction-fee asset. The project also uses PI-denominated rewards for eligible contributions and lockup incentives. Those distribution rules should not be confused with proof-of-stake consensus or an issuer’s promise to redeem PI for money.
Pi Network ↗: A payment-oriented ledger with a mobile participation and token-distribution system; phone check-ins are distinct from the nodes that run consensus.
POL ↗: POL is the gas and staking token for Polygon PoS, replacing MATIC in those roles. A token’s branding or migration history does not establish which network a wallet balance occupies or whether a separate Polygon project uses the same security model.
Polkadot ↗: Polkadot connects specialized chains through a shared security system. A parachain can define its own application rules while obtaining validation resources from Polkadot rather than establishing an entirely independent security budget.
Polygon PoS ↗: Polygon PoS is an Ethereum-connected smart-contract chain with its own validator consensus, distinct from Polygon-branded zero-knowledge rollups.
Pool reserves ↗: The quantities of assets held by a trading pool. In a simple two-asset AMM, a swap adds one asset and removes another; these reserves are trading inventory, not a stablecoin issuer’s bank reserves.
Post-condition ↗: An explicit requirement attached to a transaction about its permitted asset effects. Stacks can reject execution when the specified conditions are not satisfied. Protection depends on choosing conditions that actually capture what the sender intends.
Precompile ↗: A function exposed through a special execution interface while its work is implemented directly by the network software. Precompiles can make selected operations efficient or connect contracts to built-in services. Available functions depend on the chain and version.
Preconfirmation ↗: An early indication or commitment that a transaction will be included or ordered in a particular way. Its strength depends on who issues it and what enforces it. It is a different milestone from finalized settlement on the underlying chain.
Price feed ↗: A stream or interface publishing price observations for applications. Its asset, currency, update timing and calculation method matter: a market price, redemption rate and reserve measurement answer different questions.
Price floor ↗: A lower price boundary used in a stated context. In the sale lab it rejects bids below the limit but still permits a partial fill; it does not guarantee buyers for the full quantity.
Price impact ↗: The price change caused by an order consuming finite trading liquidity. A large sale can move through lower bids or change a pool’s reserves, so its average price can be worse than the initial small-trade quote.
Price-time priority ↗: A matching rule that gives better-priced orders priority and, at the same price, usually fills earlier orders first. It is one venue design, not a universal rule for every exchange or blockchain market.
Principal ↗: The starting or outstanding amount committed or borrowed, before separately measured earnings. A receipt can record principal even when withdrawal is delayed; whether that principal is recoverable depends on the assets and obligations behind it.
Priority fee ↗: An additional transaction fee used to influence processing priority under a network’s rules. On Ethereum it can compensate the block proposer. Offering a higher tip does not bypass validity checks or guarantee an application’s desired outcome.
Private key ↗: Secret cryptographic material used to create authorization signatures. Someone who can use the key may be able to spend assets controlled by it. The key does not contain the assets; it supplies authority over their recorded ownership.
Profit and loss ↗: The gain or loss calculated for a position over a stated interval and in a chosen unit. Price changes are only one component; funding, trading costs and other charges can change the net result.
Proof circuit ↗: A precisely specified set of computational checks that a proof system establishes were satisfied. The checks might cover authorized transfers or balance calculations. A proof can be mathematically valid while a mistake in those checks proves the wrong requirement.
Proof of authority ↗: An agreement arrangement in which approved authorities produce or validate blocks. Participation depends on admission and governance rules. It can use sophisticated consensus software, but its trust model differs from unrestricted competition through mining or stake.
Proof of History ↗: Solana’s method of building a verifiable sequence of hashes that helps establish the order of events and the passage of computational time. It supplies ordering information; validators and stake-based consensus still determine accepted history.
Proof of reserves ↗: Evidence about assets held at a particular time, sometimes using addresses and cryptographic records. Its scope may omit liabilities, borrowed assets or restrictions on use, so showing reserves alone does not establish complete financial health.
Proof of stake ↗: A family of mechanisms in which committed assets help determine participation or voting influence in blockchain agreement. Validators carry out defined duties and may face penalties. Holding a coin or joining a yield product alone is not necessarily consensus participation.
Proof of Staked Authority ↗: A network-specific model combining stake or delegated voting with an authorized or selected block-producing set. The exact selection and penalty rules vary. Staking availability does not necessarily mean anyone can immediately operate an active validator.
Proof of Stakeholder ↗: Canton’s model in which parties affected by a contract validate their entitled transaction views against its authorization rules. “Stakeholder” refers to a role or interest in that contract, rather than simply the amount of network token held.
Proof of Transfer ↗: Stacks’ mechanism in which miners commit bitcoin to compete for block-production opportunities. Other Stacks participants validate proposed blocks under its rules. The connection to Bitcoin works alongside these additional participants rather than replacing them.
Proof of work ↗: A mechanism in which block producers demonstrate computational work by finding a result that satisfies a difficulty target. Others can verify it cheaply. Work helps choose among valid histories; it does not make invalid transactions valid.
Protocol ↗: The rules computers and participants follow to communicate, authorize actions and accept updates. In crypto, the word can mean a blockchain’s rules or an application’s contract system; each has its own assumptions and people able to change it.
Protocol fee ↗: A portion of activity charges directed to a protocol’s designated recipient under its rules. It differs from fees paid to liquidity providers or validators, and it does not automatically become income for every token holder.
Prover ↗: The participant or software that produces a cryptographic proof for a specified claim. For example, it can prove that a batch of transactions followed defined rules. Producing a proof does not make the underlying rules or outside inputs correct.
Pseudonymous ↗: Using identifiers such as addresses instead of real names. Activity may still be linked to a person through exchanges, repeated patterns or other records. Pseudonymity therefore does not mean that transactions are anonymous or untraceable.
Public key ↗: Cryptographic information used to check signatures made by the corresponding private key. It can be shared without granting the same signing ability. An account address may be derived from a public key, but the two are not always identical.
Pure Proof of Stake ↗: Algorand’s stake-based consensus design using cryptographically selected participants to propose and certify blocks. Selection changes through verifiable lotteries. Its guarantees still depend on honest participating stake and the protocol’s communication assumptions.

Q

QNT ↗: QNT is the associated Quant utility token. Flow Apps can charge QNT or other supported tokens for services. Such service payments are distinct from the execution fees of connected networks; the profile does not infer one universal gas asset from the QNT listing.
Quant Fusion Rollup ↗: Quant’s institutional execution environment connects several ledgers through an OP Stack-derived rollup with permissioned data availability and access controls.
Quorum ↗: A group large enough, under a protocol’s rules, to authorize a decision. Some networks measure stake weight; federated systems use participants’ chosen trust relationships. The composition and overlap of approving groups matter, not just their headcount.

R

RandomX ↗: Monero’s proof-of-work algorithm, designed around general-purpose processor execution and memory-intensive work. Its goal is to reduce specialized mining-hardware advantages. That design goal does not prove that mining power is evenly distributed.
Real-world asset ↗: An asset or claim linked to something outside a blockchain, such as a bond, bank deposit or property interest. Its token representation still depends on custody, records, enforceable rights and any conditions on transfer or redemption.
Rebasing token ↗: A token whose recorded holder balances can adjust under its accounting rules without ordinary transfers. Some staking receipts use this to reflect rewards or losses; more units do not necessarily mean a higher value in dollars.
Receipt token ↗: A token recording an interest in assets or a position held through another mechanism. Transferring the receipt transfers that interest under its rules; it does not create a second independent copy of the underlying capital.
Recursive borrowing ↗: Repeatedly supplying collateral, borrowing against it and using the borrowed assets to add more collateral. The larger deposits rest partly on debt; each loop can add costs and exposure to liquidation rather than independent new capital.
Redemption ↗: Returning a token or claim through its supporting arrangement in exchange for specified assets. It differs from selling to another trader, and may require eligibility, fees or waiting; the payout is not always cash.
Redemption exchange rate ↗: The amount of underlying assets represented by each receipt under an arrangement’s accounting rules. It can differ from the price another trader offers for the receipt, especially when access, timing or confidence changes.
Redemption risk ↗: The possibility that an expected asset delivery or payout is delayed, restricted or fails. A recorded claim or completed token transfer does not by itself ensure that a separate issuer, bank or counterparty completes its obligation.
Reference price ↗: A chosen price used to display or calculate value, rather than a promise to buy the entire position. Multiplying holdings by this price gives a valuation; actual sale proceeds depend on executable liquidity and costs.
Reflexive backing ↗: Support whose value depends strongly on confidence in the same system it is meant to stabilize. If exits issue more of a falling balancing token, increased supply and weaker demand can reinforce each other.
Rehypothecation ↗: Reusing assets received as collateral to support another transaction or obligation under the applicable arrangement. This can link several claims to the same resources, so control, permissions and recovery priorities matter when stress reaches the chain of obligations.
Relay chain ↗: Polkadot’s coordinating chain for shared validation and consensus. It supports the checking of application-chain blocks rather than being the location where every application directly executes. The individual application chains maintain their own state and rules.
Relayer ↗: A participant that carries messages or supporting evidence between systems. Depending on the protocol, the receiver can verify the evidence without trusting the relayer for correctness. Availability, delivery timing and verification rules remain separate concerns.
Reorganization ↗: A switch to a different accepted branch that replaces previously accepted blocks. Affected transactions may return to pending or disappear from accepted history. Reorganizations can happen under existing rules and do not necessarily indicate a software upgrade.
Repayment ↗: Returning assets to reduce a debt, including interest or charges required by the arrangement. Full repayment can release collateral when the other rules permit; repaying one layer of a strategy does not automatically close every other obligation.
Replay protection ↗: Rules that prevent a previously signed instruction from being reused where it was not intended. Transaction counters and network identifiers can help, but protection depends on exactly what the signature covers and which rules the receiving system enforces.
Reserve attestation ↗: A report assessing specified reserve information against stated criteria for a defined date or period. Its scope and methods matter; it is not a continuous guarantee of asset access, full solvency or every aspect of the issuer’s business.
Reserve factor ↗: The portion of borrowing interest that a lending protocol allocates to its designated reserves or treasury rather than suppliers. Its value affects supplier earnings, but it is not a promise that reserves will cover every possible loss.
Reserves ↗: Assets held by a system for a particular purpose. Stablecoin reserves support obligations to token holders; liquidity-pool reserves are the tokens available for swaps. Their value and accessibility matter, and neither a reported reserve amount nor a pool balance guarantees an exit at a particular price.
Responsive validity proof ↗: A design in which a challenged state claim must be defended with an acceptable validity proof within a required period. Morph uses this approach. It differs from requiring a proof for every batch before that batch can be accepted.
Restaking ↗: Committing assets already associated with one staking arrangement to support additional services or obligations. The capital is reused rather than multiplied, and added rewards can come with extra operator, contract and penalty conditions.
Ring signature ↗: A signature technique showing that one member of a group authorized a message without revealing which member. In payment privacy systems, it helps obscure the spending source while additional mechanisms prevent double spending and protect other details.
Rollup ↗: A scaling system that processes transactions separately and submits grouped information to a base chain for verification and settlement. Its security depends on the proof or dispute mechanism, data availability and deployed controls, not merely the rollup label.
RPC ↗: Remote procedure call: a way for an app or wallet to ask a node for information or submit an instruction. An RPC provider operates that connection, so its availability and responses affect what the interface can show.

S

Sale proceeds ↗: The assets received from selling a position. Gross proceeds are before the stated deductions, while net proceeds subtract them; tokens left unsold are not proceeds, even if the interface still assigns them a value.
Scrypt ↗: A computation used in the proof-of-work designs of networks such as Litecoin and Dogecoin. It differs from Bitcoin’s SHA-256 mining algorithm. Using the same mining algorithm does not make two chains share one ledger or identical security.
Secondary market ↗: A market where existing holders trade assets with one another. A stablecoin sale normally transfers ownership rather than withdrawing the issuer’s reserves or reducing outstanding tokens; its price depends on available trading conditions.
Seed ↗: Secret starting material from which a wallet can derive a family of keys. A recovery phrase often helps recreate this seed. The same seed and derivation rules recreate the same keys; they do not create another independent balance.
Seed phrase ↗: A sequence of words that encodes recovery material used by many wallets to recreate keys. Anyone with the necessary words and any required passphrase may obtain the same control. Recovery also depends on using the correct wallet scheme and settings.
Sei ↗: An EVM-compatible smart-contract network that combines optimized validator agreement with parallel execution and state-storage changes intended to reduce transaction-processing delays. SEI pays network gas and participates in staking and governance. A token traded by an application is distinct from SEI, even though the application uses the network’s execution and consensus.
Self-custody ↗: Holding the means to authorize your own asset transfers rather than relying on a custodian’s account ledger. It brings responsibility for keys and permissions; token issuer controls and smart-contract rules can still restrict what the assets do.
Sequencer ↗: A component that orders transactions for a system such as a rollup. Its quick acknowledgment tells users about local ordering, which can precede proof verification, challenge completion and base-chain settlement. Its availability and powers depend on the design.
Settlement ↗: The process by which a system accepts the outcome of an obligation or transaction under its rules. In layered blockchains, local execution can precede base-chain settlement. What remains reversible or withdrawable depends on the relevant mechanism.
SHA-256 ↗: A cryptographic hash algorithm that produces a 256-bit fingerprint. Bitcoin uses it in several parts of its design, including proof of work. It fingerprints data; it is not encryption that can be reversed with a password.
Sharding ↗: Dividing a network’s state or processing work into coordinated parts. This can reduce the work each participant handles, but cross-part operations and security still need protocol rules. A shard is not automatically an independent blockchain with unrelated security.
Shared dependency ↗: A component that several positions rely on, such as the same issuer, bank, bridge or price feed. Failure can affect them together, but the exact consequence may be delayed access, price exposure or lost backing rather than identical losses.
SHIB ↗: BONE pays Shibarium transaction fees and supports validator staking. SHIB is an associated ecosystem token, not the chain’s native gas asset. Owning SHIB alone is not participation in BONE-based validator consensus.
Shibarium ↗: The Shiba Inu ecosystem’s EVM network uses its own proof-of-stake validators, with BONE rather than SHIB as its gas and staking asset.
Shielded transaction ↗: A transaction form designed to conceal selected details, such as participants or amounts, while still proving required rules. What remains visible depends on the system and transaction path; moving between public and shielded forms can reveal additional relationships.
Short position ↗: A position that generally gains when its referenced asset price falls and loses when it rises. It can be created through borrowing or a derivative; required collateral, payments and possible losses depend on the arrangement.
Sidechain ↗: A separate blockchain connected to another through a bridge or related mechanism. It generally relies on its own consensus participants. Connection or checkpointing does not by itself make the other chain verify every sidechain transaction.
Signer ↗: A person, device or program able to provide an authorization signature. An account may require one signer or several. What the signature permits depends on the signed message and the account’s rules.
Simple interest ↗: Interest calculated on the original principal without adding previous interest to the earning base. At an unchanged annual rate, period interest equals principal multiplied by that rate and the fraction of a year.
Slashing ↗: A protocol-defined penalty that removes some committed stake for specified misconduct, such as contradictory votes. It is distinct from ordinary missed-duty penalties or a falling token price. The exact offenses and amounts are network-specific.
Slippage ↗: The difference between the execution expected when an order was quoted and its actual result. Changing prices, reserves or opposing orders can cause it; slippage can improve or worsen the outcome.
Slippage tolerance ↗: A user-selected boundary on acceptable execution relative to a quote. It can be translated into a minimum output or maximum input; it does not remove existing price impact or predict the amount prices will move.
Slot ↗: A scheduled opportunity for a selected participant to produce a block. A slot can be missed, so counting slots is not always the same as counting produced blocks. Timing and selection rules differ across networks.
Smart account ↗: An account whose authorization or behavior is governed by program rules. It can support features such as several signers, spending limits or recovery. Those features depend on the actual code and any permissions to change it.
Smart contract ↗: A program whose execution and recorded effects follow a blockchain’s rules. It can hold assets and enforce conditions, but “smart” does not mean safe or legally complete. Bugs, outside data and administrative permissions can still affect outcomes.
Snowman consensus ↗: Avalanche’s agreement mechanism that repeatedly samples validator preferences to converge on an accepted block history. The sampling rules and validator assumptions are essential to its guarantees; it does not require every decision to collect an ordinary vote from every node.
Soft fork ↗: A rule change that tightens validity conditions, so blocks satisfying the new rules also satisfy the older broader rules. This describes compatibility between rule sets, not whether the upgrade is desirable or universally adopted.
SOL ↗: SOL pays transaction fees, funds account balances required for storage, and can be delegated for consensus staking. Application tokens are separate assets.
Solana ↗: A smart-contract chain designed to execute many independent account updates in parallel.
Solidity ↗: A programming language commonly used to write Ethereum-style smart contracts. The source is compiled into instructions for an execution environment. Using the language or familiar tools does not establish that the resulting contract is secure.
Solvency ↗: Having enough recoverable assets to meet obligations under the accounting assumptions used. This differs from immediate access to cash: an arrangement can have adequate assets overall but still be unable to pay every withdrawal at once.
Soroban ↗: Stellar’s smart-contract environment, adding programmable applications alongside its built-in payment and asset operations. Contracts consume resources under their own execution rules; they do not turn Stellar’s consensus into token-weighted staking or mining.
SP1 ↗: A proof-generation system used to demonstrate that specified computation was performed correctly. Mantle describes it within its validity-proof architecture. Proof verification is one component of settlement, alongside data publication, contract rules and Ethereum’s own finality.
Spender ↗: The address authorized to use a token allowance. It may belong to a person or a contract; the application’s friendly name is not a substitute for identifying the address actually receiving this authority.
Spot price ↗: A price for an immediate or very small trade at the current market state. In a curved pool, it differs from the average price for a large trade because the trade itself changes the reserves.
Stable ↗: A live EVM-compatible network built around stablecoin payments, with USDT0 used for both transfers and gas while STABLE serves a separate staking and governance role. USDT0 pays gas. STABLE supports validator delegation and governance, with validator-distributed gas revenue described in the token model. Despite its name, STABLE itself is not the dollar-pegged payment asset.
StableBFT ↗: Stable’s consensus design built on CometBFT for agreement among its delegated proof-of-stake validators. Its finality claims depend on the validator and fault assumptions. Using a stablecoin for transaction fees is a separate feature of the network.
Stablecoin ↗: A token designed to track a reference value, commonly one dollar or euro. Its stability depends on reserves, collateral, incentives or other arrangements; the target is not a guarantee of its trading price or of instant redemption.
Stacks ↗: A Bitcoin-connected smart-contract network that uses Proof of Transfer, its own block signers, and Clarity contracts to extend what applications can do around Bitcoin.
Stake ↗: Assets committed under a network’s rules to support validator participation or voting influence. Commitment can impose restrictions and penalties. The rights, exit process and possible losses depend on the network rather than on the word “stake” alone.
Stake-weighted ↗: Influence allocated according to the amount of qualifying stake, rather than one vote per person or computer. The network defines which assets count and how weight is measured. Large holdings or delegated balances can therefore affect decision-making power.
Staking ↗: Committing assets under a proof-of-stake network’s rules to support validator duties or voting influence. Rewards, restrictions and penalties depend on the network and any intermediary used. A product advertising a yield is not necessarily participating in consensus.
Staking pool ↗: An arrangement that combines participants’ stake or delegated influence to support validator operations and distribute rewards. Users depend on the pool’s operators or rules for relevant duties. Fees, custody, penalties and withdrawal arrangements vary between pools and networks.
Staking rewards ↗: Payments for participating in a proof-of-stake network’s duties under its rules, often funded by issuance or transaction fees. Operator charges and penalties affect the holder’s result; these payments are different from interest paid by borrowers.
Stale price ↗: A measurement that has not updated recently enough for its intended use. It may have been correct when published but can misstate present conditions, affecting borrowing, collateral valuation or liquidation decisions.
State ↗: The information a system currently records, such as balances, ownership and contract settings. Processing a transaction can change that state. A state record describes the accepted result at a particular point, rather than the full sequence of earlier events.
State root ↗: A compact cryptographic summary of a particular recorded state. Other systems can use it as a reference when checking evidence. The summary does not itself reveal all the balances or prove that the steps producing them were valid.
State transition ↗: An update from one recorded system condition to another, following specified rules. For example, a transfer reduces one balance and increases another. Validators or proofs check whether the proposed change follows the applicable rules.
Stealth address ↗: A technique that creates a separate destination for a payment so an observer cannot simply link it to the recipient’s published address. It protects one relationship; other transaction details and outside information can still affect privacy.
Stellar ↗: A payments and asset-issuance network with trust-based consensus and smart-contract support.
stETH ↗: Lido’s staking receipt for ether, with balances that adjust as its accounting recognizes rewards and penalties. A holder’s exit depends on Lido’s withdrawal process or market liquidity; the receipt is distinct from ether held directly.
Storage proof ↗: Cryptographic evidence about a provider’s storage commitment, such as creating a specified replica or continuing to hold data over time. Storage proof acceptance is distinct from successfully retrieving a file when a particular user requests it.
STX ↗: STX pays execution fees and rewards miners. Locking STX supports the signer system and can earn BTC transferred by miners, subject to the stacking mechanism’s participation rules.
Subnet ↗: A network-specific subgroup of nodes or services with an assigned role. In Internet Computer, a subnet replicates application execution; other ecosystems use the word differently. The label alone does not establish how participants are admitted or what they verify.
Substrate ↗: A framework and associated software components for building blockchains. Developers can choose application rules and consensus arrangements around them. Sharing this software does not make every resulting chain part of Polkadot’s shared validation system.
Sui ↗: A Move-based application chain where owned and shared objects organize assets and execution. SUI pays computation and storage fees and can be delegated for staking. A storage fund helps compensate future validators for data that earlier users created.
Super Representative ↗: An elected block-producing representative in TRON’s delegated proof-of-stake arrangement. Token holders use network voting rules to influence selection. Voting for a representative differs from running its infrastructure or directly validating every block.
Supermajority ↗: A voting threshold greater than a simple half, often measured by stake rather than people. The required threshold depends on the protocol. Reaching it provides only the guarantees supported by that protocol’s assumptions about honest participants.
Supply rate ↗: The rate attributed to assets supplied to a lending market. It usually differs from the borrower rate because only some funds are borrowed and fees or reserves may be retained; incentive payouts can be an additional component.
sUSDe ↗: A separate receipt received for placing USDe in Ethena’s rewards vault. Discretionary distributions can increase the USDe represented by each receipt; this use of staking does not mean validating a proof-of-stake blockchain or receiving a fixed yield.
Swap ↗: An exchange of one asset for another. A blockchain swap applies the contract’s pricing, fees and execution conditions; authorizing input tokens is separate from successfully completing the exchange itself.
Synchronizer ↗: In Canton, infrastructure coordinating ordered message delivery and transaction processing among participants. It can work with encrypted messages while participants validate their relevant contract data. Its ordering role is different from knowing and approving every private business record.
Synthetic dollar ↗: A dollar-targeting instrument built from financial positions rather than simply a dollar bank balance. Assets and offsetting derivatives can reduce price exposure, but funding, custody, price mismatches and settlement remain part of the arrangement.

T

Taker ↗: A participant whose order trades against liquidity already offered by someone else. Venues may charge takers differently from makers; being a taker describes the execution role rather than whether a trade is profitable.
TAO ↗: TAO is the native asset. Subnets also have distinct alpha tokens paired with TAO in liquidity pools. Staking into a subnet exchanges TAO for its alpha; withdrawing reverses that exchange at the available pool price.
Tendermint ↗: A family of blockchain consensus software and designs in which a validator set exchanges proposals and votes to agree on blocks. Guarantees depend on sufficient honest voting power and network assumptions. Different chains using it retain separate validator arrangements.
Testnet ↗: A network used to develop or test software and procedures. Its assets, rules and operator arrangements may differ from production. A successful demonstration there does not establish that the same feature is deployed or secure on mainnet.
The Open Network (TON) ↗: A sharded, message-based smart-contract network; its native token is now named Gram, formerly Toncoin.
TIA ↗: TIA pays for publishing blobs and other network transactions. It also supports staking, delegation, and governance; an application using Celestia may choose its own separate user-facing fee asset.
Time-weighted average price ↗: A price average calculated over a stated time window. It can reduce sensitivity to a brief price move, but also responds more slowly; its usefulness depends on the underlying data, window and market liquidity.
Timelock ↗: A rule that delays an action until a specified time or block condition. Governance timelocks can give users time to inspect scheduled changes. Their protection depends on which actions are covered and whether another authority can bypass the delay.
Token ↗: A unit of ownership or value recorded under a blockchain or application’s rules. Tokens can represent interchangeable balances, unique items or outside claims. The rules and issuer determine what control or rights a particular token actually provides.
Token approval ↗: An authorization letting a specified address spend tokens from an owner’s balance under the token contract’s rules. Setting an approval does not itself transfer those tokens; it can enable a separate transfer later.
Token emissions ↗: Token distributions scheduled by a protocol, often used for rewards or incentives. They may increase circulating supply or create new units; the schedule describes units distributed, not the market value recipients will obtain.
Token inflation ↗: An increase in the number of token units. If your balance does not grow at the same pace, your share of the supply falls; token supply inflation is separate from a change in the token’s market price.
Token metadata ↗: Descriptive information such as a token’s name, symbol, decimal display setting or linked media. Metadata helps interfaces present an asset but is not proof of authenticity, backing or legal rights; different contracts can use identical descriptions.
Token standard ↗: A shared set of interfaces and behavior that wallets and applications can recognize. A standard improves compatibility, but it does not certify security, backing, legal rights or the absence of extra administrative controls.
Token unlock ↗: The point when a restriction on using or transferring a token allocation ends. An unlock changes access to the units; it does not necessarily mint new units or imply that every recipient immediately sells.
Tokenization ↗: Representing an asset or right with tokens recorded on a digital ledger. The underlying asset may remain elsewhere, so token transfers alone do not prove that a custodian holds it or that every holder can redeem it.
Tokenomics ↗: The supply rules, allocations, incentives and financial rights associated with a token. It asks who receives units, what holders can do, what funds rewards and who can change those rules; it does not establish a future market price.
TON Virtual Machine ↗: TON’s smart-contract execution environment. Contracts process messages, and work involving several contracts may unfold across multiple linked transactions. Its name refers to the execution engine, while validators and consensus determine the accepted network history.
Total supply ↗: The number of token units currently existing under a stated counting method, usually including units that are locked or held in a treasury. It differs from circulating supply and from any maximum allowed in the future.
Total value locked ↗: The reported value of assets deposited in a defined set of contracts. The figure depends on prices and counting rules; nested receipts can lead to double counting, and TVL does not measure profit, available cash or solvency.
Trading fee ↗: A charge for executing an exchange. Depending on the venue, it can go to liquidity providers, an operator or a protocol; it is separate from any network fee paid to process the transaction.
Trading volume ↗: The amount of an asset traded over a stated period under a venue’s counting method. It measures completed activity, whereas order-book depth measures currently offered quantities; high past volume does not guarantee an easy exit now.
Transaction ↗: An instruction submitted to a network to change its recorded state, such as transferring value or calling a contract. Authorization, validity, inclusion and final settlement are separate steps; signing or broadcasting an instruction does not guarantee completion.
Transaction fee ↗: The charge for submitting or executing an operation under network rules. It can compensate operators, be destroyed or follow another allocation. Fees are distinct from the amount transferred and may still apply when an included transaction fails.
Treasury ↗: Assets held to fund a project or protocol’s operations and programs. Rewards paid from a treasury consume an existing resource; they are different from recurring income generated by borrowers or customers.
TRON ↗: A smart-contract and payment chain with elected block producers and separate bandwidth and computation resources.
TRON bandwidth ↗: A TRON resource used for transaction data. It differs from Energy, which measures contract-execution work. Available resources and the network’s payment rules determine the TRX cost, so a familiar transfer amount alone does not establish the total fee.
TRON Energy ↗: A TRON resource consumed by smart-contract execution. Accounts can obtain resources through the network’s staking and delegation arrangements or pay applicable costs in TRX. Energy is separate from the bandwidth resource used to submit transaction data.
TRON Virtual Machine ↗: TRON’s environment for executing smart contracts written with Ethereum-style tools. Its network resource rules distinguish transaction bandwidth from contract-execution Energy. Familiar programming interfaces do not mean that Ethereum validators check or settle TRON transactions.
TRX ↗: TRX is the native asset for staking, governance and resource-related fees. Holding USDT on TRON does not by itself provide TRX or enough Energy for every transfer.

U

Unbonding ↗: The process or waiting interval for releasing assets committed to staking or a related service. Timing and continuing penalty exposure depend on the protocol; requesting an exit does not necessarily make the assets immediately transferable.
Underlying asset ↗: The asset that a token, receipt or financial contract represents or refers to. Owning a claim linked to an underlying asset is different from holding that asset directly, because additional contracts and exit conditions can intervene.
UNI ↗: UNI is the ranked Uniswap ecosystem token associated with this profile. The network’s native currency and gas asset is ETH. Holding UNI and paying an execution fee on Unichain are different activities.
Unichain ↗: An Ethereum rollup associated with the Uniswap ecosystem, designed around onchain trading and liquidity; ETH pays its network fees.
Unique Node List ↗: An XRP Ledger server’s selected list of validators whose statements it considers when deciding agreement. Reliable operation depends on compatible trust choices and sufficient honest overlap. The list is not simply a ranking of nodes by token holdings.
Unit of account ↗: The unit used to state prices, debts and values, such as dollars, euros or a token. A position can gain in token units while losing in dollars, so a return or debt figure needs its unit specified.
Unlimited approval ↗: An approval using a very large spending limit rather than the amount needed for one action. It may remain usable for later balances under the token’s rules until changed; it does not create tokens or override the owner’s available balance.
Unrealized gain ↗: A change in a still-open position’s assessed value. It can affect account equity and liquidation under venue rules, but it is different from proceeds actually received by closing the position at executable prices.
Upgradeability ↗: The ability to change a deployed application’s code or behavior through an authorized mechanism. It can fix problems or introduce new ones. Users need to know who can approve changes, any delay and whether their assets remain affected.
USDC ↗: Circle’s dollar-targeting stablecoin, issued on supported blockchains under its reserve and redemption arrangements. It is a token rather than a blockchain, and ordinary ownership does not necessarily provide the same direct services as an eligible Circle Mint account.
USDe ↗: Ethena’s synthetic dollar token, supported by a managed portfolio that can include assets and hedging positions. It targets a dollar but is not a bank deposit; direct minting and redemption depend on the arrangement’s access rules.
USDS ↗: A dollar-targeting token in the Sky ecosystem with a documented conversion route to and from DAI. Its backing and liquidity arrangements can include other stablecoins, so token conversion does not remove dependencies on those assets’ issuers.
USDT ↗: Tether’s dollar-targeting token, supported by its stated reserve arrangement. Direct issuance and redemption follow its eligibility and service terms; the reserve description does not mean every reserve asset is physical cash or immediately available.
Utilization ↗: The fraction of a lending pool’s supplied assets currently borrowed under its accounting definition. Higher utilization generally means less cash remains available to withdraw and can cause the protocol’s borrowing rate to rise.
UTXO ↗: An unspent transaction output: a discrete piece of recorded value with conditions for spending it. A transaction consumes whole existing outputs and creates new outputs, often including change. A wallet’s balance can consist of many separate outputs.

V

Validator ↗: A participant responsible for duties such as checking proposed updates, producing blocks or voting on history. The exact role differs across networks. Consensus validators should be distinguished from unrelated services that also use the title “validator.”
Validator committee ↗: A selected group of validators assigned a particular checking or voting duty. Some protocols rotate committees using a stake-weighted lottery. Agreement depends on the selection rules, required voting threshold and assumptions about honest participation, rather than the group’s name alone.
Validator set ↗: The group currently permitted or selected to take part in a network’s block-production or consensus duties. How that group changes, who can join and how its votes are weighted are central parts of the security model.
Validity proof ↗: Cryptographic evidence that specified computation followed a defined set of rules. In a rollup it can establish valid state changes for a transaction batch. It does not prove that outside prices are accurate or that the application’s rules are desirable.
Validity rollup ↗: A rollup that submits cryptographic proofs showing that proposed state changes followed defined execution rules. The proofs can reduce verification work, but do not automatically hide transaction details or eliminate data, contract and upgrade dependencies.
Validium ↗: A system that verifies execution using validity proofs while keeping transaction data outside the base chain’s ordinary data-publication path. Correct execution proofs do not remove the separate risk that required data is withheld or unavailable.
Variable rate ↗: A borrowing or earning rate that can change as market conditions or protocol rules change. Extending today’s rate across a full year is an assumption, not a commitment that the same rate will apply throughout.
Vault ↗: A contract or managed arrangement that holds assets under defined deposit, accounting and withdrawal rules. Some vaults run strategies or distribute rewards; the word alone does not specify what the assets do or who can change the rules.
VeChainThor ↗: An enterprise-oriented smart-contract network with separate VET staking and VTHO fee tokens, transaction sponsorship, and support for bundling multiple actions.
Verifiable random function ↗: A cryptographic function that produces a random-looking output together with evidence that it was calculated correctly for a particular input and key. Networks can use it to select participants while allowing others to verify the selection.
Verifier ↗: The participant or program that checks whether a cryptographic proof satisfies its verification rules. Acceptance establishes the defined mathematical claim under the scheme’s assumptions, not every possible claim about the application or its inputs.
Vesting ↗: Rules that make an allocation available gradually or after conditions are met. A vesting release can let a recipient transfer previously restricted units without creating new tokens at the time of release.
VET ↗: VET is the principal staking asset. Active staking supports VTHO generation, and VTHO pays transaction fees. Current rules therefore differ from older descriptions in which merely holding VET generated gas tokens.
View key ↗: A capability that lets a chosen observer inspect otherwise private transaction information without necessarily granting spending authority. The exact information exposed varies by scheme. Sharing a viewing capability changes who can see records even if the public cannot.
Virtual machine ↗: A defined software environment that interprets and runs programs. Blockchain virtual machines specify how instructions affect state and consume resources, allowing different nodes to calculate matching results from the same inputs.
Virtual voting ↗: Inferring how participants would vote from the information recorded about their communication, instead of transmitting every vote separately. Hashgraph uses this approach within its agreement process. It still relies on defined rules and fault assumptions.

W

Wallet ↗: Software or a device that helps manage authorization keys, view balances and prepare transactions. The assets are recorded by the network, not stored inside the screen. Some wallets control keys locally; others depend on a service.
Wallet disconnection ↗: Ending a website’s connection to a wallet interface. This may stop routine account access through that connection, but it does not remove spending permissions already recorded in token contracts or cancel an already submitted transaction.
WebAssembly ↗: A portable instruction format that software can execute in a defined runtime. Some blockchains use it for contracts. Sharing WebAssembly does not make those chains’ account rules, supported features or consensus systems identical.
Withdrawal queue ↗: A process that orders pending requests to retrieve assets from a protocol. Completion depends on the arrangement’s liquidity and release rules; joining a queue is not the same as having the assets available to spend.
Witness ↗: The information used to demonstrate a cryptographic statement. In a zero-knowledge proof it can contain private details that are not revealed to the verifier. In Bitcoin transaction formats, the word can instead refer to data satisfying spending conditions.
WLD ↗: WLD is the associated ecosystem token, including a bridged deployment on World Chain. ETH is the native gas asset. Sponsorship or a paymaster can cover fees or accept another token from a user without making that token the network’s native currency.
Workchain ↗: In TON, workchains organize account and execution environments, and shardchains subdivide their processing. Applications communicate through messages across these structures. Splitting the work does not remove the need for agreed rules and correct validation.
World Chain ↗: An Ethereum rollup for the World ecosystem, combining EVM applications with identity-related services and gas sponsorship; ETH remains the native fee asset.
Wrapped asset ↗: A token representing another asset through a contract or custody arrangement. Wrappers can adapt an asset for another interface or chain; obtaining the underlying asset depends on that specific wrapper’s backing and release rules.
wstETH ↗: A wrapped form of stETH whose token count does not rebase. The amount of stETH represented by each wstETH changes with the underlying accounting, while its market price and eventual withdrawal proceeds remain separate questions.

X

X Layer ↗: X Layer is an Ethereum layer two associated with OKX. Current developer documentation describes an enhanced OP Stack network, so older descriptions of its initial zkEVM architecture should not be treated as the current design.
XDC ↗: XDC pays public-chain transaction fees and provides stake associated with validator participation. A financial asset issued on XDC remains a separate token with its own issuer and contractual conditions.
XDC Network ↗: An EVM-compatible network oriented toward trade finance and tokenized assets, combining a public ledger with options for separate enterprise subnets.
XDPoS ↗: XDC’s stake-based mechanism for selecting masternodes and coordinating block agreement. The validator system supports finality under its Byzantine-fault assumptions. A private subnet can use different participation rules from the public network, despite sharing related technology.
XLM ↗: XLM pays network fees and supports minimum balances and contract storage costs. Stellar validators do not receive ordinary protocol staking rewards for holding XLM.
XMR ↗: XMR is the native payment and fee asset. Mining rewards compensate block production; the asset is not a claim on a custodian or a stablecoin reserve.
XRP ↗: XRP is the native asset used for transaction costs and account reserves. Consensus does not allocate votes according to how much XRP a holder stakes.
XRP Ledger ↗: A payments and token ledger that reaches agreement through overlapping trusted-validator lists.

Y

Yield ↗: Income or rewards expressed relative to the assets committed, over a stated period and in a stated unit. It can come from interest, fees, incentives or other payments; asset-price losses and costs can outweigh it.
Yield farming ↗: Arranging assets across applications to obtain fees, interest or incentive rewards. A strategy may combine several claims and obligations; depositing tokens into a rewards contract does not necessarily mean participating in blockchain consensus.
Yuma Consensus ↗: Bittensor’s mechanism for combining participant evaluations into incentive allocations. Its use of the word consensus should not be confused with finalizing blockchain history. The chain’s block-production and finality mechanisms perform those separate ledger roles.

Z

Zcash ↗: A payment network with transparent transfers and shielded transfers that use zero-knowledge proofs.
ZEC ↗: ZEC is the native payment and fee asset. Shielding does not create a second currency or a separate promise to redeem ZEC at a fixed price.
Zero-knowledge proof ↗: A way to prove that a defined statement is true without revealing the secret information that establishes it. The verifier still learns the statement’s truth. Privacy depends on the chosen statement, public inputs and the surrounding system.
ZK Stack ↗: A software framework for building chains using the ZKsync family of execution and proof technology. It supplies components, not a guarantee that every deployment has identical behavior. Execution compatibility, data publication and administrative controls still vary by configuration.

A

B

C

D

E

F

G

H

I

K

L

M

N

O

P

Q

R

S

T

U

V

W

X

Y

Z

No matching terms.