# Welcome To Viper Network ## Overview Viper Network introduces a decentralized, incentivized RPC infrastructure to address a critical gap in the Web3 ecosystem: the lack of rewards for RPC nodes. Unlike validators, RPC nodes are natively unrewarded, discouraging participation and scalability. This has led to over-reliance on centralized Node-as-a-Service platforms and rate-limited public nodes, creating vulnerabilities and single points of failure for blockchain interactions. As new Layer 1s, Layer 2s, and rollups emerge, dApps on these chains require seamless infrastructure to interact with them. However, building and scaling support for such a diverse and expanding ecosystem is a complex challenge, beyond the capabilities of centralized solutions. Web3 needs a high-performance, decentralized interaction layer to ensure scalability and resilience—an inevitability for the multichain future. This doc outlines the Viper Network's approach to solving these challenges through incentivization, scalability, and a trustless infrastructure while highlighting its design mechanisms and vision for the decentralized Web3 ecosystem. #### **Understanding Blockchain Interactions and the Role of RPC** Before we dive into what we’re building at Viper, let’s take a moment to understand **how blockchain interactions work** and the crucial role that RPC plays in enabling them. At its core, a blockchain is a **distributed database**—imagine it as a global Excel file maintained by thousands of interconnected servers, called **nodes**, spread across the world. All these nodes collectively agree on the content of this file, ensuring that the data remains consistent, secure, and immutable. But here’s the catch: **how do you access this distributed database?**\ You can’t just open it on your computer because you don’t have the file locally. Instead, you need to interact with a server or an **RPC node** that holds the file. Every interaction you have with a blockchain—whether it’s checking your account balance, reading smart contract data, or sending a transaction—requires you to communicate with these RPC nodes. Think of them as the **pipeline** connecting the outside world (your application, wallet, or dApp) to the underlying blockchain infrastructure. #### **What is RPC?** RPC, or **Remote Procedure Call**, is the communication protocol that powers this interaction. It allows your computer to send queries (like *What’s my account balance?*) to an RPC node and receive responses. Essentially, RPC nodes act as translators between your requests and the blockchain’s data, enabling seamless communication between users and decentralized networks. In essence, RPC is what makes **blockchain usability possible**, forming the backbone of every interaction with the network. This vital role highlights why reliable and scalable RPC infrastructure is critical for the growth and adoption of Web3 applications.
## Quick links {% content-ref url="/pages/wHFVOZx9q76XySOsGyKP" %} [The Problem](/introduction/the-problem) {% endcontent-ref %} {% content-ref url="/pages/dIOSN666BdOJ7x8CNWSU" %} [Viper Network](/introduction/viper-network) {% endcontent-ref %} ## Get Started We've put together some helpful guides for you to get set up with our product quickly and easily. {% content-ref url="/pages/M1o3seef2rDiDOqJN2Ax" %} [Design](/protocol/design) {% endcontent-ref %} {% content-ref url="/pages/rVpqDuGvAw5G6NJ9XgTI" %} [Economics](/protocol/economics) {% endcontent-ref %} {% content-ref url="/pages/Yn2BlpXR4XSEzjmfsJqH" %} [Governance](/protocol/governance) {% endcontent-ref %} # The Problem ### Challenges In Bootstrapping RPC Nodes Launching a blockchain requires bootstrapping two key components: validators and RPC nodes. Validators have inherent rewards, making their onboarding easier. However, RPC nodes lack such incentives, posing a significant challenge. Without rewards, node operators have no motivation to contribute compute power or scale their infrastructure. To compensate, many chains run their own RPC nodes as public endpoints, offering free access. These public nodes, however, are neither scalable nor reliable for production use. This gap has fueled the adoption of centralized RPC providers, but these services come with several drawbacks and primarily focus on supporting a handful of top-performing chains, leaving others underserved.

No Inherent Rewards For RPC Nodes From The Chain

### The Drawbacks Of Centralized Providers Centralized RPC providers have gained traction due to their convenience and ease of integration. However, they fall short of meeting the critical demands of a decentralized ecosystem. Their inherent limitations not only compromise the core principles of Web3—**decentralization, trustlessness, and resilience**—but also present significant scalability and security challenges. *** **1. Scalability and Coverage** Centralized providers often prioritize only the most prominent Layer 1 blockchains (like Ethereum) or widely adopted Layer 2 scaling solutions, such as Optimism and Arbitrum. This leaves emerging Layer 1s, Layer 2s, and rollups without sufficient RPC infrastructure, creating a **bottleneck for adoption**. For newer chains, bootstrapping RPC infrastructure is both time-consuming and resource-intensive. Without support from centralized providers, dApps on these chains face challenges in providing reliable and scalable services to their users. Furthermore, centralized platforms struggle to scale effectively as the multichain ecosystem expands, leaving a fragmented infrastructure landscape. *** **2. Security Concerns** Centralized RPC platforms are inherently vulnerable to **single points of failure**, making them attractive targets for attackers. Over the years, various security incidents have highlighted their fragility: * **Privacy Leaks**: Centralized platforms have been known to collect and potentially sell user data to third parties, including bots and analytics services, violating the privacy expectations of Web3 users. * **DNS Hijacking**: Domain Name System (DNS) attacks have compromised RPC endpoints, redirecting users to malicious servers that steal data or funds. * **Censorship**: Centralized providers are susceptible to external pressures, such as government regulations or corporate policies, which could lead to censorship of certain transactions or applications. These vulnerabilities directly contradict Web3’s vision of **trustless interactions**, where users should be able to interact with the blockchain securely and without intermediaries. *** **3. Reliability** One of the most glaring issues with centralized RPC providers is their **unreliability during high-traffic events**. Major blockchain events, such as NFT drops or token launches, often overwhelm their infrastructure, leading to **frequent downtimes**. This disrupts user experiences and causes significant losses for dApps reliant on these platforms. The reliance on centralized infrastructure also makes entire dApps vulnerable to a single provider's performance. If an RPC provider experiences downtime, the dApps using their services effectively become unusable, breaking the trust of their user base. *** **4. Data Integrity and Trust Issues** In Web3, where trustless interactions are paramount, centralized RPC providers create **uncertainty around data integrity**: * **Accuracy Concerns**: Users have no visibility into whether the data returned by these providers is accurate or tampered with. * **Opaque Processes**: The centralized nature of these platforms means users must place **blind trust** in their operations, undermining the transparency expected in a decentralized ecosystem. For example, centralized RPC providers could theoretically censor or modify data being sent to users, impacting dApps that rely on precise blockchain information. This introduces risks of **transaction manipulation** and **misinformation**, which are unacceptable in critical financial or governance applications. *** **5. Misalignment with Web3 Principles** Web3 was designed to eliminate intermediaries and empower individuals to interact with decentralized systems in a **trustless and transparent** manner. However, centralized RPC providers reintroduce many of the issues Web3 sought to solve: * **Centralized Gatekeeping**: A small group of providers controls access to the blockchain, consolidating power and influence. * **Lack of Decentralization**: Their existence as central hubs creates choke points that could cripple the ecosystem if exploited. This fundamental misalignment indicates that **centralized RPC providers are not a sustainable solution** for Web3’s infrastructure needs. ### The Complex Challenge Of A Multichain Future As more Layer 1s, Layer 2s, and rollups are launched, the need for seamless interactions between dApps and their respective chains continues to grow. However, building infrastructure support for every chain is a monumental challenge. Each chain comes with unique architectures, requiring tailored solutions that centralized platforms cannot scale to meet. The fragmentation across chains and their infrastructures has created a bottleneck, preventing Web3 from realizing its full potential. A scalable, decentralized RPC interaction layer is not just beneficial—it is inevitable for the multichain era. # Viper Network Viper is an ultimate **Incentivization Layer** for RPC nodes, designed for the **multichain future**, leveraging Decentralized Physical Infrastructure Networks **(DePIN)** to create a **globally distributed, decentralized, trustless, and high-performance RPC interaction layer** for Web3 applications. The backbone of this system is our **Reputation Protocol**, which evaluates and rewards nodes based on their **Work and Quality of Service (QoS)** metrics, such as latency, reliability, and availability. This ensures that node operators are incentivized not only to participate but to continuously improve their service quality. By introducing this incentive-driven model, Viper addresses the limitations of centralized providers while staying true to Web3’s principles of decentralization and trustlessness.

Viper Overview

### Features of Viper Network **Multi-Chain Support** Viper is built to support the growing multichain ecosystem by enabling any blockchain—whether Layer 1, Layer 2, or rollup—to bootstrap its RPC nodes seamlessly. The protocol manages the incentivization of node operators, ensuring that chains can focus on scaling and innovation while Viper takes care of the infrastructure and rewards needed to maintain reliable RPC services. **Decentralization for Security** * **Geo-Distributed Nodes:** Nodes are distributed across different locations, reducing the risks associated with single points of failure. * **Session Tumbling:** Nodes are pseudorandomly paired and rotated periodically, ensuring no single node remains a permanent point of access for any application. This mechanism prevents targeted attacks and enhances the network’s resilience.

Session Tumbling

**Reliable and Fault-Tolerant Network** * **Performance-Driven Node Selection:** Nodes are prioritized based on their Quality of Service (QoS) scores, measured by metrics like latency, availability, and reliability.

Performance Based Node Selection

* **Penalties for Underperformance:** Nodes that fail to meet QoS standards are penalized, ensuring high service quality across the network. * **Fault Tolerance:** Even if 1/3rd of the network goes down, the system continues to operate seamlessly without disruption, ensuring network stability and resilience. **Optimized for Speed, Accuracy, and Efficiency** * **Geo-Localized Node Access:** Users are connected to the nearest available node, reducing response times. * **Fishermen Monitoring:** Fishermen act as masked clients, sending sample relays to evaluate each node’s uptime, speed, and reliability. The resulting report card scores influence future node selection and determine the share of rewards a node receives, incentivizing consistent high performance.

Fisherman Monitering

**Cost Efficiency and Predictability** * #### **Minimal Operational Costs** Viper Network achieves **minimal operational costs** by optimizing both resource utilization and network economics. * **Off-the-Shelf Hardware**: Node runners utilize readily available hardware, eliminating the need for expensive custom infrastructure. * **Reduced Labour Costs**: With plug-and-play hardware, automated coordination, and easy-to-follow tutorials, the onboarding and operational processes are streamlined, reducing dependency on technical expertise. * **No Real Estate Costs**: Nodes can be deployed on personal property, removing the need for dedicated facilities and associated expenses. * **Global Access**: Viper’s decentralized model enables anyone, anywhere, to participate in the network, promoting inclusivity and scalability. * **Pay-As-You-Go Model**: Users pay a constant base rate based on relay volume, ensuring predictable and efficient cost structures. This efficiency is further amplified by **multi-instance support**, which allows multiple nodes to share computational resources. This maximizes performance while minimizing the operational costs for individual node operators. * **USD-Pegged Pricing:** Existing decentralized services require an unpredictable budget due to token price volatility. At Viper the cost per relay is pegged to USD, ensuring predictable and stable pricing for users. # Design ### Key Actors The VIPR Network is powered by a diverse set of actors who ensure its efficiency, reliability, and decentralization: * **Servicers (Nodes)** are responsible for providing decentralized infrastructure services. To participate, they must stake a portion of VIPR tokens, which serves as a commitment to maintaining quality and reliability. Their earnings are determined by the throughput they serve and the quality of their services, as measured by the network. * **Validators** verify relay proofs and the report cards submitted by Servicers and Fishermen, ensuring the accuracy of reported metrics such as throughput and quality scores. Their role is critical for maintaining the integrity of the network. * **Requestors (Clients)** are entities seeking to utilize the network’s decentralized services. They stake VIPR tokens as a commitment, the amount staked and the USD value of tokens at the time of staking determines the level of throughput they can access. This staking mechanism ensures fairness and prioritization of resources. * **Fishermen** act as quality auditors, evaluating the performance of Servicers by sending sample relays. They measure key metrics like availability and latency, ensuring that Servicers meet the required Quality of Service (QoS) standards. * **Token Holders** can stake or delegate their tokens to Servicers or Validators, participate in on-chain governance decisions, or hold the token as an investment, benefiting from its potential value appreciation. * **Chains** partnering with Viper receive a small portion of rewards for driving traffic to the network and promoting its use within their communities. This creates a mutually beneficial relationship, incentivizing adoption across the blockchain ecosystem. ### Viper Network Flow 1. [**Requestor and Servicer Staking**](/protocol/economics/stake): * **Requestors**: Entities seeking decentralized infrastructure services stake the native token to access services, determining their throughput level. * **Servicers**: Nodes offering services stake the native token, committing to network participation and ensuring service quality.

Requestor & Servicer Staking

2. [**Session Pairing**](/protocol/design/pair)**:** * Once staking is complete, **Requestors**, **Servicers**, and a **Fisherman** are dynamically paired to form a session. * Fishermen act as **shadow clients**, monitoring Servicers’ performance throughout the session. * This dynamic pairing ensures a balanced and randomized service model that prevents favouritism and exploitation.

Interaction

2. [**Servicing Interactions**](/protocol/design/service)**:** * During the session, Servicers fulfil service requests from Requestors through peer-to-peer (P2P) interactions. * Every serviced relay generates a **proof**, stored locally by the Servicer until the session concludes. 4. **Proof Submission:** * At the session's conclusion, Servicers submit relay proofs ([Commit Tx](/protocol/design/finality#transactions)) and Fishermen submit the report cards of the servicers in that particular session ([ReportCard Tx](/protocol/design/finality#transactions)) to the blockchain. * This submission encapsulates the essence of the service interactions and the Quality of Service (QoS) provided. 5. **Validation by Validators:** * Validators verify the submitted proofs and the report card([Verify Tx](/protocol/design/finality#transactions)) evaluating both the volume of relays served and the Servicer's performance quality. * This stage ensures the accuracy and integrity of the transactions and interactions within the network. 6. [**Incentives and Rewards**](/protocol/economics/reward)**:** * Servicers are rewarded with an amount of the native token, directly proportional to the volume of service provided and their performance scores, as determined by the Fishermen * This incentivization drives Servicers to consistently deliver high-quality services to Requestors, maintaining a robust network.

Proof, Report Submission and Incentivization

7. **Session Renewal:** * At the conclusion of a session, a new one is dynamically generated. * This cyclical renewal perpetuates network activity and ensures the continuous availability of decentralized infrastructure services, keeping the ecosystem active and scalable. 8. **Withdrawal and Conclusion:** * Requestors or Servicers, upon deciding to withdraw from the Viper Network, initiate the unstaking process. * Unstaking effectively unregisters them from the network, and the staked tokens are returned to their respective accounts. # Pair The **Viper Network** introduces a **session-based approach** to regulate interactions between **Requestors (clients)** and **Servicers**. This mechanism ensures a dynamic, efficient, and fair distribution of tasks while maintaining the network's integrity and performance. ### Session **Sessions in Viper Network** In Viper Network, **sessions** represent the temporary relationship between a **Requestor** and a set of **pseudorandomly** selected **Servicers**. These sessions are created to facilitate the exchange of **relay services**—the process through which the Requestor sends requests to Servicers for data processing, transactions, or blockchain interactions. Each session is designed to: * **Establish a pairing** between the Requestor and a specific group of Servicers. * Assign servicers based on **non-native chain requirements** (i.e., the specific blockchain the Requestor wants to interact with) and the **geo zone** that aligns with the Requestor’s location or service needs. This geographical selection helps ensure low latency. * Operate for a **predefined duration**, allowing sufficient time for requests to be processed. Once the session ends, a **Rollover mechanism** is used to regenerate a new session, creating a **fresh pairing** between the Requestor and a different set of Servicers. This **dynamic rotation** prevents any single group of Servicers from being continually overloaded with requests from a particular client, ensuring a fair workload distribution. In addition to the client-servicer relationship, sessions in the Viper Network also involve the selection of a **Fisherman**. The **Fisherman** acts as a performance monitor for the Servicers involved in that session. Their role is vital for ensuring the **quality and reliability** of the services being provided. The **Fisherman** is responsible for: * **Evaluating Servicer Performance**: The fisherman assesses factors such as: * **Reliability**: How consistently the Servicer responds to requests. * **Availability**: Whether the Servicer is operational during the session. * **Latency**: The speed at which the Servicer processes and responds to relay requests. * **Gathering Data**: The fisherman collects key performance metrics, which are then used to determine the **quality of service** delivered during the session. The performance scores generated by the Fisherman are integral to the **rewards and penalties system** within the Viper Network. Servicers are rewarded for high performance and penalized for low-quality service. This **reputation-based evaluation** helps maintain trust and ensures that only reliable, high-performing nodes continue to serve the network.
### **Session Generation** A **session** in the Viper Network consists of four main components that ensure fairness, transparency, and reliability in the interaction between Requestors and Servicers. These components—**Key**, **Header**, **Servicers**, and **Fishermen**—work together to facilitate secure, performance-driven service exchanges. **1. Session Key** The **session key** is crucial in selecting the right group of Servicers for a session. It ensures that the selection process is fair and random, preventing bias and exploitation. * The session key is generated by combining several pieces of information: * A **unique seed** derived from the hash of the latest block and the block height. * The **Requestor's public key**, ensures that the session is tailored to the individual user’s needs. * The **non-native chain ID**, identifies the chain the Requestor wishes to interact with. * This combined data is passed through a **hash function**, producing a unique session key that is used to select Servicers for the session. This process helps guarantee that the selection of Servicers is both random and fair for all participants. **2. Session Header** The **header** contains key information about the session and its structure. It serves as a reference point for all data associated with the session, ensuring the integrity of the process. * The **Session Header** includes: * The **Requestor's public key** to associate the session with the correct user. * The **chain** and **geo-zone** that the Requestor is interacting with, ensuring location-based selection. * The **number of Servicers** requested, ensuring that the right amount of resources is allocated. * The **Session block height**, providing a reference to the session’s place in the blockchain. **3. Servicers** Servicers are key participants in the Viper Network, responsible for providing services to clients and maintaining the integrity of the network. The selection of Servicers for each session is governed by a sophisticated mechanism to ensure fairness and reliability. * **Eligibility Criteria**: * Servicers with a **performance score** above 0.75 (out of 1) and meeting the **minimum staking requirements** are eligible for selection. * **Weighted Selection**:
Performance ScoreStaked TokensWeight
> 0.90≥ Minimum (10,000)1
> 0.75≥ 2x Minimum2
> 0.75≥ 3x Minimum3
> 0.75≥ 4x Minimum4
≤ 0.90≥ MinimumScore will be considered as Weight (0.1 - 0.9)
* **Pseudorandom Selection**: * The Servicers for each session are chosen based on a **weighted random process**, giving higher-weighted Servicers a higher chance of selection. This ensures that high-performing and well-staked Servicers are more likely to be chosen, while maintaining a decentralized approach. **4. Fishermen** Fishermen play a critical role in ensuring the **Quality of Service (QoS)** within the Viper Network. They act as **shadow clients**, continuously evaluating the performance of Servicers during a session. * **Fisherman Role**: * Fishermen are **pseudo-randomly selected** for each session and are responsible for sending **sample relays** to all Servicers in the session. * By observing these relays, they measure the **latency**, **availability**, and **reliability** of each Servicer. * **Fisherman Scores**: * The performance metrics collected by Fishermen are used to calculate **performance scores** for each Servicer. These scores reflect the quality of service provided during the session. * Higher scores, indicating better QoS, result in greater rewards for the Servicers. * **Selection**: * The **assignment of Fishermen** to sessions is determined by the Team, ensuring that there are no malicious actors involved. # Service Service in Viper Network plays a crucial role in facilitating the relay of RPC requests between clients and blockchains. Servicers, which are nodes operating within the network, are responsible for servicing these relays. They ensure the efficient and reliable transmission of data, providing a seamless connection between clients and the underlying blockchain infrastructure. Servicers are staked and incentivized to perform their tasks diligently, as their performance directly impacts their rewards. By maintaining a robust network of servicers, Viper Network ensures the availability, reliability, and responsiveness required for smooth and uninterrupted interactions between clients and blockchains. ### **Relay** A **relay** is the fundamental mechanism that enables interaction between clients and blockchains within the Viper Network. It represents an **API request** made by a client to interact with a specific blockchain, either to **read** data (e.g., account balances, transaction history) or **write** data (e.g., submitting a transaction). Once the client sends the request, it is routed through the network to the designated **Servicers**, who then process the request by interacting directly with the blockchain on the client’s behalf. After the blockchain responds to the request, the **Servicers** relay the blockchain’s response back to the client, completing the **request-response cycle**. This system allows clients to seamlessly access blockchain data or submit transactions, all while interacting in a **trustless** and **decentralized** manner.

Relay

#### Relay Lifecycle 1. **Request Initiation**: The relay lifecycle begins when a requestor initiates a session by specifying essential information such as the blockchain it intends to interact with, the desired geographic zone (geozone), and the number of servicers required for the session. 2. **Session Generation**: Upon receiving the request, a session is generated based on the provided information. This session contains details essential for the subsequent relay process, including the servicers paired and the fisherman. 3. **Relay Request Submission**: With the session information at hand, the requestor submits relay requests to the servicers. These requests include pertinent details regarding the payload to be relayed and information about the session itself. 4. **Request Validation and Proof Storage**: Upon receiving relay requests, the servicers validate the requests to ensure their authenticity and integrity. Subsequently, they store relevant proof of the request's receipt and authenticity 5. **Relay Execution**: Following successful validation, the servicers execute the relay requests as specified. This may involve interacting with the designated blockchain, processing transactions, or executing smart contract functions, among other actions. 6. **Response Generation**: Upon completing the relay task, the servicers generate responses corresponding to the relayed actions. 7. **Response Signing and Return**: Before returning the response to the requestor, the servicers sign the response to ensure its authenticity and integrity. Once signed, the response is returned to the requestor, completing the relay lifecycle for the specific request. ### Quality of Service Ensuring a **high Quality of Service (QoS)** for relay services is essential for the **Viper Network**, as it directly impacts the reliability and user experience. To maintain this standard, Viper leverages the role of the **Fisherman**, an actor dedicated to continuously evaluating and overseeing the performance of Servicers during each session.

Fisherman Monitering

#### Session Report Card A unique feature of the Viper Network is its dynamic **report card system**, which evaluates each Servicer’s performance after every session. This report card influences two key aspects: 1. **Chances of being selected for future sessions.** 2. **Proportion of rewards** earned based on performance. By incorporating these report cards, the Viper Network motivates Servicers to consistently provide high-quality service, knowing that their rewards are directly linked to their performance. The Fisherman plays a crucial role in updating these report cards, ensuring the integrity and reliability of the network’s services. **Key Performance Metrics** The **Fisherman** evaluates each Servicer based on three key metrics: **availability**, **latency**, and **reliability**. These metrics are calculated and used to determine the Servicer’s performance score, which in turn affects their rewards. 1. **Availability** * The **Fisherman** sends **sample relays** to all Servicers within a session, monitoring their responsiveness to these requests. * **Downtime percentage** is calculated by measuring the ratio of **unanswered relays** to the total relays sent. * The **scaled availability score** is calculated as follows: `scaledAvailabilityScore = 1 - (unansweredRelays / totalRelays)` * A higher availability score rewards Servicers that are more responsive and have lower downtime. *** 2. **Latency** * The **Fisherman** measures **Round Trip Time (RTT)**, which is the time it takes for the Fisherman to receive a signed response from a Servicer. * The **latency score** is calculated based on the ratio of the **lowest average latency** (fastest Servicer in the session) to the **average latency** of each Servicer. * This score is **clamped to a maximum value of 1** to ensure consistency. `score = lowestAverageLatency / averageLatency (clamped to 1 )` * Servicers with faster response times receive higher scores, incentivizing them to minimize latency. *** 3. **Reliability** * **Reliability** measures how consistently Servicers provide correct responses. The **Fisherman** sends **sample requests** locally and compares the outcomes with the responses from the Servicers. * If discrepancies are found, it indicates errors or inconsistencies in the Servicer’s responses. * **Reliability score** is calculated as the ratio of **matched samples** to the total samples sent: `reliabilityScore = matchedSamples / totalSample` * Servicers with fewer discrepancies and more accurate responses receive higher reliability scores, ensuring that only consistent, error-free Servicers thrive in the network. | Metric | Score Weightage | | ------------ | --------------- | | Availability | 30% | | Latency | 40% | | Reliability | 30% | **\*\*** *The weights assigned to performance metrics are parameterized and can be adjusted in the future through the DAO governance.* *** #### Global Report Card The **Viper Network’s Global Report Card system** is an integral feature designed to track and evaluate the performance of validators over time. The system uses three key performance metrics to assess the overall contribution of validators: **Latency Score**, **Availability Score**, and **Reliability Score**. When a validator submits a QoS report, the network updates the corresponding report card as follows: 1. **Updating Scores**: \ When a **validator** submits a **Quality of Service (QoS)** report, the Viper Network updates the corresponding report card using a **decaying average formula**: `updatedScore = (decayedCurrentScore` \* 0.98 + newScore) / 2 * **Decaying Average**: The formula applies a **0.98 decay factor** to the current score, which reduces the impact of older sessions. This ensures that the report card reflects the validator’s **recent performance** more accurately and remains sensitive to changes in service quality. * **Balancing Historical and Recent Performance**: By averaging the **decayed current score** with the **new score**, the system maintains a balance between a validator’s long-term performance and the latest session's results. This method also ensures that as the total number of sessions increases, the effect of any single new session on the overall score is minimized. The decaying average makes the report card more reflective of current performance rather than being overwhelmed by the cumulative effect of older sessions. 2. **Averaging the Scores**: \ The updated **Latency**, **Availability**, and **Reliability** scores are averaged, allowing the system to continuously track the performance of the validator over time without giving disproportionate weight to recent sessions. This approach ensures that: * The report card remains **sensitive to changes** in performance. * Older scores lose relevance more gradually, allowing for a more dynamic reflection of the validator's service quality. 3. **Total Score Calculation** To calculate the total score for each validator, the individual scores (Latency, Availability, and Reliability) are multiplied by their respective **weights** and then added together. The total score is then normalized by dividing the sum by **1,000,000,000,000** to keep it within a manageable range. This method ensures that each score contributes proportionally based on its **assigned weight**, reflecting the importance of each metric to the overall validator performance. The report card system incentivizes validators to maintain consistent, high-quality service to the network and its users. # Finality In order to establish a reliable and consensus-driven infrastructure provisioning system within the Viper Network, the selection of a distributed, secure, and immutable database accessible to all participants is crucial. Therefore, the blockchain database structure, specifically the implementation of Tendermint Core, was chosen. The security model of the Finality Storage layer revolves around the concept of Proof of Stake. Every registered Node in the network becomes part of a Validator Set, which enables a weighted, pseudo-random, deterministic selection for the role of Block Producer. The selected Block Producer is responsible for producing the next block in the chain. As each block is validated by every peer in the network, Block Producers have no incentive to produce invalid blocks. Any attempt to do so would result in punishment according to the applicable monetary policy and network protocol rules. By utilizing Tendermint Core and implementing a robust Proof of Stake mechanism, Viper Network ensures the trustworthiness and reliability of its infrastructure, promoting a secure and consensus-driven environment for all participants. ### Transactions The Viper Network operates on a foundation where the Finality Storage serves as the authoritative and immutable record for all participants. It serves as the singular source of truth within the network. To contribute to this shared state, participants are required to submit transactions through a standardized and versioned interface to Nodes. These transactions are then propagated by the Nodes and ultimately incorporated into blocks by the Block Producers. To contribute to this shared state, participants engage in various types of transactions. These transaction types include: 1. **Staking Transaction:** * Participants initiate staking transactions to solidify their engagement in the network, committing a specific token amount above 10000 in native tokens * This commitment establishes an active role, granting participants defined privileges and responsibilities within the network. 2. **Unstaking Transaction:** * Conversely, unstaking transactions enable participants to reclaim their staked tokens when they choose to discontinue active participation after a lock-in period of 21 days. * This mechanism offers flexibility, allowing participants to manage their involvement in the network dynamically. 3. **Token Transfer Transaction:** * This transaction type facilitates the smooth transfer of native tokens among network participants, fostering efficient peer-to-peer transactions. * Participants can securely exchange value within the network, contributing to the seamless functioning of the ecosystem. 4. **Report Card Transaction:** * This transaction type is utilized at the conclusion of a session to generate a comprehensive [report card](/protocol/design/service#session-report-card) by utilizing reliability, availability, and latency scores calculated for servicers. * The report includes the Merkle root of the of test results, ensuring the integrity and authenticity of the data. * Accompanied by a signature and a nonce to verify the legitimacy of the report, confirming it was generated by a valid Fisherman belonging to a specific session. * The transaction is submitted along with a Merkle proof and a pseudo-randomly selected leaf, which are later used in the "verify transaction". 4. **Commit Transaction:** * Initiated by participants to assert ownership or rights over specific rewards by submitting a commit transaction for the work completed. * Generates a root for the proofs, serving as evidence of the completed tasks, and submits it to the chain. * Ensures participants can access their entitled benefits or holdings within the network, promoting fairness and transparency. 4. **Verify Transaction:** * Involves retrieving both commit and report card data for a particular servicer within a specific session. * Generates the Merkle proofs and leaves for the commit and report card respectively and submits it to the chain. * The transaction is later handled by validating the Merkle proof against previously submitted Merkle roots of both the commit and report card, ensuring data consistency and integrity. * It then verifies the Fisherman's signature against the report and scores, ensuring authenticity and reliability and the client's signature against the proof of the relay. * Validators confirm the validity of the transaction, after which tokens are minted to the address of the servicer proportionally to the volume of relays served and the performance score. * Updates the [global report card](/protocol/design/service#global-report-card) maintained for the servicer, reflecting the latest performance metrics. #### Transaction Cost In the Viper Network, transaction costs play a pivotal role in deterring spam and ensuring the judicious use of network resources. These costs are predefined and subject to adjustment through parameters set within the protocol, offering flexibility and adaptability to evolving network conditions. Managed through decentralized autonomous organization (DAO) governance, these parameters can be modified as needed, allowing for dynamic adjustments that align with the network's monetary policies and protocol guidelines. \ \ By imposing transaction costs, the network discourages excessive and frivolous transactions, promoting responsible behaviour among participants. Utilizing native cryptocurrency tokens to cover these costs ensures efficient resource allocation while reinforcing network integrity and stability. This mechanism not only maintains the integrity of the Finality Storage but also contributes to overall reliability and performance, enhancing the network's capacity to support its growing ecosystem. # Economics **$VIPR** serves as the native token of the Viper Network, fulfilling crucial roles in facilitating transactions, incentivizing participants, and ensuring the security and governance of the network. Building upon the mechanics described earlier, the following provides a concise summary of the token's key use cases: {% content-ref url="/pages/EHqUsrfBppl56hKp2Acn" %} [Stake](/protocol/economics/stake) {% endcontent-ref %} {% content-ref url="/pages/WJ7IA6tprI4smeALNoxP" %} [Reward](/protocol/economics/reward) {% endcontent-ref %} {% content-ref url="/pages/z8gKnuGfCaRPIP42kcWb" %} [Burning](/protocol/economics/burning) {% endcontent-ref %} ### **Token Value Drives Network Growth** The value of tokens issued by servicers mirrors the overall worth of the network and its services, showing how big and popular it is. As the network expands, this link between token and network value encourages more investment in new nodes. In simpler terms, when token values increase, more people invest in and enhance the network. This, in turn, causes token values to go up again. It's like a cycle – higher token value leads to more network growth, and more growth increases token value. This feedback loop is shown in the flywheel below.

Viper Flywheel

### Stake For Access Model In the Viper Network, a stake-based access model is employed to ensure the integrity and reliability of network participants. Under this model, participants are required to stake a certain amount of native cryptocurrency tokens as collateral to gain access to network functionalities and benefits. The stake acts as a financial commitment, incentivizing participants to uphold network rules, provide quality services, and adhere to protocol guidelines. Additionally, staked tokens serve as a form of security against malicious behavior, discouraging fraudulent activities and reinforcing trust within the ecosystem. Through this stake-based approach, the Viper Network fosters a secure and sustainable environment where participants are incentivized to contribute positively to the network's growth and stability.

Stake for access model

# Stake Staking in the Viper Network is a fundamental stage where participants commit their tokens as a form of collateral to actively engage and contribute to the network's operations. By staking tokens, participants demonstrate their commitment to the network's success and gain the opportunity to earn rewards in return. ### Requestor Staking Requestors in the Viper Network stake tokens to gain access to send relays on the network. The amount of stake and the USD value of tokens at the time of staking determines the number of relays they can send. After each session, the stake is burned based on the number of requests sent, ensuring that the stake aligns with the level of activity and resource usage. ### Servicer Staking Servicers in the Viper Network stake tokens to be part of the network and receive incentives for servicing the relays sent by the clients. All nodes in the network are staked as validators, but only the top stakers are selected to validate blocks. This staking mechanism serves multiple purposes. 1. Staking tokens act as a barrier to prevent anyone from easily joining the network and potentially causing bloat or disruption. By requiring a stake, it ensures that participants have a genuine commitment and stake in the network's success. 2. Staking serves as a form of security and alignment of incentives. Servicers who stake tokens have a direct financial stake in the network's proper functioning and are motivated to provide reliable and efficient relay services. This aligns their interests with the network's goals and encourages them to maintain high-quality service. 3. Staking becomes expensive for misbehaviour. In case of any malicious activity or failure to follow the network's rules, a portion of the staked tokens can be slashed as a penalty. This discourages misbehaviour, enhances network security, and ensures that participants have an economic disincentive to act against the network's best interests. To participate in the network, servicers stake a certain amount of VIPR tokens either directly or through delegated staking. #### Direct Staking

Direct staking

Direct staking is the process of having the operator of the servicer be the recipient of the rewards of that servicer. #### Delegated Staking

Delegated staking

Delegated staking is the process of having the operator of the servicer be a different account from the account that receives the rewards. # Reward Once a relay is serviced and the proof is verified by the network, the corresponding reward in the form of the native cryptocurrency is added to the Servicer’s, Fishermen, Governor , Requestor's and Validators account. This process helps to ensure that the rewards are distributed in a timely manner and that the servicers are incentivized to continue providing high-quality service to the network. | Actor | Allocation Percentage | | ------------------------------- | ---------------------------------------------------------------------------------- | | Governer | 10% | | Validator | 5% | | [Requestor](#requestor-rewards) | 5% (if they have the special key), otherwise, the allocation goes to the Governor. | | Fishermen | 5% | | Servicer | 72% | | Chain | 3% (if not partnered, goes to Servicer) | **\*\*** *The allocations assigned to the actors are parameterized and can be adjusted in the future through the DAO governance.* ### Servicer Rewards Servicers are rewarded based on two key factors: * **Relay Volume:** The number of relays processed by the Servicer during a session (\~1hr). * **Performance Score:** Quality of service metrics evaluated by Fishermen, such as availability and latency. `Reward = Relay Volume × Performance Score` \ \ This formula incentivizes Servicers to maximize both relay volume and quality, ensuring efficient and reliable service for the network. ### Validator Rewards Validators maintain the security and integrity of the Viper Network by verifying transactions and adding new blocks to the native blockchain. For their efforts, Validators receive a share of the block rewards. Validator rewards act as a key incentive, motivating Validators to actively participate in consensus and maintain network stability. ### Fisherman Rewards Fishermen are critical to maintaining the Quality of Service (QoS) in the Viper Network. Acting as pseudo-clients, Fishermen send sample relays to Servicers to evaluate their performance across standardized metrics: * **Availability:** Uptime of the Servicer. * **Latency:** Response time of the Servicer. * **Reliability:** Consistency in response accuracy. Fishermen compile these evaluations into report cards, which play a vital role in holding Servicers accountable and ensuring the network maintains high-quality performance standards. Fishermen receive rewards for their unbiased and accurate evaluations, ensuring Servicers provide high-quality and reliable performance. ### Requestor Rewards Requestors (only portals and tool builders) receive rewards for directing traffic to the Viper Network. This serves as both an incentive and a discount mechanism for their participation. These incentives encourage developers, infra protocols and portals to actively utilize Viper’s decentralized infrastructure to build great UX/UI, APIs or Tools. This not only enhances the utility and accessibility of the network but also accelerates adoption by creating value-added services for end users To ensure that the rewards are properly distributed and accounted for, a special key needs to be generated for the client. This key can only be generated by the Team, who has the authority to allocate rewards to eligible clients. ### Chains and Partner Rewards Partnered chains receive 3% of the reward allocation as an incentive for driving traffic and promoting Viper within their communities, whether through mentions in documentation, blogs, tutorials, or other community-driven efforts. These rewards foster a network effect, encouraging chains to actively support and endorse Viper, thereby boosting visibility and adoption. By promoting Viper to their developers and users, partnered chains create a virtuous cycle of mutual growth. *\*\*In cases where a chain is not a partner, the 3% allocation is redistributed to Servicers.* # Burning Burning serves as a fundamental mechanism within the Viper Network, fulfilling both security and economic purposes. It plays a vital role in discouraging and economically disincentivizing bad behavior, while also managing the total supply of the VIPR token to prevent hyperinflation and maintain long-term stability. ### Requestor Stake Burning In Viper Network, a token-burning mechanism is implemented to regulate network usage and maintain a healthy ecosystem. At the conclusion of each session, tokens are burned on the requestor's side proportional to the level of network utilization. This approach ensures that the network remains efficient and sustainable by curbing excessive usage and incentivizing responsible behaviour. As tokens are systematically removed from circulation based on usage metrics, the scarcity of tokens increases, potentially leading to an appreciation in token value over time. By aligning economic incentives with network utilization, the Viper Network promotes a balanced and self-sustaining ecosystem, fostering long-term viability and growth. ### Jailing and Slashing Jailing and slashing are critical components of the Viper Network's security measures, designed to maintain integrity and reliability. * **Jailing:** Jailing entails restricting the functionality of an entity within the network due to certain violations or failures to meet network standards. * **Slashing:** Slashing involves the reduction of an entity's stake as a penalty for malicious behaviour or network rule violations. **Implementation:** * **Fisherman Slashing:** Fishermen face slashing penalties if they submit invalid report cards, resulting in a 0.02% loss of their stake and will be jailed if they miss more than 3 report cards. * **Servicer Inactivity:** Servicers may be paused and slashed for being inactive, as detected by the Fisherman, with a 0.0001% stake deduction. * **Poor Performance:** Servicers scoring below 0.67 after servicing five sessions risk being slashed by 0.001% of the stake and jailed for inadequate performance. * **Irregular Block Signing:** Servicers not regularly signing blocks face stake deductions by 0.0001% and potential jailing. * **Double Signing:** Servicers face a slashing of 0.0001% of stake and jail penalties for engaging in double signing, a serious violation. * **Replay Attack:** Slashing penalties of 0.0001% of stake are enforced for participating in replay attacks, ensuring network security and reliability. # Governance {% hint style="info" %} The DAO, which is yet to be launched, will focus on decentralization and community-driven governance, the Viper Network DAO aims to be at the forefront of the next generation of the internet. {% endhint %} The Viper Network would employ a Decentralized Autonomous Organization (DAO) in future to ensure sustained functionality and resilience of the network. A fraction of the network's rewards is allocated to the DAO, utilizing these funds for continuous improvement and safeguarding the network's integrity over the long term. The DAO assumes the responsibility of making critical decisions regarding the network's economic structure and the onboarding of new users. This proactive approach contributes to maintaining a fair and inclusive environment for all participants. # Join Community Join our vibrant community on Discord for engaging discussions and stay updated with the latest news by following us on Twitter. Explore insightful articles on Medium to deepen your understanding * [**Discord**](https://discord.gg/eBDYH4Zxek) * [**Twitter**](https://twitter.com/viper_network_) * [**Medium**](https://medium.com/@vipernet)