☁️
Züs
  • About Züs
  • Concepts
    • Architecture
      • Mining on the Züs Blockchain
        • Onboarding a New Miner or Sharder
        • Block Production Protocol
        • Block Finalization
        • Merkle Patricia Trees(MPT) and Recovery
        • View Change and Distributed Key Generation(DKG)
      • Payment
      • Storage
      • Token Bridge Protocol
      • Resources
    • Tokenomics
      • Staking Process
      • Block Rewards
      • Delegation
    • Store
    • Earn
    • Build
    • NFT
  • Resources
    • Whitepapers
      • Tokenomics Paper
      • Architecture Paper
      • Storage Paper
    • Patents
      • NON-FUNGIBLE TOKEN BLOCKCHAIN PROCESSING
      • FREE STORAGE PROTOCOL FOR BLOCKCHAIN PLATFORM
      • TRANSFERRING CONTENT VIA PROXY RE-ENCRYPTION
      • STREAMING CONTENT VIA BLOCKCHAIN TECHNOLOGY
      • SPLIT-KEY WALLET ACCESS BETWEEN BLOCKCHAINS
      • ENFORCING SECURITY PARAMETERS SPECIFIED BY AN OWNER ON A BLOCKCHAIN PLATFORM
      • CLIENT AUTHENTICATION USING SPLIT KEY SIGNING ON A BLOCKCHAIN PLATFORM
      • BLOCKCHAIN CONTENT PURCHASING PROTOCOL
      • BLOCKCHAIN BASED PRIVACY COMPLIANCE PLATFORM
      • SYSTEMS AND METHODS OF SELF-ADMINISTERED PROTOCOLS ON A BLOCKCHAIN PLATFORM
      • SYSTEMS AND METHODS OF AGGREGATE SIGNING OF DIGITAL SIGNATURES ON MULTIPLE MESSAGES SIMULTANEOUSLY U
      • SYSTEMS AND METHODS OF BLOCKCHAIN PLATFORM FOR AUTOMATED ASSET BASED PROVISIONING OF RESOURCES
      • SYSTEMS AND METHODS OF SELF-FORKING BLOCKCHAIN PROTOCOL
      • SYSTEMS AND METHODS OF SUSTAINABILITY PROTOCOL USING DISTRIBUTED BLOCKCHAIN APPLICATION WITH IoT SEN
      • SYSTEMS AND METHODS OF BLOCKCHAIN PLATFORM FOR DISTRIBUTED APPLICATIONS
  • API Reference
    • Endpoints
      • Block
      • Client
      • Connection
      • DNS
      • File
      • Smart Contracts
      • Blobber Stats
      • Transactions
      • Miners and Sharders
        • Stats
        • State
        • Diagnostics
        • Configuration
        • Smart Contract State
        • Smart Contract Stats
        • Chain Stats
  • Hackathon
    • Register to Hackathon
      • How to Add Members to Hackathon Team
    • Repos
    • Documentation
  • Products
    • Bolt
      • Get Started
      • Stake
      • Activity
      • Buy ZCN
      • Sell ZCN
      • Send Tokens
      • Receive Tokens
      • Settings
        • Manage Profile
        • Wallet
        • Read Pool
      • Troubleshooting
    • Vult
      • Sign Up
      • Upload File
      • Upload an Encrypted File
      • Upload a File to a Folder
      • Share a Uploaded File
      • Move a Uploaded File
      • Delete a File
      • Make File Available Offline
      • Troubleshooting
    • Atlus
      • Dashboard Overview
      • Service Providers
      • Charts
        • Market Charts
        • Network Charts
        • Storage Charts
        • Züs Explainer
      • Blockchain
      • Server Map
    • Blimp
      • Sign Up
        • Buy ZCN for Storage
      • Use Blimp as Direct Storage
      • Use Blimp as S3 Server
        • S3 Operations
      • Use Blimp for Cloud Migration
      • Manage Allocations
        • Extend Size
        • Extend Duration
        • Add Blobber
        • Replace Blobber
        • Make allocation Immutable
        • Freeze Allocation
        • Cancel Allocation
    • Chimney
      • Get Started
      • Deploy Blobber on Own Server
      • Deploy Blobber on Rented Server
      • Stake Blobber
      • Add Blobber
      • Monitor Blobbers
      • Visualize Blobber Logs
      • View Blobber Rank
    • Chalk
      • Sign Up
      • Create NFT Collection
        • Buy ZCN for NFT via ERC token
        • Buy ZCN for NFT via Credit card
      • Explore NFT Collections
      • My NFTs
      • Profile
        • Withdraw Earnings
        • Manage Collections
  • Guides
    • Zus GO SDK
    • Zus JS SDK
    • Zbox CLI
      • Repo
      • Get Started
      • Creating and Managing Allocations
      • Uploading and Managing Files
      • Lock and Unlock Tokens
      • Tips and Troubleshooting
    • Zwallet CLI
      • Repo
      • Get Started
      • Zwallet Operations
      • Staking on miners and sharders
      • Burn and Mint Tokens using Zwallet
      • Troubleshooting
    • Add a Blobber
      • Repo
      • Getting Started
    • Add a Miner/Sharder
      • Repo
      • Getting Started
    • Setup a Blockchain
      • Repo
      • Quickstart
        • Understand the Script
      • Step 1: Set up the project
      • Step 2: Setup the network for Züs components
      • Step 3: Initialize and Build the Züs components
      • Step 4: Start Sharder and Miner Containers
      • Step 5 : Create a wallet using zwalletcli
      • Step 6: Starting the blobber containers
      • Step 7: Validate Züs deployment
      • Step 8: Creating an Allocation on Blobber
      • Restarting Sharder and Miner Containers with CleanDB.
      • Additional Tips and Troubleshooting
    • Glossary
  • Support
    • Help Center
      • Community
      • Issues on Github
      • Contact Us
Powered by GitBook
On this page
  • Service Providers, Staking, and Delegates
  • Token Pools and Markers
  1. Concepts
  2. Architecture

Payment

This page describes how payment works in the Züs network.

PreviousView Change and Distributed Key Generation(DKG)NextStorage

Last updated 2 years ago

The native token of Züs is ZCN. The total supply of ZCN is capped at 400 million tokens.

Service Providers, Staking, and Delegates

Züs ecosystem includes a variety of service providers, including miners, sharders, and blobbers. We refer to them generically as service providers.

Service providers must stake a certain amount of tokens to ensure their proper behavior; if they do not perform their duties adequately, a portion of these tokens may be slashed (destroyed).

When tokens can be unstaked (reclaimed) depends on the role of the service provider. For instance, miners and sharders tokens can only be unstaked during a view change. Blobbers can unstake tokens at anytime for un-allocated storage, but cannot unstake tokens for allocated storage.

Similar to protocols such as EOS, Züs includes the role of delegates. A delegate is a client that wishes to stake tokens to share in the rewards, but who does not directly participate in the service provided. They stake tokens on behalf of the service provider, and share in any rewards or punishments that result. When rewards are paid out, the service provider takes a service charge percentage of the total rewards. The remainder of the rewards is divided between the delegates according to the amount of tokens that they have staked.(Note that the service provider itself may also be a delegate if it staked tokens).

In some cases, rewards may be divided between multiple types of service providers. For instance, transaction fees and the block reward for a block are divided between miners who produce the block and the sharders who store it by a specified share ratio.

Token Pools and Markers

A client may set aside tokens into a token pool. The tokens in these pools retain a connection to the client, but cannot be accessed except by the rules specified for the pool. For instance, a stake pool holds tokens that a delegate may have staked; the delegate can reclaim them eventually, but the rewards may be slashed if the terms of service are not met.

In some cases, a client may wish to set aside funds for some ongoing service that a provider can draw from when they prove work has been done. Züs provides this behavior with token pools and markers. A marker is a message signed by the client authorizing the release of tokens when some condition is met. Token pools and markers have a relationship roughly akin to bank accounts and checks. Not all token pools allow the release of funds through markers, and the nature of the markers may be different for different types of token pools.

The markers may include additional data, and thereby can serve as a formal commitment by the service provider to some service for the client. For instance, write markers (discussed in ) commit a blobber to store specific data; if it is later found to be missing that data, it may be penalized.

An additional benefit of this design is that the service provider can observe the balance of the token pools, and thereby know that there are sufficient funds available to pay for the service, with two caveats:

  • The client may decide to close the token pool and, depending on the design of the pool, recover (some portion of) the tokens; however, there is a delay before the client recovers their funds, allowing service providers to redeem any outstanding markers. Depending on the service, the client may need to meet additional conditions before reclaiming their tokens. illustrates an example of how this process can work.

  • If multiple providers can draw from the same token pool, there may be outstanding markers that have not yet been redeemed.

[6]
Storage Architecture
Storage Architecture