# What is Proof of Stake? ## 1. Definition **Proof of Stake (PoS)** is a consensus protocol used by blockchain networks to secure the system, validate transactions, and produce new blocks. Unlike **Proof of Work (PoW)**, which relies on computational power, PoS assigns validation rights to participants—called validators—based on the amount of cryptocurrency they lock (stake) into the network. In this model, the probability of being selected to validate or propose a block increases proportionally with the amount staked. This approach dramatically reduces energy consumption and supports greater scalability compared to traditional PoW systems. To maintain network integrity, validators are held accountable: if they act maliciously or fail to fulfill their duties, they risk losing a portion of their stake as a penalty. ## 2. Core components | **Component** | **Description** | | ------------------ | ----------------------------------------------------------------------------- | | **Validators** | Participants who lock up coins to secure the network and validate blocks. | | **Block Proposal** | Validators are pseudo-randomly chosen to propose the next block. | | **Attestation** | Other validators vote to confirm the proposed block is valid. | | **Finality** | When a block becomes irreversible, often after multiple confirmations. | | **Stake** | The amount of cryptocurrency a validator locks in the protocol as collateral. | ## 3. How it works **Proof of Stake (PoS)** operates through a structured series of steps that ensure secure, decentralized, and efficient block production. It replaces the energy-intensive mining process of Proof of Work with a more scalable, capital-based model. Here’s how it works in most modern PoS systems: ### **3.1. Staking** Users lock a certain amount of cryptocurrency (e.g., ICBX) into a smart contract to become eligible for participation as validators. This process is called **staking**. Key aspects include: **Minimum stake requirement**: Networks may set a minimum token amount required to participate. **Lock-up period**: Tokens are locked for a defined period, during which they cannot be withdrawn. **Delegation (in some systems)**: Users can delegate their tokens to trusted validators without directly validating blocks themselves. The more a validator (or their delegators) stake, the higher the chance of being selected to produce or validate blocks. ### **3.2. Validator Selection** Validators are selected to propose or attest to new blocks based on a **weighted random selection**. The most common factors include: **Randomness**: Many networks use a Verifiable Random Function (VRF) or RANDAO to introduce cryptographic randomness. **Amount staked**: Higher stakes increase the chances of being selected. **Staking duration or history**: Some networks factor in how long tokens have been staked or validator reliability. **Performance score**: Past behavior (uptime, correctness) may impact selection weight. ### **3.3. Block Proposal and Voting** Once selected: The **proposer** creates a block containing transactions and metadata. A **committee of validators (attesters)** vote on whether the proposed block is valid. If a **quorum** is reached (i.e., enough validators attest), the block is added to the chain. This process ensures Byzantine Fault Tolerance (BFT), where the system remains secure even if a minority of validators behave maliciously. ### **3.4. Rewards** Validators are compensated for their work through: **Transaction fees**: Collected from users who include them in their transactions. **Block rewards**: Newly minted tokens, if the protocol supports inflationary rewards. **MEV (Miner/Validator Extractable Value)**: In some cases, validators can prioritize high-value transactions for additional income. Rewards are often distributed proportionally based on stake and **validator uptime** or **performance metrics**. ### **3.5. Slashing (Penalties)** To maintain network trust and accountability, PoS includes a **slashing mechanism**: Validators who act maliciously (e.g., **double-signing**, **surround voting**, or proposing invalid blocks) are penalized. Penalties range from **minor loss of rewards** to **partial or total loss of staked tokens**. Validators who are **offline or non-responsive** for long periods may be **ejected** from the active set or **fined**. ## 4. Advantages of Proof of Stake ### **4.1. High Throughput for Scalable Applications** PoS accelerates transaction processing and supports higher data capacity across the network. This makes it particularly effective for platforms that require rapid execution and can handle large transaction volumes, such as DeFi, gaming, and real-time applications. ### **4.2. Instant Transaction Finality** Through validator consensus, blocks achieve finality almost instantly without requiring multiple confirmations. This provides fast, seamless transaction approvals with strong consistency and security guarantees. ### **4.3. Minimal Resource Usage** By removing the need for energy-intensive mining, PoS dramatically reduces energy consumption. Its lightweight and efficient design is environmentally sustainable while maintaining high security. ### **4.4. Fair and Adaptive Incentive Structure** Validator rewards are distributed through a collective and transparent model that aligns incentives with active participation. This fair structure encourages decentralization and fosters long-term network engagement. ### **4.5. Decentralized Governance and Decision-Making** Token holders can participate in selecting validators and influencing protocol upgrades. This delegation-based governance model supports informed decision-making, increases operational resilience, and strengthens overall protocol integrity. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.icb.network/getting-started/technical-overview/what-is-proof-of-stake.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.