Payment

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

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 [6], 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 Storage Architecture) 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. Storage Architecture 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.