Less jargon.
More understanding.

An address is a shareable identifier that tells wallet software where to direct a cryptocurrency payment. In Bitcoin, it usually encodes information used to construct the spending conditions for a transaction output, rather than identifying an account maintained by a central operator. Different address formats support different output types, including legacy, SegWit, and Taproot. An address is not the same as a private key: sharing an address allows someone to send funds or inspect associated public activity, but does not normally give them spending authority. One wallet can generate many addresses, and using a fresh receiving address can reduce straightforward links between payments. Before sending, the sender must check the intended network and the complete destination. A valid checksum can detect certain typing errors, but it cannot prove that the address belongs to the intended recipient or protect against malicious address substitution.

Sources: developer.bitcoin.org · github.com

An airdrop is a distribution of cryptocurrency tokens to selected addresses, often intended to introduce a project, reward earlier participation, or distribute governance rights. Eligibility may depend on a recorded snapshot of balances, past application activity, or a claim process defined by the distributor. Some airdrops arrive automatically; others require the recipient to submit a transaction and pay network fees. Receiving tokens does not establish their usefulness, market value, or legitimacy. Anyone may create assets with misleading names, and unsolicited tokens can advertise malicious claim websites. A genuine distribution does not require disclosure of a wallet's private keys or recovery phrase. Claim transactions and token approvals also deserve scrutiny because they may grant spending permissions. When evaluating an airdrop, separate the mechanics of distribution from the project's economic design, transfer restrictions, vesting schedule, and the security of the contract handling the claim.

Sources: ethereum.org · blog.uniswap.org

Altcoin is an informal name for a cryptocurrency other than Bitcoin. The category can include coins native to independent blockchains as well as tokens issued through applications on existing networks, depending on the speaker's usage. It is not a technical standard, a quality rating, or a guarantee that different assets share the same characteristics. An altcoin may use proof of work, proof of stake, or another consensus design, while a token may inherit transaction processing from its host chain. Projects can also differ in issuance limits, governance, administrator powers, privacy features, and available software. A low price per unit does not necessarily make an altcoin inexpensive relative to its supply or economic activity. Useful comparisons therefore examine what the asset does, who can change its rules, how transfers are validated, and whether its claimed functionality exists independently of promotional material.

Sources: ethereum.org · namecoin.org

An application-specific integrated circuit, or ASIC, is a chip designed to perform a narrowly defined task efficiently. In Bitcoin mining, ASIC hardware repeatedly calculates the hashes used in the network's proof-of-work process. Specialization allows this equipment to perform far more relevant hashing work per unit of energy than general-purpose computers used for the same task. However, an ASIC designed for one mining algorithm cannot simply be reconfigured to mine every cryptocurrency. Its usefulness depends on algorithm compatibility, electricity requirements, cooling, reliability, and the competitiveness of other miners. Hash rate describes its calculation speed, while energy efficiency describes the power needed for that output; neither alone determines profitability. An ASIC does not hold authority to change Bitcoin's rules. It produces candidate proofs of work, and independent full nodes still reject blocks that violate consensus requirements, regardless of the hardware that generated them.

Sources: developer.bitcoin.org

An atomic swap is a method for exchanging assets between parties so that the protocol aims to complete both sides of the exchange or allow refunds, rather than leave one party paid and the other unpaid. A common design uses hash time-locked contracts: one participant commits to a secret's hash, and revealing the secret to claim one asset enables the other participant to claim the corresponding asset. Different deadlines provide refund paths when the exchange does not finish. The participating networks must support compatible cryptographic and timing mechanisms. Atomic does not mean instantaneous, free, or completely riskless. Users still face transaction fees, confirmation delays, monitoring requirements, and implementation errors. Cross-chain reorganizations and poorly chosen timeouts can also matter. Unlike a custodial exchange, the arrangement seeks to avoid handing both assets to an intermediary, but careful protocol design and reliable wallet software remain essential.

Sources: github.com

An automated market maker is a trading mechanism that uses programmed rules and pooled assets to quote exchanges, rather than matching every trade against another user's standing order. A common constant-product design relates two token reserves through a mathematical invariant, so buying one asset changes the pool's balance and the price available for subsequent trades. Other designs use different curves, concentrated liquidity, or additional parameters. Liquidity providers supply the assets and may receive trading fees, but their returns depend on market movements, trading activity, costs, and the protocol's rules. Large trades relative to available liquidity can produce substantial price impact. Arbitrage trades help connect pool prices to prices elsewhere, without guaranteeing identical quotes at every moment. An AMM removes some operational roles of a traditional exchange, but it does not eliminate smart contract vulnerabilities, token-specific restrictions, manipulation risks, or losses associated with providing liquidity.

Sources: developers.uniswap.org

Bech32 and Bech32m are related encoding formats used for native Bitcoin SegWit addresses. They combine a readable network prefix, an encoded witness version and program, and an error-detecting checksum. Bitcoin mainnet addresses in these formats begin with bc1. Bech32 is used for witness version zero, while Bech32m provides the checksum used for later witness versions, including Taproot's version one. They should not be treated as interchangeable encodings for the same output type. Their design improves the handling of transcription errors compared with relying on an unchecked character string, but checksum validity does not establish the identity or honesty of a recipient. Wallets must decode the correct network, witness version, and program length before constructing a payment. A supported address can be used without disclosing a private key. Software that does not recognize the relevant address type should not be bypassed by manually altering its prefix or checksum.

Sources: github.com · github.com

Bitcoin is a peer-to-peer monetary network, and bitcoin, commonly represented by BTC, is its native digital asset. Participants can transfer value using transactions authorized by cryptographic spending conditions rather than a central account administrator. Full nodes independently verify those transactions and the blocks containing them, while miners compete through proof of work to extend the valid transaction history. Bitcoin's issuance schedule reduces the block subsidy over time and limits the possible supply to approximately 21 million coins under its established rules. Each BTC is divisible into 100 million satoshis, allowing transfers smaller than one coin. The ledger is public and pseudonymous, not automatically anonymous. BTC should also be distinguished from wrapped representations, exchange account balances, and separately issued tokens associated with the Bitcoin ecosystem. Those products can introduce additional custodians, contracts, or indexing rules that are not part of holding native BTC directly.

Sources: bitcoin.org · bitcoin.org

Bitcoin Core is an open-source software project that provides a widely used implementation of a Bitcoin full node, together with wallet and developer interfaces. A node running the software can validate blocks and transactions, maintain its view of the blockchain, and communicate with peers without accepting another company's ledger as authoritative. Its wallet capabilities can generate addresses, track funds, and help construct and sign transactions when configured for that purpose. Bitcoin Core is not the Bitcoin network itself, an exchange, or a company that can reverse payments. Publishing a software release also does not automatically force every participant to adopt new rules. Operators decide what software to run, and consensus compatibility determines whether their nodes follow the same valid history. Understanding this distinction helps explain why a development proposal, a released feature, and an activated network rule are different stages rather than interchangeable events.

Sources: bitcoincore.org · github.com

Bitcoin DeFi is a broad label for financial applications that use BTC or assets linked to Bitcoin for activities such as trading, borrowing, collateral management, or payment coordination. It does not identify a single protocol or a uniform security model. Some arrangements use Bitcoin's native transaction scripting, while others rely on sidechains, additional execution networks, bridges, custodians, or wrapped BTC tokens. These differences determine who controls funds and which software enforces the application's promises. A platform connected to Bitcoin does not automatically inherit every protection of holding native BTC in a self-controlled wallet. Questions about redemption, liquidation rules, price oracles, administrator keys, and emergency withdrawals are therefore central to understanding a particular application. Bitcoin itself uses proof of work; a product advertising BTC staking or yield should explain its separate reward mechanism rather than imply that simply holding BTC earns native consensus rewards.

Sources: ethereum.org · dev.rootstock.io

A Bitcoin Improvement Proposal is a document used to describe a proposed change, standard, or process relevant to the Bitcoin ecosystem. BIPs can cover consensus rules, wallet interoperability, address formats, application interfaces, and other technical topics. A numbered proposal provides a stable reference for discussion, but receiving a BIP number does not mean that the community endorses it or that the network has adopted it. Some proposals become widely implemented, others remain under discussion, and others are withdrawn or superseded. The document's scope and status therefore matter as much as its title. A wallet standard can be useful without changing Bitcoin consensus, whereas a consensus proposal requires compatible deployment and adoption arrangements. Reading a BIP helps distinguish what its authors actually specify from broader claims made about the technology in marketing or social media.

Sources: github.com

A block is a structured collection of transaction data that a blockchain records as one step in its history. A Bitcoin block contains a header and a list of transactions, beginning with a special coinbase transaction. The header links to a previous block and commits to the included transactions through a Merkle root. Miners search for a header hash that satisfies the proof-of-work target, but finding such a hash is only one requirement for acceptance. Full nodes also check transaction validity and other consensus limits. A block can be valid without remaining in the eventual best chain if competing branches are discovered. The term therefore describes a data structure, not an unconditional promise of final settlement. Block explorers display its hash, height, timestamp, transaction count, and other details, each of which answers a different question about the recorded history.

Sources: developer.bitcoin.org · bitcoincore.org

A block explorer is a website or application that presents blockchain records in a searchable format. It can help users look up a transaction identifier, inspect a block, examine outputs associated with an address, or estimate how many confirmations a payment has received. The displayed information is usually assembled by software that queries and indexes a node's data. An explorer is a viewing service, not the authority that makes transactions valid. Its labels, address groupings, fee estimates, and token interpretations may include assumptions beyond the underlying ledger. A missing result can reflect an indexing delay, a network mismatch, or an unconfirmed transaction the service has not seen. Looking up an address on a public service can also reveal interest in that address to the operator. For sensitive verification, distinguish raw blockchain evidence from the explorer's additional presentation and analysis.

Sources: bitcoincore.org · bitcoincore.org

A block header is the compact summary of a block that Bitcoin miners hash during proof-of-work calculations. The Bitcoin header is 80 bytes long and includes a version field, the previous block's hash, a Merkle root committing to transactions, a timestamp, an encoded difficulty target, and a nonce. These fields connect a candidate block to a particular history and set of contents. Changing the transaction list changes its commitment and therefore changes the header that miners must hash. A valid proof of work requires the resulting hash to fall at or below the applicable target. Headers make it possible to examine accumulated work without first downloading every transaction, but a header alone does not establish that all transactions obey consensus rules. Full validation requires the relevant block data and the state needed to check its spends.

Sources: bitcoincore.org · developer.bitcoin.org

Block height is a block's position within a particular blockchain history, counted from the genesis block at height zero. Its immediate successor has height one, and each later block increases the height by one along that branch. Height is useful for describing confirmation depth, scheduled events, and restrictions that depend on the number of blocks rather than clock time. It is not a globally unique block identifier: competing branches can contain different blocks at the same height. A block hash identifies the particular block more precisely. Height also should not be treated as an exact calendar. Bitcoin targets an average block interval, but individual blocks can arrive sooner or later. When a chain reorganization replaces recent blocks, the block associated with a particular height can change even though the numbering system itself stays the same.

Sources: bitcoincore.org · bitcoincore.org

The block reward is the compensation a miner may claim when producing a valid Bitcoin block. It consists of two separate components: the block subsidy, which introduces newly issued bitcoin, and the transaction fees paid by transactions included in that block. The miner claims the permitted amount through the coinbase transaction. These components should not be confused because the subsidy follows a predetermined reduction schedule, while fees depend on the transactions selected and their spending amounts. A block containing unusually high fees can therefore have a larger total reward than another block with the same subsidy. The reward is not spendable immediately; coinbase outputs must satisfy Bitcoin's maturity requirement. Mining pools may distribute proceeds according to their own accounting agreements, so an individual participant's payout is not necessarily the same thing as the network-level block reward.

Sources: bitcoincore.org · github.com

The block subsidy is the portion of a Bitcoin block's reward that creates new bitcoin according to the network's issuance rules. It began at 50 BTC per block and is reduced by half after each interval of 210,000 blocks. Because accounting uses whole satoshis, the scheduled reductions eventually bring newly permitted issuance to zero. Transaction fees are separate and may still compensate miners after that point. The subsidy is a maximum amount allowed by consensus, not a payment that a central administrator can increase at will. A miner attempting to claim more than the permitted subsidy and fees produces an invalid block. Lost private keys do not cause replacement coins to be issued, and a smaller circulating supply does not alter the schedule. This distinction separates Bitcoin's issuance policy from market supply, accessible holdings, and the total compensation earned through mining.

Sources: github.com · bitcoincore.org

Block weight is Bitcoin's accounting system for limiting block size while distinguishing transaction data from segregated witness data. Under the SegWit rules, a block can contain at most four million weight units. Data outside the witness receives four weight units per byte, while witness data receives one. The equivalent formula is three times the stripped size plus the total serialized size. Transaction virtual size, commonly expressed in virtual bytes, is its weight divided by four and rounded upward. This lets wallets compare fee rates across transactions with different structures. Weight is not simply the number of transactions or the number of coins transferred. Two transactions sending the same value may consume different space because they use different inputs, outputs, or spending conditions. Understanding weight helps explain why batching payments and selecting suitable input types can change transaction costs.

Sources: github.com · bitcoincore.org

A blockchain is an ordered history organized into blocks that cryptographically refer to earlier blocks. Those links make alterations evident because changing earlier content changes the commitments that later blocks rely on. A functioning blockchain system also needs rules for validating updates and deciding which history participants should follow. The linked structure alone does not provide decentralization, economic security, or accurate information about the outside world. Bitcoin combines it with proof of work and independent transaction validation, while other networks use different mechanisms. Recent history may be reorganized when the applicable consensus rules select another branch. Public records can be inspected, but visibility does not necessarily identify the people controlling addresses. When evaluating a blockchain, useful questions concern who can propose changes, who verifies them, how disagreements are resolved, and what assumptions protect the ledger against manipulation.

Sources: developer.bitcoin.org · ethereum.org

A BRC-20 token is a fungible token represented through an application-level convention associated with Bitcoin inscriptions. In the original BRC-20 experiment, small JSON inscriptions describe operations such as deploying a token, minting units, and preparing transfers. Indexing software interprets these records and calculates balances according to the convention's rules. Bitcoin nodes validate the underlying Bitcoin transactions, but they do not natively enforce a BRC-20 account ledger as a separate consensus asset. The name resembles Ethereum's ERC-20 standard, yet the original design does not provide the same smart contract execution model. Users must also distinguish token units from the satoshis and transaction outputs carrying associated inscriptions. Transfers can involve several steps, fees, and indexer-dependent interpretation. A token's existence on Bitcoin does not guarantee liquidity, useful rights, safe trading, or agreement among every application displaying its balance.

Sources: domo-2.gitbook.io

A bridge is a system that transfers assets, messages, or representations of value between blockchain environments. One common asset design locks coins on an origin network and creates corresponding tokens elsewhere; another destroys a representation before releasing the original asset. The precise mechanism varies, and the destination token is not automatically identical to native coins on its source chain. Bridges may rely on custodians, signer groups, smart contracts, external validators, or cryptographic verification. Each design introduces different assumptions about who can authorize transfers and what happens during failures. A secure underlying blockchain does not remove weaknesses in the bridge connecting it to another system. Relevant risks include contract errors, compromised signing keys, false messages, unavailable liquidity, and suspended redemption. Evaluating a bridged asset therefore requires understanding both chains and the mechanism responsible for maintaining and returning its backing.

Sources: ethereum.org

A change address is a wallet-controlled destination used to receive the portion of transaction inputs that is not being sent to the recipient or paid as fees. Bitcoin transactions spend complete unspent outputs rather than subtracting an amount from a conventional account balance. When selected inputs exceed the payment and fee, the wallet usually creates a separate change output. For example, spending an output containing more bitcoin than the intended payment normally returns the difference to the sender's wallet. A fresh change address can make casual address reuse less revealing, although public transaction patterns may still expose relationships. Change is not necessarily shown as an incoming payment from another person. Users reviewing a transaction should verify that both the recipient output and the change destination are correct, especially when using offline signing workflows or software they do not fully trust.

Sources: bitcoincore.org · developer.bitcoin.org

The coinbase transaction is the special first transaction in a Bitcoin block through which the miner claims the permitted block subsidy and transaction fees. Unlike an ordinary transaction, it does not spend previously created outputs through a normal input. Its distinctive input contains block-related data rather than authorization to spend another person's funds. The total value of its outputs cannot exceed the allowable reward, although a miner may claim less. Coinbase outputs must mature for 100 blocks before they can be spent, reducing problems associated with rewards from blocks that later leave the accepted chain. A mining pool can direct the reward to addresses under its control and distribute participant payouts separately. The term is part of Bitcoin's transaction design and should not be confused with the cryptocurrency exchange that uses the same word as its company name.

Sources: github.com · developer.bitcoin.org

A cold wallet is a custody arrangement in which the private keys needed to spend cryptocurrency are kept away from routinely connected computing environments. The term describes key management, not a separate location where coins physically reside: the assets remain represented on the blockchain. One workflow uses an online watching-only wallet to prepare a transaction, an offline device to sign it, and the online system to broadcast the signed result. This separation reduces exposure to some remote attacks but does not eliminate unsafe backups, compromised devices, malicious transaction requests, or physical theft. Recovery materials must also be protected because they can recreate spending authority without the original wallet. Moving funds out of cold storage does not inherently require importing its secret keys into an online application. The quality of the signing process, destination verification, and backup procedures matters more than the label alone.

Sources: electrum.readthedocs.io

A confirmation indicates that a transaction has been included in the blockchain history a node currently accepts. In Bitcoin, inclusion in a block gives the transaction its first confirmation, and each additional block built above it increases the count. More depth usually makes replacement of that history more difficult under proof of work, but confirmations are not a mathematical guarantee that a reorganization is impossible. A transaction seen in the mempool has not yet received a confirmation, even when a wallet displays it as pending. Different recipients may require different confirmation depths depending on transaction value, risk tolerance, and operational circumstances. There is no single waiting count that makes every payment equally safe. Users should also distinguish on-chain confirmations from an exchange's internal deposit processing, which may involve additional checks before the platform credits an account.

Sources: developer.bitcoin.org

Consensus rules are the requirements that a blockchain participant applies when deciding whether transactions and blocks are valid. Bitcoin's rules cover matters such as spending authorization, prevention of duplicate spends, allowable issuance, proof of work, and block weight. A full node checks these requirements for itself rather than accepting a block merely because many peers announce it. Consensus is distinct from transaction relay policy: a node may decline to forward a transaction that could still be valid if a miner includes it in a block. It is also distinct from a poll of users or a vote by software developers. Participants need compatible validation rules to maintain a shared history. When discussing a proposed change, identifying whether it affects consensus, local policy, or a wallet interface helps explain its deployment requirements and the consequences of disagreement.

Sources: github.com · developer.bitcoin.org

A cryptocurrency is a digital asset whose operation uses cryptographic techniques to authorize transfers and maintain records under a network's rules. Bitcoin and ether are native assets of their respective blockchains, while many other assets are tokens issued through applications on an existing chain. The category contains substantial differences in decentralization, supply policy, privacy, governance, and security. Cryptography can establish that an authorized key approved a transfer, but it does not by itself guarantee honest issuers, accurate prices, or useful economic rights. Most public cryptocurrency ledgers expose transaction information rather than encrypting every payment. Holding cryptocurrency also differs from holding an account balance at an intermediary, because the latter introduces the intermediary's custody and withdrawal arrangements. Understanding an asset requires identifying its network, the software that enforces its rules, and the people or mechanisms capable of changing those rules.

Sources: ethereum.org · bitcoin.org

A custodial wallet is a service in which another party controls the private keys or equivalent signing authority for a user's cryptocurrency. The user typically accesses an account through credentials, while the provider manages transfers and recovery procedures. This can simplify some tasks, but an account balance is not the same as independently controlling the corresponding on-chain outputs. Withdrawals may depend on the provider's systems, policies, available assets, and willingness to process requests. Transfers between customers of the same service may be internal bookkeeping entries rather than blockchain transactions. Custody therefore introduces risks involving security breaches, insolvency, account restrictions, and operational failures. A familiar interface or a published wallet address does not eliminate these risks. The central question is who can authorize movement of the assets and what evidence or process gives the user a dependable claim to withdraw them.

Sources: ethereum.org · bitcoin.org

A decentralized application is an application whose important operations are carried out through a distributed network, often using smart contracts on a blockchain. Its interface may resemble an ordinary website, while transactions submitted through that interface trigger publicly verifiable contract execution. Examples include exchanges, lending systems, games, and digital asset registries. Decentralization is not an all-or-nothing property: an application can use on-chain contracts while still relying on a centralized website, price feed, hosting provider, or administrator key. Users should therefore separate the interface from the contracts and infrastructure underneath it. A website disappearing does not always make the contracts inaccessible, but interacting without the usual interface can be difficult and risky. The DApp label also does not establish that code is immutable, audited, permissionless, or economically sound. Those characteristics depend on the specific implementation and its controls.

Sources: ethereum.org

A decentralized exchange is a system for trading digital assets in which settlement is coordinated through blockchain transactions or related protocols rather than solely through a central exchange's internal ledger. Designs include automated market makers, on-chain order books, and systems combining off-chain order matching with on-chain settlement. Many allow users to trade from self-controlled wallets, but this does not remove every intermediary or permission. Interfaces, routing services, administrator privileges, and token contracts can still affect execution. Traders must consider liquidity, price impact, slippage limits, network fees, and the permissions requested before a swap. A displayed token name is not enough to identify an asset; its contract and network matter. DEX access also does not guarantee a fair market or prevent fraudulent tokens. Understanding the settlement mechanism is more informative than assuming that the word decentralized describes every component equally.

Sources: developers.uniswap.org · ethereum.org

Decentralized finance is an umbrella term for financial applications implemented through blockchain-based protocols, commonly using smart contracts. Activities include asset exchanges, collateralized borrowing, lending pools, derivatives, and automated liquidity provision. Publicly accessible contracts can make transaction rules and recorded activity inspectable, but visibility alone does not establish safety. A protocol may depend on price oracles, administrator permissions, external custodians, or governance decisions. Combining several applications can create useful workflows while also carrying failures from one component into another. Advertised yields may come from trading fees, borrower payments, token incentives, or arrangements that expose depositors to losses; the source should not be assumed. Bitcoin-related DeFi may additionally require a bridge or separate execution network. The useful distinction is between what the code enforces directly and what still depends on operators, external information, collateral value, or redemption arrangements.

Sources: ethereum.org · ethereum.org

Difficulty adjustment is Bitcoin's mechanism for changing how hard it is to find a valid proof-of-work block as mining conditions change. On Bitcoin mainnet, the target is recalculated after each interval of 2016 blocks, using elapsed block time to move the average toward approximately ten minutes per block. More demanding difficulty corresponds to a lower numerical target that fewer hashes satisfy. If blocks have arrived too quickly, the next adjustment generally makes mining harder; if they have arrived too slowly, it generally makes mining easier, within the protocol's adjustment limits. The mechanism does not schedule individual blocks, which remain probabilistic, and it does not guarantee stable miner income. Increased hash rate can make blocks arrive faster before the next adjustment. Other networks, including Bitcoin testing networks, can use different rules, so mainnet's interval should not be treated as universal across cryptocurrencies.

Sources: github.com · developer.bitcoin.org

A digital signature is a cryptographic value that allows others to verify that a message was authorized using a particular private key. Verification uses the corresponding public key and detects changes to the signed information. In cryptocurrency systems, signatures help satisfy spending conditions without revealing the private key itself. Bitcoin uses signature schemes including ECDSA and Schnorr, depending on the output and spending arrangement. A signature is not encryption: it normally does not conceal the transaction's contents. Nor does it automatically establish the signer's real-world identity, because the relationship between a person and a key may be unknown. Wallet prompts deserve careful review because a valid signature can authorize an unwanted transaction just as effectively as an intended one. Security depends on the signing algorithm, correct implementation, protected keys, and a clear understanding of the message or transaction being approved.

Sources: csrc.nist.gov · github.com

Double spending is an attempt to use the same digital funds in conflicting transactions. Bitcoin prevents both transactions from being valid within one accepted history when they try to spend the same previously unspent output. Nodes check that an output exists, that its spending conditions are met, and that it has not already been consumed. However, conflicting transactions can circulate before confirmation, and competing blockchain branches can temporarily include different spends. Proof of work and confirmation depth make replacing an accepted history progressively more difficult under the network's security assumptions. Merely seeing a transaction broadcast is therefore weaker evidence than verifying its inclusion and subsequent confirmations. Double spending does not require copying a physical coin or learning someone else's private key; it concerns disagreement over which authorized spend becomes part of the ledger that recipients ultimately rely on.

Sources: developer.bitcoin.org · developer.bitcoin.org

Dust refers to very small cryptocurrency amounts, with a specific transaction-policy meaning in Bitcoin. A Bitcoin output may be considered dust when its value is too low relative to the estimated cost of spending it under a node's configured dust-relay assumptions. The threshold depends on factors such as output type and policy settings; there is no single amount that describes every output under every configuration. Dust policy should not be confused with a universal consensus prohibition on small payments. Separately, a wallet can contain outputs that are technically spendable but uneconomical at prevailing fee rates. Unsolicited tiny payments can also be used in attempts to analyze wallet activity, although receiving dust alone does not reveal a private key. Combining such outputs with other funds may create public links, making coin selection and privacy considerations relevant before spending them.

Sources: github.com · github.com

ERC-20 is an Ethereum token interface standard for fungible assets, meaning units within a particular token are treated as interchangeable. It specifies common functions and events for balances, transfers, total supply, and allowances that let another address spend an approved amount. This shared interface helps wallets, exchanges, and applications interact with many different tokens using similar software. It does not require a particular business model, fixed supply, market price, or governance arrangement. Some familiar metadata fields, including a token's name, symbol, and decimal precision, are optional in the original specification. Decimals affect display conventions rather than creating fractional arithmetic inside the token's integer balances. Implementations can add minting privileges, transfer restrictions, or other behavior, so interface compatibility is not a security certificate. Users should verify the contract address and understand approvals rather than relying only on a familiar ticker symbol.

Sources: eips.ethereum.org

ERC-721 is an Ethereum standard for non-fungible tokens that distinguishes individual assets through unique identifiers within a contract. Its interface provides methods for checking ownership, transferring tokens, and approving other addresses to manage specified tokens or an owner's collection. The combination of contract address and token identifier identifies a particular token more precisely than its image or collection name. Optional extensions can provide metadata or enumeration features, but the core standard does not require all associated media to be stored on-chain. A token may therefore refer to information hosted elsewhere, with separate availability and modification risks. Ownership of an ERC-721 token also does not automatically grant copyright, commercial use rights, or ownership of a physical object. Those claims depend on additional arrangements. The standard primarily defines interoperable ownership and transfer behavior, not the broader value or enforceability of the represented asset.

Sources: eips.ethereum.org

Ethereum is a public blockchain platform designed to execute transactions and programmable smart contracts across a distributed network. Its native asset is ether, commonly abbreviated ETH, which is used to pay transaction fees and participates in the network's proof-of-stake security system. Applications can issue separate tokens using standards such as ERC-20 and ERC-721, but those tokens are not automatically equivalent to ETH. Ethereum's execution environment lets contracts maintain state and interact with one another, supporting exchanges, digital collectibles, and other applications. That flexibility also creates risks involving contract logic, permissions, and dependencies. Ethereum should be distinguished from Bitcoin, which has a different transaction model and uses proof of work. It should also be distinguished from Ethereum-compatible networks: software compatibility does not mean they share the same validator set, native asset, settlement guarantees, or bridge arrangements.

Sources: ethereum.org · ethereum.org

A fifty-one percent attack is a commonly used name for an attack involving control of a majority of a proof-of-work network's effective mining power. An attacker with sustained majority hash rate can seek to outpace honest miners, reorganize recent history, censor transactions, or replace the attacker's own payments with conflicting spends. The label is shorthand rather than a precise boundary between possible and impossible attacks: outcomes also depend on duration, confirmation depth, coordination, and chance. Majority mining power does not allow an attacker to forge other users' signatures, spend arbitrary outputs, or create coins beyond consensus limits accepted by full nodes. The attack concerns selection among valid histories, not unlimited authority over validity rules. Mining concentration therefore matters, but counting mining devices or nodes is not equivalent to measuring control of the work used to extend the chain.

Sources: bitcoin.org · developer.bitcoin.org

Fork has several related meanings in cryptocurrency discussions. A temporary chain fork occurs when different valid blocks extend the same predecessor and nodes initially see competing branches. Bitcoin resolves these situations by following the valid branch with the greatest accumulated proof of work, potentially removing a recent block from the accepted history. A protocol fork instead concerns a change to validation rules; hard forks and soft forks describe different compatibility relationships between old and new rules. A software fork is simply a separate development branch or copy of a codebase and need not create a new blockchain at all. These meanings should not be mixed together. A routine competing block does not automatically create a lasting new cryptocurrency, and a proposed software change does not establish that users have adopted new consensus rules. Context determines what a particular fork announcement actually implies.

Sources: developer.bitcoin.org · github.com

A full node is software that independently checks blockchain data against the network's consensus rules rather than relying solely on another service's conclusions. In Bitcoin, it verifies transactions and blocks, maintains the information needed to identify spendable outputs, and communicates with other peers. Running a full node is distinct from mining: a node can validate the chain without competing to produce blocks or earning a block reward. Storage configuration also matters. An archival node retains historical block data, while a pruned full node can discard older block files after processing them and still enforce validation rules. A full node gives its operator a stronger basis for verifying payments and reducing reliance on third-party blockchain services. It does not automatically provide anonymity, keep private keys safe, or make a network decision by casting a vote proportional to the number of installed copies.

Sources: bitcoin.org · developer.bitcoin.org

Fungibility is the property that units of an asset can be treated as equivalent and interchangeable for a particular purpose. For a fungible token, one unit normally carries the same protocol-level rights as another unit of the same token. This does not mean that tokens issued by different contracts are interchangeable merely because they share a name or ticker. Fungibility is also separate from divisibility: an asset can be split into smaller units without every identifiable item being equivalent. Non-fungible tokens instead distinguish individual identifiers and their ownership. In public cryptocurrency systems, transaction histories remain observable, so service providers may treat otherwise equivalent units differently based on their own policies or analysis. The concept therefore has both a technical dimension, concerning how balances are represented, and a practical dimension, concerning how people and applications actually accept the asset.

Sources: eips.ethereum.org · eips.ethereum.org

Gas is the accounting unit Ethereum uses to measure the computational and storage-related work required by transactions. Sending ETH, calling a contract, and executing a complex application can consume different amounts of gas. The transaction fee depends on gas consumed and the effective price paid per unit, rather than on the asset's transferred market value alone. A gas limit caps the amount of work a transaction is permitted to use; it should not be confused with a quoted gas price. A transaction that reverts can still consume gas for work performed, even though its attempted application-state changes do not take effect. Fees are ordinarily paid in the network's native asset, although applications may arrange payment abstractions. Bitcoin transaction fees use a different model centered on transaction size and weight, so gas is not a universal name for every blockchain's fee calculation.

Sources: ethereum.org

The genesis block is the starting block of a blockchain, assigned height zero. Unlike later blocks, it does not extend an earlier block within that chain. Bitcoin software identifies a specific genesis block as part of its network configuration, establishing the initial reference from which subsequent block relationships are traced. Different networks, including testing environments, can have different genesis blocks even when they use related software. The term describes a technical starting point, not a guarantee that a project is decentralized or trustworthy. A new cryptocurrency can create its own genesis block while choosing very different rules for issuance, permissions, and validation. When examining network data, the genesis reference helps distinguish one chain from another. It also illustrates why a copied codebase does not automatically share Bitcoin's transaction history, accumulated proof of work, or native BTC balances.

Sources: github.com

A governance token is a digital asset used in a protocol's decision-making arrangements. Depending on the implementation, holders may submit proposals, delegate voting power, approve parameter changes, or influence how a treasury is used. Some votes directly trigger on-chain execution, while others signal preferences that an operator or separate process must implement. The token's actual powers are defined by contracts and governance procedures, not by the label alone. Voting thresholds, delegation, quorum, timelocks, administrator privileges, and the distribution of holdings can substantially affect practical control. Owning a governance token does not automatically grant company equity, revenue rights, or authority over every part of an application. A protocol may also have emergency powers outside ordinary voting. Understanding who can propose, approve, execute, or block a change is therefore more useful than assuming that token ownership provides equal or comprehensive participation.

Sources: developers.uniswap.org

A halving is the scheduled reduction of Bitcoin's block subsidy by half after each interval of 210,000 blocks. Because Bitcoin aims for an average block interval of approximately ten minutes, halvings occur roughly every four years, but the protocol uses block height rather than a fixed calendar appointment. The event reduces newly permitted issuance per block; it does not halve existing wallet balances, transaction amounts, or the maximum supply. It also does not necessarily halve a miner's total block reward because transaction fees are a separate component. Mining revenue after a halving depends on several variables, including fees, market prices, operating costs, and competition. The schedule is a monetary rule, not a mechanism that guarantees a price increase. Discussions of an upcoming or past halving should therefore distinguish the directly specified subsidy change from uncertain market responses and individual business outcomes.

Sources: github.com · github.com

A hard fork is a change to blockchain validation rules that can make blocks acceptable under the new rules but unacceptable under the old ones. Nodes that retain the old rules may reject the changed chain, even when it has substantial mining work or validator support. If different groups continue maintaining incompatible histories, a persistent chain split can result. A hard fork does not always produce two active currencies, however; participants may coordinate an upgrade without maintaining an alternative chain. It also should not be confused with copying software into a separate development repository. Important practical questions include which rules change, how activation occurs, whether transactions can be replayed across branches, and how wallets identify the intended network. The compatibility distinction describes the change's technical effect, not whether the proposal is beneficial, legitimate, or broadly supported by users.

Sources: developer.bitcoin.org

A hardware wallet is a dedicated device designed to generate or protect private keys and authorize cryptocurrency transactions without routinely exposing those keys to a general-purpose computer. The connected phone or computer can prepare a payment, while the device performs signing and may display details for confirmation. The coins remain recorded on the blockchain rather than stored inside the device. Hardware separation can reduce certain malware risks, but it does not make every transaction safe. A user can still approve the wrong destination, disclose a recovery phrase, install untrusted software, or rely on an insecure backup. Device loss is usually a recovery problem rather than automatic loss of funds when the required backup remains intact. Conversely, anyone obtaining sufficient recovery material may bypass the device entirely. The security model includes the device, its software, the verification process, and the backup arrangement.

Sources: trezor.io · bitcoin.org

A cryptographic hash function transforms input data into a fixed-length output called a hash or digest. The same input produces the same digest, while a small change normally produces a very different result. Security properties include making it impractical to recover a suitable input from its digest or find distinct inputs with the same digest under the function's intended assumptions. A hash is not encrypted text and is not designed to be decrypted with a secret key. Cryptocurrency systems use hashes for data commitments, identifiers, Merkle trees, and proof-of-work calculations. These uses do not make a hash a guarantee that the original data is truthful; it can commit just as effectively to inaccurate information. Its role is to help detect changes or prove relationships between data. Different hash algorithms have different designs, output lengths, and security characteristics, so their names are not interchangeable.

Sources: csrc.nist.gov

Hash rate measures how many hashing attempts mining equipment performs per second. Units such as terahashes per second and exahashes per second describe increasingly large quantities of calculations. A miner's hash rate affects its expected share of proof-of-work opportunities relative to other miners, but it does not guarantee a block discovery within a particular period. The network's total hash rate is generally estimated from observed block production and difficulty rather than measured by directly inspecting every machine. Short estimation windows can therefore be noisy. Hash rate also differs from energy efficiency: equipment may perform many calculations while consuming substantially different amounts of electricity. Comparisons across cryptocurrencies require caution because different mining algorithms perform different kinds of work. For Bitcoin, hash rate is one indicator of mining activity, not a direct measure of transaction throughput, user adoption, decentralization, or investment value.

Sources: bitcoincore.org · stratumprotocol.org

A hierarchical deterministic wallet derives a structured tree of cryptographic keys from a starting secret using defined mathematical rules. Bitcoin's BIP-32 standard describes a common method for creating parent and child keys, allowing a wallet to organize accounts and generate many receiving and change addresses. Because derivation is deterministic, the same starting information and paths can reproduce the same keys. An extended public key can support watching-only functions and address generation for eligible branches without revealing the corresponding spending keys. However, sharing it can expose a broad view of wallet activity and should not be treated as privacy-neutral. An HD wallet is not synonymous with a specific recovery-word format; mnemonic encoding and key derivation are related but separate standards. Successful recovery may require knowing the wallet's script type and derivation paths as well as possessing the correct secret material.

Sources: github.com

A hot wallet is a wallet arrangement in which signing keys are available to a device or service that is connected to a network during normal use. It is commonly used for frequent payments because transaction creation and signing can happen without an offline transfer process. Hot describes connectivity and key exposure, not ownership: a hot wallet can be self-custodial or operated by a custodian. Encrypting a wallet file or protecting an account with authentication helps address some risks, but malware may still target an unlocked signing environment or substitute payment details. Backups remain essential because connectivity does not provide automatic recovery. A user may keep limited spending funds in a hot wallet while using a separate arrangement for other holdings, but the appropriate setup depends on practical needs. The key distinction is where spending authority becomes available when a transaction is authorized.

Sources: electrum.readthedocs.io · ethereum.org

An inscription is content recorded using the Bitcoin inscription convention associated with Ordinals. It can contain text, an image, or other data, commonly placed in a Taproot transaction's witness through a script structure that carries the content without executing it as ordinary instructions. Ordinals-aware software associates the inscription with a satoshi and tracks its movement according to its indexing rules. Bitcoin nodes validate the underlying transaction and script requirements, but they do not need to interpret the content as a collectible or enforce a marketplace's claimed value. Inscribing data consumes block space and requires transaction fees. The content's presence on-chain also does not establish copyright ownership, authenticity of an artist, or rights to an external asset. Careful wallet handling matters because ordinary spending can move the output associated with an inscription even when the user intended to preserve it.

Sources: docs.ordinals.com

Layer 2 refers to a system built above a base blockchain to handle some activity outside the base chain while using it for settlement or enforcement. The term covers different designs, so the actual relationship to the underlying chain matters more than the marketing label. Bitcoin's Lightning Network uses payment channels, while Ethereum rollups use different methods for executing transactions and establishing their results. A separate chain or custodial service does not automatically become a layer 2 merely because it accepts deposits from a well-known network. Important distinctions include who can withdraw funds, what information remains available, how disputes are resolved, and whether a privileged operator can halt activity. Faster or cheaper transactions can come with liquidity requirements, exit delays, or additional software assumptions. Layer 2 therefore describes an architectural relationship, not a universal guarantee of base-layer security in every circumstance.

Sources: ethereum.org · docs.lightning.engineering

The Lightning Network is a Bitcoin payment-channel network that allows participants to make transfers without recording every individual payment directly on Bitcoin's blockchain. Channel participants commit funds through on-chain transactions and exchange updates that represent changing balances. Payments can be routed across connected channels, subject to available liquidity and the network's payment protocols. Opening or closing channels can require on-chain fees, and routed payments can carry forwarding fees. Lightning does not introduce a separate native mining token: payments are denominated in bitcoin units. Its security and usability depend on wallet design, channel management, monitoring arrangements, and the ability to use on-chain enforcement when necessary. Some services provide custodial Lightning accounts, which add provider risk rather than giving the user direct control of channel funds. A fast Lightning payment should therefore be distinguished from a new on-chain transaction and its confirmations.

Sources: github.com · docs.lightning.engineering

A liquidity pool is a collection of assets held under a protocol's rules to support activities such as trading or lending. In an automated market maker, users trade against the pool's reserves, and liquidity providers contribute assets that make those exchanges possible. Providers typically receive a recorded claim on a share of the pool and may earn fees or incentives. The composition and value of that claim can change as trades occur and market prices move. Providing liquidity is therefore not equivalent to simply holding the deposited tokens. One important risk is loss relative to holding the same assets separately, often called impermanent loss, which can remain economically real when liquidity is withdrawn. Pool depth, fee rules, contract security, token behavior, and withdrawal conditions also matter. A large displayed yield does not by itself explain the source or durability of returns.

Sources: developers.uniswap.org

A mempool is a node's local collection of transactions it has accepted for possible inclusion in future blocks. There is no single globally identical Bitcoin mempool: nodes can learn about transactions at different times and apply different relay, replacement, and memory-management policies. Transactions may enter through peers or local wallet broadcasts and leave when they are confirmed, replaced, expired, or removed under the node's rules. Being present in one mempool does not guarantee propagation across the network or inclusion by a miner. Fee rates influence selection, but miners can apply their own preferences and package considerations. A transaction may also depend on another unconfirmed transaction, making their relationship important. Mempool observations are useful for estimating congestion and fees, but they describe pending local information rather than a finalized ledger or a centrally managed queue with guaranteed ordering.

Sources: bitcoincore.org · github.com

Merged mining allows work performed for one proof-of-work blockchain to contribute to securing another compatible blockchain. A common design commits information about the auxiliary chain into the parent chain's mining work, allowing the auxiliary network to verify an appropriate proof without requiring a completely separate hashing effort. The parent chain does not necessarily need to recognize or validate the auxiliary chain's transactions. Each network still has its own consensus rules, ledger, and asset. Merged mining therefore does not merge coin supplies or make an auxiliary token interchangeable with BTC. It can let miners participate in additional reward opportunities, but the auxiliary network's security depends on the work actually committed to it and its own validation design. Any bridge, federation, or redemption mechanism connecting the networks remains a separate source of assumptions. Sharing hashing work alone does not settle those custody questions.

Sources: dev.rootstock.io

A Merkle tree is a data structure that combines hashes in successive layers until they produce a single root commitment. Bitcoin uses a Merkle root in the block header to commit to the block's transaction identifiers. A Merkle proof can demonstrate that a particular transaction belongs to the committed set using a relatively small collection of intermediate hashes, without presenting every other transaction in the block. Changing a committed item changes the path to the root, making the alteration detectable under the hash function's security assumptions. However, inclusion is not the same as full validity. A proof that a transaction appears in a block does not independently establish that all its inputs were spendable or that the block belongs to the best valid chain. Merkle structures also appear in other cryptocurrency applications, where the meaning of a proved item depends on what the tree commits to.

Sources: bitcoincore.org · developer.bitcoin.org

Mining is the process of constructing candidate blocks and competing to satisfy a proof-of-work requirement. In Bitcoin, miners select transactions, create a coinbase transaction, assemble a block header, and repeatedly vary candidate data while searching for a hash below the required target. A successful candidate must still satisfy every other consensus rule before full nodes accept it. Mining helps order transactions and makes replacing accepted history costly, while permitted rewards create incentives for participation. It is not the same as running an ordinary full node, staking a token, or solving useful scientific calculations. Individual results are probabilistic, and operating costs can continue even when no block is found. Equipment efficiency, electricity costs, network competition, pool arrangements, and fees all affect a miner's economics. Increasing the number of mining machines does not directly increase Bitcoin's permitted transaction volume or alter its issuance schedule.

Sources: developer.bitcoin.org · github.com

A mining pool coordinates work from multiple miners and distributes proceeds according to an agreed payout method. Participants submit shares, which are proofs meeting a pool-defined target that is usually easier than the network's block target. Shares help estimate contributed work even when they are not valid network blocks. Pooling can make individual payouts less irregular than solo mining, but it does not increase the underlying probability that a given quantity of hashing work discovers a block. Payout methods differ in how they handle fees, variance, timing, and the operator's obligations. The pool's control over transaction selection can also matter for decentralization and censorship resistance. Mining protocols may give participants different levels of influence over templates. A pool account balance is a claim under the pool's arrangements, not an automatically enforced share of every coinbase output on the blockchain.

Sources: developer.bitcoin.org · stratumprotocol.org

Multisignature is a spending arrangement that requires authorization from more than one cryptographic key. A common Bitcoin example is a two-of-three setup, in which any two designated keys can jointly authorize a transaction. The keys may be held by different people, devices, or locations, reducing dependence on one secret or one operator. Multisig is different from making several copies of the same private key or splitting a recovery phrase into informal pieces. It creates a defined authorization policy that the spending mechanism enforces. The arrangement can improve resilience, but it also increases coordination and backup complexity. Losing too many keys can make funds inaccessible, and recovery may require wallet configuration information in addition to individual secrets. Standardized partially signed transaction formats can help separate participants review and sign the same payment without first combining their private keys in one place.

Sources: developer.bitcoin.org · github.com

A non-fungible token is a token whose individual identifier distinguishes it from other tokens in the same system. Rather than representing interchangeable units of one balance, an NFT records ownership of a particular token instance. Applications use this structure for collectibles, game items, membership credentials, and references to other assets. The token and the associated content are separate concepts: many NFTs point to metadata or media stored outside the blockchain, and several tokens can refer to similar or identical images. Technical ownership therefore does not automatically establish authenticity, copyright, commercial permission, or ownership of a physical object. Those claims require additional evidence and arrangements. NFT standards define transfer and approval behavior, but implementations may add administrator controls or changing metadata. Evaluating an NFT involves checking its network, contract, identifier, storage method, transfer permissions, and the precise rights the issuer claims it represents.

Sources: ethereum.org · eips.ethereum.org

A nonce is a value used within a protocol to distinguish operations or vary an input, but its exact role depends on context. In Bitcoin mining, the block header includes a 32-bit nonce field that miners can change while searching for a hash satisfying the target. Exhausting that field does not exhaust every possible candidate, because miners can also change other permitted data, such as information in the coinbase transaction that affects the Merkle root. In account-based systems such as Ethereum, an account transaction nonce instead helps order transactions and prevent repeated execution of the same authorized operation. Cryptographic signature schemes use another kind of nonce with strict security requirements. These meanings are related by the use of a distinguishing value, but they are not interchangeable. A miner's header nonce is not a wallet password, an account balance, or a measure of mining difficulty.

Sources: developer.bitcoin.org · ethereum.org

OP_RETURN is a Bitcoin Script instruction that causes script execution to fail when it is executed. An output whose locking script begins with OP_RETURN is therefore provably unspendable and can be used to carry data without creating an output that nodes must retain as spendable. Applications use such outputs for commitments, metadata, and protocol-specific messages. Any bitcoin value assigned to that unspendable output cannot later be recovered through ordinary spending. The data still occupies transaction and block space, so creating the output is not free storage. Rules governing which data-carrying transactions a node relays are policy matters and can vary by configuration or software version; historical relay limits should not be mistaken for timeless consensus rules. Bitcoin's acceptance of the underlying transaction also does not mean it validates the meaning or accuracy of every application message embedded in the output.

Sources: github.com · github.com

An oracle is a mechanism that supplies information to a blockchain application from outside the application's directly verifiable state. A lending contract, for example, may need an asset price to determine collateral requirements or liquidations. The blockchain can verify that an oracle update followed specified authorization rules, but that does not automatically prove the reported information reflects reality. Oracle designs differ in their data sources, aggregation methods, update schedules, incentives, and handling of unavailable or inconsistent values. A single price from a thinly traded market can be especially vulnerable to manipulation, while multiple sources still require careful assumptions. Oracles can also communicate results between systems or trigger external actions. The important distinction is between deterministic contract execution and the quality of the input driving that execution. A contract can operate exactly as written and still produce harmful outcomes when its oracle data is wrong.

Sources: ethereum.org

Ordinals is a convention for assigning numbers to individual satoshis and tracking them as Bitcoin transactions move value between outputs. Its numbering follows the order in which satoshis are mined, while transfer interpretation uses defined ordering rules. This creates a way for Ordinals-aware software to discuss particular satoshis rather than only aggregate bitcoin amounts. Inscriptions can associate content with these tracked units, but numbering and inscription content are distinct parts of the ecosystem. Ordinal identifiers are not a new native coin, and Bitcoin consensus does not assign different monetary denominations to satoshis based on their ordinal number. Marketplaces may attribute collectible significance to certain histories or categories, but that significance is separate from Bitcoin's base accounting rules. Using suitable wallet software matters because an ordinary transaction can move a tracked satoshi according to the convention even when the user was thinking only about its BTC value.

Sources: docs.ordinals.com

A peer-to-peer network connects participants directly so they can exchange data without routing every interaction through one central server. Bitcoin nodes use peer connections to announce transactions and blocks, request missing data, and discover other reachable nodes. Each node still applies its own validation rules; receiving a message from a peer does not make the message trustworthy. The network structure helps distribute information and reduces dependence on a single operator, but not every node connects to every other node. Connectivity, peer diversity, bandwidth, and software behavior affect how information propagates. Peer-to-peer communication also does not automatically provide anonymity or prevent traffic analysis. A hostile set of connections can distort what a node initially sees, making independent validation and sound networking design important. P2P describes the communication architecture, while consensus describes how participants decide which received information belongs in the accepted ledger.

Sources: developer.bitcoin.org

A private key is secret cryptographic information used to perform operations such as creating digital signatures. In a typical cryptocurrency wallet, control of the relevant private key allows its holder to authorize spending when the remaining output or contract conditions are satisfied. The associated public key can be shared for verification without revealing the private key under the cryptographic system's security assumptions. A private key is not the same as a receiving address, transaction identifier, account password, or recovery phrase, although a recovery phrase may recreate many private keys. Losing the necessary keys without a usable backup can make funds inaccessible. Exposing them can let someone else authorize transactions without obtaining a separate account login. Security therefore involves generation quality, protected storage, reliable backups, and careful signing procedures. No legitimate payment recipient needs a sender's private key simply to receive cryptocurrency.

Sources: csrc.nist.gov · developer.bitcoin.org

Proof of reserves is a process intended to provide evidence about assets held by a cryptocurrency custodian relative to specified customer balances. Implementations may combine demonstrations of control over blockchain addresses with a Merkle-tree commitment that lets customers check whether their balances were included in a reported snapshot. The exact scope matters: evidence of assets alone does not establish that all liabilities were included, that assets are unencumbered, or that the operator can meet every future withdrawal. A snapshot also does not continuously verify the institution's condition between reporting dates. Different reports use different procedures, assurance levels, and asset coverage, so the phrase should not be treated as a uniform certification. Users examining a report should distinguish verifiable inclusion from broader claims about solvency, ownership, accounting controls, and operational security. Transparency tools can be useful while still leaving important questions outside their demonstrated scope.

Sources: kraken.com

Proof of stake is a family of consensus mechanisms in which participants commit an asset as stake to help determine who proposes or attests to blocks and how dishonest behavior is discouraged. Ethereum uses a proof-of-stake design with validators, rewards, penalties, and specific finality rules. Other networks can use materially different selection methods and enforcement mechanisms, so the label does not identify one universal protocol. Unlike proof of work, participation is not based primarily on winning a repeated hashing competition. Stake concentration, validator availability, client diversity, and the consequences of conflicting messages can affect security. Delegating through a service may also introduce custody or contract risks beyond the underlying consensus rules. Holding a token is not automatically the same as operating a validator. The actual process for committing stake, performing duties, earning rewards, and withdrawing depends on the network and participation arrangement.

Sources: ethereum.org

Proof of work is a mechanism that makes producing an acceptable result computationally costly while allowing others to check that result comparatively quickly. Bitcoin uses it by requiring a candidate block header's hash to meet a numerical target. Miners perform repeated trials, and finding a valid result provides evidence of an expected amount of hashing effort rather than a record of every calculation attempted. Nodes compare accumulated work when choosing among valid blockchain histories. This makes rewriting history require additional competitive work, but proof of work does not replace transaction validation or establish that any external information is true. It also does not mean miners are solving useful scientific problems; Bitcoin's work is specifically tied to its block-selection process. Difficulty adjusts the expected effort, while the random nature of hashing means individual miners can experience long or short intervals between successes.

Sources: developer.bitcoin.org · developer.bitcoin.org

A public key is the shareable component of an asymmetric cryptographic key pair. In cryptocurrency signature systems, it lets others check that a signature was produced using the corresponding private key without revealing that private key. Bitcoin derives public keys through elliptic-curve operations and uses them in spending conditions, sometimes directly and sometimes through commitments or hashes. A public key is not always identical to a receiving address, because addresses can encode different kinds of output information. Knowing an ordinary public key does not normally provide spending authority, but publishing it can still reveal relationships between transactions or wallet activity. Extended public keys used by hierarchical wallets can expose considerably more information than a single key. Verification also establishes a relationship to a cryptographic key, not necessarily to a named individual. Real-world identity requires additional evidence outside the key's mathematical properties.

Sources: csrc.nist.gov · github.com

Replace-by-fee is a transaction replacement mechanism that can let an unconfirmed Bitcoin transaction be superseded by a conflicting transaction offering sufficient additional fees under applicable node policies. Wallets use it to increase the incentive for miners to confirm a payment when the original fee is inadequate. BIP-125 describes an opt-in signaling approach, but replacement policies can differ across implementations and software versions, so signaling should not be treated as the only possible condition everywhere. A replacement is a new transaction and can have a different transaction identifier. It must still satisfy ordinary spending authorization and validity requirements. RBF does not edit an already confirmed transaction or guarantee that the replacement will arrive first or be mined. Recipients should therefore distinguish pending transaction observations from confirmed settlement, while senders should review whether their wallet preserves the intended payment outputs during a fee adjustment.

Sources: github.com · github.com

Runes is a Bitcoin-based fungible token protocol that uses an output-oriented accounting model. Its messages, called runestones, are encoded in designated OP_RETURN outputs and interpreted to define operations such as creating a rune, minting units under specified terms, and allocating balances to transaction outputs. Rune creation is commonly called etching. Unlike the original BRC-20 approach, Runes does not represent its basic operations as JSON inscriptions. Bitcoin full nodes validate the underlying transactions, while protocol-aware software interprets rune balances and transfer rules. The reference implementation is important because precise parsing behavior can affect outcomes, including the treatment of malformed messages. Rune units are separate from the satoshis in the outputs that carry associated balances and still require bitcoin for transaction fees. A valid token record does not establish demand, redeemability, or issuer credibility, and careless transaction construction can unintentionally move or destroy token balances.

Sources: docs.ordinals.com

A satoshi, often shortened to sat, is the smallest whole unit used in Bitcoin's base-layer value accounting. One bitcoin equals 100 million satoshis, so one satoshi is 0.00000001 BTC. Wallets can display the same underlying amount in either denomination, which can make small payments easier to read without changing their value. Transaction fee rates are often quoted in satoshis per virtual byte rather than as a percentage of the payment. Some higher-layer systems use finer internal accounting units, but Bitcoin transaction output amounts remain denominated in whole satoshis. A satoshi is a unit of BTC, not a separate cryptocurrency or an independently issued token. Ordinals-related software can track particular satoshis through an additional convention, but the base protocol does not assign a larger face value to one because of its number, history, or collectible description.

Sources: github.com

A Schnorr signature is a digital signature produced using a Schnorr-style cryptographic construction. Bitcoin's BIP-340 specifies a particular version over the secp256k1 elliptic curve, including its encoding and verification rules. It forms part of the signing capabilities used with Taproot. The construction has mathematical properties that can support efficient verification and carefully designed multiparty signing protocols, but ordinary signatures do not automatically combine themselves or make every multisignature wallet private. Additional protocols must handle participant coordination and security correctly. BIP-340 signatures use a 64-byte core encoding, distinct from some other Bitcoin signature representations. As with other signature schemes, security depends on protecting private keys and implementing nonce generation and signing correctly. A Schnorr signature proves authorization under a key and a defined message; it does not encrypt transaction contents, identify the signer as a person, or prove the payment's economic purpose.

Sources: github.com

A seed phrase, also called a recovery phrase or mnemonic phrase, is a sequence of words used by many wallets to encode information from which wallet keys can be derived. BIP-39 defines a common scheme using a word list, entropy, and a checksum, with familiar lengths such as twelve or twenty-four words. Not every wallet uses the same mnemonic standard or recovery procedure. Some arrangements also use an optional passphrase, which changes the derived wallet rather than acting as a conventional password-reset credential. Anyone possessing sufficient recovery information may be able to recreate spending authority on another device. The phrase should therefore be treated as a high-value secret, not an ordinary support code. Recovery can additionally depend on derivation paths, script types, or multisignature configuration. A valid word sequence does not by itself prove that a particular wallet contains the expected addresses or funds.

Sources: github.com

Segregated Witness is a Bitcoin protocol upgrade that separates certain spending-authorization data into a witness structure while changing how transaction capacity is accounted for. Its design introduced block weight and new witness-program output types. For SegWit serialization, the ordinary transaction identifier excludes witness data, while a separate witness transaction identifier commits to it. This addresses important forms of transaction malleability and supports protocols that need more stable transaction references. SegWit does not remove signature checks: the witness still carries information that nodes must validate when the spending rules require it. It also does not make payments anonymous or guarantee lower fees in every situation. Costs depend on the complete transaction structure and prevailing fee rates. Native SegWit addresses use appropriate Bech32-family encodings, but compatibility depends on the witness version and the sender's software rather than on the general SegWit label alone.

Sources: github.com

Self-custody means that a user controls the cryptographic authority needed to move cryptocurrency rather than relying on a provider to approve withdrawals from an internal account. It can be implemented through a software wallet, hardware device, offline signing setup, or a carefully designed multisignature arrangement. The defining feature is control of spending authority, not the appearance of an application or the presence of a personal account name. Self-custody reduces some intermediary risks but transfers responsibility for backups, transaction review, device security, and recovery planning to the holder. Losing every usable recovery path can make funds inaccessible, while disclosing sufficient key material can allow unauthorized spending. It also does not protect against approving a harmful contract interaction or sending to the wrong address. A sound custody arrangement must address both theft prevention and the ability to recover access when devices or circumstances change.

Sources: bitcoin.org · electrum.readthedocs.io

SHA-256 is a cryptographic hash algorithm in the SHA-2 family that produces a 256-bit digest. The output is commonly displayed as 64 hexadecimal characters. Bitcoin uses two successive SHA-256 operations when hashing block headers for proof of work, and related hashing constructions appear elsewhere in its data structures. The algorithm maps input data to a digest; it does not encrypt the data or provide a decryption operation. Miners do not break SHA-256 when they discover a block. They search through varying candidate headers until a resulting hash meets the required numerical target. The ability to verify a result quickly is different from the difficulty of finding one. SHA-256 should also be distinguished from the elliptic-curve signature algorithms that authorize Bitcoin spending. Hashing and digital signatures serve complementary roles, but possessing a transaction hash does not grant access to its funds.

Sources: csrc.nist.gov · developer.bitcoin.org

A sidechain is a separate blockchain connected to another network through a mechanism for transferring or representing assets. It can offer different execution capabilities, block timing, or transaction rules while maintaining its own ledger and consensus arrangements. Moving BTC into a Bitcoin-related sidechain usually involves a peg or bridge that controls how the original coins are locked and how they can be released. The sidechain asset is therefore subject to additional assumptions beyond Bitcoin's ordinary spending rules. Some sidechains use merged mining, while others rely on validators or federations; sharing some infrastructure does not make every design equally secure. A sidechain should not automatically be described as inheriting all base-chain security or as a rollup. The critical questions concern validation, withdrawal authorization, operator control, and what happens when the bridge or sidechain stops functioning. Those details determine the practical relationship between the two networks.

Sources: ethereum.org · dev.rootstock.io

A smart contract is program logic that enforces specified conditions within a blockchain environment. On Ethereum, contracts can hold state, receive transactions, and interact with other contracts to implement applications such as exchanges or token systems. Bitcoin supports a different and more constrained scripting model for defining spending conditions, including signatures, hash conditions, and timelocks. The word contract does not by itself mean the code forms an enforceable legal agreement. Nor does smart imply that the program can judge fairness, verify arbitrary real-world facts, or correct its own mistakes. Execution follows the implemented rules, including any vulnerabilities or administrator powers. External information may require an oracle, and upgrades may depend on privileged keys or governance procedures. Reviewing a smart contract therefore involves understanding its code, permissions, dependencies, and economic behavior rather than assuming that automated execution makes the arrangement trustworthy or risk-free.

Sources: ethereum.org · developer.bitcoin.org

A soft fork is a change that tightens blockchain validation rules so that blocks accepted under the new rules remain acceptable under the older, less restrictive rules. Upgraded nodes enforce the additional conditions, while older nodes may continue following the same chain without understanding every new restriction. This compatibility relationship distinguishes a soft fork from a hard fork, which can allow blocks older nodes reject. Compatibility does not eliminate deployment risks or make adoption automatic. Participants still need an activation process and sufficient enforcement to avoid accepting histories that violate the intended rules. Bitcoin's SegWit and Taproot upgrades are examples of changes designed through soft-fork mechanisms. A software release, miner signal, and active consensus requirement are distinct events. Understanding a proposed soft fork therefore requires examining exactly which previously permitted behaviors become invalid and how participating nodes determine when to enforce that restriction.

Sources: github.com · github.com

A stablecoin is a cryptocurrency token designed to track a reference value, often one unit of a national currency. Designs differ substantially: some depend on reserves managed by an issuer, others use crypto collateral and liquidation rules, and others rely more heavily on algorithmic incentives. A target price is not a guarantee that the token will always trade at that price or be redeemable on demand. Reserve quality, redemption eligibility, custody, contract controls, market liquidity, and the performance of the stabilization mechanism all matter. Issuers or administrators may also have powers to freeze addresses or modify operations, depending on the implementation. Stablecoins can serve as trading units or payment instruments within blockchain applications, but they are not automatically equivalent to cash in a bank account. Their apparent price stability should be evaluated separately from operational, counterparty, collateral, and network risks.

Sources: ethereum.org

Staking is the act of committing an asset to participate in a protocol's security or incentive system. In a proof-of-stake blockchain, it commonly supports validator duties such as proposing blocks and attesting to the accepted history. Participants may receive rewards and can face penalties, withdrawal delays, or slashing under the network's particular rules. Staking can be performed directly or through a provider, and pooled or liquid-staking products introduce additional contracts and operational arrangements. The term is also used loosely for locking tokens in unrelated reward programs, so an advertised staking product should explain what the committed assets actually do. Bitcoin uses proof of work and does not pay native proof-of-stake rewards to BTC holders. Products described as BTC staking rely on an additional protocol or service. Quoted reward rates are not guaranteed investment returns and must be considered alongside fees, token value changes, and potential losses.

Sources: ethereum.org · ethereum.org

Stratum is a family of communication protocols used to coordinate cryptocurrency mining equipment with pools and related infrastructure. It carries information about mining jobs and submitted work so that devices know what to hash and operators can evaluate their contributions. Stratum is not Bitcoin's consensus mechanism and does not change what full nodes consider a valid block. Stratum V2 includes distinct components for mining communication, job declaration, and template distribution, allowing different roles to be separated. Its design also supports stronger transport security and arrangements that can give miners more influence over transaction selection. Whether those capabilities are available depends on the actual equipment, software, pool support, and configuration. A connection labeled Stratum therefore does not establish a particular payout method or level of decentralization. The protocol handles coordination, while the pool agreement and underlying blockchain rules govern different parts of the mining process.

Sources: github.com · stratumprotocol.org

Taproot is a Bitcoin upgrade that introduces a spending design combining a public-key path with optional script-based alternatives. When the key-path conditions are satisfied, an output can be spent using a Schnorr signature without revealing unused alternative scripts. When a script path is used, the spender reveals the relevant script and the proof needed to connect it to the output's commitment, rather than necessarily revealing every possible spending condition. This can improve efficiency and reduce unnecessary disclosure for suitable arrangements. Taproot does not make all Bitcoin transactions anonymous or automatically compress every complex policy into one ordinary signature; wallet and protocol design still matter. Taproot outputs use witness version one and Bech32m addresses. The upgrade should be distinguished from individual applications that use its capabilities, because a particular token protocol, wallet feature, or inscription convention can add assumptions beyond Taproot's consensus rules.

Sources: github.com · github.com

A testnet is a blockchain environment used to develop and test software without using the main network's real assets. Developers can exercise wallet behavior, contract interactions, transaction handling, or mining-related code in conditions that resemble a public network while accepting that the environment may be less stable. Test coins are intended for experimentation rather than investment, and they are not interchangeable with mainnet BTC or other production assets. Bitcoin has multiple testing arrangements, including named public test networks, signet environments, and local regression testing, each serving different needs. Their consensus parameters and operating assumptions can differ from mainnet. Successful testing therefore provides useful evidence but does not prove that a system is ready for every production condition. Users should verify the selected network and avoid reusing sensitive mainnet recovery material merely for convenience when experimenting with unfamiliar software or test services.

Sources: github.com · github.com

A timelock is a condition that restricts when a transaction or spending path can become valid. Bitcoin supports absolute constraints tied to a block height or time threshold and relative constraints measured from an earlier output's confirmation. These mechanisms support arrangements such as payment channels, delayed recovery paths, and refunds when another party does not complete an exchange. A timelock usually defines the earliest permitted spending point rather than automatically sending funds at a scheduled moment. Someone still needs to construct, authorize, and broadcast an appropriate transaction, and confirmation depends on mining. Blockchain time measurements also should not be treated as precise wall-clock appointments. A locked output may contain alternative spending paths with different conditions, so the full script or policy matters. Understanding which party can spend, after which trigger, and through which authorization path is essential to interpreting the protection a timelock provides.

Sources: github.com · github.com

A token is a digitally represented unit of value, access, ownership, or another defined interest tracked under a protocol's rules. In common cryptocurrency usage, tokens are often distinguished from coins native to a blockchain: BTC is native to Bitcoin, while an ERC-20 asset is tracked by a contract on its host network. However, terminology varies, and not every token system uses a general-purpose smart contract. Bitcoin-based conventions can rely on separate indexing rules that interpret underlying transactions. A token's name or ticker does not uniquely identify it; the network, contract or protocol identifier, and issuance rules are more precise. Tokens can be fungible or non-fungible and can represent very different rights. Creating a token does not by itself create reserves, enforce off-chain promises, establish market demand, or guarantee that the issuer cannot change important controls. Those properties require separate examination.

Sources: ethereum.org · docs.ordinals.com

A token burn is a process intended to remove token units from usable supply. In a smart contract system, a dedicated burn operation may decrease a holder's balance and the contract's recorded total supply. Another approach sends assets to a demonstrably unspendable destination, although this may not change the supply figure reported by the token contract. These mechanisms should be distinguished from temporarily locking tokens or moving them into an issuer-controlled treasury. A burn can be part of redemption, fee processing, migration, or an economic policy, but reducing units does not guarantee higher market value. The effect depends on demand, remaining supply, future minting powers, and the credibility of the removal mechanism. Users should also distinguish intended burns from accidental loss of keys, which can make assets inaccessible without producing a verifiable supply-reduction event. The exact contract or protocol determines what a burn actually changes.

Sources: docs.openzeppelin.com · github.com

Tokenization is the process of representing an asset, entitlement, or defined relationship through a digital token. A system might tokenize a membership, an in-game item, a claim to stored goods, or an interest associated with a financial arrangement. Blockchain records can help track issuance and transfers, but the connection between the token and anything outside the chain requires additional mechanisms. A token referring to a physical asset cannot independently prove that the asset exists, remains available, or will be delivered. Custody, verification, redemption procedures, and applicable agreements therefore remain important. Tokenization also does not automatically divide an asset into economically useful fractions or make it liquid. The design must specify what each unit represents and whether transfers carry the intended rights. The central distinction is between ownership of the token record and the separate rights, obligations, or assets that the record is intended to represent.

Sources: ethereum.org · ethereum.org

Tokenomics is an informal term for the economic design of a cryptocurrency token. It includes how units are created, who receives them, when allocated tokens become transferable, what the token is used for, and whether supply can expand or contract. Relevant features can include maximum supply, ongoing issuance, vesting schedules, treasury holdings, fees, burns, governance rights, and reward programs. The term describes a framework for analysis rather than a guarantee that a project has a sustainable economy. A low circulating supply can look very different from the eventual supply after scheduled unlocks, while a burn mechanism can coexist with significant new minting. Token utility also needs to be distinguished from speculative demand or promises of future functionality. Understanding tokenomics means tracing actual incentives and control rights, including who can change them, rather than relying solely on a distribution chart or a headline yield figure.

Sources: docs.openzeppelin.com · blog.uniswap.org

A transaction fee is the amount paid to have a transaction processed under a blockchain's rules and fee market. For an ordinary Bitcoin transaction, it equals the total value of the inputs minus the total value assigned to outputs. Miners may claim those fees when the transaction is included in a valid block. Wallets commonly estimate an appropriate fee using transaction virtual size and a rate quoted in satoshis per virtual byte. The amount of BTC being transferred is not itself the main measure of required block space: input count, output structure, and spending conditions are important. A higher fee can improve a transaction's competitiveness but cannot promise an exact confirmation time. An exchange's withdrawal charge is also not necessarily identical to the on-chain fee it pays. Other blockchains use different mechanisms, including gas accounting, so fee terminology should be interpreted in network context.

Sources: developer.bitcoin.org · developer.bitcoin.org

A transaction identifier, commonly abbreviated TXID, is a hash-derived reference used to identify a cryptocurrency transaction. Bitcoin transactions can be looked up by TXID in a node or block explorer, and spending inputs refer to earlier outputs using the originating TXID together with an output index. A TXID is not a receiving address or a secret that authorizes spending. Its existence also does not prove confirmation, because a wallet can calculate an identifier before the transaction is mined or even broadcast. Bitcoin distinguishes the ordinary TXID from the witness transaction identifier for transactions using witness serialization. Changes to relevant transaction data can change the identifier, which matters when a wallet replaces an unconfirmed payment. When investigating a payment, verify the correct network, the actual recipient output, and its confirmation status rather than treating a pasted identifier or screenshot as complete evidence of settlement.

Sources: bitcoincore.org · github.com

An unspent transaction output is a previously created transaction output that remains available to be spent under its locking conditions. Bitcoin tracks spendable value through UTXOs rather than maintaining a conventional account balance for each address. Each output specifies an amount and spending requirements, while a later transaction consumes the complete output as an input and creates new outputs. A wallet's displayed balance generally summarizes the outputs it can identify and potentially spend, subject to confirmation, maturity, or other constraints. Selecting several small UTXOs can require more transaction data than selecting one larger output, affecting fees. Spending patterns can also reveal relationships between addresses. An output's presence in the UTXO set does not tell an observer who holds the necessary keys, and a wallet can watch an output without being able to spend it. UTXO management therefore connects accounting, transaction construction, cost, and privacy.

Sources: bitcoincore.org · developer.bitcoin.org

A cryptocurrency wallet is software, hardware, or a coordinated system that helps users manage addresses, view assets, and construct or authorize transactions. The familiar word can be misleading because coins are not literally stored inside the application; the blockchain records the relevant balances or spendable outputs, while the wallet manages information and access. Some wallets control private keys directly, some work with external signing devices, and watching-only wallets can display activity without spending authority. Custodial services may use the same label while keeping keys under the provider's control. Wallets also differ in supported networks, recovery standards, transaction features, and privacy behavior. A displayed balance does not prove that the user has every secret or configuration detail needed for recovery. Evaluating a wallet therefore involves identifying who can sign, how transactions are verified, what is backed up, and which dependencies remain if the usual interface becomes unavailable.

Sources: developer.bitcoin.org · ethereum.org

Wrapped bitcoin is a general description for tokens on another network that are intended to represent BTC held or controlled through a separate arrangement. WBTC is one named implementation, while other systems use different custody, signing, and redemption mechanisms. The representation allows Bitcoin-linked value to interact with applications that cannot directly spend native Bitcoin outputs. However, possessing a wrapped token is not the same as controlling the underlying BTC with a Bitcoin private key. The connection depends on the issuer, bridge, operators, reserves, contracts, and rules for minting and redemption. A target one-to-one relationship does not guarantee unrestricted redemption or identical market prices at all times. Users should distinguish the official token on a specified network from additional bridged copies and look-alike contracts. The important questions are who controls the backing, how its existence is demonstrated, and what process returns native BTC to the holder.

Sources: wbtc.network · docs.threshold.network

A zero-knowledge proof is a cryptographic method that lets a prover demonstrate that a statement is true without revealing the secret information used to establish it, beyond what the statement itself discloses. For example, a system can prove knowledge of a value satisfying specified conditions while keeping that value hidden. Blockchain applications use related proof systems for privacy and for verifying computations performed elsewhere. These are different goals: using a validity proof does not automatically make transaction amounts, identities, or application activity private. The proof also establishes only the precisely encoded statement, not the honesty of every external input or the quality of the broader system. Designs differ in proof size, verification cost, setup assumptions, and computational requirements. Zero-knowledge technology should therefore be evaluated through its actual guarantees and implementation rather than treated as a universal synonym for anonymity, correctness, or unlimited scalability.

Sources: ethereum.org