> For the complete documentation index, see [llms.txt](https://zkop.gitbook.io/whitepaper/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zkop.gitbook.io/whitepaper/zkop-whitepaper.md). # ZKOP WHITEPAPER
### Zero Knowledge Ownership Blockchain |

Privacy · Ownership · Interoperability · Intelligence

| | --------------------------------------------------------------------------------------- | ## Abstract | ZKOP is a blockchain built for mass adoption. It is an open source, permissionless chain that allows users to securely own, manage, and transact digital assets without reliance on centralized intermediaries. Through zero-knowledge proofs and selective disclosure, ZKOP ensures privacy while maintaining trust, compliance, and interoperability. Nobody owns ZKOP. The blockchain is secured by a decentralized network of validators and governed transparently by its community. Anyone can participate, operate a node, or earn rewards by validating the chain. With the latest evolution of the protocol, ZKOP now integrates three transformative capabilities: Guardian-Based Wallet Control for secure key recovery, an AI Assistant and Portfolio Intelligence Layer for smart user guidance, and a Private Social Interaction Layer enabling anonymous community participation. Together, these features position ZKOP as the most comprehensive privacy-first ecosystem in Web3. | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## Problem Despite the growing adoption of blockchain, several obstacles prevent the open web from reaching mainstream usage. ZKOP is designed to solve these challenges through selective privacy, simplified onboarding, and multichain interoperability. #### **a. Challenges in Traditional Web 2.0 Applications** * **Limited Decentralization:** Most users still rely on centralized platforms due to ease of use, while decentralized systems remain complex and intimidating. * **Platform Dominance:** Corporations control user data, dictate rules, and capture the majority of value, leaving contributors uncompensated. * **Privacy Exposure:** User information and transactions are stored and monetized without consent, creating risks of exploitation. * **Lack of True Ownership:** Identities, content, and financial activity remain under centralized custody, with little portability across platforms. #### **b. The Concept of the Open Web** The open web introduces a model where users directly own their digital assets, identity, and activity. It enables interaction with decentralized applications without intermediaries, ensuring privacy and fairness. Through selective disclosure, value flows back to participants instead of being extracted by central platforms. #### **c. Challenges in the Open Web** * **Onboarding Barriers:** Seed phrases, gas fees, and complex wallets discourage mainstream adoption. * **Validator Complexity:** High token requirements and technical setup limit participation in securing networks. * **Full Transparency:** Most blockchains expose balances and transactions publicly, discouraging institutional and private usage. * **Fraud and Compliance:** Decentralization makes KYC and fraud prevention difficult without privacy-preserving methods. * **Economic Instability:** Poorly designed token models remain prone to volatility and manipulation. ZKOP addresses these with account abstraction for simple onboarding, multiple validator classes to lower entry costs, zero-knowledge proofs for privacy and compliance, and a balanced tokenomics model ensuring long-term stability. ## Solution - ZKOP ZKOP is designed to redefine ownership, privacy, and interoperability in the Web3 ecosystem. By embedding zero-knowledge proofs and selective disclosure into its core, ZKOP empowers users to decide what information is visible on-chain while interacting with decentralized applications. ## **Core Components of ZKOP** ### **A. Selective Privacy** ZKOP introduces **Selective Privacy**, enabling users and applications to control what information is visible on-chain while keeping sensitive data protected. Instead of exposing all transaction details by default, ZKOP leverages zero-knowledge technology to allow verification without revealing underlying data, ensuring both confidentiality and trust. #### **Concept and Motivation** Traditional blockchains operate on full transparency, where all transaction data, wallet balances, and user activity are publicly accessible. While this ensures trustlessness, it creates significant limitations for real-world adoption, particularly for individuals, institutions, and enterprises that require confidentiality. On the other hand, fully private systems sacrifice auditability and verifiability, making compliance and trust more difficult. ZKOP addresses this gap through **Selective Privacy**, a model where privacy is **configurable, controlled, and provable**. Users are not forced into complete transparency or complete anonymity. Instead, they gain the ability to decide **what to reveal, when to reveal it, and to whom**. #### **1. Zero-Knowledge Verification** ZKOP uses zero-knowledge proofs to validate transactions without exposing sensitive data such as sender, receiver, or transaction amount. This ensures: * Transaction correctness is mathematically proven * Network consensus is maintained * Sensitive data remains confidential The blockchain verifies validity without requiring full data visibility. #### **2. Configurable Privacy Levels** Users and applications can define different levels of privacy depending on their needs. For example: * Fully private transactions * Partially disclosed data (e.g., amount hidden, sender visible) * Fully transparent transactions when required This flexibility allows ZKOP to support both individual users and enterprise-grade applications. #### **3. Controlled Disclosure** Selective Privacy enables users to reveal specific information when required, without exposing their entire transaction history. Through cryptographic proofs, users can: * Prove ownership of assets * Verify transaction validity * Share selective data with auditors, institutions, or counterparties This makes ZKOP suitable for **compliance, reporting, and regulated environments**. #### **4. Private State Commitments** ZKOP supports private state commitments, where transaction data is stored in an encrypted or hashed form while maintaining verifiability. This allows: * Secure data storage on-chain * Privacy-preserving smart contract interactions * Protection of user activity and balances Applications can build logic that operates on private data without revealing it publicly. #### **5. Developer-Level Privacy Integration** Selective Privacy is integrated at the protocol level, allowing developers to build applications with native privacy controls. Developers can: * Define visibility rules within smart contracts * Enable selective disclosure flows * Build privacy-first applications without external tools This creates a flexible environment for building **DeFi, identity systems, enterprise solutions, and SocialFi platforms**.
### B. Guardian-Based Wallet Control ZKOP introduces a guardian-based wallet system where users assign trusted entities to assist in recovery or controlled actions. Instead of relying on a single private key, wallets operate with predefined conditions i.e inactivity triggers, multi-approval thresholds, and time-locked recovery flows that collectively govern wallet behavior without ever exposing private keys directly. #### Concept and Motivation The loss of private keys remains one of the most critical unsolved problems in self-custodial blockchain adoption. Estimates suggest that 20% or more of all circulating Bitcoin is permanently inaccessible due to lost or forgotten keys. ZKOP's Guardian-Based Wallet Control directly addresses this gap, inspired by Account Abstraction (ERC-4337) principles and social recovery wallet design, extending these concepts natively into its Layer 1 architecture. Guardians are pre-approved entities i.e individuals, institutions, hardware devices, or smart contracts designated by the wallet owner at setup. Critically, guardians cannot unilaterally access funds or sign transactions. Their role is limited to co-approving specific recovery or emergency flows defined by the user. #### 1. Guardian Assignment When creating or upgrading a ZKOP wallet, the user defines a guardian set. This set can include personal contacts, other wallets, institutional custodians, or hardware security modules. Each guardian is assigned a weight or tier, and the user specifies the minimum approval threshold required for any recovery action to execute. #### 2. Multi-Guardian Approval System Recovery or emergency actions require a configurable quorum of guardian signatures — for example, a threshold of 3-of-5 guardians. No single guardian can override the others, and no guardian can access funds without the required threshold being met. All approval logic is enforced on-chain through ZKOP's smart contract layer, making the process transparent, auditable, and tamper-resistant. Guardian approvals are aggregated using threshold signature schemes (e.g., Shamir's Secret Sharing or multi-party computation), ensuring that no partial set of guardians can reconstruct the signing key or execute transactions independently. #### 3. Time-Locked Recovery All guardian-initiated recovery flows are subject to a mandatory time-lock window, configurable by the wallet owner (e.g., 48 hours to 7 days). During this window, the original owner can veto or cancel the recovery if they detect unauthorized attempts. Any guardian-initiated flow broadcasts an on-chain alert, giving the owner time to respond before the action finalizes. #### 4. Emergency Access Without Key Exposure In emergency scenarios — such as account compromise, hardware loss, or death — guardians can collectively approve asset transfer to a new wallet address. Crucially, this process does not reconstruct or expose the original private key. Instead, a new signing authority is established through the guardian approval, maintaining zero-knowledge security guarantees throughout. #### 5. Inactivity Triggers Users can configure inactivity-based triggers that automatically activate guardian oversight if the wallet has not been accessed for a specified period. This feature is particularly relevant for inheritance planning, long-term cold storage, or institutional treasury management.
### C. AI Assistant & Portfolio Intelligence Layer ZKOP integrates a native AI assistant that helps users understand and manage their on-chain activity privately. It explains transactions before execution, analyzes portfolio behavior, suggests optimal actions, and highlights privacy achievements, all without transmitting sensitive data to external systems. #### Concept and Motivation Blockchain interfaces have long been criticized for their complexity. Even experienced users frequently interact with contracts without fully understanding what a transaction will do, what gas it will consume, or what privacy implications it carries. ZKOP's AI layer is designed as a private-by-default assistant that understands on-chain context without transmitting raw wallet data to centralized inference servers. #### 1. Transaction Explanation Before Execution Before a user submits any transaction, ZKOP's AI assistant performs a pre-execution analysis. It decodes contract calldata, simulates expected outcomes, estimates gas costs, identifies potential risks such as reentrancy vulnerabilities or unexpected token approvals, and presents a plain-language summary of what the transaction will do. This dramatically reduces the risk of accidental approvals, phishing attacks via malicious contracts, and costly transaction errors. #### 2. Portfolio Insights and Behavioral Analysis The intelligence layer continuously analyzes wallet activity to surface actionable insights. Users receive personalized summaries of their asset distribution, historical transaction patterns, yield opportunities, and risk exposure. The AI identifies behavioral patterns — such as frequent high-gas transactions or suboptimal token swap routing — and suggests more efficient alternatives. #### 3. Privacy Optimization Guidance The assistant tracks the user's on-chain footprint and provides specific guidance on how to reduce address linkability, when to use shielded transaction pathways, and which interactions may inadvertently expose sensitive data. Users receive a dynamic privacy score based on their transaction patterns, with specific action items to improve it — making sophisticated privacy concepts accessible without technical expertise. #### 4. Cross-Chain Activity Intelligence The AI layer tracks cross-chain positions holistically, alerting users to bridging risks, liquidity conditions, and optimal timing for asset transfers. It also surfaces arbitrage opportunities and yield differentials across connected chains in a user-friendly format. #### 5. Private AI Inference Architecture ZKOP addresses data leakage concerns through a hybrid inference architecture: lightweight on-device models handle routine analysis using locally cached chain data, while more complex queries use zero-knowledge attested inference — where computations are performed on anonymized datasets and results are returned without exposing raw wallet details to external servers.
### D. Private Social Interaction Layer ZKOP introduces a native private social interaction layer where users can communicate, interact, and participate using anonymous cryptographic identities. Users are not linked to visible wallet addresses or real-world identities, and interactions such as messaging, community participation, and activity sharing remain private by default. #### Concept and Motivation The intersection of social interaction and blockchain — commonly referred to as SocialFi — represents one of the fastest growing verticals in the Web3 ecosystem. However, virtually all existing social blockchain platforms face a fundamental tension: social engagement naturally requires some form of identity, yet blockchain identity is inherently public, persistent, and linkable. ZKOP's Private Social Interaction Layer is architected to solve this problem at the protocol level. Using zero-knowledge identity commitments, end-to-end encrypted messaging, and anonymous community participation, ZKOP enables genuine social interaction without the panopticon of public wallet association. #### 1. Anonymous Profiles Not Linked to Public Wallet Data Each ZKOP user can generate one or more anonymous social identities — cryptographic personas that are mathematically unlinkable to their on-chain wallet address without explicit user disclosure. These identities are generated using ZK commitments: the user proves they control a valid ZKOP account without revealing which account it is. A user's social reputation, community participation history, and interaction record exist independently of their financial activity. #### 2. Private Messaging and Interaction ZKOP's social layer includes an end-to-end encrypted messaging protocol built on established cryptographic primitives (analogous to Signal's double-ratchet algorithm adapted for decentralized key management). Messages are encrypted client-side using the recipient's public key derived from their anonymous identity, routed through ZKOP's network without metadata exposure, and decryptable only by the intended recipient. #### 3. Community Participation Without Identity Exposure Users can join and participate in ZKOP communities — forums, DAOs, group chats, collaborative projects — using their anonymous identities. Community reputation systems track contributions without tying these to real identities or wallet addresses. Governance participation is particularly powerful: users can vote on ZKOP DAO proposals using anonymous ZK proofs of their validator or token-holder status, ensuring stake-weighted governance without revealing individual voting positions until the result is finalized. #### 4. Selective Identity Reveal Privacy on ZKOP's social layer is user-controlled. Selective disclosure mechanisms allow users to voluntarily reveal specific attributes when it serves their interests — for example, proving they hold above a certain token threshold to join a premium community, or demonstrating validator status to access governance discussions. A user can prove 'I am a ZKOP validator' without revealing which validator, or 'I have participated for over six months' without revealing their wallet address. #### 5. Anti-Sybil and Reputation Integrity ZKOP addresses Sybil resistance through ZK-based identity commitments tied to unique on-chain account creation, ensuring that each anonymous social profile corresponds to a distinct ZKOP account without revealing which account it is. Additional optional reputation mechanisms, such as on-chain activity age or staking proof, can be used by communities to set their own anti-Sybil thresholds. ## Architecture ZKOP is built as a layered ecosystem. The current architecture focuses on delivering real, usable products immediately, while the foundational infrastructure evolves in parallel toward a full Layer 1 blockchain.
LayerDescriptionStatus
Ethereum Launch LayerToken launch and initial liquidity on Ethereum. Fair distribution with no presale.Active
Application LayerzkVault privacy tools, AI Assistant, Guardian Wallet, and Private Interaction Layer.In Development
Future L1 InfrastructurePrivacy-first Layer 1 blockchain with validator participation and ZK execution.Roadmap
## **Future Infrastructure** ### **ZKOP Layer 1** ZKOP is designed to evolve into a **privacy-first Layer 1 blockchain with EVM compatibility**, enabling developers to build scalable applications with native support for selective privacy and zero-knowledge verification. The future architecture will leverage a **Proof of Stake (PoS) consensus model** to ensure energy efficiency, scalability, and secure network participation through validators. **ZKOP’s validator ecosystem** is planned to support both **standard staking and flexible participation models**, enabling broader accessibility while maintaining decentralization and network security. This infrastructure will form the foundation for integrating **privacy, intelligent systems, and scalable application development** within a unified blockchain environment. ### Validator Model The Layer 1 will support two validator classes to maximize accessibility and decentralization. #### 1) Standard Validators Standard Validators are the primary operators who secure the chain by validating transactions, proposing blocks, and maintaining consensus integrity. They must meet defined staking minimums and hardware requirements, and run the official ZKOP client software. #### 2) Fluid Staking Validators Fluid Validators utilize ZKOP's liquid staking system, focusing on flexible and accessible participation. They enable efficient network contribution while maintaining liquidity, without requiring high token holdings or advanced technical expertise. ### Consensus Protocol Mechanics The ZKOP Proof of Stake consensus mechanism ensures fair validator selection, block proposal, validation, and distribution of rewards, while penalizing malicious behavior to maintain the integrity of the blockchain. {% stepper %} {% step %} #### Validator Selection Validators are chosen based on the proportion of tokens they have staked relative to the total stake in the network. This probabilistic selection ensures proportional but randomized participation, preventing stake concentration from dominating block proposals. | Formula | | ------------------------------------------------------------------------------------------------------------------------------------------------------ | |

P(i) = Si / Stotal

| |

P(i) = probability that validator i is selected
Si = stake of validator i
Stotal = total active stake in the system

| | {% endstep %} | {% step %} #### Block Proposal A validator is eligible to propose a block if its selection probability satisfies a randomly generated threshold r (a random number between 0 and 1). The selected validator then proposes block B(t), containing a set of valid transactions {T1, T2, ..., Tn}. | Formula | | ---------------------------------------------------------------------------------------------------------------------------------------------------- | |

P(i, t) = True if Si/ Stotal ≥ r

| | {% endstep %} | {% step %} #### Block Validation Other validators verify the correctness of the proposed block by checking transaction validity, state transitions, and consensus rules. A supermajority of validator signatures is required to advance block finalization. | Formula | | --------------------------------------------------------------------------------------------------------------------------------------------------------- | |

V(Bi(t)) = Valid ⟹ Bi(t) ∈ Blockchain

| | {% endstep %} | {% step %} #### Slashing Conditions If a validator acts maliciously or proposes an invalid block, its stake is reduced proportionally. Slashing discourages double-signing, equivocation, and other protocol violations by imposing direct financial penalties. | Formula | | ------------------------------------------------------------------------------------------------------------------------------------- | |

S'i= Si × (1 − σ)

| |

S'i = remaining stake after slashing
σ = slashing percentage

| | {% endstep %} | {% step %} #### Rewards Distribution Validators receive rewards for correctly proposing or validating blocks. Rewards are allocated proportionally based on stake weight and participation rate, gradually diminishing over time to align with long-term fee-based sustainability. | Formula | | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | |

Ri = FB + RB

| |

Ri = reward of validator i
FB = total fees in the block
RB = block reward

| The validator's updated stake becomes: | Formula | | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | |

S'i = Si + Ri

| | {% endstep %} | {% step %} #### Finality Mechanism A block is considered finalized when validated by a supermajority of validators. This ensures economic finality, making chain reorganizations prohibitively costly and providing users with reliable transaction confirmation. | Formula | | | | | | ---------------- | ----------------------------------------------- | ------------------------------------------------ | --------------------------------------------------- | -------------------------------------------------------------------------- | |

| VB | ≥ α × | Vtotal |

| |

| VB | = number of validators who validated block B
| Vtotal | = total validators in the network
α = supermajority threshold (≥ ⅔)

| | {% endstep %} | | | | | | {% endstepper %} | | | | | ### ZKOP Governance ZKOP is governed by a decentralized autonomous organization (DAO), ensuring that decisions are transparent, inclusive, and fair. Governance rights are linked to validator participation and token staking, giving all stakeholders a voice in the blockchain's evolution. The DAO manages proposals, community voting, and the execution of key upgrades. Areas of control include treasury allocation, validator parameters, and privacy frameworks. Guardian wallet configurations, AI layer policies, and social layer community standards are also subject to DAO governance, ensuring that new features evolve in alignment with community values. As ZKOP matures, governance will expand to include more community stakeholders, ensuring the blockchain evolves in a decentralized and adaptive manner.
## **ZKOP Tokenomics** The ZKOP token is designed to support network security, ecosystem growth, and long-term sustainability. #### **Total Supply:** 1,000,000,000 ZKOP
#### **Distribution:** | **Allocation Category** | **Percentage** | **Amount (ZKOP)** | | ------------------------------- | -------------- | ----------------- | | Public Distribution & Liquidity | 50% | 500,000,000 | | Ecosystem | 20% | 200,000,000 | | Marketing | 10% | 100,000,000 | | Team (vesting) | 10% | 100,000,000 | | Reserve | 10% | 100,000,000 | | Total Supply | 100% | 1,000,000,000 | * **Public Distribution & Liquidity**\ Allocated for fair launch participation and liquidity provisioning to ensure accessibility and market stability. * **Ecosystem**\ Reserved for developer incentives, partnerships, grants, and overall ecosystem expansion. * **Marketing**\ Dedicated to growth initiatives, community building, and global awareness. * **Team (Vesting)**\ Allocated to the core team with a structured vesting schedule to ensure long-term alignment. * **Reserve**\ Held for future strategic needs, protocol upgrades, and unforeseen opportunities. The token distribution is structured to promote **fair access, sustainable growth, and long-term ecosystem development**. ## **Launch Model** ZKOP follows a **fair launch model on Ethereum**, with **no presale and no private allocations**.\ This approach ensures open participation, transparent distribution, and equal opportunity for all participants from the outset. ## **Roadmap** The ZKOP roadmap outlines a phased approach focused on building a robust privacy-first ecosystem, integrating intelligent features, and scaling toward a fully operational blockchain network.
#### **Phase 1 - Launch & zkVault Beta (Q2 2025)** Initial launch of the ZKOP platform with the introduction of **zkVault Beta**, enabling early users to experience core privacy functionalities and foundational infrastructure. #### **Phase 2 - AI Assistant & Platform (Q3 2025)** Deployment of the **AI Assistant and Portfolio Intelligence Layer**, enhancing user experience through transaction insights, portfolio analysis, and intelligent guidance across the platform. #### **Phase 3 - Ecosystem Expansion & Grants (Q4 2025)** Expansion of the ZKOP ecosystem through **developer grants, partnerships, and community initiatives**, driving adoption and encouraging application development. #### **Phase 4 - Privacy & Intelligence Expansion (Q1 2026)** Further enhancement of **privacy mechanisms and AI capabilities**, strengthening selective disclosure, user control, and intelligent interaction across the network. #### **Phase 5 - ZKOP Chain Development (Q2–Q3 2026)** Advanced development of the **ZKOP blockchain infrastructure**, focusing on scalability, performance optimization, and full integration of core protocol features. #### **Phase 6 - Mainnet & Network Evolution (2027+)** Launch of the **ZKOP Mainnet**, followed by continuous network upgrades, governance expansion, and long-term ecosystem evolution. ## Vision ZKOP aims to become a leading privacy-first blockchain ecosystem that enables secure participation in the open web with selective privacy and data ownership at its core. It ensures that individuals and institutions can operate transparently while keeping sensitive information private. The blockchain would reward contributions in development, validation, and usage while eliminating reliance on centralized entities. ZKOP's vision is shaped by adaptability, sustainability, and openness, with future technical papers expanding details as the mainnet evolves. ## Disclaimers This whitepaper is provided for informational purposes only and does not constitute financial, legal, or investment advice. It should not be considered an offer or solicitation to buy or sell tokens or securities of any kind. Readers should consult professional advisors before engaging in related activities. This document may include forward-looking statements that are subject to risks and uncertainties. These statements reflect the vision of the ZKOP team at the time of publication and are not guarantees of future results. Actual outcomes may differ materially. ZKOP assumes no obligation to update this paper unless required by law and disclaims liability from reliance on it. ## Risks and Considerations Participation in the ZKOP blockchain involves exposure to financial, regulatory, technical, and market risks. The following points highlight potential challenges that stakeholders should carefully evaluate before engaging with the ecosystem. **a. Financial Risks** The ZKOP token is subject to significant price volatility. Market conditions, liquidity availability, and external economic events may impact its value. Staking returns cannot be guaranteed. **b. Regulatory Risks** The regulatory landscape for digital assets, zero-knowledge technologies, and decentralized blockchains is still evolving. Future legislation or jurisdictional restrictions could affect the operations, token utility, or accessibility of ZKOP. Privacy-preserving features and anonymous social interactions may be subject to additional regulatory scrutiny in some jurisdictions. **c. Technological Risks** Although ZKOP undergoes security audits and employs advanced cryptography, vulnerabilities may still exist in smart contracts, consensus layers, or bridge mechanisms. Failures in zero-knowledge circuits, guardian contract logic, AI inference components, or social layer encryption could impact blockchain stability and user privacy. **d. Market Risks** The adoption and value of ZKOP depend heavily on ecosystem usage, liquidity, and broader blockchain industry trends. Competition from other Layer 1 chains, fluctuations in demand, or unfavorable macroeconomic conditions may affect growth and long-term sustainability. **e. Liability and Legal** ZKOP and its contributors are not responsible for financial losses arising from token participation, validator operations, or reliance on the information in this whitepaper. Participants are advised to seek independent legal, financial, and tax advice prior to involvement. Distribution of this document may be restricted in certain jurisdictions, and recipients are solely responsible for compliance with applicable laws. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://zkop.gitbook.io/whitepaper/zkop-whitepaper.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.