---
# System prepended metadata

title: Sentinel Network Overview

---

Sentinel Network Overview
===



About
---

This document is a reference to the way the Sentinel Network functions and also has details on how various stakeholers of the network, like users of Services/dApps, Delegators, Validators, etc. progress through the journey of testnets to the mainnet and incentives behind the same.

Index
---

1. Sentinel Network Overview
    - Sentinel Public Network
    - Sentinel Private Network

2. Sentinel Network Architecture

    - Hub
    - Zone

3. Hub

    1. Why is the Hub required?
    2. Validators
    3. Transaction Types
    4. Support for Zones

        - Zones are only through governance
        - Mention reg. Validators for Zones
    5. How does staking work in the Hub?
    6. Are there different tokens for staking and slashing?
    7. Governance
       
4. Zones

    1. Why are Zones required?
    2. Validators of Zones
    3. Types of Zones
        - Service Zone
        - Private Net (utilizes shared security and is not a Zone)
        - Private Zone (secured by it's own validators)
    4. Communication between Zones and Hubs

4. Sentinel p2p Marketplace

    1. Services
        1) Proposal
        2) Service Launch (Zone Launch)
        3) Service Governance
        4) Technical Details 
    2. Merchants
    3. Integrations
    4. Payments

5. Sentinel dVPN
    
    1. Sentinel dVPN as part of the Sentinel Hub
    2. Sentinel dVPN as an independent Zone
    3. Architecture
        1) Overview
        2) Node Network
        3) Clients
    4. Service level salient implementations
        1) Privacy - Proof based signature exchange
        2) Discovery - Resolver Node
        3) TBD
    5. Service implementation in Private Nets (TBD)
        Private Net utilizes shared security of the Sentinel Hub

        1) Sentinel dVPN in Private Nets
        2) Revenue Model for Private Net hosts 
         
    
6. Sentinel Relay Network
    1) Sentinel Relay Network as part of Sentinel Hub
    2) Sentinel Relay Network as a Zone (TBD)
    3) Architecture
        1) Overview
        2) Node Network
        3) Clients 
    4. Service implementation in Private Nets
        1) Sentinel Relay Net in Private Nets
        2) Revenue Model for Private Net hosts

7. Plan for Turing Testnets

    1. Sentinel-Turing-1

        - Testing of modules as part of the Cosmos SDK and transactions written exclusively for the Sentinel Hub

    2. Sentinel-Turing-2

        - Implement fully functional Sentinel dVPN with clients to utilize multiple protocols
        - Implement Governance as part of the Client
        - Implement Sentinel Private Net

Begin Draft - Overview
---

1. **Sentinel Network Overview**

    Sentinel Network is a decentralized marketplace that facilitates the exchange of Services (or dApps) and Resources, bandwidth for now and soon Storage.
    
    This exchange of Services are facilitated by Sentinel's resource monitoring and metering protocols that operate based on proofs submitted by the *providers* and the *consumers*.

    Sentinel as a network enables various services to securely offer their services either on the Sentinel Public Network or the Sentinel Private Network.
    
    1. **Sentinel Public Network**

        Sentinel Public Network is the network whose nodes are accessible to everyone that has a client connecting to the Sentinel Network. These nodes intend to serve users of the Sentinel Network.

        All clients of the Sentinel Network should ideally connect with the Sentinel Public Network and connect to the nodes listed. Nodes that choose not to be part of a Public Network can opt-out as well and be only a part of Private Networks.

        Sentinel Public Network is analogous to the *marketplace* where Service Providers and Consumers exchange Services & Resources. Sentinel Marketplace enables the entire community to exchange Services & Resources as listed by the governance of the network.

    2. **Sentinel Private Network**

        Sentinel Private networks work similar to the Sentinel Public Network, expect the fact that, nodes listed and services available to users of that specific Private Network, might not be available on another. This enables Sentinel Private Nets (short for Networks) to maintain high quality of service within a specific environment handled by a finite number of users/nodes.

        Sentinel Private Networks are usually relevant and are in the context of an organization running their own networks for added security. Private Nets can have strict authorization protocols for secure entry or can enable frictionless access to *Services* & *Nodes* within.

        Private Nets have the potential to be used for not-for-profit organizations & communities, small & medium to large scale enterprises, etc. Individuals will have the ability to run a private network

### Sentinel Network Architecture

1) **Sentinel Hub**

    The Sentinel Hub, powered by Validators of the Sentinel Network, enable the network to govern, incentivize, penalize, etc. and connects the network by enabling transfer of *data* and *assets* between multiple chains of the network.

    The Sentinel Hub works with multiple Zones to achieve that. With Inter Blockchain Communication developed by Cosmos for the Cosmos Network, the Sentinel Hub will communicate with the Cosmos Hub, where the entire Sentinel ecosystem will be accessible to networks/chains in the Cosmos Hub and vice-versa.

    **Validators of the Sentinel Hub**

    The Sentinel Hub is developed using the Cosmos SDK on the Tendermint consensus framework that utilizes **Validators** that are required to *validate* transactions on the Hub. `Hub Validators` validate transactions that are diverse in nature including, but not limited to governance, bank (transfer of tokens), dVPN, etc. which are decided at genesis.

    Each block of the chain has transactions proposed by a single validator from a set of existing Validators (the maximum is at 41 in the Sentinel-Turing-1 testnet) and can increase with governance. Validators require a specific stake in the network to have the voting power required to propose blocks.

    Validators are penalized/slashed stake if they result in misbehaving on the network.

    Slashing is triggered when:

    1) there's Double Signing on the network. This is when you sign 2 blocks at the same time (or same block height)
    2) if a Validator goes offline and does not sign any blocks for more than 100 blocks (6 seconds * 100)
    3) other factors that are might affect the performance of the network

**NOTE:** the above slashing list will vary and will be updated for every testnet and the criteria of one testnet does not imply the same for the others that follow

3. **Sentinel Zone**

    A Zone on the Sentinel Network works with it's own application logic and can either run it's own chain with Zone specific Validators called `Zone Validators` 

    Zones in the Sentinel Network do not exist at the moment (in Sentinel-Turing-x Testnets), but  

3. Hub

    1. Why is the Hub required?
    2. Validators
    3. Transaction Types
    4. Support for Zones

        - Zones are only through governance
        - Mention reg. Validators for Zones
        
4. Zones

    1. Why are Zones required?
    2. Validators of Zones
    3. Transaction Types

5. Plan for Turing Testnets

    1. Sentinel-Turing-1 : Testing of modules as part of the Cosmos SDK and transactions written exclusively for the Sentinel Hub

    2. Sentinel-Turing-2 : 

******

Sentinel dVPN
    
   1. Sentinel dVPN as part of the Sentinel Hub
   2. Sentinel dVPN as an independent Zone
   3. Architecture
       1) Overview
       2) Node Network
       3) Clients
   4. Service level salient implementations
       1) Privacy - Proof based signature exchange
       2) Discovery - Resolver Node
       3) TBD
   5. Service implementation in Private Nets (TBD)
        Private Net utilizes shared security of the Sentinel Hub

       1) Sentinel dVPN in Private Nets
       2) Revenue Model for Private Net hosts 
         