Glossary

A

Address Reuse Using the same wallet address across multiple transactions. On public blockchains, this enables observers to link activity over time. INVSBL is designed so transaction execution does not rely on reusable public identifiers.

Anonymity Set The group of potential participants among which a transaction sender or receiver cannot be distinguished. Some privacy systems rely on anonymity set size. INVSBL does not expose information that allows transaction participants to be narrowed through set analysis.

Asset Sufficiency Confirmation that a sender has enough balance to complete a transaction. In INVSBL, this is validated using cryptographic proofs without revealing balances.

Authorization Proof that an entity is permitted to move specific assets. INVSBL validates authorization without exposing wallet identities or ownership details.


B

Base Blockchain (Base Layer) The underlying blockchain on which transactions are settled, such as Solana or EVM networks (Base, Ethereum). The base layer provides consensus, security, and finality.

Block Explorer A public interface for viewing blockchain activity. INVSBL transactions appear as valid on-chain activity but do not expose transaction context such as participants or amounts.


C

Compatibility The ability to work with existing wallets, assets, and infrastructure. INVSBL preserves native asset standards and execution environments.

Consensus The process by which a blockchain network agrees on transaction validity and ordering. INVSBL relies on the consensus mechanisms of the underlying chain.

Counterparty The other participant in a transaction. On public blockchains, counterparty relationships are visible. INVSBL is designed so counterparties cannot be determined from on-chain data.

Cryptographic Proof Mathematical evidence that a condition is satisfied without revealing the underlying data. INVSBL uses cryptographic proofs to validate transactions while limiting information disclosure.


D

Decoupling Separating information that is normally linked together, such as sender, receiver, amount, and transaction history. INVSBL is designed to avoid exposing these linkages.


F

Finality The point at which a transaction is confirmed and cannot be reversed. INVSBL transactions reach finality through the underlying blockchain.


I

Inference The process of deriving private information from public data, such as linking addresses through patterns. INVSBL limits publicly observable data used for inference.

Identity Graph A model built from transaction data to map relationships between entities. INVSBL is designed so transaction data does not support identity graph construction.


M

Metadata Information about a transaction beyond basic validity, such as timing, frequency, and relationships. Public blockchains expose extensive metadata. INVSBL limits metadata exposure.

Metadata Leakage Unintended disclosure of transaction information through patterns or correlations. INVSBL is designed to reduce observable metadata that enables such analysis.

Mixer A service that pools and redistributes funds to obscure transaction trails. Mixers rely on anonymity sets and timing assumptions. INVSBL does not pool funds or operate as a mixer.


O

On-Chain Data recorded directly on a blockchain and verified by the network. INVSBL transactions are settled on-chain while limiting what contextual information is visible.

Obfuscation A technique that hides information by making it harder to interpret, rather than by removing it entirely. Obfuscation often relies on noise, aggregation, timing delays, or probabilistic assumptions.

In blockchain systems, obfuscation may reduce clarity but still leaves data available for analysis over time.

Observability The ability to view and analyze transaction details. Public blockchains are highly observable. INVSBL reduces observability of transaction context while preserving verifiability.


P

Privacy by Default A design approach where transactions are handled consistently without requiring users to enable special modes. INVSBL applies the same execution model to all transactions.

Pseudonymous Using identifiers such as wallet addresses instead of real names. Pseudonymity still allows activity tracking. INVSBL aims to reduce address-based tracking.


R

Retrospective Analysis Analyzing historical blockchain data to identify patterns or link activity over time. INVSBL is designed to limit the usefulness of retrospective analysis.


S

Stealth Address A one-time address used to prevent address reuse. INVSBL avoids reliance on reusable public addresses through its transaction design.

Surveillance Infrastructure Systems that collect and analyze long-term behavioral data. Public blockchains enable large-scale transaction monitoring. INVSBL reduces the amount of data available for such analysis.


T

Timing Correlation Linking transactions based on when they occur. INVSBL is designed to limit timing-based inference.

Transaction Graph A network of transactions and relationships used for analysis. INVSBL transactions do not expose the information needed to build meaningful transaction graphs.

Transaction History A record of past transactions associated with an address. INVSBL transactions are not linked to reusable identifiers.

Transaction Lifecycle The stages a transaction passes through from initiation to settlement. INVSBL limits exposure throughout execution.

Transparent Transaction A transaction where sender, receiver, and amount are publicly visible. INVSBL does not expose full transaction context.


U

Unlinkable Describes transactions that cannot be reliably connected to each other or to the same participant based on available data.


V

Verifiability The ability for a network to confirm transaction correctness. INVSBL preserves verifiability while limiting what is observable.


Z

Zero-Knowledge Proof (ZKP) A cryptographic method that allows verification of a statement without revealing the underlying data. INVSBL uses zero-knowledge proofs to validate transactions.

zk-SNARK A compact zero-knowledge proof system used in some privacy protocols. Specific implementations vary by system.

zk-STARK A zero-knowledge proof system that avoids trusted setup and is scalable, with different performance trade-offs.

Last updated