# INTRODUCTION

![](/files/-Lj0ESkVcleWonFT6CqE)

## CyberWay — the Most Powerful Infrastructure for Decentralized Applications

**Welcome to the CyberWay source code repository! CyberWay is a EOS fork with some major improvements.**

**There is public testnet running currently.**

[![buildkite](https://badge.buildkite.com/f0940b2380542f6c80c1c01aa773d61c1d3470007fa5b9e6c3.svg?branch=master)](https://buildkite.com/cyberway) [![GitHub](https://img.shields.io/github/license/cyberway/cyberway.svg)](https://github.com/cyberway/cyberway/blob/master/LICENSE)

### Getting Started

#### More information about CyberWay

* [White Paper](https://docs.cyberway.io/users/white_paper)
* [Main features of CyberWay](https://docs.cyberway.io/users/cyberway_features)
* [Bandwidth differences between EOS and CyberWay](https://docs.cyberway.io/users/bandwidth_differences)
* [Bandwidth implementation](https://docs.cyberway.io/users/bandwidth_implementation)
* [The best blockchain for user-friendly dApps](https://cyberway.io)

#### Advantages

* Free Registration (Free Resource as Bonuse for Inviting other Peoples)
* Free Transactions (Resource Credits)
* Fast Block Confirmations (three seconds)
* Delegated Proof-of-Stake Consensus (DPOS)
* Creating your own dApps with your own Tokens (<https://docs.cyberway.io/devportal/create_application>)
* First dApps already built on CyberWay and many more to come
* Transferring Funds between dApps without Reducing their Cost
* Decentralized management, No any Supervisory Authority
* Migration of your Blockchain to CyberWay and using it as a Separate dApp

#### Devportal

* [Mainnet Connection Guide](https://docs.cyberway.io/validators/mainnet_connection)
* [Install the CDT](https://docs.cyberway.io/development_environment/install_cdt)
* [Create Development Wallet](https://docs.cyberway.io/development_environment/create_development_wallet)
* [Guide to Creating and Deploying an Application on CyberWay](https://docs.cyberway.io/devportal/create_application)
* [System Smart Contracts](https://docs.cyberway.io/devportal/system_contracts)
* [Application Smart Contracts](https://docs.cyberway.io/devportal/application_contracts)
* [The Cyberway Wallet designed for the Bittrex Market](https://docs.cyberway.io/devportal/cyberway_wallet_for_bittrex)
* [The Event Model](https://docs.cyberway.io/devportal/event_engine)

### Community

**Telegram:**

* CyberWay - <https://t.me/cyberway_en> (for general questions and inquiries)
* CyberWay Validators - <https://t.me/cyberway_validators_en> (for questions and inquiries concerning validators of CyberWay platform)
* CyberWay Dev - <https://t.me/cyberway_dev> (for instant technical feedback from our Dev team)

**Twitter:**

* We'll keep you updated over <https://twitter.com/cyberwayio>


# USERS

* [White Paper](/users/white_paper)
* [Main features of CyberWay](/users/cyberway_features)
* [Bandwidth differences between EOS and CyberWay](/users/bandwidth_differences)
* [Bandwidth implementation](/users/bandwidth_implementation)
* [How to Launch EOS dApps on CyberWay](/users/how_to_launch_eos_dapps_on_cyberway)
* [Glossary](/users/glossary)


# White Paper

## Introduction

Since the development of the first so-called “blockchain” database named “Bitcoin”, complex transaction behaviour was a “Holy Grail” for people wondering how they could pay, bet, play, and even order pizza with such assets.

The first complex transaction logic implementation was made available right in “Bitcoin” with a stack virtual machine providing a limited set of operations for the end-user to make some fun with it. Fine example is an Omni-layer built on top of the operations set, which end-user intention is to provide a creation and usage of the custom user-defined assets. Such a system successfully fulfilled contemporary requirements for liquid asset transfer. Unfortunately, such an application logic usage rapidly overflowed the throughput available, so no mass adoption happened.

Another attempt to provide the customizable complex transaction behaviour was made with creation of “Ethereum”, which provided an unnecessarily created from scratch programming language called “Solidity” for creation of even more complex application logic, hoping it would not overflow the database throughput. Obviously this lead to another failure. Primal language and naive database architecture understanding did not survive the reality check - in 2017 the protocol was literally down with CryptoKitties hype.

The scalability troubles got up again, so another popular solution was rapidly proposed. It’s name was EOS. The solution was to split the computable transaction complex behaviour and to process it with the set of cluster nodes, which were called “Validators”. This lead to the entrustment of an enourmous responsibility to these “Validators”. They were now not only about data storage providers, but also computation providers. Now these guys not only store and process your data, but they even define the way your transaction behaves itself, define if they allow such a transaction to be written or not. Futhermore, such an “improvement” lead to the unacceptable database node hardware requirements, which made the support truly awful. Moreover such a split was not enough for building production-ready applications - who would like to find out if the upvote transaction, which was even payed for, was at first queued and then rejected?

## Proposal

CyberWay is a decentralised application platform that addresses and overcomes the shortages mentioned above.

### EOS-compatibility

CyberWay is an upgraded fork of EOS. So, the backward compatibility is held. The code contains most of the tolerable EOS parts, but excludes the awful ones. So-called “Smart Contracts” API backward compatiblity is held too, but the insides have changed. That means every EOS application could easily become the CyberWay-based one and vice versa. Enough of that. Next.

### Bandwidth

EOS’s bandwidth distribution is closely related to the amount of asset the particular user owns. Furthermore, it requires for the user to hold the asset to be available for the usage at any time. That means the asset becomes a highly valuable, but also it becomes the non-available for the newcomers one. So no newcoming applications are welcomed to be built with EOS.

Striving to eliminate these inconveniences Cyberway introduces some changes.

The bandwitdh accounting is split to the couple of categories:

* Priority-based bandwidth allows a user to get required computational facilities according to the amount of core-asset available.
* Shared bandwidth supplies users with the unused computational power according to the particular user activity.

### State Storage

EOS’s state storage is extremely unreliable and does not ensures that data is saved and restored after restart correctly. Futhermore, EOS does not provide any convenient API, but supposes the data structure stored inside would be complex.

CyberWay solves these troubles. CyberWay uses the external DBMS for the state storage, which means the particular developer favourite query language can be used and the external well-designed replication and clusterisation mechanisms, done by real engineers and scientists, are also about to reduce the hardware costs and make life easier.

### Event Engine

Because of the storage internals being factored out the separate service, the additional transaction contents-based event engine implementation is required. It is now impossible to alert the CyberWay executable from the various database if something happened or not, just like it was in EOS. Monitoring-purposed event engine, implemented as a part of updateable application, takes back the ability to track changes coming with every transaction, even if the data storage is completely outside.

### Virtualization

Just like EOS, CyberWay requires for the transaction behaviour to be updated easier, than updating the whole cluster software. That is why the WebAssembly engine is used for the virtualization purposes and with C++ as primary language for the application development.

## Separation

Why don’t just patch EOS?

Several troubles are about the data itself, and not the code:

* EOS’s architecture made the memory quant an expensive one: according to the <https://eosrp.io> the cost of such a memory quant fluctuates from $0.2 to $0.5. That means any transaction-intensive application (e.g. some social applications) with even a quite small amount of active users (e.g. 2000-3000) would take at least 400MB per week, which would cost up to $200,000.
* EOS’s custom transaction behaviour is stored inside the huge hash-table allocated over a shared memory and the access is provided with an interface, based on quite sofisiticated executable logic, which also costs.

  The obvious solution - to make a cache service and process the data all inside it - is also quite a task because:

  * The so-called “Constitution” of EOS defines the largest time interval available for the unused data to be stored with the same ownership as 3 years. This is quite unacceptable with some kind of applications (e.g. social ones) demanding data availability from the very beggining, but the changes are hard to make because lots of other application types are perfetcly fine with this.
  * EOS is made to produce replication packages as fast as it can - about half of a second. Such a frequency is fine for marketing purposes, but it significally reduces the complexity of custom transaction logic. This is also unacceptable.
* Reduced amount of validators - only 21, and no significant increase is expected because of EOS protocol restrictions.
* Censorship availability for validators implemented right in the protocol core.

## Applications

Applications are welcomed to use the following.

### Shared Bandwidth

Shared bandwidth sets a limit for the user activity based on its’ staked asset amount, but no less than some basic threshold. This is required to prevent spam to database from the newcomers, and redistribute more computational resources to the succesful application developers.

Shared bandwidth is accounted separately for the network, RAM and CPU usage.

Coming to accounting - this is done with particular application bandwidth balance, which shares the convenient part for the user performing the transaction. That is why this is called “Shared” bandwidth. The application is a multisignature account, which requires at least one additional signature from the particular user, for its’ bandiwidth to be used.

This type of bandwidth allows CyberWay to provide applications with free on-boarding of users at early stages via CyberWay Acceleration Program. Later successful application could get CYBER tokens within Acceleration Program from special fund.

### Priority-Based Bandwidth

Priority-based bandwidth is required for the user to surely write the transaction. It is formed with the amount of core asset staked by the particular user and guarantees the transaction gets written right at next replication time. The whole amount of staked core asset forms the bandwidth market.

Each account gets a share from the whole bandwidth market according to the amount of core asset the account has staked. Considering the case some user owned and staked the significant part of the whole bandwidth supply means the reduction of the resources available for other users. This is definitely not something requiring applications want.

That is why CyberWay introduces the prioritization of the bandwidth. That means the bandwidth gets split to a couple of categories:

* Guaranteed bandwidth, which works exactly as EOS’s one.
* Priority bandwidth, which is defined according to the particular account priority.

How do account earn the priority?

There are couple of ways:

* Perform less transactions using the currently available guaranteed bandwidth. The priority lowers as more transactions gets put inside with a single user.
* Stake more core asset.

The guaranteed/prioritized bandwidth split ratio is set by the cluster validators.

### Memory Rent

Cluster RAM is something the applications require to work. In contrast to EOS, CyberWay supposes the RAM to be rented from so-called validators, but not to be owned. The rules are the following:

* Every validator sets a price for 1Kb memory per month. The price begins from the median price value across all validators.
* Users place their orders for some particular memory amount rent per month.
* The order is recognized as emplaced for a week, after that it gets evaluated in case the cluster-wide demanded memory is lower than the amount of proposed one.
* In case the proposed amount of memory is lower than demanded, proposed memory gets auctioned.

In case the memory rent time is up, but there is still some user data stored inside, the archive operation is introduced. Validators are in charge of initiating such an archivation and the restore is available for the user for the price median-valued among validators.

### DBMS-based State Storage

Inspite of existing so-called “blockchain” databases, CyberWay does not intend to implement the database management software and uses the external DBMS as a state storage for more reliability. For now, only MongoDB is available, but in case of requirements, more are coming. Such a configuration considered to be troublesome for managing, but more reliable in long term.

Embedded state storage is also available in CyberWay. RocksDB is used for the in-memory and in-daemon storage management component that is faster than MongoDB.

### Event Engine

As the state storage engine is incapsulated and factored out of the controller daemon, the event engine is implemented as a helper application, syncronizing and managing the data in external storages.

The input of such an application is a transaction set, each of which gets registered as “processed” and only after this the data are unpacked to state storage.

Such an approach allows to make sure the routine data operations are processed as required and to split the data managing daemon to single-responsibility micro-services.

## Domain Names

Every created account is not identified with a key as other databases do, but it gets a unique 8 byte identifier encoded in base32. Also a human-readable 63 byte length unique names are available for the assignment for every user. In case of the amount of such names is greater than one, it gets charged and called a “Domain Name”.

Every domain name can be auctioned from base protocol or created by owner of a lower-level domain name. Domain names are transferable and reassignable. Therefore, a need for conversion between a domain name and account identifier gets satisfied with a newly introduced sufficient mechanism as much as need for domain transactions. Domain transactions are transactions which get applied to the data only related to the particular domain-name/application.

## Protocol Properties

Protocol properties are also got changed comparing to EOS’s ones.

### Block Generation

First of all, block generation time is increased for achieving more stable node replication. EOS’s 0.5 second block replication time is fine for most application in case of all the nodes are located in the same datacenter. But for truly distributed protocol, this requires to be increased due to increased network latency. CyberWay supposes the block replication time to be 3 seconds.

### Validators

Validators are the key members of a protocol. They keep the database safe and consistent and get rewarded for that.

Inspite of EOS’s 21 default validators, in CyberWay the number of validators is to be increased up to 101 in the future. This is required for more decentralization to be achieved.

### Consensus Algorithm

CyberWay consensus algorithm is heavily inspired by Tezos’ and Cosmos’ one. So, active users are rewarded for voting and non-active users are punished for not voting.

Every account is allowed to vote for several validators with staked tokens.

Validator’s weigh is determined as follows: w = m / sqrt(S), where m is a number of votes for any particular candidate, S is a total number of votes for any particular candidate (or number of stakes tokens as 1 vote is 1 token)

A particular validator receives a reward from the emission and redistributes a share of it among his supporters. In case of misbehavior, e.g. a block omission, the validator as well as his supporters are fined. The staked tokens are burned. This novelty makes block validators more responsible, and voters more careful and thoughtful.

The validators get a share of emission. The share depends on the total amount of staked tokens. The more tokens are staked, the less inflation is. Thus, the CyberWay has in-built incentives for users to participate in governance via voting. Moreover, the passive users are diluted as they do not get any rewards from validators.

What if some user considers another user to understand better, which validator is the best service provider? This gets covered by CyberWay with a proxy mechanism which ensures that some user could delegate his own assets to another user called “Proxy”. The proxy user gets fees for its service.

### Censorship

In contrast to EOS, CyberWay completely removes any inequality between the users. There are no privileged accounts, no so-called “Constitution”, no blacklists.

### Workers

Workers are the mechanism first introducted in BitShares. These are users, who get their issuance share for making improvements for the protocol. The improvement can be registered and referenced by any user, particular improvement to resolve is selected via voting by validators.

## Conslusion

CyberWay is a fork of EOS, specified to handle more complex applications with more decentralization available. Workers are considered to be the most powerful tool for decentralized protocol improvements. The scalability and performance CyberWay introduces is fine enough for running complex social applications or financial service apllications or gaming applications. The absence of censorship and priveledged accounts makes CyberWay more decentralized than EOS, while introduced technical features enable developers to build advanced applications on top of it.


# Main features of CyberWay

In anticipation of the release of a new blockchain called CyberWay Golos Сore team (the team developing golos.io) informs the community about the key technical provisions of the product. As mentioned previously, CyberWay is a fork of the well-known EOS platform. Keeping in mind that CyberWay inherits some EOS codebase, it's important to take a look at the differences of these two platforms.

## Reasons for creating CyberWay

EOS is excellent in terms of performance characteristics and smart contracts functionality. However, building applications on top of it without creating additional add-in is impossible.

Other reasons for choosing a separate way for CyberWay are given below:

* High costs of used memory in EOS. As of January 2019 (according to the eosrp.io source), a price for 1 KB of RAM data for storing was around $ 0,571. This means that storing only user data and consensus data on posts and voting results for a week (for a platform like golos.io) might require of at least 400 MB and could cost a minimum of $ 200,000.
* EOS smart contract data is stored in a huge hash table in shared memory and access to this data is possible via functions. The disadvantage of this solution is that in this case it is difficult to build search and aggregate queries. As a result the processing of data from this table becomes cumbersome. The most effective solution is to create cache services that would read data from blocks and save them straight to the databases where they can be easily processed. Implementing such a solution directly on the EOS platform is quite complicated.
* The EOS system system operates in accordance with the adopted Constitution representing a set of rules for resolving disputes in the form of a textual description (for example, if any user data are not used during 3 years the ownership of them shifts to EOS). It’s obvious that not every community could adopt the current EOS Constitution. That limits the user base of EOS and hinders application development. The EOS platform is focused on creating blocks with a maximum achievable frequency — two blocks per second. Such a high performance can be effective in marketing, but it limits the feasible complexity of smart contracts. CyberWay will meet demand of application developers that prefer reliability over speed (the goal for CyberWay is to have a block per 3 second).
* Besides Constitution, EOS has privileged accounts or privileged smart contracts. This could be a code that is associated with the privileged contract, for example, Ricardian contract that could be set as decision maker. Such privileged contracts do restrict decentralization. The resilience to censorship, the lack of a single point of failure and other manifestations of reliability of blockchain technologies are crucial for some applications and businesses. Regardless of general share of such businesses, the choice of a centralized solution as a rule is the way more preferable.

## Distinctive features of CyberWay and EOS platforms

### Differences in platform architecture

![Fig.1 — Structural diagram of EOS platform](/files/-LllOdnxQ9ou1jkSzI_H)

![Fig.2 — Structural diagram of CyberWay platform](/files/-LllOdnz8UnYt0q_C6iQ)

The main differences between EOS and CyberWay:

* The difference is in the set of functions that are transferred from smart contracts to the input of web assemblers. CyberWay has its own set of functions coming from smart contracts and used for bandwidth subsystem and data storage. Unlike EOS, CyberWay has event generator. The web assembler does not compile any functions but converts them into calls within blockchain thus creating embedded functions for the event generator.
* The way of accessing system state data.\
  In EOS system state data are stored in a database located directly on the blockchain node. The client does not have any direct access to the database meaning he is forced to contact blockchain node to obtain data. System state data in CyberWay are stored in a database management system (DBMS) and conveniently placed outside the blockchain node.
* The way of analyzing events and data processing.\
  When it comes to EOS, the analysis of events occurring in the blockchain is done via plug-ins. CyberWay has event generator that forms events on operations inside the blockchain and sends them straight to the event queue. Event information is processed by microservices. The structure of the interactions between microservices and the blockchain is client dependent. This allows to build a flexible infrastructure for processing information that appears inside blockchain.
* The way how bandwidth is allocated.\
  Bandwidth resources in EOS are allocated to all accounts regardless of their activity. In the case of low user activity resources allocated to “silent” users are not used. CyberWay bandwidth resources could be allocated to the applications and granted by them to the end users on demand according to the activities of users. This ensures more efficient bandwidth usage.

### Detailing the differences in bandwidth subsystems

The bandwidth subsystem allows the user to perform transactions in accordance with his or her share in the network.

In EOS system the newbies are given funds to the extent necessary to complete a transaction. It is assumed that any new user knows how to work in the system. He has to have a certain amount of staked tokens on his own balance to execute transactions.

A newly attracted CyberWay user may not be familiar with the system. He could start using any CyberWay-based application without any tokens in his wallet. When any user-generated transaction happens the application uses its own tokens to put it forward. In this case when user is no longer active no bandwidth resources are blocked.

If a user is ready to use CyberWay on his own he could buy system tokens and block them for transactions. Once the time has elapsed, the allocated and blocked bandwidth funds can be returned back to the liquid state.

Unlike EOS, CyberWay is built to attract not only users but applications as well and optimize the allocation of system tokens.

### Database differences

In EOS system state data are kept directly on a node in the database that construes a separate part of shared memory. This architecture limits the client's operations. The client can not get direct access to the database.\
The applications can only access the database indirectly via EOS node using very primitive set of functions.\
CyberWay system state data are located in the DBMS outside blockchain node, including consensus information. The DBMS is designed to store consensus data only. Big data (English big data) are stored in a separate database and contain all the necessary information about events in the system.

The access to the mentioned database is implemented via intrinsic functions called by WebAssembler virtual machine. There is no direct compilation of these functions as WebAssembler converts them into calls within the blockchain itself and creates embedded functions. The calls to the event engine are also added to this set of features. Calls for the event generator are also part of this set of functions. a mechanism inside the blockchain into which an arbitrary contract can add its own events (known as data sets) that will be delivered to the new microchip on the external microservice.

Any of the smart contracts can call a function while generating any event and, therefore, trigger the event generator. The event generator puts the event in the event queue. The events are consequently distributed to their respective recipients in the form of ready-made API calls with operations and parameters.

The CyberWay architecture is allowing to shape a microservice infrastructure around the blockchain site using the event model. It particularly allows you to implement both repository of social applications texts outside the blockchain and a history of operations performed in the blockchain one.

Unlike EOS, CyberWay architecture provides the client with flexible access to any of the repositories and grants any information of interest while in EOS each client request leads to a set of queries in the database. CyberWay allows the data needed to be gathered in different blocks. As a result, customers make a request to the database, where the aggregated and processed information is stored.

This structure makes implementing a repository for texts of social applications outside the blockchain possible, as well as a repository of the history of operations performed in the blockchain.

## Other differences between CyberWay and EOS

Although CyberWay inherits EOS logic it contains a number of features that distinguish it from EOS. Below are the most important features of CyberWay:

* Ability to process long domain names of accounts. Unlike EOS, where a domain name is limited to 12,5 characters, CyberWay limits domain name to 253 characters. The separated part of the domain name could be up to 63 characters. The long domain name allows the applications to offer services. At the same time the hierarchical structure ensures interconnections as the user could have a unique name (alias) within each service.
* Set of rules that ensures participation of users in selection of block producers. The users participating in the voting for block producers get remuneration as a percentage of rewards that validators receive for the blocks they oproduce. The users who do not participate in the voting, do not get remuneration, and thus are diluted by inflation the annual percentage of token emissions.
* Any user can propose or implement a new functionality for CyberWay thanks to funds allocated for Workers from the reward pool.
* The absence of supervisory authority in CyberWay. In EOS, all the rules are specified by a special document — the Constitution. The key decisions are made by ECAF (The EOSIO Core Arbitration Forum) and block producers are obliged to fulfill them. CyberWay does not have any special forums. Thus, all users have equal rights when interacting with the blockchain.
* The absence of both "grey" and "black" lists of accounts in Cyber Way. In EOS, block producers have «black» and «gray» lists of users. ECAF can make a ruling and put any user on these lists (taking into account the evidence of his or her malicious actions). A user who is unable to operate on the blockchain. The mentioned lists are synchronized outside the blockchain.
* CyberWay plans to increase the number of block producers till 101 in the future in order to create greater decentralization.

## Ancillary

One of the first applications to be implemented on CyberWay will be the Golos application. This application will be identical to Golos.io in terms of functionality. CyberWay capabilities will be demonstrated basing on this application.


# Bandwidth differences between EOS and CyberWay

## Allocation of bandwidth resources to the user within the EOS system

EOS users can perform transactions having a sufficient number of staked system tokens on his own balance suited for bandwidth acquisition. In the absence of these tokens they may be allocated a share of bandwidth for funds of another user. In fig. 1 a structural diagram describes a case of providing a bandwidth share to a user under the account name №2 at the expense of the user’s funds under the account name №1.

![Fig. 1 — Structural diagram of bandwidth allocation to account 2 using the funds of account 1](/files/-LquER6Tte_RovBPn_WY)

The fig. 1 clarifies that there are two parts of staked system tokens on the balance of each account, one of which can be spent on CPU resources acquisition only while the other — the acquisition of NET resources.

Account №1 allocates (i.e. delegates) a share of its funds (see shaded parts of the scheme) reserved only for the use of CPU and NET resources to account 2. In this case, the allocated funds will be withdrawn from balance of the account №1 and credited to the balance of the account №2 as resources reserved for the use of resources CPU and NET respectively only.

Proceeding the delegation of reserved funds can be executed in two versions:

* **allocation in option 1** (allocation of own bandwidth resources). Funds allocated can be used by account 2 for the acquisition of bandwidth resources of account 1 only. The delegated share of bandwidth (CPU, NET) will be added to the 2 bandwidth resources already held by the account. Account 2 after a certain time may refuse to use the bandwidth resources delegated to it. In that case, account 2 cannot transfer funds delegated to it from the state of reserved (staked) to normal system tokens. These funds will be returned back to the account 1 balance after three days;
* **allocation in option 2** (allocation of third-party bandwidth resources). Funds allocated can be used by account 2 to purchase bandwidth resources from the system from shared resources. Upon completion of the use of bandwidth resources, account 2 can remove these funds from the state of reserved (staked) to normal system tokens. These tokens will be credited to the account 2 balance after three days. Account 1 buys the resources of CPU and NET account 2 and gives it system tokens reserved for the purchase of these funds. &#x20;

Allocation operation can be performed under the circumstance that the total number of tokens reserved for acquiring bandwidth resources to the system is not less than the established threshold value. The fulfillment of this condition is controlled by the network. If this condition is not met, the delegation operation is blocked. If this condition becomes impracticable after the delegation operation, the return of tokens will also be blocked until the condition becomes fulfilled again.

## Allocation of bandwidth resources to the user in CyberWay system

User activity in the network is limited by the bandwidth allocated to him — the resources of bandwidth. It is decreasing with a reduction of the bandwidth allocated. The bandwidth share is allocated to the user in absolute accordance with the funds on his balance and reserved specifically for the bandwidth use. The bandwidth share for CPU, NET, and RAM resources is calculated separately. Bandwidth resources are located on the application balance and are allocated to the user directly when he performs a transaction in the system which ensures their dynamic distribution. The regulations of bandwidth allocation to a user in CyberWay are described below.

### Allocation of resources on the principle of shared bandwidth

A distributed application can encompass a single bandwidth on its balance and use it as a shared bandwidth. In this case, to allocate a bandwidth share to the user, the transaction created by it must be signed with two keys — the user's private key and the application's private key. The application creates a pair of private-public keys belonging to this account. The private key of the account is stored in the protected part of the service (website) while the public key is in the blockchain. The public key is used to control the compliance of signatures of accounts in a transaction with signatures that belong to accounts registered in the blockchain and are stored in the blockchain as exemplary (Fig. 2).

![Fig. 2 — Structural diagram of the allocation of bandwidth resources by shared bandwidth principle](/files/-LquER6V4mnGkLxB0RkF)

Allocation of the bandwidth share to the user (from the space of application's common resources) is carried out by demand meaning it happens when the user is proceeding a transaction. This achievement is available courtesy double-signature transaction implemented specifically for the bandwidth use. A transaction will fall to the blockchain only in the presence of two key signatures (the user and the application private keys). The user cannot perform any action without the application presence as well as the application cannot perform any action without the presence of the user.

### Allocation of resources on the priority bandwidth principle

The amount of the guaranteed bandwidth allocated to the specific account from overall bandwidth is in accordance with the number of system tokens blocked by this account. If the user brings a significant amount of system tokens to the blocked state for acquiring bandwidth the total amount of blocked tokens in the system will consequently increase while the bandwidth share that is in use of the other accounts will decrease. This creates possibility of a bandwidth shortage for the others which will prevent the incorporation of their transaction in the next formed block. That means their activity in the system will be definitely reduced.

All the users must be provided with equal conditions. That’s why CyberWay has implemented a resource allocation method based on the priority bandwidth principle.

The total bandwidth is divided into two zones:

* Guaranteed bandwidth zone (EOS classic version) which ensures the allocation of a share of resources to an account according to the number of blocked tokens;
* Priority bandwidth zone allocated to the account according to accounts’ priority. &#x20;

A user who has a considerable amount of system tokens at disposal is able to convert them (partially or fully) to a locked state and use the guaranteed bandwidth zone. A user who does not have this feature can choose the priority bandwidth zone. The order of inclusion of transactions in the unit in this bandwidth depends on the priority of the account.

The priority of the account at the time of the formation of the block is determined by two mediums: the priority of operations of this account and the number of operations already completed by it at this time. The user can enhance his priority by blocking (i.e. reserving) a certain number of system tokens specifically for this instance (a larger number gives a higher priority).

Account priority tends to decrease when completing the operations. An account with the least number of completed operations will have the highest priority while having the same number of blocked system tokens at his/her disposal. A user performing operations with a certain periodicity does not need to block system tokens to increase the priority of operations.

The proportion decision on how total bandwidth is distributed between the guaranteed and priority bands is made by block producers.

### Delegating the bandwidth resources on requestbw request

A user can use the services of one of the providers who has enough resources to be provided for temporary use (in the event of not having enough system tokens reserved (staked) himself for the bandwidth resources acquisition or even complete absence of any funds). In order to do this, the user (or the provider himself) needs to add an operation of providing bandwidth resources in the transaction created. The operation is as follows:

```
requestbw (account name, provider name)
```

Parameters:

* `account name` — the name of the account that needs to allocate bandwidth resources;
* `provider name` — the name of the provider providing bandwidth resources.

requestbw operation is performed directly by the smart contract logic on the provider end node specified in the request. The decision to provide bandwidth resources to an account is made at the smart contract level. The smart contract logic checks the presence of the account name in the table of registered users, as well as the presence on the balance of the smart contract of the necessary number of reserved (staked) tokens to allocate bandwidth resources. If these conditions are met, the account specified in the request is allowed to allocate bandwidth resources. The logic of the smart contract for the received request sends a confirmation in the form:

```
confirmbw (account name, bwlimit)
```

Parameters:

* `account name` — the name of the account that needs to allocate bandwidth resources;
* `bwlimit` — the maximum possible value of bandwidth resources allocated to the account. &#x20;

The bandwidth resources required to complete the transaction are debited from the balance of the provider's smart contract.\
In case the smart contract does not have the required number of reserved tokens, this smart contract generates a similar request for the next smart contract with which it has an agreement to allocate bandwidth resources, requests bandwidth resources from the next smart contract, indicating the account names and provider. In the absence of the necessary funds for the next smart contract, a similar request is generated for the next smart contract. The next specific smart contract is selected in accordance with the logic of the previous smart contract and their agreement on the allocation of resources. As soon as a smart contract with the available means to allocate bandwidth resources is detected in the request chain, this smart contract sends a confirmation message of `confirmbw`.

The bandwidth resource allocation algorithm in the form of a block diagram is shown in Fig. 3.

![Fig. 3 — Structural diagram of the bandwidth resource allocation request processing algorithm](/files/-LquER6YVetBX96LoEzr)

In the event that none of the smart contracts can allocate bandwidth resources to the account specified in the request, the transaction is not performed and the user is sent a refusal message.

To execute requestbw, it is enough in the transaction to have only one signature — the user's private key.

## Key differences between bandwidth allocation algorithms in EOS and CyberWay

In the EOS system, bandwidth resources are allocated by the application to all accounts, regardless of their activity. The application can have users with both high and low activity, as well as users who have been absent from the system for a long time. The allocated bandwidth resources to users with low activity seem to become unclaimed, as a result of which the bandwidth resources used in the application are limited, which could be allocated to attract new users.

Unlike EOS, the implemented logic of the bandwidth subsystem in CyberWay provides the allocation of CPU, NET and RAM resources taking into account the degree of user activity and the presence of remaining resources in the application. Since bandwidth resources are on the balance of the application, in the event of users with low activity appearing in the system or disappearing, the decision on the reallocation of resources remains with the application. Therefore, bandwidth resources in CyberWay are used more efficiently.

In EOS system, the bandwidth resources allocated to the account in the CPU part (and similarly in the NET part) are calculated by the formula:

```
CPU_bandwidth = CPU_token / (total number of CPU_token)
```

Variables:

* `CPU_token` — the number of reserved system tokens on the account balance allocated for the acquisition of a share of CPU resources;
* `total CPU_token` — the total number of reserved system tokens in the application and allocated to CPU resources. &#x20;

In accordance with the formula indicated above, as bandwidth resources are allocated to new users, the allocated share to the next user will decrease. Therefore, to save the amount of allocated bandwidth, the next user needs to increase the number of CPU\_token. If the application has a significant number of inactive users, the efficiency of using bandwidth resources decreases.

In the CyberWay system, the bandwidth resources allocated to an account in the CPU (NET) part are calculated similarly in accordance with the above formula. Unlike EOS, bandwidth resources are not assigned to users and are on the balance of the application. Operations are performed by the application. Users with low activity are allocated a minimum amount of resources. In the case of users with high activity or lack of resources in the system, the missing part is purchased from the system.

## Conclusions

Despite the fact that both EOS and CyberWay systems implement bandwidth subsystems, the logic of their work has a significant difference. The bandwidth subsystem in CyberWay is implemented taking into account existing flaws in the logic of the bandwidth subsystem in EOS. CyberWay implements methods that ensure the use of node resources (nodes) more optimally.


# Bandwidth implementation

With this technical post we’re determined to record all the key points related to the technical implementation of the bandwidth in writing, which were covered by the Golos • Core team during the october Discord meeting itself (04.10.18 to be precise); familiarize both GOLOS users and developers with all the subtleties and reinforce the basic understanding with the help of some examples.

## Bandwidth implementation within the old ChainBase platform

In the application of GOLOS, the user's activity within the network happens to be limited to the bandwidth allocated to him.

The bandwidth value for each user is calculated on an individual basis in direct proportion to Golos Power (GP) available in his own balance. The initial balance amount is provided by vesting crediting courtesy the parent application account through which the registration actually takes place, in our case, for instance, it is operated through Golos.io.

The user can maintain activity in the system (for example, operate on transactions for publications or voting) only if there is a vesting sum equal to at least a base value within his own balance.

The minimum value of this base amount of funds in GOLOS is determined by delegates voting. To actually determine the base value, it is necessary to take into account the current rate of the Golos Power to GOLOS and the minimum bandwidth necessary to perform all the basic operations. For example, there is a bandwidth dependence on the size of the post published by the user and his current activity in the network (the average size of the blocks generated). Another example is the minimum Golos Power when voting for posts.

In the latest releases of the platform, it became possible to delegate the Golos Power with tangible detail added: instead of transferring the assets to the balance of a new user they simply become available for temporary use, which makes a crucial change to the economics of the application and makes it possible to spend funds from the balance of the application account more effectively.

During the use of both mechanisms, the application’s account will need to identify a middle ground for the value of funds transferred or delegated, in which the Golos Power on the balance of the new account will be sufficient for the normal activity of the active user, but most of the funds will not be blocked for inactive users.

## Bandwidth sharing

In the GOLOS application based on the CyberWay platform, which is a fork of the EOS system, the algorithm for calculating the bandwidth for the account is different as it does not depend on the Golos Power value anymore. Indeed, the bandwidth value is calculated in the separate order for CPU, NET, RAM and Storage and is paid by the blockchain system tokens rather than the application tokens.

A distributed application can have a total bandwidth on its balance sheet. Due to the fact that the behavior after registration from user to user may vary, the task of systematizing the use of the common bandwidth was solved, and the efficiency of its use was increased.

Thus, a dynamic distribution of resources of the total bandwidth is assumed depending on the actual use by a particular user. In other words, it was decided to allocate the user’s bandwidth share for the application as needed, that is, when the user performs transactions in the system.

This task can be accomplished using the implementation of two-step subscription bandwidth usage. There is a smart contract managing the multisig-account application in the prototype created. The most active members of the community among the elected ones are included in the number of the signatories of the account from the side of the application - obviously, the list of signatories to this account may vary.

To put a signature on behalf of the multisig-account of the application in order to use the resources of the common bandwidth, the community generates a pair of private-public keys. The public key is stored securely in the blockchain, while the private community key is stored in a secure part of the service (normally, a website). The signature on the use of resources is stamped with a private key, and the check is performed with a public key. Signers of a multisig-account can at any time change the common private key to access the bandwidth in case of inappropriate use. The private key allows you to use bandwidth, but does not allow it to be liquidated or sold (for example, on any exchange).

It is worth mentioning that the multisig-account of the application has the rights to buy and sell the bandwidth, provided that the majority of delegates sign their names under this operation. At the same time, the generated key can only be used to allocate bandwidth, and for protection purposes, its regular regeneration is recommended.

When creating a new user account, it becomes necessary to pay for the storage location of the account in the blockchain's RAM. So that the user would pass the payment for the creation of a new account and the application would not spend additional money for that too, there is a possibility for the new account to remain on the community balance. In this case, the account is created with two pairs of public-private keys. The account has a threshold equal to 2 (two private signatures are required to complete the transaction), and each key has a weight equal to 1. One private key is given to the user, and the second is stored in the protected part of the community service.

As a result, each transaction created by a user is signed by two keys - a user private key and a private key belonging to the community. A transaction can go into a blockchain only if there are signatures of these two keys, that is, the user cannot perform actions without the participation of the application, and the application cannot perform actions without the participation of the user.

The implementation of this solution allows you to more flexibly allocate bandwidth resources. For example, in the event that a user with low activity appears in the system, limited to registration, a minimal amount of resources will be allocated for its use. In the future, community delegates will be able to adjust the bandwidth (buy it for new users in case of lack of resources, etc.).

It is important that each user at any time has the opportunity to redeem his account from the application and exit the two-sign rule for each transaction, which requires redeeming space for storing his account from the community for system tokens. The redemption cost is determined by the blockchain rules - this is the number of system tokens that must be paid for RAM to store the account with its balances. The user needs to take into account that in order to complete transactions, he will need to purchase blockchain system tokens for using the bandwidth resources, such as CPU and NET.

In order to summarize, CyberWay platform will supposedly represent two types of users: those using the personal bandwidth and those using the total bandwidth available on the balance of a certain application.

It is important to add that this system has the right to exist not only within the framework of the “application + user” scenario, but also into the “user + another user” scheme. Any account will be able to sell its own bandwidth at fixed prices, which will form an alternative liquid bandwidth scheme in the system.


# How to Launch EOS dApps on CyberWay

CyberWay services allow users to create their own applications with their own tokens, as well as migrate applications from other platforms and deploy them on the CyberWay blockchain while preserving accounts, keys, and funds. Thus in August 2019, [transit](https://docs.cyberway.io/validators/transit_guide) of the Golos blockchain to the CyberWay platform was successfully completed.

EOS dApp developers can easily duplicate their dApp onto CyberWay with just a few clicks, and gain an immediate access to CYBER Token holders. You are welcome to follow the instructions provided below.

**Step\_1** Visit a CyberWay’s dApp to create an account (i. e. [commun.com](https://commun.com)).

**Step\_2** Make sure to have enough CYBER tokens staked in your account to allocate resources. To convert tokens into CYBER you can use the following command:

```
cleos transfer <your account> cyber.stake <quantity>
```

Visit [Stake Usage Guide](https://docs.cyberway.io/validators/stake_usage_guide) for more information.

**Step\_3** Install the standard cleos developer tool.\
If you want to deploy the dApp on a separate server, we recommend that you read this [guide](https://docs.cyberway.io/devportal/create_application) first.

**Step\_4** Ensure that you have compiled your contract with a compatible CDT (Contract Development Toolkit). Currently this is [CyberWay CDT](https://doxygen-cdt.cyberway.io/index.html) based on EOSIO CDT 1.6.3 .

**Step\_5** Create an account for your smart contract:

```
cleos  system newaccount <Creator> <contractAccount> <contractAccountOwnerKey> <contractAccountActiveKey> --stake "100.0000 CYBER"
```

**Step\_6** Deploy your smart contract:

```
cleos set contract <contractAccount> <compiled contract code directory>  --abi <abi file name.abi> -p <contractAccount>@active
```

**Step\_7** Make sure the process is completed successfully.

```
cleos get info
```

It is considered, dApp has successfully been deployed if no errors appeared at run time.

**Useful links**\
[How to register as a validator candidate](https://docs.cyberway.io/validators/quick_reference)\
[Wallet and Key for Development](https://docs.cyberway.io/devportal/create_development_wallet)\
[Mainnet Connection Guide](https://docs.cyberway.io/validators/mainnet_connection)\
[Referral program](https://docs.cyberway.io/devportal/application_contracts/golos_contracts/golos.referral_contract)


# Glossary

## ABI

The Application Binary Interface (ABI) is a JSON-based description on how to convert user actions between their JSON and binary representations. The ABI may also describe how to convert the database state to/from JSON. Once you have described your contract via an ABI this allows developers and users to interact with your contract seamlessly via JSON.

## Account

An account is a unique identifier and a requirement to interact with CyberWay blockchain. Unlike most other cryptocurrencies, transfers are sent to a human readable account name instead of a public key, while keys attributed to the account are used to sign transactions.

## Account Name

An account name is a human-readable identifier that is stored on the blockchain. Account names can consist of individual parts separated by the symbol "dot". Wherein, two "dot" symbols near each other are not allowed. Account names can only contain the alphanumeric characters, the "hyphen" symbol can be used as well, but should not be at the beginning or end of any account name part. Capital letters in an account user name are unacceptable.

## Action

Functionality exposed by a smart contract that is exercised by passing the correct parameters via an approved transaction to CyberWay network.

## Bandwidth

Bandwidth represents resources allocated to an account for performing a transaction, as well as for storing its personal information. Bandwidth resources include CPU, RAM, NET, and Storage.

## Block

A special structure for recording a group of transactions in the Bitcoin system and similar ones. A block consists of a header and a list of transactions. The block header includes its own hash, the hash of the previous block, transaction hashes, and additional overhead information.

## Blockchain

A strictly structured database with certain rules for building chains of transactions and access to information that excludes data theft, fraud, violation of property rights, etc.

## Blockchain Application

A blockchain application is a software application that has integrated a blockchain in its architecture as the storage layer for part of, or, all of its data. This includes software applications that do not own their own contract on the blockchain and instead only interact with the system contracts of the blockchain.

## Block Log

The block log is an append only log of blocks written to disk and contains all the irreversible blocks.

## Community

A group of persons formed around some point of interest. Community can be created by any user or group of users. Each community has its own point and parameters.

## Community leader

A person registered in the Commun application as a leader and is on top-leaders list of the same community. Leader is responsible for setting community parameters and moderating message content. Community leaders are elected by users of the same community through endless voting.

## Community user

A person is considered a community user if the person is registered in the Commun application and has a balance with points of same community. A user can be a member of several communities simultaneously if the user has balances with points of the same communities. Community user able to perform the following operations: posting, voting for a content and a leader, creating a community.

## Container

An object created using a Docker image and containing all the necessary components for the operation of the application. The container is a secure platform for the operation of the application.

## CPU

CPU is processing power granted to an account by a CyberWay based blockchain. The amount of CPU an account has is measured in microseconds, and represents the amount of processing time an account has at its disposal when executing its actions. CPU is recalculated after each block is produced, based on the amount of system tokens the account staked for CPU bandwidth in proportion to the amount of total system tokens staked for CPU bandwidth at that time.

## Chain State

The chain state or database is a memory mapped file, storing the blockchain state of each block (account details, deferred transactions, transactions, data stored using multi index tables in smart contracts, etc.). Once a block becomes irreversible the chain state is not cached anymore.

## Cleos

(`cleos` = `command line` + `eos`) `cleos` is a command line tool that interfaces with the REST API exposed by nodeos. `cleos` contains documentation for all of its commands. For a list of all commands known to `cleos`, simply run it with no arguments.

## Confirmed Transaction

On completion of the transaction, a transaction receipt is generated. Receiving a transaction hash does not mean that the transaction has been confirmed, it only means that the node accepted it without error, which also means that there is a high probability other validators will accept it. A transaction is considered confirmed when a nodeos instance has received, processed, and written it to a block on the blockchain, i.e. it is in the head block or an earlier block.

## Cryptographic Hash

A cryptographic hash function is a hash function which takes an input (or `message`) and returns a fixed-size alphanumeric string. The alphanumeric string is called the `hash value`, `message digest`, `digital fingerprint`, `digest` or `checksum`.

## Daemon

A program on Linux systems, launched by the system itself and running in the background without direct user interaction.

## Deferred Action

Deferred actions are actions sent to a peer action that are scheduled to run, at best, at a later time, at a block validator's discretion. There is no guarantee that a deferred action will be executed. From the perspective of the originating action, i.e., the action that creates the deferred action, it can only determine whether the create request was submitted successfully or whether it failed (if it fails, it will fail immediately). Deferred actions carry the authority of the contract that sends them. A deferred action can also be cancelled by another action.

## Deserialization

Deserialization is the reverse process of serialization. It turns a stream of bytes into an object in memory. CyberWay structures are enhanced with two operators which implement the serialization and deserialization of data to and from the database.

## Digital Signature

A digital signature is a mathematical scheme for verifying the authenticity of digital messages or documents. A valid digital signature, where the prerequisites are satisfied, gives a recipient very strong reason to believe that the message was created by a known sender (authentication), and that the message was not altered in transit (integrity). Digital signatures are a standard element of most cryptographic protocol suites, and are commonly used for software distribution, financial transactions, contract management software, and in other cases where it is important to detect forgery or tampering.

## Dispatcher

Every smart contract must provide an `apply` action handler. The `apply` action handler is a function that listens to all incoming actions and performs the desired behavior. In order to respond to a particular action, code is required to identify and respond to specific action requests. `apply` uses the `receiver`, `code`, and `action` input parameters as filters to map to the desired functions that implement particular actions. To simplify the work for contract developers, CyberWay provides the CYBERWAY\_/EOSIO\_DISPATCH macro, which encapsulates the lower level action mapping details of the apply function, enabling developers to focus on their application implementation.

## Docker

Software to automate the installation of the application in the virtualization environment at the operating system level. Provides installation of an application with all its environments and dependencies into a container that can be ported to any Linux system with cgroups support in the kernel, and also provides a container management environment.

## Docker-compose

Command line tool for managing multiple Docker multi-container applications.

## Docker-file

A file containing instructions and parameters for creating a Docker image for specific tasks.

## Docker image

Docker platform template, available only by reading and used to create containers.

## DPoS (Delegated Proof-of-Stake)

DPoS stands for "Delegated Proof of Stake" and is a consensus algorithm initially developed by Daniel Larimer in 2013 for Bitshares. It's sometimes referred to as "Democracy as Proof of Stake".

## Gallery

A collection of mosaics united by the same theme. Each community has its own gallery.

## Gem

User's opinion about an entity presented for discussion. Opinion can be expressed in the form of positive or negative comment, vote or other forms of attitude to the entity. The strength (weight) of opinion depends on number of points allocated to it by the user.

## Genesis (Greek genesis)

The beginning of the formation of any object or subject and the subsequent process of its development, which led to a certain state.

## Genesis Block

The genesis block is the very first block in the CyberWay blockchain. The subsequent block added after the genesis block becomes block `1` and continues the sequence. The genesis block lays the foundation for other blocks to be added to form a blockchain.

## Genesis Node

The genesis node is the first node in the blockchain network. The genesis node is used to perform a set of actions such as creating system accounts, initializing system, and token contracts in order to create a fully-functional blockchain with varying capabilities such as governance, resource allocation, and more.

## Head Block

The head block is the last block written to the blockchain, stored in reversible\_blocks.

## Indices

In the context of a multiple index table, an index is a particular ordering of the elements in the table. Multiple index indices allow the same data in one table to be viewed as different data structures by specifying the specific index on the table.

## Inline Action

Inline actions request other actions that need to be executed as part of the original calling action. Inline actions operate with the same scopes and authorities of the original transaction, and are guaranteed to execute with the current transaction. These can effectively be thought of as nested transactions within the calling transaction. If any part of the transaction fails, the inline actions will unwind with the rest of the transaction.

## Irreversible Block

A block is considered irreversible (i.e. immutable) on blockchain when (2/3rd + 1) of the currently elected validators have acknowledged it.

## Keosd

(`key` + `eos` = `keosd`) A component that securely stores keys in wallets.

## Key

A string of characters (bit string) used by the cryptographic algorithm for encrypting and decrypting messages, setting and verifying a digital signature, as well as identification. Keys are symmetric (the same key is used for encryption and decryption) and asymmetric (public and private).

## Mosaic

Data table of the entity discussion process from the moment of its publication to the reward completion moment to all participants in this process. An author at the time of publication creates a mosaic and inserts the first gem into it. Each user, leaving a comment or voting for the post, contributes a gem to this mosaic. Once the discussion and payments are terminated, this mosaic collapses.

## Multi-Index

CyberWay wraps the boost multi-index library to provide in memory data persistence. A subset of the functionality provided by the boost multi-index is provided in the CyberWay multi-index.

## Multisig

`Multisig` or `msig` is a short term for multiple signatures. It is used to describe the case in which one requires more than one account's permission to execute a transaction. CyberWay provides the system account, which can be used to push onto the blockchain the `multisig` proposals and their corresponding account's permission required to approve the proposal. `Multisig`, when used properly, increases the security of an account, the security of a smart contract, and it's also the method by which validators are able to affect changes within blockchain.

## NET

NET required to store transactions on CyberWay blockchain. The amount of NET an account has is measured in bytes, representing the amount of transaction storage an account has at its disposal when creating a new transaction. NET is recalculated after each block is produced, based on the system tokens staked for NET bandwidth by the account. NET measures the size of the transactions and not contract state.

## Node

A separate (software) device that is connected to the blockchain network according to the client-server scheme. Nodes are active elements and form the basis of the blockchain network technology.

## Nodeos

(`node` ​​+ `eos` = `nodeos`) the basic daemon of the CyberWay node, which can be configured using plug-ins to start the node. Examples of use: block production, dedicated API endpoints, and local development.

## Opus

Mosaic description type. It indicates what the mosaic describes, such as a post or comment.

## Packed Transaction

In order to transfer transaction content between nodes faster and to save storage space when storing transaction content in database, the transactions are `converted` from `json` into a packed form which is smaller in size. To get the packed version of a transaction one can use the `cleos` convert command.

## Pending Block

The pending block is the block currently being built by each node. Transactions are added to the pending block as they are received and processed. The pending block becomes the head block once it is written to the blockchain. Note that a head block is initially reversible.

## Permission

A weighted security mechanism that determines whether or not a message is properly authorized by evaluating its signature(s) authority. Every account has two default permissions, `owner` and `active`, but can also have custom permissions to further secure communications from an account to contracts. Every permission name has a "parent". Parents possess the authority to change any of the permissions settings for any and all of their children.

## Permission Threshold

The sum of permission weights necessary for a signature to be considered valid.

## Permission Weight

A permission weight is a value given to an account for authorization purposes. This is typically used in the context of a mutli-sig to give one or more accounts more control over a multi-sig than others.

## Permission level

Permissions are arbitrary names used to define the requirements for a transaction sent on behalf of that permission. Permissions can be assigned for authority over specific contract actions by "linking authorization" or linkauth. Every account has two native named permissions, `owner` and `active`.

## Plugin

A software component, made as a separate module and being an addition to the main program.

## Point

Main payment unit used for payments within a separate community. Point is not a token and can not be used in exchange trading. Points are used as coins to encourage community members and applied only within the community.

## Private key

A code string with which you can access your wallet or bitcoin address. Required for transactions.\
A private key is a secret key used to sign transactions. In CyberWay, a private key's authority is determined by it's mapping to a CyberWay account name.

## Proxy account

An account empowered with a specific voting authorization during the voting process. A proxy account can be declared by any user who is ready to accept votes from other users and vote for the validators on their behalf.

## Proxy account level

A conditional division of users into categories. The highest level of proxy account is zero, which is assigned only to validators. The first and further levels in ascending order are assigned to users who have declared themselves proxy accounts. The number of levels (categories) of proxy accounts is not limited. The number of proxy accounts of the same level is also not limited. The last level of proxy account is assigned to the ordinary user.

## Public key

A publicly available key that can be authorized to permissions of an account and can be used to identify the origin transaction. A public key can be inferred from a signature.

## P2P

A peer-to-peer computer network in which all participants (nodes) are equal in rights and can interact with each other, being a client and server simultaneously.

## RAM

RAM is a part of the bandwidth resources allocated to an account for the duration of a transaction for storing consensus information.

## Reversible Block

Any block on blockchain with a block number greater than the last irreversible block. Reversible blocks are blocks that are not currently guaranteed to be on the blockchain.

## Safe

Functionality allowing a user to manipulate funds in order to preserve them, namely to lock funds and withdrawal operations on them, including transfer, selling points to buy tokens. Access to funds is possible only after they are unlocked by the safe owner.

## Scope

Scope is a region of data within a contract. Contracts can only write to regions in their own contracts but they can read from any other contract's regions. Proper scoping allows transactions to run in parallel for the same contract because they do not write to the same regions. Scope is not to be conflated with an account name, but contracts can use the same value for both for convenience.

## Serialization

Serialization is the process of turning an object in memory into a stream of bytes so it can be stored on disk or sent over the network.

## Signature

A signature is a mathematical scheme for demonstrating the authenticity of digital messages or documents.

## Smart Contract

A smart contract is a computer protocol intended to facilitate, verify, or enforce the negotiation or performance of a contract.

## Stake

A share of bandwidth resources (RAM, NET, CPU and Storage) allocated to a user. The user can manage the share of resources allocated to him both independently and entrust its use to another user (delegate the share of resources).

## Staked tokens

Tokens allocated for a stake acquisition that can’t be used for anything else in this state. The user can stake active tokens listed on his/her balance or deposit them. Also, the user can perform the reverse operation — withdraw tokens from the staked state to active.

## Storage

Storage is a part of the bandwidth resources allocated to an account for storing personal account information.

## System Contract

The design of the CyberWay blockchain calls for a number of smart contracts that are run at a privileged permission level in order to support functions such as validator registration and voting, token staking for CPU and network bandwidth, RAM purchasing, multi-sig, etc. These smart contracts are referred to as the system contracts and are the following, `bios`, `domain-names` `govern`, `multi-signature`, `stake` and `tokens` contracts.

## Tables

Tables in CyberWay blockchain are achieved via Multiple Index Table.

## Test Network

A test network or `testnet` is an instantiation of the CyberWay platform that is intended for testing purposes. Generally, the native token has no value and is given away to developers so they can test. Some features of a testnet may be disabled such as consensus and governance.

## Transaction

A complete all-or-nothing change to the Blockchain. A combination of one or more actions. Usually the execution result of a Smart Contract.

## Token CMN

Main coin registered in the system of CyberWay and introduced to exchange of funds between communities, as well as between Commun and Cyberway blockchain.

## Tracery

Mosaic identifier, which is a hash sum generated from post author name and publication title.

## Trusted Community Client

A person appointed by commun leaders to make decisions within the dApp application.

## Unconfirmed Transaction

A transaction is considered unconfirmed as long as no `nodeos` instance has received, processed, and written it to a block on the blockchain, i.e. it is not in the head block or a block earlier than the head block.

## Validator

A validator (or a block producer) is an identifiable entity composed of one or more individuals that express interest in participating in running CyberWay network. By participating it is meant these entities will provide a full node, gather transactions, verify their validity, add them into blocks, and propose and confirm these blocks. A block producer is generally required to have experience with system administration and security as it is expected that their full-node have constant availability.

## Validator Schedule

The list of validators who currently have the possibility of being selected to produce the next block. This list changes with every new block.

## WASM (Web-Assembly Machine)

WASM stands for WebAssembly. WASM is an emerging web standard with widespread support of Google, Microsoft, Apple, and others.

## WIF

WIF stands for Wallet Import Format and is an encoding for a private key. The following is an example of a WIF Private Key: 5HprTdeuiow57FgeRt39Bnmf4nEB3kEsreAbuatmU.

## Wallet

Wallets are clients that store keys that may or may not be associated with the permissions of one or more accounts. Ideally a wallet has a locked (encrypted) and unlocked (decrypted) state that is protected by a high entropy password.


# DEVELOPMENT ENVIRONMENT

* [Core Concepts](/development_environment/core_concepts)
* [1 Before You Begin](/development_environment/before_you_begin)
* [2 Install the CDT](/development_environment/install_cdt)
* [3 Create Development Wallet](/development_environment/create_development_wallet)
* [4 Start keosd and nodeos](/development_environment/start_keosd_nodeos)
* [5 Create Test Accounts](/development_environment/create_test_accounts)


# Core Concepts

## Accounts, Wallets and Permissions

### Accounts

An account is a human-readable name that is stored on the blockchain. It can be owned through authorization by an individual or group of individuals depending on permissions configuration. An account is required to transfer or push any valid transaction to the blockchain.

### Wallets

Wallets are clients that store keys (only keys, not tokens) that may or may not be associated with the permissions of one or more accounts. Ideally, a wallet has a locked (encrypted) and unlocked (decrypted) state that is protected by a high entropy password. The CyberWay repository comes bundled with a CLI client called `cleos` that interfaces with a lite-client called `keosd` and together, they demonstrate this pattern.

### Authorization and Permissions

Permissions are arbitrary names used to define the requirements for a transaction sent on behalf of that permission. Permissions can be assigned for authority over specific contract actions by linking authorization or linkauth.

## Smart Contracts

A smart contract is a piece of program code that can executed on a blockchain and keep the state of contract execution as a part of the immutable history of that blockchain instance. It is a self-executing set of functions (algorithms) with the terms of the agreement between parties being directly written into lines of code. The code and the agreements contained therein exist across a distributed, decentralized blockchain network. The code controls the execution, and transactions are trackable and irreversible. Developers can rely on that blockchain as a trusted computation environment in which inputs, execution, and the results of a smart contract are independent and free of external influence.

More details about smart contracts being used on CyberWay can be found [here](https://docs.cyberway.io/devportal/system_contracts).

## Delegated Proof of Stake (DPOS)

The CyberWay platform implements a decentralized consensus algorithm capable of meeting the performance requirements of applications on the blockchain called the Delegated Proof of Stake. Under this algorithm, a user who holds tokens on CyberWay blockchain, can select validators through a continuous approval voting system. Anyone can choose to participate in the block production and will be given an opportunity to produce blocks, provided this person can persuade token holders to vote for him/her.

More details about selecting validators can be found [here](https://docs.cyberway.io/validators/voting_for_validators).

## Bandwidth Resources

Account activity in the network is limited by the bandwidth allocated to it — the resources of bandwidth (CPU, NET, RAM and Storage). It is decreasing with a reduction of the bandwidth allocated. The bandwidth share is allocated to account in absolute accordance with funds on its balance. Bandwidth resources are located on the application balance and are allocated to acoount directly when this account performs a transaction in the system which ensures their dynamic distribution. User does not have to worry about in what proportion it is necessary to allocate funds for each of these bandwidth resources before performing transactions. The system automatically allocates the resources necessary for the transaction in accordance with their optimal consumption.

### RAM

RAM, in CyberWay blockchain, is one of the important system resources consumed by blockchain accounts and smart contracts. RAM acts as a permanent storage and is used to store metadata, such as account names, permissions, token balance and other data for speedy on-chain data access.

### Storage

Storage, in CyberWay blockchain, is referred to as `Storage bandwidth` and is used to store user's information (not metadata), such as posts, comments and so on.

### CPU

CPU, in CyberWay blockchain, represents the processing time of an action and is measured in microseconds (μs). CPU is referred to as `CPU bandwidth` in the `cleos` get account command output and indicates the amount of processing time an account has at its disposal when pushing actions to a contract.

### Network (NET)

NET, in CyberWay blockchain, is the `network bandwidth`, measured in bytes, of transactions and is referred to as `NET bandwidth` on the `cleos` get account command.

More details about the resources of bandwidth can be found [here](https://docs.cyberway.io/users/bandwidth_differences).


# 1 Before You Begin

We appreciate your interest in contributing to the CyberWay platform! We always welcome contributions from our community to make our code and docs better.

This section provides guidance on how to install the CyberWay binaries on your server. To do this, you need to:

* Prepare server
* Clone CyberWay repository
* Run the start\_light.sh script.

## Step 1: Prepare server

The server where CyberWay binaries are installed, must meet the following characteristics (or above):

* RAM size (a min. of): 8 GB
* disk space (a min. of): 20 GB

One of the following operating systems must also be installed on the server:

* Ubuntu 16.04
* Ubuntu 18.04
* MacOS Darwin 10.12 (or later versions)
* Centos 7
* Fedora 25 (or later versions)
* Mint 18

> **WARNING**\
> If you have a private key, it is strongly recommended to **save your private key** before proceeding.

If you have previous version of CyberWay installed on your system, please uninstall it before proceeding.

## Step 2: Clone CyberWay repository

Create a directory where you will upload sources and clone CyberWay repository:

```bash
mkdir ~/cyberway.launch
git clone https://github.com/cyberway/cyberway.launch  ~/cyberway.launch
```

## Step 3: Run the shell-script

> **Please, NOTE**\
> The script performs an installation and deployment of CyberWay on your server in automatic mode. By running the script, you connect your server to running block chain.

Go to the created CyberWay space and run the `start_light.sh` script:

```bash
cd ~/cyberway.launch
 ./start_light.sh
```

Configuration file, genesis data (a snapshot of CyberWay system state) and docker file should appear on your server:

* /etc/cyberway/config.ini
* /var/lib/cyberway/genesis-data/genesis.json
* /var/lib/cyberway/genesis-data/genesis.dat
* /var/lib/cyberway/docker-compose.yml

During the script execution, the following operations are done:

* creating the environment for CyberWay configuration on the server;
* downloading the Docker image;
* downloading the CyberWay genesis, including the files `genesis.json` and `genesis.dat`;
* creating Docker volumes to store the system state database and chain data;
* start the services `nodeosd` and `mongo`. Setting up these services occurs by `docker-compose.yml`.

The script runs the current version of CyberWay with the genesis data uploaded which is used as input. Successful completion of the script means a successful server connection to Mainnet as a seed-node.

The procedure for checking a connection of your server to Mainnet as a seed-node is given in [Appendix A](https://docs.cyberway.io/validators/mainnet_connection/appendix_a).

If you followed all the instructions given in that Appendix A and made sure that your server is fully synchronized with Mainnet, that meant that the server connected to Mainnet as a seed-node.


# 2 Install the CDT

This section provides guidance on how to install `cyberway.cdt` tools on your server.

The CyberWay Contract Development Toolkit (CyberWay CDT) is based on EOSIO CDT and is a collection of tools related to contract compilation. CyberWay CDT is primarily used for compiling contracts and generating ABI.

It is recommended to build and debug contracts on a specific server. Therefore, the server where CDT is installed, must meet the following characteristics (or above):

* RAM size (a min. of): 8 GB
* disk space (a min. of): 20 GB

One of the following operating systems must also be installed on the server:

* Ubuntu 16.04
* Ubuntu 18.04
* MacOS Darwin 10.12 (or later versions)
* Centos 7
* Fedora 25 (or later versions)
* Mint 18

**Attention**

* If you have previously installed CyberWay.CDT, run the `uninstall.sh` script (it is in the root of CyberWay.CDT repository) before downloading and using the binary releases.

## Install cyberway.cdt on local server

Installing `cyberway.cdt` requires you to perform the following actions:\
1\. Cloning the `cyberway.cdt` repository to your server\
2\. Building binaries\
3\. Tools installation

The last two actions are performed by scripts `build.sh` and `install.sh` located in the root of `cyberway.cdt`. These scripts are universal and designed for all operating systems supported by the CyberWay platform.

### Clone the cyberway.cdt repository

The location where `cyberway.cdt` is cloned is not that important because `cyberway.cdt` will be installing as a local binary in later steps. You can clone `cyberway.cdt` to "contracts" directory previously created or to any other location on your local system that is fit.

```bash
 $ cd CONTRACTS_DIR
 $ git clone --recursive https://github.com/cyberway/cyberway.cdt
```

### Build binaries

```bash
 $ cd cyberway.cdt
 $ ./build.sh
```

### Install tools

```bash
 $ sudo ./install.sh
```

The following tools will be installed to your local machine:

* cyberway-abidiff
* cyberway-cpp
* eosio-abigen
* eosio-cc
* eosio-init
* eosio-ld
* eosio-objcopy
* eosio-pp
* eosio-wasm2wast
* eosio-wast2wasm
* llvm-ar
* llvm-nm
* llvm-objdump
* llvm-ranlib
* llvm-readelf
* llvm-readobj
* llvm-strip

### Uninstall

```bash
 $ cd cyberway.cdt
 $ sudo ./uninstall.sh
```

The `install.sh` and `uninstall.sh` scripts need to be ran with `sudo` because various binaries of `cyberway.cdt` will be installed locally. It needs to be typed computer's account password.

## Important

Installing `cyberway.cdt` will make the compiled binary global, therefore it can be accessable anywhere. For this tutorial, it is strongly suggested that you do not skip the install step for `cyberway.cdt`, failing to install will make it more difficult to follow this and other tutorials and make usage more difficult in general.


# 3 Create Development Wallet

This section provides instructions for creating a wallet for use in developing or maintaining software. Before a user can make a change to program code of the product, he/she needs to create a wallet and keys for development.

**Wallet** — a repository of public-private key pair. Private key is stored in encrypted form and is needed to sign operations performed on the blockchain. Wallet is accessed using `cleos`.

> **About Wallets**\
> A common misconception in cryptocurrency regarding wallets is that they store tokens. However, in reality, a wallet is used to store private keys in an encrypted file to sign transactions. Wallets do not serve as a storage medium for tokens. Tokens are not stored in the wallets. Wallets store only keys for signing operations.
>
> A user builds a transaction object, usually through an interface, sends that object to the wallet to be signed, the wallet then returns that transaction object with a signature which is then broadcast to the network. When/if the network confirms that the transaction is valid, it is included into a block on the blockchain.

## Step 1: Create a Wallet

The first step is to create a wallet. Use `cleos` wallet create to create a new "default" wallet using the option `--to-console` for simplicity. If using `cleos` in production, it is wise to instead use `--to-file` so your wallet password is not in your bash history. For development purposes and because these are development and not production keys `--to-console` poses no security threat.

```bash
$ cleos wallet create --to-console
```

The `cleos` application will return a password to save. Further information appears with a reminder that this password will be needed when unlocking the wallet, and that without a password, it will be impossible to recover the imported keys.

```bash
Creating wallet: default
Save password to use in the future to unlock this wallet.  
Without password imported keys will not be retrievable.  
"PW5HuQcBBqb...............................kEiE36gweSxy"
```

Running the default command creates a wallet named «default». If you want to create a wallet with a different name (for example, when creating more than one wallet) you can use the `--name` option (or `-n`).

```
$ cleos wallet create --name second-wallet --to-console
```

As a result, a wallet with the `second-wallet` name is created.

## Step 2: Open the Wallet

Wallets are stored in the `keosd` application. Wallets are kept in the closed state by default. To open the wallet, you have to use the `open` operation.

```
$ cleos wallet open
or
$ cleos wallet open --name second-wallet
```

It will return:

```
Opened: default
or
Opened: second-wallet
```

To obtain a list of open wallets use the `list` operation.

```
$ cleos wallet list
```

It will return:

```
Wallets:
[
  "default",
  "second-wallet"
]
```

In the absence of purses in the open state, the following information will appear:

```
Wallets:
[
]
```

## Step 3: Unlock a Wallet

Despite the fact that the wallet is open, the `keosd` application keeps it in a locked state. To use the wallet, it must be unlocked by `unlock` operation.

```bash
$ cleos wallet unlock
or
$ cleos wallet unlock --name second-wallet
```

A password prompt will appear. Enter the password and press `enter`.

**Note:**

> You can enter the password directly on the command line by adding the `--password` option. For example,

```bash
$ cleos wallet unlock --password PW5...w2
```

You can get a list of open wallets by re-executing:

```
$ cleos wallet list
```

It should return:

```bash
Wallets:
[
  "default *",
  "second-wallet *"
]
```

The presence of the (\*) symbol means that the wallet is in the unlocked state.

## Step 4: Import keys into your wallet

After the wallet is created and unlocked, a pair of keys can be loaded into it - private and public. To do this, you can use the `create_key` operation. This operation allows you to generate keys and automatically load them into the wallet. By default, a key with type `K1` — privileged will be generated.

```bash
$ cleos wallet create_key
```

When having more than one wallet, you have specify the name of the wallet in the team, adding the `-name <text>` option.

```bash
$ cleos wallet create_key  --name second-wallet
```

It will return something like the following:

```bash
Created new private key with a public key of: "GLS8PE...,X6P..."
```

**Please note:**

> Unlike EOS, in CyberWay the public key code actually starts with the `GLS` characters.

## Step 5: Import the Development Key

Every new CyberWay chain has a default "system" user called "cyber". This account is used to setup the chain by loading system contracts that dictate the governance and consensus of the CyberWay chain. Every new CyberWay chain comes with a development key, and this key is the same. Load this key to sign transactions on behalf of the system user (cyberway)

```bash
$ cleos wallet import
```

You'll be prompted for a private key, enter the cyberway development key provided below:

```bash
5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3
```

You now have a default wallet unlocked and loaded with a key, and are ready to proceed

## Step 6: Lock a Wallet (Wallets)

Sometimes it is necessary to have your wallet locked. For instance, when the long-term interruptions in software development are occuring. To lock a single wallet you can use the `lock` operation.

```bash
$ cleos wallet lock
or
$ cleos wallet lock --name second-wallet
```

A message about locking the user's wallet should appear:

```bash
Locked: 'default'
or
Locked: 'second-wallet'
```

To lock all user wallets, use the `lock_all` operation.

```bash
$ cleos wallet lock_all
```

The following message on locking all user wallets should appear:

```bash
Locked All Wallets
```

## Important

Never use the development key for a production account! Doing so will most certainly result in the loss of access to your account, this private key is publicly known.

Our congratulations!!! You now have a default wallet unlocked and loaded with a key, and are ready to proceed!!!


# 4 Start keosd and nodeos

This section provides guidance on how to start `keosd` and `nodeosd` services.

## Step 1: Start nodeosd

### Start a node

To start a node, it is necessary to start two services — `nodeosd` and `mongo`. To simplify the startup process, use the `docker-compose` utility. Enter the directory where `docker-compose.yml` is located, and execute the services load command:

```bash
$ sudo docker-compose up -d
```

The option `-d` is required to run container in background.

### Check a launch of containers

To check if containers have been started successfully, run the following command:

```bash
$ sudo docker ps
```

To see text of log files, you can use the following commands:

```bash
$ sudo docker logs --tail 100 -f nodeosd
$ sudo docker logs --tail 100 -f mongo
```

Options: `--tail` — sets a number of text lines;\
`-f` — indicates that it is necessary to monitor the update log file.

Check that the text of log files does not contain error messages. There should also be messages about created containers with the names `nodeosd` and `mongo`. The text should have the following form:

```bash
info  2019-03-07T06:57:09.024 thread-0  producer_plugin.cpp:1491      produce_block        ] Produced block 00000c992d36ab56... #3225 @ 2019-03-07T06:57:09.000 signed by producera [trxs: 0, lib: 2564, confirmed: 0]
```

It should also have information about blocks received over the network:

```bash
info  2019-03-07T06:57:00.096 thread-0  producer_plugin.cpp:344       on_incoming_block    ] Received block 6d6ac52bfe754174... #3222 @ 2019-03-07T06:57:00.000 signed by cyber [trxs: 0, lib: 2562, conf: 0, latency: 96 ms]
```

## Step 2: Start keosd

### Start the keosd service

Connecting a node to blockchain is done using the `cleos` utility. This utility requires a running `keosd` service to store private keys. The `keosd` service can be started on user's computer via Docker.

Start the `keosd` service and connect it to the Docker network where `nodeosd` is running:

```bash
$ sudo docker run -ti -d --name keosd --net cyberway-net cyberway/cyberway:stable /opt/cyberway/bin/keosd
```

### Start the cleos service

Assign alias to run `cleos` in the container `keosd`:

```bash
$ alias cleos='sudo docker exec -ti keosd cleos --url http://nodeosd:8888'
```

### Check connection to blockchain

Check if your node has been connected to blockchain:

```bash
$ cleos get info
```

No errors should be while the services are running.

### Create storage for private key

```bash
$ cleos wallet create --file wallet.pass
```

The `keosd` service automatically locks storage if it is not in use. Storage can be unlocked using the command:

```bash
$ cleos wallet unlock --password 'sudo docker exec -ti keosd cat wallet.pass'
```

### Import the private key

To import your private key, you can use:

```bash
$ cleos wallet import --private-key <private-key>
```

## Troubleshutting

In case of errors while container is running, it is recommended to stop the services, remove Docker volume and create it again. To stop the services, you can use:

```bash
$ sudo docker-compose down
```

To remove Docker volume, you can use the following command:

```bash
$ sudo docker volume rm cyberway-mongodb-data cyberway-nodeos-data
```


# 5 Create Test Accounts

This section provides guidance on how to create an account name using a public key.

## About an account

An account is a collection of authorizations stored on the blockchain and used to identify a sender/recipient. It has a flexible authorization structure that enables it to be owned either by an individual or by group of individuals depending on how permissions have been configured. An account is required to send or receive a valid transaction to the blockchain.

This tutorial series uses two "user" accounts, `bob` and `alice`, as well as the default `cyberway` account for configuration. Additionally accounts are made for various contracts throughout this tutorial series.

## Create Test Accounts

> **Public Key Persistence**\
> In section [Create Development Wallet](https://docs.cyberway.io/development_environment/create_development_wallet), you created a development key pair and pasted the public key in the *Development Public Key* field for the value to persist throughout the tutorial.

In the following steps, if you see `YOUR_PUBLIC_KEY` instead of the public key value, you can either go back to section [Create Development Wallet](https://docs.cyberway.io/development_environment/create_development_wallet) and persist the value or replace `YOUR_PUBLIC_KEY` with the public key value manually.

Throughout these tutorials the accounts `bob` and `alice` are used. Create two accounts using `cleos create account`:

```bash
cleos create account cyberway bob YOUR_PUBLIC_KEY
cleos create account cyberway alice YOUR_PUBLIC_KEY
```

For each command that confirms that the transaction has been broadcast, you should see a confirmation message similar to the following:

```bash
executed transaction: 40c605006de...  200 bytes  153 us
#         cyberway <= cyberway::newaccount            {"creator":"cyberway","name":"alice","owner":{"threshold":1,"keys":[{"key":"EOS5rti4LTL53xptjgQBXv9HxyU...
warning: transaction executed locally, but may not be confirmed by the network yet    ]
```

## Public Key

Note in `cleos` command a public key is associated with account `alice`. Each CyberWay account is associated with a public key.

Be aware that the account name is the only identifier for ownership. You can change the public key but it would not change the ownership of your CyberWay account.

Check which public key is associated with `alice` using `cleos get account`:

```bash
cleos get account alice
```

You should see a message similar to the following:

```bash
permissions:
     owner     1:    1 GLS6MRyAjQq8ud7h...HuGYqET5GDW5CV
     active    1:    1 GLS6MRyAjQq8u...8BhtHuGYqET5GDW5CV
memory:
     quota:       unlimited  used:      3.758 KiB

net bandwidth:
     used:               unlimited
     available:          unlimited
     limit:              unlimited

cpu bandwidth:
     used:               unlimited
     available:          unlimited
     limit:              unlimited
```

Notice that actually `alice` has both `owner` and `active` public keys. CyberWay has a unique authorization structure that has added security for your account. You can minimize the exposure of your account by keeping the owner key cold, while using the key associated with your `active` permission. This way, if your `active` key were ever compromised, you could regain control over your account with your `owner` key.

In term of authorization, if you have an `owner` permission you can change the private key of `active` permission. But you cannot do so other way around.

> **Using Different Keys for Active/Owner on a PRODUCTION Network**\
> In this tutorial we are using the same public key for both *owner* and *active* for simplicity. In production network, two different keys are strongly recommended.

## Troubleshooting

If you get an error while creating the account, make sure your wallet is unlocked:

```bash
cleos wallet list
```

You should see an asterisk (\*) next to the wallet name like this one:

```bash
Wallets:
[
  "default *"
]
```


# SOFTWARE MANUALS

## Core

* [nodeos:](/software_manuals/core/nodeos) The core service daemon that runs on every CyberWay node
* [cleos:](/software_manuals/core/cleos) A command line interface to interact with the blockchain and manage wallets
* [keosd:](/software_manuals/core/keosd) A key manager service daemon for storing private keys and signing digital messages
* [cyberway.cdt:](https://doxygen-cdt.cyberway.io) Contract Development Toolkit is a suite of tools used to build contracts

## How To Guides

* [How To Ban An Unwanted Account](/software_manuals/how_to_guides/ban_account)
* [How To Calculate Reward For An Author](/software_manuals/how_to_guides/calculate_reward_for_author)
* [How To Calculate Reward For A Beneficiary](/software_manuals/how_to_guides/calculate_reward_for_beneficiary)
* [How To Calculate Reward For A Curator](/software_manuals/how_to_guides/calculate_reward_for_curator)
* [How To Create A Wallet](/software_manuals/how_to_guides/create_wallet)
* [How To Create An Account](/software_manuals/how_to_guides/create_account)
* [How To Create A Proxy Account](/software_manuals/how_to_guides/create_proxy_account)
* [How To Create Key Pair](/software_manuals/how_to_guides/create_key_pair)
* [How To Delegate Resources](/software_manuals/how_to_guides/delegate_resources)
* [How To Deploy A Node Using A Snapshot](/software_manuals/how_to_guides/deploy_node_using_snapshot)
* [How To Deploy A Smart Contract](/software_manuals/how_to_guides/deploy_smart_contract)
* [How To Get Account Information](/software_manuals/how_to_guides/get_account_information)
* [How To Get Block Information](/software_manuals/how_to_guides/get_block_information)
* [How To Get Transaction Information](/software_manuals/how_to_guides/get_transaction_information)
* [How To Import A Key](/software_manuals/how_to_guides/import_key)
* [How To Link Permission](/software_manuals/how_to_guides/link_permission)
* [How To List All Key Pair](/software_manuals/how_to_guides/list_all_key_pair)
* [How To Stake Tokens](/software_manuals/how_to_guides/stake_tokens)
* [How To Stop A Node Using Docker](/software_manuals/how_to_guides/stop_node_using_docker)
* [How To Submit A Proposal For HardFork](/software_manuals/how_to_guides/submit_proposal_for_hardfork)
* [How To Transfer Tokens To A Worker](/software_manuals/how_to_guides/transfer_tokens_to_worker)
* [How To Undelegate Resources](/software_manuals/how_to_guides/undelegate_resources)
* [How To Unlink Permission](/software_manuals/how_to_guides/unlink_permission)
* [How To Unstake Tokens](/software_manuals/how_to_guides/unstake_tokens)
* [How To Vote](/software_manuals/how_to_guides/vote)

## API Reference

* [Nodeos Chain API](/software_manuals/api_reference/nodeos_chain_api)
* [Nodeos Producer API](/software_manuals/api_reference/nodeos_producer_api)
* [Nodeos Net API](/software_manuals/api_reference/nodeos_net_api)

## Cleos Command Reference

* [Convert](/software_manuals/command_reference/convert)
* [Create](/software_manuals/command_reference/create)
* [Get](/software_manuals/command_reference/get)
* [Multisig](/software_manuals/command_reference/multisig)
* [Net](/software_manuals/command_reference/net)
* [Push](/software_manuals/command_reference/push)
* [Set](/software_manuals/command_reference/set)
* [Sign](/software_manuals/command_reference/sign)
* [System](/software_manuals/command_reference/system)
* [Transfer](/software_manuals/command_reference/transfer)
* [Version](/software_manuals/command_reference/version)
* [Wallet](/software_manuals/command_reference/wallet)


# Core

* [nodeos:](/software_manuals/core/nodeos) The core service daemon that runs on every CyberWay node
* [cleos:](/software_manuals/core/cleos) A command line interface to interact with the blockchain and manage wallets
* [keosd:](/software_manuals/core/keosd) A key manager service daemon for storing private keys and signing digital messages
* [cyberway.cdt:](https://doxygen-cdt.cyberway.io) Contract Development Toolkit is a suite of tools used to build contracts


# nodeos

### Introduction

`nodeos` is the core service daemon that runs on every CyberWay node. It can be configured to process smart contracts, validate transactions, produce blocks containing valid transactions, and confirm blocks to record them on the blockchain.

> **Access Node** A local or remote CyberWay access node running `nodeos` is required for a client application or smart contract to interact with the blockchain.

## Nodeos Usage

`nodeos` is a command line interface (CLI) application. It can be started manually from the command line or through an automated script. Nodeos options are used mainly for housekeeping purposes, such as setting the directory where the blockchain data resides, specifying the name of the `nodeos` configuraton file, setting the name and path of the logging configuration file, etc. All CLI options can be found by running `nodeos --help` as shown below.

```bash
$ nodeos --help
```

```
Application Options:
Application Config Options:
  --plugin arg                          Plugin(s) to enable, may be specified 
                                        multiple times

Application Command Line Options:
  -h [ --help ]                         Print this help message and exit.
  -v [ --version ]                      Print version information.
  --print-default-config                Print default configuration template
  -d [ --data-dir ] arg                 Directory containing program runtime 
                                        data
  --config-dir arg                      Directory containing configuration 
                                        files such as config.ini
  -c [ --config ] arg (=config.ini)     Configuration file name relative to 
                                        config-dir
  -l [ --logconf ] arg (=logging.json)  Logging configuration file name/path 
                                        for library users
```


# cleos

## Introduction

`cleos` is a command line tool that interfaces with the REST API exposed by `nodeos`. Developers can also use `cleos` to deploy and test CyberWay smart contracts. To use `cleos`, you need the end point (IP address and port number) of a running `nodeos` instance.

## Cleos Commands

For a list of all `cleos` commands, run:

```bash
$ cleos --help
```

```
Command Line Interface to EOSIO Client
Usage: cleos [OPTIONS] SUBCOMMAND

Options:
  -h,--help                   Print this help message and exit
  -u,--url TEXT=http://127.0.0.1:8888/
                              the http/https URL where nodeos is running
  --wallet-url TEXT=unix:///user-name/eosio-wallet/keosd.sock
                              the http/https URL where keosd is running
  -r,--header                 pass specific HTTP header; repeat this option to pass multiple headers
  -n,--no-verify              don't verify peer certificate when using HTTPS
  --no-auto-keosd             don't automatically launch a keosd if one is not currently running
  -v,--verbose                output verbose errors and action console output
  --print-request             print HTTP request to STDERR
  --print-response            print HTTP response to STDERR

Subcommands:
  version                     Retrieve version information
  create                      Create various items, on and off the blockchain
  convert                     Pack and unpack transactions
  resolve                     Resolve domain names and usernames to account
  get                         Retrieve various items and information from the blockchain
  set                         Set or update blockchain state
  transfer                    Transfer tokens from account to account
  net                         Interact with local p2p network connections
  wallet                      Interact with local wallet
  sign                        Sign a transaction
  push                        Push arbitrary transactions to the blockchain
  multisig                    Multisig contract commands
  wrap                        Deprecated. Do nothing.
  system                      Send cyber.system contract action to the blockchain.
```

## Cleos Subcommands

To get help with any particular subcommand, run `cleos SUBCOMMAND --help`. For instance:

```bash
$ cleos create --help
```

```
ERROR: RequiredError: Subcommand required
Create various items, on and off the blockchain
Usage: cleos create SUBCOMMAND

Subcommands:
  key                         Create a new keypair and print the public and private keys
  account                     Create a new account on the blockchain
                              (assumes system contract does not restrict RAM usage)
```

`cleos` can also provide usage help for subcommands within subcommands. For instance:

```bash
$ cleos create account --help
```

```
Create a new account on the blockchain (assumes system contract does not restrict RAM usage)
Usage: cleos create account [OPTIONS] creator name OwnerKey [ActiveKey]

Positionals:
  creator TEXT                The name of the account creating the new account (required)
  name TEXT                   The name of the new account (required)
  OwnerKey TEXT               The owner public key or permission level for the new account (required)
  ActiveKey TEXT              The active public key or permission level for the new account

Options:
  -h,--help                   Print this help message and exit
  -x,--expiration             set the time in seconds before a transaction expires, defaults to 30s
  -f,--force-unique           force the transaction to be unique. this will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times
  -s,--skip-sign              Specify if unlocked wallet keys should be used to sign transaction
  -j,--json                   print result as json
  -d,--dont-broadcast         don't broadcast transaction to the network (just print to stdout)
  --return-packed             used in conjunction with --dont-broadcast to get the packed transaction
  -r,--ref-block TEXT         set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake)
  -p,--permission TEXT ...    An account and permission level to authorize, as in 'account@permission' (defaults to 'creator@active')
  --max-cpu-usage-ms UINT     set an upper limit on the milliseconds of cpu usage budget, for the execution of the transaction (defaults to 0 which means no limit)
  --max-net-usage UINT        set an upper limit on the net usage budget, in bytes, for the transaction (defaults to 0 which means no limit)
  --max-ram-usage UINT        set an upper limit on the ram usage budget, in bytes, for the transaction (defaults to 0 which means no limit)
  --max-storage-usage UINT    set an upper limit on the storage usage budget, in bytes, for the transaction (defaults to 0 which means no limit)
  --delay-sec UINT            set the delay_sec seconds, defaults to 0s
  --bandwidth-provider TEXT ...
                              set an account which provide own bandwidth for transaction
  --dont-declare-names        don't add `declarenames` action for resolved account names
```

## Cleos Example

The following `cleos` command creates a local wallet named `mywallet` and displays the password to the screen:

```bash
cleos wallet create -n mywallet --to-console
```

```
Creating wallet: mywallet
Save password to use in the future to unlock this wallet.
Without password imported keys will not be retrievable.
"GL...4gEE9sUG3D"
```


# keosd

### Introduction

`keosd` is a key manager service daemon for storing private keys and signing digital messages. It provides a secure key storage medium for keys to be encrypted at rest in the associated wallet file. `keosd` also defines a secure enclave for signing transaction created by `cleos` or a third part library.

### Operation

When a wallet is unlocked with the corresponding password, `cleos` can request `keosd` to sign a transaction with the appropriate private keys.

### Audience

> `keosd` is intended to be used by developers only.

## Keosd Usage

> **Recommended Usage** For most users, the easiest way to use `keosd` is to have cleos launch it automatically. Wallet files will be created in the default directory (`~/eosio-wallet`).

### Launching keosd manually

`keosd` can be launched manually from the terminal by running:

```bash
$ keosd
```

By default, `keosd` creates the folder `~/eosio-wallet` and populates it with a basic `config.ini` file. The location of the config file can be specified on the command line using the `--config-dir` argument. The configuration file contains the HTTP server endpoint for incoming HTTP connections and other parameters for cross-origin resource sharing.

### Auto-locking

By default, `keosd` is set to lock your wallet after 15 minutes of inactivity. This is configurable in the `config.ini` by setting the timeout seconds in `unlock-timeout`. Setting it to 0 will cause `keosd` to always lock your wallet.

### Stopping keosd

The most effective way to stop `keosd` is to find the `keosd` process and send a SIGTERM signal to it.

### Other options

For a list of all commands known to `keosd`, simply run it with no arguments:

```bash
$ keosd --help
```

```
Application Options:
Config Options for eosio::http_plugin:
  --unix-socket-path arg (=keosd.sock)  The filename (relative to data-dir) to 
                                        create a unix socket for HTTP RPC; set 
                                        blank to disable.
  --http-server-address arg             The local IP and port to listen for 
                                        incoming http connections; leave blank 
                                        to disable.
  --https-server-address arg            The local IP and port to listen for 
                                        incoming https connections; leave blank
                                        to disable.
  --https-certificate-chain-file arg    Filename with the certificate chain to 
                                        present on https connections. PEM 
                                        format. Required for https.
  --https-private-key-file arg          Filename with https private key in PEM 
                                        format. Required for https
  --access-control-allow-origin arg     Specify the Access-Control-Allow-Origin
                                        to be returned on each request.
  --access-control-allow-headers arg    Specify the Access-Control-Allow-Header
                                        s to be returned on each request.
  --access-control-max-age arg          Specify the Access-Control-Max-Age to 
                                        be returned on each request.
  --access-control-allow-credentials    Specify if Access-Control-Allow-Credent
                                        ials: true should be returned on each 
                                        request.
  --max-body-size arg (=1048576)        The maximum body size in bytes allowed 
                                        for incoming RPC requests
  --http-max-bytes-in-flight-mb arg (=500)
                                        Maximum size in megabytes http_plugin 
                                        should use for processing http 
                                        requests. 503 error response when 
                                        exceeded.
  --verbose-http-errors                 Append the error log to HTTP responses
  --http-validate-host arg (=1)         If set to false, then any incoming 
                                        "Host" header is considered valid
  --http-alias arg                      Additionaly acceptable values for the 
                                        "Host" header of incoming HTTP 
                                        requests, can be specified multiple 
                                        times.  Includes http/s_server_address 
                                        by default.
  --http-threads arg (=2)               Number of worker threads in http thread
                                        pool
Config Options for eosio::wallet_plugin:
  --wallet-dir arg (=".")               The path of the wallet files (absolute 
                                        path or relative to application data 
                                        dir)
  --unlock-timeout arg (=900)           Timeout for unlocked wallet in seconds 
                                        (default 900 (15 minutes)). Wallets 
                                        will automatically lock after specified
                                        number of seconds of inactivity. 
                                        Activity is defined as any wallet 
                                        command e.g. list-wallets.
  --yubihsm-url URL                     Override default URL of 
                                        http://localhost:12345 for connecting 
                                        to yubihsm-connector
  --yubihsm-authkey key_num             Enables YubiHSM support using given 
                                        Authkey
Application Config Options:
  --plugin arg                          Plugin(s) to enable, may be specified 
                                        multiple times
Application Command Line Options:
  -h [ --help ]                         Print this help message and exit.
  -v [ --version ]                      Print version information.
  --print-default-config                Print default configuration template
  -d [ --data-dir ] arg                 Directory containing program runtime 
                                        data
  --config-dir arg                      Directory containing configuration 
                                        files such as config.ini
  -c [ --config ] arg (=config.ini)     Configuration file name relative to 
                                        config-dir
  -l [ --logconf ] arg (=logging.json)  Logging configuration file name/path 
                                        for library users
```


# How To Guides

> **Note**\
> Many operations listed in this section are performed on command line using `cleos`. You have to install the currently supported version of `cleos`.

* [How To Ban An Unwanted Account](/software_manuals/how_to_guides/ban_account)
* [How To Calculate Reward For An Author](/software_manuals/how_to_guides/calculate_reward_for_author)
* [How To Calculate Reward For A Beneficiary](/software_manuals/how_to_guides/calculate_reward_for_beneficiary)
* [How To Calculate Reward For A Curator](/software_manuals/how_to_guides/calculate_reward_for_curator)
* [How To Create A Wallet](/software_manuals/how_to_guides/create_wallet)
* [How To Create An Account](/software_manuals/how_to_guides/create_account)
* [How To Create A Proxy Account](/software_manuals/how_to_guides/create_proxy_account)
* [How To Create Key Pair](/software_manuals/how_to_guides/create_key_pair)
* [How To Delegate Resources](/software_manuals/how_to_guides/delegate_resources)
* [How To Deploy A Node Using A Snapshot](/software_manuals/how_to_guides/deploy_node_using_snapshot)
* [How To Deploy A Smart Contract](/software_manuals/how_to_guides/deploy_smart_contract)
* [How To Get Account Information](/software_manuals/how_to_guides/get_account_information)
* [How To Get Block Information](/software_manuals/how_to_guides/get_block_information)
* [How To Get Transaction Information](/software_manuals/how_to_guides/get_transaction_information)
* [How To Import A Key](/software_manuals/how_to_guides/import_key)
* [How To Link Permission](/software_manuals/how_to_guides/link_permission)
* [How To List All Key Pair](/software_manuals/how_to_guides/list_all_key_pair)
* [How To Stake Tokens](/software_manuals/how_to_guides/stake_tokens)
* [How To Stop A Node Using Docker](/software_manuals/how_to_guides/stop_node_using_docker)
* [How To Submit A Proposal For HardFork](/software_manuals/how_to_guides/submit_proposal_for_hardfork)
* [How To Transfer Tokens To A Worker](/software_manuals/how_to_guides/transfer_tokens_to_worker)
* [How To Undelegate Resources](/software_manuals/how_to_guides/undelegate_resources)
* [How To Unlink Permission](/software_manuals/how_to_guides/unlink_permission)
* [How To Unstake Tokens](/software_manuals/how_to_guides/unstake_tokens)
* [How To Vote](/software_manuals/how_to_guides/vote)


# How To Ban An Unwanted Account

## Goal

Ban an account whose activity may harm the dApp functioning, as well as the blockchain as a whole.

## Before you begin

* Install the currently supported version of `cleos`.
* Understand the following:
  * Who is a Golos application leader.
  * What is a [multisig propose transaction](https://docs.cyberway.io/software_manuals/command_reference/multisig#multisig-propose-transaction).

## Steps

**Step 1**\
Identify accounts whose activities are causing a negative reaction. Assume these are: *usr11uyviduc*, *usr11xzbpec*, *usr11vzjrqzl*, *usr11deuytwa*.

**Step 2** Create transactions containing the action *ban* to block each of the listed accounts. You can call the action *ban* from contract `gls.ctrl` using command line *cleos*.

```bash
$ for i in <account-1> ... <account-n>; do
    cleos --url http://<node> push action gls.ctrl ban '["'$i'"]' --bandwidth-provider gls.ctrl/gls -p gls.ctrl -d -s -x <expiretime> 2>> <file_name.trx>
done
```

*Example*

```bash
$ echo > ban.trx
$ for i in usr11uyviduc usr11xzbpec usr11vzjrqzl usr11deuytwa; do
    cleos --url http://seed-1:8888 push action gls.ctrl ban '["'$i'"]' --bandwidth-provider gls.ctrl/gls -p gls.ctrl -d -s -x 1209600 2>> ban.trx
done
```

The name "i" is a loop parameter which are sequentially assigned the listed accounts.\
To prevent the transaction from becoming `expired` while signatures are being collected, you have to set the transaction expiretime, for example, *14* days that is *1209600* in seconds (*60×60×24×14=1209600*). The maximum allowable time is *45* days.\
Resulting actions code is saved in the file `ban.trx`.

**Step 3** Edit the file `ban.trx` to put the actions in one transaction.

**Step 4** Retrive a list of active leaders who have right to sign a transaction.\
This list can be retrieved from the *gls* account authorization:

```bash
$ cleos -u http://seed-1:8888 get account -j gls
```

From the result output, select and save the list of actors that will look like:

![Actors accounts](/files/-M8xqrLkgzHFmBEkzF1g)

**Step 5** Edit the list of active leaders. Convert the active leaders list to string form like this one `[{"account", "permission"}, ... ,{"account", "permission"}]`.

*Example*

```bash
[{"actor": "lavnch3wug2o","permission: "active"},{"actor": "2cv2urmf2pud","permission: "active"}, ... ,{"actor": "rtvmqvzi5lvt","permission: "active"}]
```

**Step 6** Submit the proposal. The proposal can be submitted by any user. It is created via *propose* taken from the contract `cyber.msig`.\
The command line looks like this one:

```bash
$ cleos -u http://<node> multisig propose_trx <proposal_name> permissions.json <file_name.trx> <proposer> -p <proposer>
```

*Example*

```bash
$ cleos -u http://seed-1:8888 multisig propose_trx ban.badusers permissions.json ban.trx shwojevqcywn -p shwojevqcywn
```

**Step 7** Pass the transaction to leaders for signing.\
The link can be taken from author of the proposal.

*Example*\
Leaders can go to `https://explorer.cyberway.io/account/shwojevqcywn/proposals/bad.badusers/4` and sign the transaction.\
. ![](/files/-M9SQOWizMurukjN3HKD)


# How To Calculate Reward For An Author

## Goal

Сalculate reward to author for a post in Golos application.

## Steps

To calculate total amount of reward for a post you can use the formula:

```
payout = reward_weight × funds × (sharesfn / rsharesfn)
```

* `payout` — total amount of reward for the post.
* `reward_weight` — a weight of reward for a post.
* `funds` — total number of tokens in the reward pool.
* `sharesfn` — a share of tokens that allocated in the rewards pool to be used for reward for the post (this parameter depends on a weight of the post).
* `rsharesfn` — number of tokens that allocated in the rewards pool to be be spent on reward for all posts (parameter depends on total weight of all posts).

To determine the amount of reward to author of the post it is recommended to use the formula:

```
author_reward = payout - curation_payout - ben_payout_sum.
```

* `curation_payout` — total amount of [fee to curators](https://docs.cyberway.io/devportal/application_contracts/golos_contracts/rewards_definition#salculating-the-amount-of-fees-to-curators-for-a-post) .
* `ben_payout_sum` — total amount of [payments to beneficiaries](https://docs.cyberway.io/devportal/application_contracts/golos_contracts/rewards_definition#salculating-the-rewards-to-beneficiaries-for-a-post) .

## Useful links

* [Determining Rewards for a Post](https://docs.cyberway.io/devportal/application_contracts/golos_contracts/rewards_definition)


# How To Calculate Reward For A Beneficiary

## Goal

Сalculate reward to beneficiary for a post in Golos application.

## Steps

To calculate the reward to a beneficiary, you can apply the formula:

```
ben_reward = (payout - curation_payout) × weight
```

* `ben_reward` — amount of reward to the beneficiary.
* `payout` — total amount of reward for the post, calculated by the [formula](https://docs.cyberway.io/devportal/application_contracts/golos_contracts/rewards_definition#calculating-a-total-reward-for-a-post).
* `curation_payout` — total amount of fee to curators for the post, calculated by the [formula](https://docs.cyberway.io/devportal/application_contracts/golos_contracts/rewards_definition#salculating-the-amount-of-fees-to-curators-for-a-post).
* `(payout` - curation\_payout)\` — total amount of rewards allocated to beneficiaries and author.
* `weight` — a weight of reward allocated to the beneficiary. This percentage value is set by the author at the time of posting.

**Important**

> The part of funds allocated to author for a post is distributed between the beneficiaries and the author. The share of total reward allocated to beneficiaries, as well as the number of beneficiaries, are determined by the author at the time of posting.

## Useful links

* [Determining Rewards for a Post](https://docs.cyberway.io/devportal/application_contracts/golos_contracts/rewards_definition)


# How To Calculate Reward For A Curator

## Goal

Сalculate reward to curator for a post in Golos application.

## Steps

Сalculate total amount of fee to curators for the post:

```
curation_payout = curators_prcnt × payout
```

* `curators_prcnt` — share (in percent), total reward for the post deducted to curators. This percentage is specified by author during the post creation. If author does not specify this percentage, the minimal curators percentage value is taken.&#x20;
* `payout` — [total reward](https://docs.cyberway.io/devportal/application_contracts/golos_contracts/rewards_definition#calculating-a-total-reward-for-a-post) for the post.

To calculate the reward `curator_rewardⱼ` allocated to individual curator j you can use this formula:

```
curator_rewardⱼ = curation_payout × (curatorswⱼ / weights_sum)
```

* `curatorswⱼ` — a weight of a positive vote j of the «upvote» type.
* `weights_sum` — total weight of all positive votes of the «upvote» type.
* `(curatorswⱼ / weights_sum)` — a share allocated to j-th curator of the total fee of all curators.

The more curator have staked tokens, the greater percentage of total reward is allocated to him.

## Useful links

* [Determining Rewards for a Post](https://docs.cyberway.io/devportal/application_contracts/golos_contracts/rewards_definition)


# How To Create A Wallet

## Goal

Create a `keosd` wallet.

## Before you begin

* Install the currently supported version of `cleos`
* Understand the following:
  * What is an [account](https://docs.cyberway.io/users/glossary#account);
  * What is a [public](https://docs.cyberway.io/users/glossary#public-key) and [private](https://docs.cyberway.io/users/glossary#private-key) key pair.

## Steps

Create a wallet and save the password to a file:

```bash
$ cleos wallet create --file password.pwd
```

This should produce similar output as below. Note the wallet is named default if no name is provided.

```bash
Creating wallet: default
Save password to use in the future to unlock this wallet.
Without password imported keys will not be retrievable.
saving password to password.pwd
```

Alternatively, you can name a wallet with `-n` option:

```bash
$ cleos wallet create -n named_wallet -f passwd
```

You should see something like the output below:

```bash
Creating wallet: named_wallet
Save password to use in the future to unlock this wallet.
Without password imported keys will not be retrievable.
saving password to passwd
```


# How To Create An Account

## Goal

Register an account in the system and delegate staked tokens to it so that this account can perform transactions.

## Before you begin

* Install the currently supported version of `cleos`.
* Understand the following:
  * What is an [account](https://docs.cyberway.io/users/glossary#account);
  * What is a [public](https://docs.cyberway.io/users/glossary#public-key) and [private](https://docs.cyberway.io/users/glossary#private-key) key pair.
* Created an Owner and an Active key pair.
* Imported a key pair which can authorize on behalf of a creator account.

## Steps

User `alice` creates the `bob` account name and transfers to him 100 CYBER tokens:

```bash
$ cleos system newaccount alice bob "100.0000 CYBER"
```

If the `--transfer` flag is added to command line then staked tokens will irrevocably be transferred to created account:

```bash
$ cleos system newaccount alice bob "100.0000 CYBER" --transfer
```


# How To Create A Proxy Account

## Goal

Declare yourself as a proxy accoun.

## Before you begin

* Install the currently supported version of `cleos`.
* Understand the following:
  * What is a [proxy account](https://docs.cyberway.io/users/glossary#proxy-account);
  * What is a  [proxy level](https://docs.cyberway.io/users/glossary#proxy-account-level);
  * What is a [stake](https://docs.cyberway.io/users/glossary#stake);
  * How does voting works.

## Steps

`alice` sets the proxy account level:

```bash
$ cleos system setproxylvl alice 1
```

`alice` is now registered as a proxy account.

## Useful link

* [Voting for validators](https://docs.cyberway.io/validators/voting_for_validators#voting-for-validators)

## Useful link

* [Proxy level](https://docs.cyberway.io/validators/voting_for_validators#terminology-used)


# How To Create Key Pair

## Goal

Create a public and private key pair for signing transactions.

## Before you begin

* Install the currently supported version of `cleos`.
* Understand the following:
  * What is a [public](https://docs.cyberway.io/users/glossary#public-key) and [private](https://docs.cyberway.io/users/glossary#private-key) key pair.

## Steps

To output the key pair to the console

```bash
$ cleos create key --to-console
```

To save the key pair to file

```bash
$ cleos create key --file FILE_TO_SAVEKEY
```


# How To Delegate Resources

## Goal

Delegate resource for an account.

## Before you begin

* Install the currently supported version of `cleos`.
* Ensure the reference system contracts from `cyberway.contracts` repository is deployed and used to manage system resources.
* Understand the following:
  * What is an [account](https://docs.cyberway.io/users/glossary#account);
  * What is a [stake](https://docs.cyberway.io/users/glossary#stake);
  * What is a [bandwidth](https://docs.cyberway.io/users/glossary#bandwidth) in CyberWay;
  * What are [CPU](https://docs.cyberway.io/users/glossary#cpu), [NET](https://docs.cyberway.io/users/glossary#net), [RAM](https://docs.cyberway.io/users/glossary#ram) and [Storage](https://docs.cyberway.io/users/glossary#storage) resources.

## Steps

`alice` delegates 100 tokens to `bob`. This operation is signed by the alice's active key:

```bash
$ cleos push action cyber.stake delegateuse '[alice, bob, "10.0000 CYBER"]' -p alice@active
```

or using specialized cleos system command `delegatebw`:

```bash
$ cleos system delegatebw alice bob "100.0000 CYBER"
```

> **Note**\
> The (RAM, NET, CPU, Storage) resources are not directly delegated. Instead of resources, their total cost is delegated — number of staked tokens.

## Useful links

* [The bandwidth in CyberWay](https://docs.cyberway.io/users/bandwidth_implementation#bandwidth-sharing)
* [The cyberway.stake contract](https://docs.cyberway.io/devportal/system_contracts/cyber.stake_contract)


# How To Deploy A Node Using A Snapshot

## Goal

Deploy a node using its node state snapshot.

## Steps

Obtain snapshot via API request:

```bash
$ curl --request POST --url http://<node>/v1/producer/create_snapshot
```

Example:

```bash
$ curl --request POST --url http://127.0.0.1:8888/v1/producer/create_snapshot
```

*Output*

```bash
snaphot-<hash>.bin
```

The file generated is the node state snapshot. This file alone will not be enough to restore your node. You will also need two more blocklog files. These are `blocks.index` and`blocks.log`. Before restoring a node, these files must be in the same place where they were generated.

To deploy node using the node state snapshot, you need to specify path to the snapshot in command line:

```bash
$ nodeos --snapshot <snapshot-directory>/snapshot-<hash>.bin
```

**Important**

> `--snapshot` is incompatible with `--geneis-json` and `--genesis` options as the snapshot contains genesis information.


# How To Deploy A Smart Contract

## Goal

Deploy dApp contract.

## Before you begin

* Install the currently supported version of `cleos`.
* Unlock the wallet which contains the private key of the contract account.

## Steps

Execute:

```bash
$ cleos set contract contract_account contract_directory_path
```

Replace the `contract_directory_path` with the path points to your contract folder.


# How To Get Account Information

## Goal

Query infomation of an CyberWay account.

## Before you begin

* Install the currently supported version of `cleos`.
* Understand the following:
  * What is an [account](https://docs.cyberway.io/users/glossary#account).

## Steps

Execute the command below:

```bash
$ cleos get account ACCOUNT_NAME
```


# How To Get Block Information

## Goal

Query infomation of a block.

## Before you begin

* Install the currently supported version of `cleos`.
* Understand the following:
  * What is a [block](https://docs.cyberway.io/users/glossary#block).

## Steps

Execute the command below:

```bash
$ cleos get block BLOCK_NUMBER
```

## Useful link

* [Block information](https://docs.cyberway.io/software_manuals/api_reference/nodeos_chain_api#get_block)


# How To Get Transaction Information

## Goal

Query infomation of a transaction.

## Before you begin

* Install the currently supported version of `cleos`.
* Understand the following:
  * What is a [transaction](https://docs.cyberway.io/users/glossary#transaction).

## Steps

Execute the command below:

```bash
$ cleos get transaction id
```

> **Note**\
> Be aware that you need to connect to a `nodeos` instance to query transaction information.


# How To Import A Key

## Goal

Import an key pair.

## Before you begin

* Install the currently supported version of `cleos`.
* Understand the following:
  * What is a [public](https://docs.cyberway.io/users/glossary#public-key) and [private](https://docs.cyberway.io/users/glossary#private-key) key pair.

## Steps

Execute the command below:

```bash
$ cleos wallet import
```

Type your private key. You should see something like this:

```
private key: imported private key for: GLS5...4NdoPs7G
```


# How To Link Permission

## Goal

Link a permission to an action of a contract.

## Before you begin

* Install the currently supported version of `cleos`.
* Understand the following:
  * What is an [account](https://docs.cyberway.io/users/glossary#account);
  * What is [permission level](https://docs.cyberway.io/users/glossary#permission-level);
  * What is an [action](https://docs.cyberway.io/users/glossary#action).

## Steps

Link a permission level *permlvl* to the action *transfer* of contract *contractname*

```bash
$ cleos set action permission alice contractname transfer permlvl
```


# How To List All Key Pair

## Goal

List all key pairs.

## Before you begin

* Install the currently supported version of `cleos`.
* Understand the following:
  * What is a [public](https://docs.cyberway.io/users/glossary#public-key) and [private](https://docs.cyberway.io/users/glossary#private-key) key pair.

## Steps

Unlock your wallet

```bash
$ cleos wallet unlock
```

List all public keys:

```bash
$ cleos wallet keys
```

List all private keys:

```bash
$ cleos wallet private_keys
```

You can enter the password directly on the command line by adding the `--password` option:

```bash
$ cleos wallet unlock --password PW5...3RwP2
```

> **Be careful**\
> Never use your private keys in a production enviroment!


# How To Stake Tokens

## Goal

Stake tokens for your account.

## Before you begin

* Install the currently supported version of `cleos`.
* Ensure the reference system contracts from `cyberway.contracts` repository is deployed and used to manage system resources.
* Understand the following:
  * What is an [account](https://docs.cyberway.io/users/glossary#account);
  * What is a  [stake](https://docs.cyberway.io/users/glossary#stake);
  * What is a [bandwidth](https://docs.cyberway.io/users/glossary#bandwidth) in CyberWay;
  * What are [CPU](https://docs.cyberway.io/users/glossary#cpu), [NET](https://docs.cyberway.io/users/glossary#net), [RAM](https://docs.cyberway.io/users/glossary#ram) and [Storage](https://docs.cyberway.io/users/glossary#storage) resources.

## Steps

Stake 100 CYBER tokens for `alice` account:

```bash
$ cleos push action cyber.token transfer '[alice, cyber.stake, "100.0000 CYBER"]' -p alice@active
```

or using "system stake" operation:

```bash
$ cleos system stake alice "100.0000 CYBER"
```

> **Note**\
> When you perform a transaction, you do not need to worry about which specific resource (RAM, NET, CPU or Storage) will be consumed more (or less) and how the staked tokens should be spent. The system dynamically and optimally distributes your staked tokens.

## Useful links

* [The bandwidth in CyberWay](https://docs.cyberway.io/users/bandwidth_implementation#bandwidth-sharing)
* [The cyberway.stake contract](https://docs.cyberway.io/devportal/system_contracts/cyber.stake_contract)


# How To Stop A Node Using Docker

## Goal

Correctly stop a node using docker.

## Steps

Update your doker image:

```bash
$ sudo docker pull cyberway/cyberway:v2.1.0
```

Pull out the current docker-compose.yml file:

```bash
$ sudo curl https://raw.githubusercontent.com/cyberway/cyberway.launch/master/docker-compose.yml --output /var/lib/cyberway/docker-compose.yml
```

Tell docker-compose to update containers following the directions given in docker-compose.yml:

```bash
$ cd /var/lib/cyberway
$ sudo docker-compose up -t 120 –d
```

## Useful links

* [Configuring the Docker Image](https://docs.cyberway.io/validators/testnet_installation/docker_configuration)
* [Commands Applicable to Any Kind of Container](https://docs.cyberway.io/validators/testnet_installation/main_commands)


# How To Submit A Proposal For HardFork

## Goal

Submit a proposal to implement it via HardFork.

## Before you begin

* Install the currently supported version of `cleos`.
* Understand the following:
  * Who is a worker.
  * What is a HardFork.
  * What is a [multisig propose transaction](https://docs.cyberway.io/software_manuals/command_reference/multisig#multisig-propose-transaction).

*Proposal* - an idea submitted by user to improve functionality or other characteristics of CyberWay blockchain. The proposal can be submitted as a separate post with a description of the idea without a way to implement it or with a description of the idea and a ready-made technical solution for its implementation.

*Worker* - a user directly performing work in accordance with the statement of work. A user’s account can be an individual or a group of people.

## Steps

To submit a proposal you can use the following command:

```bash
$ cleos multisig approve <proposer> <proposal_name> <permissions>
```

* `proposer`- user account submitting the proposal.
* `proposal_name` - unique name assigned to the multi-signature transaction when it is created.
* `permissions` - a level of permission required to approve the submitted proposal.

## Useful links

* [Multisig approve action](https://docs.cyberway.io/devportal/system_contracts/cyber.multi-signature_contract#approve) .


# How To Transfer Tokens To A Worker

### Goal

Create a multi-signature transaction for transferring funds from *gls.worker* account to a worker to pay for finished work. The transaction should be approved by Golos active leaders.

### Before you begin

* Install the currently supported version of `cleos`.
* Understand the following:
  * Who is a worker.
  * Who is a Golos application leader.
  * What is a [multisig propose transaction](https://docs.cyberway.io/software_manuals/command_reference/multisig#multisig-propose-transaction).

*Worker* - a user directly performing work in accordance with the statement of work. User’s account can be an individual or a group of people.

## Steps

**Step 1** Retrive a list of active leaders with the appropriate authority to create (as well as to sign) proposal transaction to pay a worker his work.

*Variant 1*\
Retrive the list of active leaders using *JS*.\
Go to `explorer.cyberway.io/account/gls.worker`.

![](/files/-M9SQP-k5GHc_IGwqbW8)

In `Permissions` section open the field of active Golos leaders with `gls@witn.smajor` account rights.

![](/files/-M9SQP-lRl6Bs_tGz-Un)

In the field `active`, account `gls.worker` has an authorization from `gls@active` - that is a list of active leaders. Copy the list of active leaders from `witn.smajor` to separate place.

![List to keep](/files/-M9SQP-mvLBhX-sfvf2p)

Signatures of these leaders will be necessary to sign proposal transaction.

*Variant 2*\
Retrive the list of active leaders using *cleos* command line.

Get *gls.worker* authority:

```bash
$ cleos -u http://seed-1:8888 get account gls.worker
```

*Output*

```bash
created: 2019-08-15T14:00:00.00
permissions:
     owner     1:    1 gls@owner
        active     1:    1 gls@active`
memory:
     quota:         0 bytes  used:        0 bytes
```

Get leaders authority:

```bash
$ cleos -u http://seed-1:8888 get account gls
```

*Output*

![](/files/-M9SQP-nVYL3MQe91Cw7)

**Step 2** Create proposal transaction.\
To prevent the transaction from becoming `expired` while signatures are being collected, you have to set the transaction expiretime, for example, *14* days that is *1209600* in seconds (*60×60×24×14=1209600*). The maximum allowable time is *45* days.

For convenience, you can get and use the list of supported options.

```bash
$ cleos push action --help
```

*Output*

![](/files/-M9SQP-oL71wtxoIuwf2)

The most important options are `-x`, `-s` and `-d`.\
The command line looks like:

```bash
$ cleos –u http://seed-1:8888 push action –d –s –x 1209600 cyber.token transfer '{"from":"gls.worker", "to":"shwojevqcywn", "quantity":"1000.000 GOLOS", "memo":""}' –p gls.worker –bandwidth-provider gls.worker/gls
```

*Output*

![](/files/-M8xqrLjzVf_PDY3xU2K)

Copy the transaction output code to a separate file (i.e. `worker.trx`).

**Step 3** Form a list of signatories.\
Retrive a list of active leaders who have right to sign a transaction. This list can be retrieved from the *gls* account authorization:

```bash
$ cleos –u http://seed-1:8888 get account –j gls
```

From the result output, select and save the list of actors that will look like:

![Actors accounts](/files/-M8xqrLkgzHFmBEkzF1g)

Convert list of actors to string form like this one `[{"account", "permission"}, ... ,{"account", "permission"}]`.

*Example*

```bash
[{"actor": "lavnch3wug2o","permission: "active"},{"actor": "2cv2urmf2pud","permission: "active"}, ... ,{"actor": "rtvmqvzi5lvt","permission: "active"}]
```

**Step 4** Submit the proposal.\
*Variant 1*\
Submit the proposal using *JS*.\
Go to `explorer.cyberway.io/account/cyber.msig/contract`, open the propose tab and fill the fields in.

![Fields to fill](/files/-M8xqrLlks6F1hdyjL3L)

* `proposer` – an author of proposal, any user can be (`shwojevqcywn` - in our case).
* `proposal_name` – proposal name (`worker.trans` - in our case).
* `requested` – kept string of signatories \[{...}].
* `trx` – kept transaction code that is {...}.
* `description` – some comment.

Enter the proposer name in the authorization field.\
Click `build transaction`.

*Variant 2*\
Submit the proposal using *cleos* command line:

```bash
cleos -u http://seed-1:8888 multisig propose_trx worker.trans permissions.json worker.trx shwojevqcywn -p shwojevqcywn
```

* `permissions.json` - the file containing permisions list in JSON form.
* `worker.trx` - the file containing transaction.

**Step 5** Sign the transaction with your private key and send a link to the transaction to Golos leaders.\
*Variant 1*\
Sign the transaction using *JS*.

![](/files/-M8xqrLmCrS5sbRcosjN)

*Variant 2*\
Sign the transaction using *cleos* command line.

```bash
cleos -u http://seed-1:8888 multisig approve shwojevqcywn worker.trans '{"actor":"shwojevqcywn", "permission":"active"}' -p shwojevqcywn
```

**Step 6** Review the proposal.\
*Variant 1*\
Review the proposal using *JS*.\
Go to `https://explorer.cyberway.io/account/shwojevqcywn/proposals`.\
The list of proposals sent by the proposer account will appear, indicating block number and transaction (worker.trans). Leaders can sign the transaction using this link.

![](/files/-M8xqrLnyVJGD-ztMrTn)

Click name `worker.trans` to get actual information about voting process.

![](/files/-M8xqrLoMPs_o9X52aLg)

*Variant 2*\
Review the proposal using *cleos* command line:

```bash
$ cleos -u http://seed-1:8888 multisig review shwojevqcywn worker.trans
```


# How To Undelegate Resources

## Goal

Return originally delegated resource for an account.

Beware that only the account which originally delegated resource can undelegate.

## Before you begin

* Install the currently supported version of `cleos`.
* Ensure the reference system contracts from `cyberway.contracts` repository is deployed and used to manage system resources.
* Understand the following:
  * What is an [account](https://docs.cyberway.io/users/glossary#account);
  * What is a [stake](https://docs.cyberway.io/users/glossary#stake);
  * What is a [bandwidth](https://docs.cyberway.io/users/glossary#bandwidth) in CyberWay;
  * What are [CPU](https://docs.cyberway.io/users/glossary#cpu), [NET](https://docs.cyberway.io/users/glossary#net), [RAM](https://docs.cyberway.io/users/glossary#ram) and [Storage](https://docs.cyberway.io/users/glossary#storage) resources.

## Steps

`alice` account withdraws 10 CYBER from `bob` account which were previously delegated to him: This operation is performed in two steps.

*Step\_1:* Request for a return of delegated staked tokens.

```bash
$ cleos push action cyber.stake recalluse '[alice, bob, "10.0000 CYBER"]' -p alice@active
```

or using specialized cleos system command `undelegatebw`:

```bash
$ cleos system undelegatebw alice bob "10.0000 CYBER"
```

*Step\_2:* Crediting withdrawn tokens to a stake.

```bash
$ cleos push action cyber.stake claim '[alice, bob, “CYBER”]' -p  alice@active
```

or using specialized cleos system command `claimbw`:

```bash
$ cleos system claimbw alice bob "CYBER"
```

> **Note**\
> The (RAM, NET, CPU, Storage) resources are not directly undelegated. Instead of resources, their total cost is undelegated — number of staked tokens.

## Useful links

* [The bandwidth in CyberWay](https://docs.cyberway.io/users/bandwidth_implementation#bandwidth-sharing)
* [The cyberway.stake contract](https://docs.cyberway.io/devportal/system_contracts/cyber.stake_contract)


# How To Unlink Permission

## Goal

Unlink a linked permission level.

## Before you begin

* Install the currently supported version of `cleos`.
* Understand the following:
  * What is an [account](https://docs.cyberway.io/users/glossary#account);
  * What is [permission level](https://docs.cyberway.io/users/glossary#permission-level);
  * What is an [action](https://docs.cyberway.io/users/glossary#action).

## Steps

Remove a linked permission level from an action *transfer* of contract *contractname* for `alice` account:

```bash
$ cleos set action permission alice contractname transfer NULL
```


# How To Unstake Tokens

## Goal

Withdraw tokens from the stake to active state for your account.

## Before you begin

* Install the currently supported version of `cleos`.
* Ensure the reference system contracts from `cyberway.contracts` repository is deployed and used to manage system resources.
* Understand the following:
  * What is an [account](https://docs.cyberway.io/users/glossary#account);
  * What is a [stake](https://docs.cyberway.io/users/glossary#stake);
  * What is a [bandwidth](https://docs.cyberway.io/users/glossary#bandwidth) in CyberWay;
  * What are [CPU](https://docs.cyberway.io/users/glossary#cpu), [NET](https://docs.cyberway.io/users/glossary#net), [RAM](https://docs.cyberway.io/users/glossary#ram) and [Storage](https://docs.cyberway.io/users/glossary#storage) resources.

## Steps

Unstake 100 CYBER tokens for `alice` account:

```bash
$  cleos push action cyber.stake withdraw alice "100.0000 CYBER"
```

or using "system withdraw" operation:

```bash
$ cleos system withdraw alice "100.0000 CYBER"
```

Tokens are withdrawn immediately without any delay. After this operation is completed, the `alice` stake will decrease by 100 CYBER tokens and her active tokens will be credited to the `alice` account balance.

## Useful links

* [The bandwidth in CyberWay](https://docs.cyberway.io/users/bandwidth_implementation#bandwidth-sharing)
* [The cyberway.stake contract](https://docs.cyberway.io/devportal/system_contracts/cyber.stake_contract)


# How To Vote

## Goal

Vote for a validator.

## Before you begin

* Install the currently supported version of `cleos`.
* Ensure the reference system contracts from `cyberway.contracts` repository is deployed and used to manage system resources.
* Understand the following:
  * What is a [validator](https://docs.cyberway.io/users/glossary#validator);
  * What is a [proxy account](https://docs.cyberway.io/users/glossary#proxy-account);
  * How does voting works.
* Unlock your wallet.

## Steps

*Option\_1:* Vote yourself. `alice` votes for the`bob` validator and allocates 50 CYBER tokens for it:

```bash
$ cleos system voteproducer prods alice bob "50.0000 CYBER"
```

*Option\_2:* Vote via a proxy account. If you are unable to vote, you can entrust your vote to a proxy account that will vote for you. To do this, you need to delegate the staked tokens to a proxy account.

`alice` delegates 50 CYBER tokens to `bob` that is a proxy account:

```bash
$ cleos system voteproducer prods alice bob "50.0000 CYBER"
```

## Useful links

* [Validators in CyberWay](https://docs.cyberway.io/validators/voting_for_validators#the-role-and-objectives-of-validators-in-the-system)
* [Voting for validators](https://docs.cyberway.io/validators/voting_for_validators#voting-for-validators)


# API Reference

* [Nodeos Chain API](/software_manuals/api_reference/nodeos_chain_api)
* [Nodeos Producer API](/software_manuals/api_reference/nodeos_producer_api)
* [Nodeos Net API](/software_manuals/api_reference/nodeos_net_api)


# Nodeos Chain API

API provides access to the blockchain information and interaction with the blockchain. For API request, it needs to perform an `POST` line with required parameters. The manual presents examples of requests using `curl`. Return code *200* indicates successful operation.

**API requests supported:**

* [get\_account](/software_manuals/api_reference/nodeos_chain_api#get_account)
* [get\_block](/software_manuals/api_reference/nodeos_chain_api#get_block)
* [get\_code](/software_manuals/api_reference/nodeos_chain_api#get_code)
* [get\_info](/software_manuals/api_reference/nodeos_chain_api#get_info)
* [get\_code\_hash](/software_manuals/api_reference/nodeos_chain_api#get_code_hash)
* [get\_block\_header\_state](/software_manuals/api_reference/nodeos_chain_api#get_block_header_state)
* [get\_abi](/software_manuals/api_reference/nodeos_chain_api#get_abi)
* [get\_raw\_code\_and\_abi](/software_manuals/api_reference/nodeos_chain_api#get_raw_code_and_abi)
* [get\_raw\_abi](/software_manuals/api_reference/nodeos_chain_api#get_raw_abi)
* [get\_table\_rows](/software_manuals/api_reference/nodeos_chain_api#get_table_rows)
* [get\_currency\_balance](/software_manuals/api_reference/nodeos_chain_api#get_currency_balance)
* [get\_currency\_stats](/software_manuals/api_reference/nodeos_chain_api#get_currency_stats)
* [get\_producers](/software_manuals/api_reference/nodeos_chain_api#get_producers)
* [get\_producer\_schedule](/software_manuals/api_reference/nodeos_chain_api#get_producer_schedule)
* [get\_scheduled\_transactions](/software_manuals/api_reference/nodeos_chain_api#get_scheduled_transactions)
* [abi\_json\_to\_bin](/software_manuals/api_reference/nodeos_chain_api#abi_json_to_bin)
* [abi\_bin\_to\_json](/software_manuals/api_reference/nodeos_chain_api#abi_bin_to_json)
* [get\_required\_keys](/software_manuals/api_reference/nodeos_chain_api#get_required_keys)
* [get\_transaction\_id](/software_manuals/api_reference/nodeos_chain_api#get_transaction_id)
* [get\_agent\_public\_key](/software_manuals/api_reference/nodeos_chain_api#get_agent_public_key)
* [resolve\_names](/software_manuals/api_reference/nodeos_chain_api#resolve_names)
* [get\_proxy\_status](/software_manuals/api_reference/nodeos_chain_api#get_proxy_status)

## get\_account

The request returns an object containing various details about a specific account on the blockchain.

**Params:**

* `(name) account_name` — An account that data is being requested for.
* `(symbol) expected_core_symbol` — A token name, consisting of a set of capital letters. This field is optional.

**Request examples:**

```bash
curl --request POST  -d '{"account_name" : "rows"}' http://<node>/v1/chain/get_account
```

```bash
curl --request POST  -d '{"account_name" : "cyber"}' http://<node>/v1/chain/get_account
```

```bash
curl --request POST  -d '{"account_name":"alice", "symbol":"SYS"}' http://<node>/v1/chain/get_account
```

### Responses

**Code:** 200 OK

**Value:**

```
{
  "account_name": "string",        // Account information about which is issued
  "head_block_num": 0,             // Hashed number of the last block created
  "head_block_time": "string",     // Date and time the last block was created (YYYY-MM-DDTHH:MM:SS.sss)
  "privileged": false,
  "last_code_update": "string",    // Date and time of the last code modification (YYYY-MM-DDTHH:MM:SS.sss)
  "created": "string",             // Point creation date and time (YYYY-MM-DDTHH:MM:SS.sss)
  "core_liquid_balance": "string", // A string representation of tokens, composed of a float with a precision of 4, and a symbol composed of capital letters between 1-7 letters separated by a space, example 1.0000 ABC.

  "ram_quota": 0,                  // A whole number
  "net_weight": 0,                 // A whole number
  "cpu_weight": 0,                 // A whole number

  "net_limit": "string",           // Net available resources
  "cpu_limit": "string",           // CPU available resources
  "ram_limit": "string",           // RAM available resources
  "storage_limit": "string",       // Storage available resources

  "ram_usage": 0,                  // Amount of memory used

  "permissions": "prods",
  "total_resources": {...},
  "self_delegated_bandwidth": {...},
  "refund_request": {...},
  "voter_info": {...},

  "stake_info": "string"            // Number of staked tokens on account balance
}
```

## get\_block

The request returns an object containing various details about a specific block on the blockchain.

**Params:**

* `(string) block_num_or_id` — A block number or a block id.

**Request example:**

```bash
curl --request POST  -d '{"block_num_or_id": "6707315"}' http://<node>/v1/chain/get_block
```

### Responses

**Code:** 200 OK

**Value:**

```
{
  "timestamp": "2020-04-20T16:28:09.000", // Date and time the block was created (YYYY-MM-DDTHH:MM:SS.sss)
  "producer": "string",                   // Account of validator who signed the block
  "confirmed": 21,                        // Number of validators confirming the block
  "previous": "006...9bd",                // Previous block ID
  "transaction_mroot": "1434...d09",      // Parent transaction ID
  "action_mroot": "dea...469",            // Parent action ID
  "schedule_version": 59218,
  "new_producers": null,                  // Account names of the new validators
  "header_extensions": [],
  "producer_signature": "SIG_K1_J...eR",
  "transactions": [                       // array of transactions included in the block
    {
      "status": "executed",               // Transaction status, takes one of the following values:
                                              "executed" - successful execution, lack of error messages;
                                              "soft_fail" - unsuccessful execution; errors that appeared during the process were processed;
                                              "hard_fail" - unsuccessful execution; errors that appeared during the process could not be processed;
                                              "delayed" - transaction execution is postponed;
                                              "expired" - the transaction timed out, the resources allocated for the transaction were returned to the owner
      "cpu_usage_us": 33823,              // CPU resource allocated for each transaction
      "net_usage_words": 88,              // Network resource allocated for each transaction
      "ram_kbytes": 19,                   // RAM resource allocated for each transaction
      "storage_kbytes": 0,                // Storage resource allocated for each transaction
      "trx": {                            // A transaction included in the block
        "id": "17...8d",
        "signatures": [
          "SIG_K1_K...24d",
          "SIG_K1_K...Fr3"
        ],
        "compression": "none",
        "packed_context_free_data": "",
        "context_free_data": [],
        "packed_trx": "a5cd...4000",
        "transaction": {...}
      }
    }
  ],
  "block_extensions": [],
  "id": "006...58f22d10",                  // The block ID
  "block_num": 6707315,                    // Number of the block
  "ref_block_prefix": 744221143
}
```

## get\_code

The request returns an object containing rows from the table for a specified account.

**Params:**

* `(name) account_name` — Account name on which the contract is based.
* `(bool) code_as_wasm` — Binary code. Default is `false`.

**Request example:**

```bash
curl --request POST  -d '{"account_name": "string", "code_as_wasm": 1}' http://<node>/v1/chain/get_block
```

### Responses

**Code:** 200 OK

**Value:**

```
{
  "account_name": "string",
  "wast": "string",         // Textual information (WAST from get_code is no longer supported)
  "wasm": "string",         // Binary code
  "code_hash": "string",
  "abi": {                  // ABI object
    "____comment": "string",
    "version": "string",
    "types": [
      {...}
    ],
    "structs": [
      {...}
    ],
    "actions": [
      {...}
    ],
    "events": [
      {...}
    ],
    "tables": [
      {...}
    ],
    "variants": []
  }
}
```

## get\_info

The request returns an object containing various details about the blockchain.

**Params:**\
No params required.

**Request example:**

```bash
curl --request POST --data '' http://<node>/v1/chain/get_info
```

### Responses

**Code:** 200 OK

**Value:**

```
{
  "server_version": "string",       // Hash code representing the last commit in the marked version
  "chain_id": "string",             // Hash string of a chain ID
  "head_block_num": 0,              // A number of the last received block in chain
  "last_irreversible_block_num": 0, // A number of the last block in a chain that is loaded into the system state
  "last_irreversible_block_id": "string", // Hash identifier of the last block in a chain that is loaded into the system state
  "head_block_id": "string",        // Identifier of the last block in a chain
  "head_block_time": "string",      // The time when the last block appeared in a chain
  "head_block_producer": "string",  // Block producer who signed the last block in a chain
  "virtual_block_cpu_limit": 0,     // Processor limit calculated after each block
  "virtual_block_net_limit": 0,     // Network limit calculated after each block
  "block_cpu_limit": 0,             // Actual maximum processor limit
  "block_net_limit": 0,             // Actual maximum network limit
  "server_version_string": "string" // String representation of a server version (patch version)
}
```

## get\_code\_hash

The request returns hash code of an object containing rows from the table for a specified account.

**Params:**

* `(name) account_name` — An account for which information in form of hash code is requested.

**Request example:**

```bash
curl --request POST  -d '{"account_name": "cyber.stake"}' http://<node>/v1/chain/get_code_hash
```

### Responses

**Code:** 200 OK

**Value:**

```
{
  "account_name": "cyber.stake",
  "code_hash": "3f5f05119...9d1c73a08b1"
}
```

## get\_block\_header\_state

The request retrieves the block header state. This query can only be applied to a block that is not irreversible.

**Params:**

* `string block_num_or_id` — A block\_number or a block\_id.

**Request example:**

```bash
 curl --request POST -d '{"block_num_or_id" : "006762...9c283"}' http://<node>/v1/chain/get_block_header_state
```

### Responses

**Code:** 200 OK

**Value:**

```
{
  "id":"006762...9c283",                         // Block ID
  "block_num":6775398,                           // Block number
  "header":{
    "timestamp":"2020-04-23T05:21:39.000",     // Time when the block appeared
    "producer":"string",                       // Account of the validator who created the block
    "confirmed":38,                            // Number of validators confirming the block
    "previous":"006762...860fd5",              // Previous block ID
    "transaction_mroot":"0000...0000",         // Parent transaction ID
    "action_mroot":"97ee40...98a8",            // Parent action ID
    "schedule_version":59678,                  // Schedule version
    "header_extensions":[],                    // Additional information
    "producer_signature":"SIG_K1_J...e9N"      // A signature of the validator who created the block
  },
  "dpos_proposed_irreversible_blocknum":6775366,
  "dpos_irreversible_blocknum":6775334,
  "bft_irreversible_blocknum":0,
  "pending_schedule_lib_num":6775337,
  "scheduled_shuffle_slot":213644813,
  "pending_schedule_hash":"d55bd...f4b6",
  "pending_schedule":{
    "version":59679,
    "producers":[                              // Validators that are in the pending schedule
      {"producer_name":"string","block_signing_key":"GLS7X...9ZpL"},
      {...}
    ]
  },
  "active_schedule":{
    "version":59678,
    "producers":[                              // Validators that are in the active schedule
      {"producer_name":"string","block_signing_key":"GLS7By...vt9s"},
      {...}
    ]
  },
  "blockroot_merkle":{
    "_active_nodes":[                          // Active node list
      "006762...60fd5",
      "..."
    ],
    "_node_count":6775397
  },
  "producer_to_last_produced":[
    ["string",6775384],                        // Account of a validator and the last block it produced
    [...]
  ],
  "producer_to_last_implied_irb":[
    ["string",6775356],                        // Account of a validator and the last irreversible block it implied
    [...]
  ],
  "block_signing_key":"GLS8...QU2u",
  "confirm_count":[1,1,2,2,2,3,...,21,22,23,24], // Number of confirmed blocks
  "confirmations":[]
}
```

## get\_abi

The request retrieves the ABI for a contract based on its account name.

**Params:**

* `(name) account_name` — Account on which the contract is based.

**Request example:**

```bash
curl --request POST  -d '{"account_name": "string"}' http://<node>/v1/chain/get_abi
```

### Responses

**Code:** 200 OK

**Value:**

```
  "account_name": "string",   // Account on which the contract is based
  "abi": {                    // ABI object
    "____comment": "string",
    "version": "string",
    "types": [
      {...}
    ],
    "structs": [
      {...}
    ],
    "actions": [
      {...}
    ],
    "events": [
      {...}
    ],
    "tables": [
      {...}
    ],
    "variants": []
  }
}
```

## get\_raw\_code\_and\_abi

The request retrieves raw code and ABI for a contract based on account name.

**Params:**

* `(name) account_name` — Account on which the contract is based.

**Request example:**

```bash
curl --request POST  -d '{"account_name": "string"}' http://<node>/v1/chain/get_raw_code_and_abi
```

### Responses

**Code:** 200 OK

**Value:**

```
{
  "account_name": "string", // Account on which the contract is based
  "wasm": "string",         // base64 encoded WASM
  "abi": "string"           // base64 encoded ABI
}
```

## get\_raw\_abi

The request returns an object containing rows from the specified table.

**Params:**

* `(name) account_name` — Account on which the contract is based.
* `(sha256) abi_hash` — ABI hash. This field is optional.

**Request example:**

```bash
curl --request POST  -d '{"account_name": "string"}' http://<node>/v1/chain/get_raw_abi
```

### Responses

**Code:** 200 OK

**Value:**

```
{
  "account_name": "string", // Account on which the contract is based
  "code_hash": "string",    // Code hash
  "abi_hash": "string",     // ABI hash 
  "abi": "string"           // base64 encoded ABI.  
}
```

## get\_table\_rows

The request returns an object containing rows from the specified table as well as containing values of the table fields specified in the parameters.

**Params:**

* `(bool) json` — Whether the object is converted to JSON. Default is `false`.
* `(name) code` — The name of the smart contract that controls the provided table.
* `(string) scope` — The account to which this data belongs.
* `(name) table` — The name of the table to query.
* `(string) table_key` — Type of key specified by index\_position.
* `(variant) lower_bound` — Lower bound of search.
* `(variant) upper_bound` — Upper bound of search.
* `(uint32_t) limit` — Total number of table rows to retrieve. Default is `10`.
* `(name) index` — Position of the index used.
* `(string) encode_type{"dec"}` — The field takes the values `dec`, `hex`. Default is `dec`.
* `(optional<bool>) reverse` — `true` if the search is in the reverse order. Default is `false`.
* `(optional<bool>) show_payer` — Display a RAM payer. Default is `false`.

**Request example:**

```bash
curl --request POST  -d '{"json": false, "code":"cyber.token", "scope":"cyber", "table" : "accounts", "table_key" : "", "lower_bound" : "", "upper_bound" : "", "limit" : "7", "key_type" : "int64", "index" : "primary", "encode_type" : "dec", "reverse" : false, "show_payer" : true}' http://<node>/v1/chain/get_table_rows
```

```bash
curl --request POST  -d '{"json": false, "code":"rows", "scope":"rows", "table" : "values", "table_key" : "", "upper_bound" : {"secondary" : 252, "forth" : 18}, "limit" : "20", "key_type" : "int64", "index" : "multy", "encode_type" : "dec", "reverse" : false, "show_payer" : true}' http://<node>/v1/chain/get_table_rows
```

```bash
curl --request POST  -d '{"json": false, "code":"rows", "scope":"rows", "table" : "values", "table_key" : "", "limit" : "5", "key_type" : "", "index" : "primary", "upper_bound" : {"key" : 14}, "encode_type" : "dec", "reverse" : false, "show_payer" : false}' http://<node>/v1/chain/get_table_rows
```

### Responses

**Code:** 200 OK

**Value:**

```bash
{
    vector<fc::variant> "rows": [ // One row per item, either encoded as hex String or JSON object.
        null
    ],
    "more": false,                // "true" if the next element is not finite and if the condition 'sizeof data() < limit' is fulfilled. By default is "false".
    "next": false                 // If "more" field is "true", this field contains an element located after the last in the rows field.
}
```

## get\_currency\_balance

The request retrieves the current balance.

**Params:**

* `(name) code` — Token code.
* `(name) account` — Account for which balance is requested.
* `(optional<string>) symbol` — A string representation of a token symbol, composed of a float with a precision of 4, and a symbol composed of capital letters, for example `1.0000 SYS`.

**Request example:**

```bash
curl --request POST  -d '{"code":"cyber.token", "account":"bob" , "symbol" : "SYS"}' http://<node>/v1/chain/get_currency_balance
```

### Responses

**Code:** 200 OK

**Value:**

```
{[
    "string"
]}
```

## get\_currency\_stats

The request retrieves currency stats of a certain type of tokens in the system.

**Params:**

* `(name) code` — Token code.
* `(string) symbol` — A string representation of a token symbol, composed of a float with a precision of 4, and a symbol composed of capital letters between 1-7 letters separated by a space, example `1.0000 SYS`.

**Request example:**

```bash
curl --request POST  -d '{"code":"cyber.token", "account":"bob" , "symbol" : "SYS"}' http://<node>/v1/chain/get_currency_stats
```

### Responses

**Code:** 200 OK

**Value:**

```
{
  "supply": "string",             // Specified type tokens in circulation
  "max_supply": "integer",        // Limit of the specified type tokens in circulation
  "account_name issuer": "string" // An account that created tokens of the specified type.
}
```

## get\_producers

The request retrieves producers (validators) list.

**Params:**

* `(bool) json` — Whether the producers list is converted to JSON. Default is `false`.
* `(string) lower_bound` — In conjunction with limit can be used to paginate through the results. For example, `limit=10` and `lower_bound=10` would be page `2`.
* `(uint32_t) limit` — Total number of producers to retrieve. Default is `50`.

**Request example:**

```bash
curl --request POST  -d '{"json" : false, "lower_bound" : 2, "limit" : 10 }' http://<node>/v1/chain/get_producers
```

### Responses

**Code:** 200 OK

**Value:**

```
{
  "rows":[                                 // One row per item, either encoded as hex string or JSON object
    {...}
  ],
  "total_producer_vote_weight": "integer",
  "more": "string"                         // Fill lower_bound with this value to fetch more rows
}
```

## get\_producer\_schedule

The request retrieves producers (validators) list.

**Params:**\
No params required.

**Request example:**

```bash
curl --request POST --data ''  http://<node>/v1/chain/get_producer_schedule
```

### Responses

**Code:** 200 OK

**Value:**

```
{
    "active": [{
        "version": 0,
        "producers": [{
            "producer_name": "string",
            "block_signing_key": "string"
        }]
    }],
    "pending": [{
        "version": 0,
        "producers": [{
            "producer_name": "string",
            "block_signing_key": "string"
        }]
    }],
    "proposed": [{
        "version": 0,
        "producers": [{
            "producer_name": "string",
            "block_signing_key": "string"
        }]
    }]
}
```

## get\_scheduled\_transactions

The request retrieves deferred transactions.

**Params:**

* `(bool) json` — Whether the packed transaction is converted to JSON. Default is `false`.
* `(string) lower_bound` — Date/time string in the format `YYYY-MM-DDTHH:MM:SS.sss` OR transaction ID.
* `(uint32_t) limit` — Total number of transactions to retrieve. Default is `50`.

**Request example:**

```bash
curl --request POST  -d '{"json" : false, "limit" : 10 }' http://<node>/v1/chain/get_scheduled_transactions
```

### Responses

**Code:** 200 OK

**Value:**

```
{
    "transactions": [
        {...}
        "more": "string" // fill lower_bound with this to fetch next set of transactions
    ]
}
```

## abi\_json\_to\_bin

The request returns an object containing rows from the specified table.

**Params:**

* `(name) code` — A name of row.
* `(name) action` — Action name.
* `(variant) args` — Arguments in JSON form.

**Request example:**

```bash
curl --request POST  -d '{"code" : "rows", "action" : "filltable", "args" : {"fildltable" : 30} }' http://<node>/v1/chain/abi_json_to_bin
```

### Responses

**Code:** 200 OK

**Value:**

```
{
  "binargs": "string"
}
```

## abi\_bin\_to\_json

The request returns an object containing rows from the specified table.

**Params:**

* `(name) code` — A name of row.
* `(name) action` — Action name.
* `(vector<char>) binargs` — String containing binary arguments.

**Request example:**

```bash
curl --request POST  -d '{"code" : "rows", "action" : "filltable", "binargs" : "1e00000000000000" }' http://<node>/v1/chain/abi_bin_to_json
```

### Responses

**Code:** 200 OK

**Value:**

```
{
    "string"
}
```

## get\_required\_keys

The request returns the required keys needed to sign a transaction.

**Params:**

* (object) transaction:
  * `(string) expiration` — Time in format of `YYYY-MM-DDTHH:MM:SS.sss` that transaction must be confirmed by. &#x20;
  * `(integer) ref_block_num` — Block number containing the transaction.
  * `(integer) ref_block_prefix` — Prefix of block containing the transaction.
  * `(string/integer)  max_net_usage_words` — Network resource allocated for the transaction.
  * `(string/integer) max_cpu_usage_ms` — CPU resource allocated for the transaction.
  * `(integer) max_ram_kbytes` — RAM resource allocated for the transaction.
  * `(integer) max_storage_kbytes` — Storage resource allocated for the transaction.
  * `(integer) delay_sec` — Delay time (in seconds).
  * `(array of objects) actions` — Actions composed of transaction.
  * `(array of integers/strings) transaction_extensions` — Objects included in the transaction.
* `(string) available_keys` — Provide the available keys.

**Request example:**

```bash
curl --request POST  -d '{"transaction" : {"trx_id":"d48b...90ee8","sender":"","sender_id": "308457...031097", "payer":"cyber.token", "delay_until":"2019-03-29T05:42:03.000", "expiration":"2019-03-29T05:52:03.000", "published":"2019-03-29T05:32:03.000", "transaction":"eead9d5...59530000000000"}, "available_keys" : ["GLS62zK8V5V...YUHM3YeLZg"] }' http://<node>/v1/chain/get_required_keys
```

### Responses

**Code:** 200 OK

**Value:**

```
{
  null // String containing keys. Empty string means the transaction has already been signed
}
```

## get\_transaction\_id

The request returns ID of a transaction using specified parameters if such transaction is in chain DB, otherwise returns a message like this one "Unknown Transaction ID: ...".

**Params:**\
Optional set params is used.

**Request examples:**

```bash
curl --request POST  -d '{"context_free_actions":[],"actions":[{"account":"cyber.token","name":"create","authorization":[{"actor":"cyber.token","permission":"active"}],"data":{"issuer":"cyber","maximum_supply":{"amount":1000000000000,"decs":4,"sym":"SYS"}},"hex_data":"0000000080ab8e470010a5d4e80000000453595300000000"}],"transaction_extensions":[]}' http://<node>/v1/chain/get_transaction_id
```

```bash
curl --request POST  -d '{"context_free_actions":[],"actions":[{"account":"cyber.token","name":"create","authorization":[{"actor":"cyber.token","permission":"active"}],"data":"0000000080ab8e470010a5d4e80000000453595300000000"}],"transaction_extensions":[]}' http://<node>/v1/chain/get_transaction_id
```

### Responses

**Code:** 200 OK

**Value:**

```
{
  "trx_id": "d48b5b27f90...a6f85fc90ee8"
}
```

## get\_agent\_public\_key

The request returns a key needed to sign a transaction if such key is in chain DB, otherwise returns an empty string.

**Params:**

* `(account_name) account` — An agent for which the key is requested. An agent is a potentially active account who has the staked tokens.
* `(symbol) symbol` — Identifier of a staked token, that is a token cost accuracy in the form of decimal places number and a token name, consisting of a set of capital letters.

**Request example:**

```bash
curl --request POST  -d '{"account" : "alice", "symbol" : "4,CYBER"}' http://<node>/v1/chain/get_agent_public_key
```

### Responses

**Code:** 200 OK

**Value:**

```
{
  "signing_key": "GLS62zK8V5U4fsg...Wn"
}
```

## resolve\_names

The request returns the resolved domain and user names retrieved from the JSON format array. The request does not successfully complete if at least one name from the array is invalid.

**Params:**

* Kinds of supported names:
  * `(string) domain` — A domain name.
  * `(string) @domain` — A domain name.
  * `(string) username@domain` — A username is in a domain scope.
  * `(string) username@@domain` — A username is directly in a domain scope.

**Request example:**

```bash
curl --request POST --data '["@alice","alice@golos","bob@@gls"]'  http://<node>/v1/chain/resolve_names
```

### Responses

**Code:** 200 OK

**Value:**

```
[
  {"resolved_domain":"rhdaax5zvnd"},                            // "alice" was resolved to "rhdaax5zvnd"
  {"resolved_domain":"gls","resolved_username":"rhdaax5zvnd"},  // "golos" was resolved to "gls"
  {"resolved_username":"ertojevqcywn"}                          // "bob" was resolved to "ertojevqcywn"
]
```

## get\_proxy\_status

The request retrieves an information for specified proxy account.

**Params:**

* `(account_name) account` — A proxy account name.
* `(symbol) symbol`  — Identifier of a token (provided by grantors), that is a token cost accuracy in the form of decimal places number and a token name, consisting of a set of capital letters.

**Request example:**

```bash
curl --request POST  -d '{"account" : "alice", "symbol" : "4,CYBER"}' http://<node>/v1/chain/get_proxy_status
```

### Responses

**Code:** 200 OK

**Value:**

```
{
  "account_name": "alice",
  "symbol": [         // Type of tokens provided to the proxy account by grantors for voting
    {
      "accuracy": "4",
      "symbol_code": "CYBER",
    }
  ]
  "proxylevel": 1,
  "proxies_count": 3  // Number of grantors
}
```


# Nodeos Producer API

The `producer_api_plugin` exposes a number of endpoints for the `producer_plugin` to the RPC API interface managed by the `http_plugin`.

For API request, it needs to perform a `POST` line with required parameters. The manual presents examples of requests using `curl`. Return code *201* indicates successful operation.

**Producer API requests supported:**

* [pause](/software_manuals/api_reference/nodeos_producer_api#pause)
* [resume](/software_manuals/api_reference/nodeos_producer_api#resume)
* [paused](/software_manuals/api_reference/nodeos_producer_api#paused)
* [get\_runtime\_options](/software_manuals/api_reference/nodeos_producer_api#get_runtime_options)
* [update\_runtime\_options](/software_manuals/api_reference/nodeos_producer_api#update_runtime_options)

## pause

The request puts a producer node in pause state and returns nothing.

**Params:**\
No params required.

**Request example:**

```bash
curl --request POST  --data '' http://<node>/v1/producer/pause
```

### Responses

**Code:** 201 OK

**Value:**\
Returns nothing.

## resume

The request switches a producer node from "pause" state to "resume" state and returns nothing.

**Params:**\
No params required.

**Request example:**

```bash
curl --request POST  --data '' http://<node>/v1/producer/resume
```

### Responses

**Code:** 201 OK

**Value:**\
Returns nothing.

## paused

The request retreives paused status for producer node.

**Params:**\
No params required.

**Request example:**

```bash
curl --request POST  --data '' http://<node>/v1/producer/paused
```

### Responses

**Code:** 201 OK

**Value:**

```
{
  "pause_production": true  // "true" if producer node is paused, "false" otherwise (that is, the node produces blocks)
}
```

## get\_runtime\_options

The request retreives run time options for producer node.

**Params:**\
No params required.

**Request example:**

```bash
curl --request POST --data '' http://<node>/v1/producer/get_runtime_options
```

### Responses

**Code:** 201 OK

**Value:**

```
{
  "max_transaction_time": 800,       // Time (in milliseconds) allocated to a transaction
  "max_irreversible_block_age": -1,  // Time (in seconds) allocated to irreversible block age
  "produce_time_offset_us": 0,       // Produce time offset (in microseconds)
  "last_block_time_offset_us": 0,    // Last block time offset (in microseconds)
  "max_scheduled_transaction_time_per_block_ms": 2000  // Max scheduled transaction time per block (in milliseconds)
}
```

## update\_runtime\_options

The operation updates run time options for producer node.\
Each of parameters specified in the operation is optional.

**Params:**

* `(integer) max_transaction_time` — Limits the maximum time (in milliseconds) that is allowed a pushed transaction's code to execute before being considered invalid. Defauts to *1000*.
* `(integer) max_irreversible_block_age` — Limits the maximum age (in seconds) of the DPOS Irreversible Block for a chain this node will produce blocks on (use negative value to indicate unlimited). Defaults to *-1*.
* `(integer) produce_time_offset_us` — Offset of non last block producing time (in microseconds). Negative number results in blocks to go out sooner, and positive number results in blocks to go out later. Defaults to *0*.
* `(integer) last_block_time_offset_us` — Offset of last block producing time (in microseconds). Negative number results in blocks to go out sooner, and positive number results in blocks to go out later. Defaults to *0*.
* `(integer) max_scheduled_transaction_time_per_block_ms` — Maximum wall-clock time (in milliseconds) spent retiring scheduled transactions in any block before returning to normal transaction processing. Defaults to *1000*.
* `(integer) incoming_defer_ratio` — Ratio between incoming transations and deferred transactions when both are exhausted. Defaults to *1.0* that  means *1:1*.

**Request examples:**

```bash
curl --request POST  -d '{"max_transaction_time": 1500, "last_block_time_offset_us": 5}' http://<node>/v1/producer/update_runtime_options
```

```bash
curl --request POST  -d '{"max_transaction_time": 1500, "max_irreversible_block_age": 5, "produce_time_offset_us": 10, "last_block_time_offset_us": 10, "max_scheduled_transaction_time_per_block_ms": 1000, "incoming_defer_ratio": 1.2}' http://<node>/v1/producer/update_runtime_options
```

### Responses

**Code:** 201 OK

**Value:**\
Returns Nothing.


# Nodeos Net API

For API request, it needs to perform a `POST` line with required parameters. The manual presents examples of requests using `curl`. Return code *201* indicates successful operation.

**Producer API requests supported:**

* [connect](/software_manuals/api_reference/nodeos_net_api#connect)
* [disconnect](/software_manuals/api_reference/nodeos_net_api#disconnect)
* [status](/software_manuals/api_reference/nodeos_net_api#status)
* [connections](/software_manuals/api_reference/nodeos_net_api#connections)

## connect

The request initiates a connection to a specified peer.

**Params:**

* `(string) endpoint` — The endpoint to connect to expressed as either IP address or URL.

**Request example:**

```bash
curl --request POST  --data '{"endpoint": "string"}' http://<node>/v1/net/connect
```

### Responses

**Code:** 201 OK

**Value:**

```
{
  "added connection"    // Otherwise "already connected" if the connection was already initiated before 
}
```

## disconnect

The request initiates disconnection from a specified peer.

**Params:**

* `(string) endpoint` — The endpoint to disconnect from, expressed as either IP address or URL.

**Request example:**

```bash
curl --request POST  --data '{"endpoint": "string"}' http://<node>/v1/net/disconnect
```

### Responses

**Code:** 201 OK

**Value:**

```
{
  "connection removed"    // Otherwise "no known connection for host" if no connection was initiated to the peer
}
```

## status

The request retreives the connection status for a specified peer.

**Params:**

* `(string) endpoint` — The endpoint to get the status for, to expressed as either IP address or URL.

**Request example:**

```bash
curl --request POST  --data '{"endpoint": "string"}' http://<node>/v1/net/status
```

### Responses

**Code:** 201 OK

**Value:**

```
{
  "peer": "string",          // The IP address or URL of the peer
  "connecting": true,        // "true" if the peer is connecting, otherwise "false"
  "syncing": true,           // "true" if the peer is syncing, otherwise "false"
  "last_handshake": {        // Structure holding detailed information about the connection
    "network_version": 0,    // Incremental value above a computed base. Defaults to "0"
    "chain_id": "string",    // Chain ID. Used to identify chain (sha256)
    "node_id": "string",     // Node ID. Used to identify peers and prevent self-connect (sha256)
    "key": "string",         // Authentication public key
    "time": "string",        // Date/time in the format (YYYY-MM-DDTHH:MM:SS.sss)
    "token": "string",       // Digest of time to prove we own the private key of the key above (sha256)
    "sig": "string",         // Signature for the digest
    "p2p_address": "string", // Address of the peer (IP address or URL)
    "last_irreversible_block_num": 0,        // Last irreversible block number. Defaults to "0"
    "last_irreversible_block_id": "string",  // Last irreversible block ID (sha256)
    "head_num": 0,           // Head number. Defaults to "0"
    "head_id": "string",     // Head ID (sha256)
    "os": "string",          // Operating system name
    "agent": "string",       // Agent name
    "generation": 0,         // Generation number
    "considers_gray":        // Considers gray. Optional field. Defaults to "false".
  }
}
```

## connections

The request returns an array of all peer connection statuses.

**Params:**\
No params required.

**Request example:**

```bash
curl --request POST --data '' http://<node>/v1/net/connections
```

### Responses

**Code:** 201 OK

**Value:**

```
[
  {
    "peer": "string",          // The IP address or URL of the peer
    "connecting": true,        // "true" if the peer is connecting, otherwise "false"
    "syncing": true,           // "true" if the peer is syncing, otherwise "false"
    "last_handshake": {        // Structure holding detailed information about the connection
      ...
    }
  }
  {...}
]
```


# Cleos Command Reference

* [Convert](/software_manuals/command_reference/convert)
* [Create](/software_manuals/command_reference/create)
* [Get](/software_manuals/command_reference/get)
* [Multisig](/software_manuals/command_reference/multisig)
* [Net](/software_manuals/command_reference/net)
* [Push](/software_manuals/command_reference/push)
* [Set](/software_manuals/command_reference/set)
* [Sign](/software_manuals/command_reference/sign)
* [System](/software_manuals/command_reference/system)
* [Transfer](/software_manuals/command_reference/transfer)
* [Version](/software_manuals/command_reference/version)
* [Wallet](/software_manuals/command_reference/wallet)


# Convert

**Description**\
The subcommands can be required to pack and unpack transactions as well as to convert data from JSON format to digital code and vice versa.

**Subcommands**

* [Pack Action Data](/software_manuals/command_reference/convert#pack-action-data) — From JSON action data to packed form.
* [Pack Transaction](/software_manuals/command_reference/convert#pack-transaction) — From plain signed JSON to packed form.
* [Unpack Action Data](/software_manuals/command_reference/convert#unpack-action-data) — From packed to JSON action data form.
* [Unpack Transaction](/software_manuals/command_reference/convert#unpack-transaction) — From packed to plain signed JSON form.

## Pack Action Data

### Description

The subcommand converts action data from JSON format to packed form.

### Positional Parameters

* `(string) account` — The name of the account that hosts the contract (required).
* `(string) name` — The name of the function that's called by this action (required).
* `(string) unpacked_action_data` — The action data expressed as JSON (required).

### Options

No options required for this subcommand.

### Command

```bash
$ cleos convert pack_action_data <account> <name> <unpacked_action_data>
```

### Examples

```bash
$ cleos convert pack_action_data c.gallery unlinkauth '{"account":"test1", "code":"test2", "type":"cybertype"}'
```

```
000000003500b1be00000000008fa1ca0000a47deaea2903
```

## Pack Transaction

### Description

The subcommand converts a transaction from plain signed JSON to packed form.

### Positional Parameters

* `(string) transaction` — The plain signed JSON (required).

### Options

* `--pack-action-data` — Pack all action data within transaction, needs interaction with `nodeos`.

### Command

```bash
$ cleos convert pack_transaction [OPTIONS] <transaction>
```

### Examples

```bash
$ cleos convert pack_transaction '{
  "expiration": "2020-02-02T18:01:32",
  "ref_block_num": 22654,
  "ref_block_prefix": 4107128227,
  "max_net_usage_words": 0,
  "max_cpu_usage_ms": 0,
  "max_ram_kbytes": 0,
  "max_storage_kbytes": 0,
  "delay_sec": 0,
  "context_free_actions": [],
  "actions": [{
      "account": "c.gallery",
      "name": "create",
      "authorization": [{
          "actor": "cmnwrtlcdzcl",
          "permission": "active"
        }
      ],
      "data": "0000000000fe...3d8ab000000"
    }
  ],
  "transaction_extensions": []
}'
```

```
{
  "signatures": [],
  "compression": "none",
  "packed_context_free_data": "",
  "packed_trx": "7429ab7f379...00000"
}
```

## Unpack Action Data

### Description

The subcommand converts action data from packed to JSON format.

### Positional Parameters

* `(string) account` — The name of the account that hosts the contract (required).
* `(string) name` — The name of the function that's called by this action (required).
* `(string) packed_action_data` — The action data expressed as packed hex string (required).

### Options

No options required for this subcommand.

### Command

```bash
$ cleos convert pack_action_data <account> <name> <unpacked_action_data>
```

### Examples

```bash
$ cleos convert unpack_action_data c.gallery unlinkauth 000000003500b1be00000000008fa1ca0000a47deaea2903
```

```
{
  "account": "test1",
  "code": "test2",
  "type": "cybertype"
}
```

## Unpack Transaction

### Description

The subcommand converts a transaction from packed to plain signed JSON form.

### Positional Parameters

* `(string) transaction` — The packed transaction JSON (string containing packed\_trx and optionally compression fields) (required).

### Options

* `--unpack-action-data` — Unpack all action data within transaction, needs interaction with `nodeos`.

### Command

```bash
$ cleos convert unpack_transaction [OPTIONS] <transaction>
```

### Examples

```bash
$ cleos convert unpack_transaction '{
  "signatures": [
    "SIG_K1_K6gS7...YE596eh"
  ],
  "compression": "none",
  "packed_context_free_data": "",
  "packed_trx": "7429ab7f379...00000"
}'
```

```
{
  "expiration": "2020-02-02T18:01:32",
  "ref_block_num": 22654,
  "ref_block_prefix": 4107128227,
  "max_net_usage_words": 0,
  "max_cpu_usage_ms": 0,
  "max_ram_kbytes": 0,
  "max_storage_kbytes": 0,
  "delay_sec": 0,
  "context_free_actions": [],
  "actions": [{
      "account": "c.gallery",
      "name": "create",
      "authorization": [{
          "actor": "cmnwrtlcdzcl",
          "permission": "active"
        }
      ],
      "data": "0000000000fe...3d8ab000000"
    }
  ],
  "transaction_extensions": [],
  "signatures": [
    "SIG_K1_K6gS7...YE596eh"
  ],
  "context_free_data": []
}
```


# Create

**Description**\
The subcommands can be used to to create various items, on and off the blockchain.

**Subcommands**

* [Account](/software_manuals/command_reference/create#account) — Retrieve an account from the blockchain.
* [Key](/software_manuals/command_reference/create#key) — Retrieve accounts associated with a public key.

## Account

### Description

The subcommand creates a new account on the blockchain (assumes system contract does not restrict RAM usage).

### Positional Parameters

* `(string) creator`— The name of the account creating the new account (required).
* `(string) name`— The name of the new account (required).
* `(string) OwnerKey`— The owner public key or permission level for the new account (required).
* `(string) ActiveKey`— The active public key or permission level for the new account.

### Options

* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'creater\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos create account [OPTIONS] <creator> <name> <OwnerKey> [<ActiveKey>]
```

### Examples

A set of keys is required to create an account. These keys can be generated by using `cleos create key`.

```bash
$ cleos create account alice bob  GLS5to...hBdcBw  GLS7A3u...K3bAS
```

## Key

### Description

The subcommand creates a new keypair and prints the public and private keys.

### Positional Parameters

No parameters required fot this subcommand.

### Options

* `--r1`, `-j` — Generate a key using the R1 curve (iPhone), instead of the K1 curve (Bitcoin).
* `-f`, `--file` TEXT`— Name of file to write private/public key output to. (Must be set, unless`--to-console\` is passed).
* `--to-console` — Print private/public keys to console.

### Command

```bash
$ cleos create key [OPTIONS]
```

### Examples

```bash
$ cleos create key -f privatedata
```

```
Private key: SxY7ghj...judaU
Public key: GLS5sUR...dSmc96
```


# Get

## Get

**Description**\
The subcommands can be used to retrieve various items and information from the blockchain.

**Subcommands**

* [Abi](/software_manuals/command_reference/get#abi) — Retrieve the ABI for an account.
* [Account](/software_manuals/command_reference/get#account) — Retrieve an account from the blockchain.
* [Accounts](/software_manuals/command_reference/get#accounts) — Retrieve accounts associated with a public key.
* [Actions](/software_manuals/command_reference/get#actions) — Retrieve all actions with specific account name referenced in authorization or receiver.
* [Block](/software_manuals/command_reference/get#block) — Retrieve a full block from the blockchain.
* [Code](/software_manuals/command_reference/get#code) — Retrieve the code and ABI for an account.
* [Currency Balance](/software_manuals/command_reference/get#currency-balance) — Retrieve the balance of an account for a given currency.
* [Currency Stats](/software_manuals/command_reference/get#currency-stats) — Retrieve the stats of for a given currency.
* [Info](/software_manuals/command_reference/get#info) — Get current blockchain information.
* [Schedule](/software_manuals/command_reference/get#schedule) — Retrieve the producer schedule.
* [Scope](/software_manuals/command_reference/get#scope) — Retrieve a list of scopes and tables owned by a contract.
* [Servants](/software_manuals/command_reference/get#servants) — Retrieve accounts which are servants of a given account.
* [Table](/software_manuals/command_reference/get#table) — Retrieve the contents of a database table.
* [Transaction](/software_manuals/command_reference/get#transaction) — Retrieve a transaction from the blockchain.
* [Transaction ID](/software_manuals/command_reference/get#transaction-id) — Get transaction id given transaction object.

### Abi

#### Description

The subcommand retrieves the ABI for an account.

#### Positional Parameters

* `(string) name` — The name of the account whose abi should be retrieved (required).

#### Options

* `-f`, `--file` *TEXT* — The name of the file to save the contract .abi to instead of writing to console.

#### Command

```bash
$ cleos get abi [OPTIONS] <name>
```

#### Examples

Retrieve and save abi for cyber.stake contract.

```bash
$ cleos get abi cyber.stake -f cyber.stake.abi
```

```
saving abi to cyber.stake.abi
```

### Account

#### Description

The subcommand retrieves an account from the blockchain.

#### Positional Parameters

* `(string) name` — The name of the account to retrieve (required).
* `(string) core-symbol` — The expected core symbol of the chain you are querying.

#### Options

* `--json`, `-j` — Output in JSON format.

#### Command

```bash
$ cleos get account [OPTIONS] <name> [<core-symbol>]
```

#### Examples

Get formatted data for user cyberio.

```bash
$ cleos get account cyberio
```

Get JSON data for user cyberio.

```bash
$ cleos get account cyberio --json
```

### Accounts

#### Description

The subcommand retrieves accounts associated with a public key.

#### Positional Parameters

* `(string) public_key` — The public key to retrieve accounts for (required).

#### Options

* `--json`, `-j` — Output in JSON format.

#### Command

```bash
$ cleos get accounts [OPTIONS] <public_key>
```

#### Examples

```bash
$ cleos get accounts GLS7w...NuSPAfXJHAhWt
{
  "account_names": [
    "testaccount"
  ]
}
```

### Actions

#### Description

The subcommand retrieves all actions with specific account name referenced in authorization or receiver.

#### Positional Parameters

* `(string) account_name` — Name of account to query on (required).
* `(int_32) pos` — Sequence number of action for this account, *-1* for last.
* `(int_32) offset` — Get actions `[pos, pos + offset]` for positive offset or `[pos - offset, pos]` for negative offset.

#### Options

* `-j`, `--json` — Print full json.
* `--full` — Do not truncate action output.
* `--pretty` — Pretty print full action json.
* `--console` — Print console output generated by action.

#### Command

```bash
$ cleos get actions [OPTIONS] <account_name> [<pos>] [<offset>]
```

#### Examples

Retrieve and save abi for cyber.token contract.

```bash
$ cleos get actions cyber.token
```

```
#  seq    when                            contract::action => receiver      trx id...   args
================================================================================================================
#  1101   2020-02-02T10:34:01.000     cyber.token::transfer => cyber.token   a3fgh5f4... {"from":"userae","to":"useraa","quantity":"0.000...
#  1102   2020-02-02T10:34:01.000     cyber.token::transfer => cyber.token   rt48fhrh... {"from":"userab","to":"useraa","quantity":"0.000...
#  1103   2020-02-02T10:34:01.000     cyber.token::transfer => cyber.token   6gg093dg... {"from":"userab","to":"userah","quantity":"0.000...
#  1104   2020-02-02T10:34:01.000     cyber.token::transfer => cyber.token   2ws8d55t... {"from":"userai","to":"useraj","quantity":"0.000...
...
```

### Block

#### Description

The subcommand retrieves a full block from the blockchain.

#### Positional Parameters

* `(string) block` — The number *or* ID of the block to retrieve (required).

#### Options

* `--header-state` — Get block header state from fork database instead.

#### Command

```bash
$ cleos get block [OPTIONS] <block>
```

#### Examples

```bash
$ cleos get block 7315
```

or

```bash
$ cleos get block 0000...5ye0ort10e
```

Result output is a block object similar to the following

```
{
  "timestamp": "2020-02-02T10:38:32.000",
  "producer": "",
  "confirmed": 21,
  "previous": "006...9bd",
  "transaction_mroot": "1434...d09",
  "action_mroot": "dea...469",
  "schedule_version": 59218,
  "new_producers": null,
  "header_extensions": [],
  "producer_signature": "SIG_K1_J...eR",
  "transactions": [],
  "block_extensions": [],
  "id": "006...58f22d10",
  "block_num": 7315,
  "ref_block_prefix": 744221143
}
```

### Code

#### Description

The subcommand retrieves the code and ABI for an account

#### Positional Parameters

* `(string) name` — The name of the account whose code should be retrieved (required).

#### Options

* `-c`, `--code` *TEXT* — The name of the file to save the contract .wast to.
* `-a`, `--abi` *TEXT* — The name of the file to save the contract .abi to.
* `--wasm` — Save contract as wasm.

#### Command

```bash
$ cleos get code [OPTIONS] <name>
```

#### Examples

Simply output the hash of cyber.token contract

```bash
$ cleos get code cyber.token
```

```
code hash: 3eadff2...0d002
```

Retrieve and save abi for cyber.token contract.

```bash
$ cleos get code cyber.token -a cyber.token.abi
```

```
code hash: 3eadff2...0d002
saving abi to cyber.token.abi
```

Retrieve and save wast code for cyber.token contract.

```bash
$ cleos get code cyber.token -c cyber.token.wast
```

```
code hash: 3eadff2...0d002
saving wast to cyber.token.wast
```

## Currency Balance

#### Description

The subcommand retrieves the balance of an account for a given currency.

#### Positional Parameters

* `(string) contract` — The contract that operates the currency (required).
* `(string) account` — The account to query balances for (required).
* `(string) symbol` — The symbol for the currency if the contract operates multiple currencies.

#### Options

No options required for this subcomand.

#### Command

```bash
$ cleos get balance <contract> <account> [<symbol>]
```

#### Examples

Get balance of eosio from cyber.token contract for SYS symbol.

```bash
$ cleos get currency balance cyber.token cyberio SYS
```

```
  10000.0000 SYS
```

### Currency Stats

#### Description

The subcommand retrieves the stats of for a given currency.

#### Positional Parameters

* `(string) contract` — The contract that operates the currency (required).
* `(string) symbol` — The symbol for the currency if the contract operates multiple currencies (required).

#### Options

No options required for this subcomand.

#### Command

```bash
$ cleos get stats <contract> <symbol>
```

#### Examples

Get stats of the SYS token from the cyber.token contract.

```bash
$ cleos get currency stats eosio.token SYS
```

```
{
  "SYS": {
    "supply": "10000.0000 SYS",
    "max_supply": "100000.0000 SYS",
    "issuer": "cyberio"
  }
}
```

### Info

#### Description

The subcommand gets current blockchain information.

#### Positional Parameters

No parameters required for this subcommand.

#### Options

No options required for this subcommand.

#### Command

```bash
$ cleos get info
```

#### Examples

This subcommand returns the current blockchain state information.

```bash
$ cleos get info
```

```
{
  "server_version": "5ad0",
  "head_block_num": 7342,
  "last_irreversible_block_num": 7325,
  "head_block_id": "006...58f2442",
  "head_block_time": "2020-02-02T17:23:40",
  "head_block_producer": "zaheader",
  "recent_slots": "111...111",
  "participation_rate": "1.00000000000000000"
}
```

### Schedule

#### Description

The subcommand retrieves the producer schedule.

#### Positional Parameters

No parameters required for this subcommand.

#### Options

* `-j`, `--json` —  Output in JSON format.

#### Command

```bash
$ cleos get schedule [OPTIONS]
```

#### Examples

This subcommand returns the current producer schedule.

```bash
$ cleos get schedule
```

```
active schedule version 0
    Producer      Producer key
    ============= ==================
    cyberio       GLS7w...NuSPAfXJHAhWt

pending schedule empty

proposed schedule empty
```

### Scope

#### Description

The subcommand retrieves a list of scopes and tables owned by a contract

#### Positional Parameters

* `(string) contract` — The contract who owns the table (required).

#### Options

* `-t`, `--table` *TEXT* — The name of the table as filter.
* `-l`, `--limit` *UINT* — The maximum number of rows to return.
* `-L`, `--lower` *TEXT* — Lower bound of scope.
* `-U`, `--upper` *TEXT* — Upper bound of scope.
* `-r`, `--reverse` —  Iterate in reverse order.

#### Command

```bash
$ cleos get scope [OPTIONS] <contract>
```

### Servants

#### Description

The subcommand retrieves accounts which are servants of a given account.

#### Positional Parameters

* `(string) account` — The name of the controlling account (required).

#### Options

No options required for this subcommand.

#### Command

```bash
$ cleos get servants <account>
```

#### Examples

```bash
$ cleos get servants alice
```

Output

```
{
  "controlling_account": [
    "alice"
  ]
}
```

### Table

#### Description

The subcommand retrieves the contents of a database table.

#### Positional Parameters

* `(string) account` — The account who owns the table (required).
* `(string) scope` — The scope within the contract in which the table is found (required).
* `(string) table` — The name of the table as specified by the contract abi (required).

#### Options

* `--index` — Index name. The same as in abi decription. If not set the index name will be *primary*.
* `-b`, `--binary` — Return the value as BINARY rather than using abi to interpret as JSON.
* `-l`, `--limit` — The maximum number of rows to return.
* `-k`, `--key` — Deprecated.
* `-L`, `--lower` — JSON representation of lower bound value of key, defaults to first.
* `-U`, `--upper` — JSON representation of upper bound value of key, defaults to last.
* `--key-type` — Deprecated.
* `--encode-type` — The encoding type of key\_type (*i64* , *i128* , *float64*, *float128*) only support decimal encoding (e.g. 'dec'). *i256* - supports both 'dec' and 'hex', *ripemd160* and *sha256* is 'hex' only.
* `-r`, `--reverse` — Iterate in reverse order.
* `--show-payer` — show RAM payer.

#### Command

```bash
$ cleos get table [OPTIONS] <account> <scope> <table>
```

#### Examples

Get the data from the *accounts* table for the *cyber.token* contract, for user *cyberio*.

```
$ cleos get table cyber.token cyberio accounts
```

### Transaction

#### Description

The subcommand retrieves a transaction from the blockchain.

#### Positional Parameters

* `(string) id` — ID of the transaction to retrieve (required).

#### Options

* `-b`, `--block-hint` *UINT* — The block number this transaction may be in.

#### Command

```bash
$ cleos get transaction [OPTIONS] <id>
```

#### Examples

```bash
$ cleos get transaction w234b9...dd76brt5
```

### Transaction ID

#### Description

The subcommand gets transaction id given transaction object.

#### Positional Parameters

* `(string) transaction` — The JSON string or filename defining the transaction which transaction ID will be retrieved (required).

#### Options

No options required for this subcommand.

#### Command

```bash
$ cleos get transaction_id <transaction>
```


# Multisig

**Description**\
Multisig contract commands.

**Subcommands**

* [Multisig Propose](/software_manuals/command_reference/multisig#multisig-propose) — Propose action.
* [Multisig Propose Transaction](/software_manuals/command_reference/multisig#multisig-propose-transaction) — Propose transaction.
* [Multisig Review](/software_manuals/command_reference/multisig#multisig-review) — Review transaction.
* [Multisig Approve](/software_manuals/command_reference/multisig#multisig-approve) — Approve proposed transaction.
* [Multisig Unapprove](/software_manuals/command_reference/multisig#multisig-unapprove) — Unapprove proposed transaction.
* [Multisig Invalidate](/software_manuals/command_reference/multisig#multisig-invalidate) — Invalidate all multisig approvals of an account.
* [Multisig Cancel](/software_manuals/command_reference/multisig#multisig-cancel) — Cancel proposed transaction.
* [Multisig Exec](/software_manuals/command_reference/multisig#multisig-exec) — Execute proposed transaction.
* [Multisig Schedule](/software_manuals/command_reference/multisig#multisig-schedule) — Schedule delayed proposed transaction.

## Multisig Propose

### Description

Propose action.

### Positional Parameters

* `(string) proposal_name` — The unique name assigned to the multisig transaction when it is created (required).
* `(string) requested_permissions` — The JSON string or filename defining requested permissions (required).
* `(string) trx_permissions` — The JSON string or filename defining transaction permissions (required).
* `(string) contract` — Contract to which deferred transaction should be delivered (required).
* `(string) action` — Action of deferred transaction (required).
* `(string) data` —The JSON string or filename defining the action to propose (required).&#x20;
* `(string) proposer` — Account proposing the transaction.
* `(uint) proposal_expiration` — Proposal expiration interval (in hours), defaults to *24* h.
* `(string) description` — Optional proposal description.

### Options

* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'proposer\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos multisig propose [OPTIONS] <proposal_name> <requested_permissions> <trx_permissions> <contract> <action> <data> [<proposer>] [<proposal_expiration>] [<description>]
```

## Multisig Propose Transaction

### Description

Propose transaction.

### Positional Parameters

* `(string) proposal_name` — The unique name assigned to the multisig transaction when it is created (required).
* `(string) requested_permissions` — The JSON string or filename defining requested permissions (required).
* `(string) transaction` — "The JSON string or filename defining the transaction to push (required).
* `(string) proposer` — Account proposing the transaction (author of multisig transaction).
* `(string) description` — Optional proposal description.

### Options

* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'proposer\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos multisig propose_trx <proposal_name> <requested_permissions> <transaction> [<proposer>] [<description>] [OPTIONS]
```

## Multisig Review

### Description

Review transaction.

### Positional Parameters

* `(string) proposer` — Account proposing the transaction (required).
* `(string) proposal_name` — The unique name assigned to the multisig transaction when it is created (required).

### Options

* `--show-approvals` — Show the status of the approvals requested within the proposal.

### Command

```bash
$ cleos multisig review [OPTIONS] <proposer> <proposal_name>
```

## Multisig Approve

### Description

Approve proposed transaction.

### Positional Parameters

* `(string) proposer` — Account proposing the transaction (required).
* `(string) proposal_name` — The unique name assigned to the multisig transaction when it is created (required).
* `(string) permissions` — The JSON string of filename defining approving permissions (required).
* `(string) proposal_hash` — Hash of proposed transaction (i.e. transaction ID) to optionally enforce as a condition of the approval.

### Options

* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'proposer\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos multisig approve [OPTIONS] <proposer> <proposal_name> <permissions> [<proposal_hash>]
```

## Multisig Unapprove

### Description

Unapprove proposed transaction.

### Positional Parameters

* `(string) proposer` — Account proposing the transaction (required).
* `(string) proposal_name` — The unique name assigned to the multisig transaction when it is created (required).
* `(string) permissions` — The JSON string of filename defining approving permissions (required).

### Options

* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'proposer\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos multisig unapprove [OPTIONS] <proposer> <proposal_name> <permissions>
```

## Multisig Invalidate

### Description

Invalidate all multisig approvals of an account. Revoke all permissions previously issued by the account for performing multisig transactions. The action applies to all proposed transactions that are at the voting stage.

### Positional Parameters

* `(string) invalidator` — Invalidator name whose previously issued permissions to perform multisig transactions must be invalidated (required).

### Options

* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'invalidator\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos multisig invalidate [OPTIONS] <invalidator>
```

## Multisig Cancel

### Description

Cancel proposed transaction.

### Positional Parameters

* `(string) proposer` — Account proposing the transaction (required).
* `(string) proposal_name` — The unique name assigned to the multisig transaction when it is created (required).
* `(string) canceler` — Canceler name that cancels the execution.

### Options

* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'canceler\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos multisig cancel [OPTIONS] <proposer> <proposal_name> [<canceler>]
```

## Multisig Exec

### Description

Execute proposed transaction.

### Positional Parameters

* `(string) proposer` — Account proposing the transaction (required).
* `(string) proposal_name` — The unique name assigned to the multisig transaction when it is created (required).
* `(string) executer` — account paying for execution.

### Options

* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'executer\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos multisig exec [OPTIONS] <proposer> <proposal_name> [<executer>]
```

## Multisig Schedule

### Description

Schedule delayed proposed transaction.

### Positional Parameters

* `(string) proposer` — Account proposing the transaction (required).
* `(string) proposal_name` — The unique name assigned to the multisig transaction when it is created (required).
* `(string) actor` — account paying for scheduling.

### Options

* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout` ).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'actor\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos multisig schedule [OPTIONS] <proposer> <proposal_name> [<actor>]
```


# Net

**Description**\
The subcommands can be used to interact with local p2p network connections.

**Subcommands**

* [Connect](/software_manuals/command_reference/net#connect) — Start a new connection to a peer.
* [Disconnect](/software_manuals/command_reference/net#disconnect) — Close an existing connection.
* [Status](/software_manuals/command_reference/net#status) — Status of existing connection.
* [Peers](/software_manuals/command_reference/net#peers) — Status of all existing peers.

## Connect

### Description

Start a new connection to a peer.

### Positional Parameters

* `(string) host`— The hostname:port to connect to (required).

### Options

No options required for this subcommand.

### Command

```bash
$ cleos net connect <host>
```

### Examples

Connect to 'hostname:port'.

```bash
$ cleos net connect hostname:port
```

## Disconnect

### Description

Close an existing connection.

### Positional Parameters

* `(string) host`— The hostname:port to disconnect from (required).

### Options

No options required for this subcommand.

### Command

```bash
$ cleos net disconnect <host>
```

### Examples

Disconnect from 'hostname:port'.

```bash
$ cleos net disconnect hostname:port
```

## Status

### Description

Status of existing connection.

### Positional Parameters

* `(string) host`— The hostname:port to query status of connection (required).

### Options

No options required for this subcommand.

### Command

```bash
$ cleos net status <host>
```

### Examples

```bash
$ cleos net status hostname:port
```

Given, a valid, existing 'hostname:port' parameter the above command returns a JSON response looking similar to the one below:

```
{
  "peer": "hostname:port",
  "connecting": false/true,
  "syncing": false/true,
  "last_handshake": {       // Structure explaining in detail in the Network Peer Protocol documentation section
    ...
  }
}
```

## Peers

### Description

Status of all existing peers.

### Positional Parameters

No parameters required fot this subcommand.

### Options

No options required for this subcommand.

### Command

```bash
$ cleos net peers
```


# Push

**Description**\
The subcommands can be used to push arbitrary transactions to the blockchain.

**Subcommands**

* [Push Action](/software_manuals/command_reference/push#push-action) — Retrieve an account from the blockchain.
* [Push Transaction](/software_manuals/command_reference/push#push-transaction) — Retrieve accounts associated with a public key.
* [Push Transactions](/software_manuals/command_reference/push#push-transactions) — Retrieve accounts associated with a public key.

## Push Action

### Description

Push a transaction with a single action.

### Positional Parameters

* `(string) account`— The account providing the contract to execute (required).
* `(string) action`— A JSON string or filename defining the action to execute on the contract (required).
* `(string) data`— The arguments to the contract (required).

### Options

* `-x,--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f,--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s,--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j,--json` — Print result as JSON.
* `-d,--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r,--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p,--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission'.
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos push [OPTIONS] <account> <action> <data>
```

## Push Transaction

### Description

Push an arbitrary JSON transaction.

### Positional Parameters

* `(string) transaction`— The JSON string or filename defining the transaction to push (required).

### Options

* `-x,--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f,--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s,--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j,--json` — Print result as JSON.
* `-d,--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r,--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p,--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission'.
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos push transaction [OPTIONS] <transaction>
```

## Push Transactions

### Description

Push an array of arbitrary JSON transactions.

### Positional Parameters

* `(string) transaction`— The JSON string or filename defining the array of the transactions to push (required).

### Options

No options required fot this subcommand.

### Command

Pushes an array of arbitrary JSON transactions.

```bash
$ cleos push transactions {<transaction1>...<transactionN>}
```


# Set

**Description**\
The subcommands can be required to set or update the blockchain state.

**Subcommands**

* [Set Code](/software_manuals/command_reference/set#set-code) — Create or update the code on an account.
* [Set Abi](/software_manuals/command_reference/set#set-abi) — Create or update the abi on an account.
* [Set Contract](/software_manuals/command_reference/set#set-contract) — Create or update the contract on an account.
* [Set Account](/software_manuals/command_reference/set#set-account) — Set or update blockchain account state.
* [Set Action](/software_manuals/command_reference/set#set-action) — Set or update blockchain action state.

## Set Code

### Description

Create or update the code on an account.

### Positional Parameters

* `(string) account`— The account to set code for (required).
* `(string) code-file`— The fullpath containing the contract WASM.

### Options

* `-c`, `--clear`— Remove code on an account.
* `--suppress-duplicate-check`— Do not check for duplicate.
* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'account\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos set code [OPTIONS] <account> [<code-file>]
```

### Examples

```bash
$ cleos set code alice ./path/to/wasm
```

## Set Abi

### Description

Create or update the contract on an account.

### Positional Parameters

* `(string) account`— The account to set the ABI for (required).
* `(string) abi-file`— The fullpath containing the contract ABI.

### Options

* `-c`, `--clear`— Remove abi on an account.
* `--suppress-duplicate-check`— Do not check for duplicate.
* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'account\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos set abi [OPTIONS] <account> [<abi-file>]
```

### Examples

```bash
$ cleos set abi alice ./path/to/abi.abi
```

## Set Contract

### Description

Create or update the contract on an account.

### Positional Parameters

* `(string) account`— The account to publish a contract for (required).
* `(string) contract-dir`— The path containing the .wasm and .abi.
* `(string) wasm-file`— The file containing the contract WASM relative to contract-dir.

### Options

* `abi-file`, `-a`, `--abi`— The ABI for the contract relative to contract-dir.
* `-c`, `--clear`— Remove contract on an account.
* `--suppress-duplicate-check`— Do not check for duplicate.
* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'account\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos set contract [OPTIONS] <account> [<contract-dir>] [<wasm-file>]
```

### Examples

Deployind the stake contract.

```bash
$ cleos set contract currency ../contracts/cyber.stake/stake.wasm ../contracts/cyber.stake/stake.abi
```

## Set Account

### Description

Set parameters dealing with account permissions.

### Positional Parameters

* `(string) account`— The account to set/delete a permission authority for (required).
* `(string) permission`— The permission name to set/delete an authority for (required).
* `(string) authority`— \[delete] NULL, \[create/update] public key, JSON string or filename defining the authority, \[code] contract name.
* `(string) parent`— \[create] The permission name of this parents permission, defaults to 'active'.

### Options

* `--add-code` — \[code] add '${code}' permission to specified permission authority.
* `--remove-code` — \[code] remove '${code}' permission from specified permission authority.
* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'account\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

To modify the permissions of an account, you must have the authority over the account and the permission of which you are modifying.

```bash
$ cleos set account permission [OPTIONS] <account> <permission> [<authority>] [<parent>]
```

### Examples

*Example 1*\
Associates a new key to the active permissions of an account.

```bash
$ cleos set account permission test active '{"threshold" : 1, "keys" : [{"permission":{"key":"GLS7...L6T2s","permission":"active"},"weight":1}], "accounts" : [{"permission":{"account":"bob","permission":"active"},"weight":50}]}' owner
```

*Example 2*\
Modifies the same account permission, but removes the key set in the last example, and grants active authority of the @test account to another account.

```bash
$ cleos set account permission test active '{"threshold" : 1, "keys" : [], "accounts" : [{"permission":{"account":"sandwich","permission":"active"},"weight":1},{"permission":{"account":"alice","permission":"active"},"weight":50}]}' owner
```

*Example 3*\
Demonstrates how to setup permissions for multisig.

```bash
cleos set account permission test active '{"threshold" : 100, "keys" : [{"permission":{"key":"GLS7...L6T2s","permission":"active"},"weight":25}], "accounts" : [{"permission":{"account":"@sandwich","permission":"active"},"weight":75}]}' owner
```

## Set Action

### Description

Set parmaters dealing with account permissions.

### Positional Parameters

* `(string) account`— The account to set/delete a permission authority for (required).
* `(string) code`— The account that owns the code for the action (required).
* `(type) type`— The type of the action (required).
* `(type) requirement`— \[delete] NULL, \[set/update] The permission name require for executing the given action (required).

### Options

* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'account\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos set action permission [OPTIONS] <account> <code> <type> <requirement>
```

### Examples

Link a 'voteproducer' action to the 'voting' permissions

```bash
$ cleos set action permission alice cyber.system voteproducer voting -p alice@voting
```

Now can execute the transaction with the previously set permissions.

```bash
$ cleos system voteproducer approve alice someproducer -p alice@voting
```


# Sign

## Description

The subcommand can be used to sign a transaction.

## Positional Parameters

* `(string) transaction`— The JSON string or filename defining the transaction to sign (required).

## Options

* `-k`, `--private-key` *TEXT* — The private key that will be used to sign the transaction.
* `-c`, `--chain-id` *TEXT* — The chain id that will be used to sign the transaction.
* `-p`, `--push-transaction` — Push transaction after signing.

## Command

```bash
$ cleos sign [OPTIONS] <transaction>
```


# System

**Description**\
The subcommands can be used to send cyber.system contract action to the blockchain.

**Subcommands**

* [System Newaccount](/software_manuals/command_reference/system#system-newaccount) — Create a new account on the blockchain with initial resources.
* [System Regproducer](/software_manuals/command_reference/system#system-regproducer) — Register a new producer.
* [System Unregprod](/software_manuals/command_reference/system#system-unregprod) — Unregister an existing producer.
* [System Voteproducer Proxy](/software_manuals/command_reference/system#system-voteproducer-proxy) — Vote your stake through a proxy.
* [System Voteproducer Prods](/software_manuals/command_reference/system#system-voteproducer-prods) — Vote for a producer.
* [System Listproducers](/software_manuals/command_reference/system#system-listproducers) — List producers.
* [System Delegatebw](/software_manuals/command_reference/system#system-delegatebw) — Delegate bandwidth.
* [System Undelegatebw](/software_manuals/command_reference/system#system-undelegatebw) — Undelegate bandwidth.
* [System Claimbw](/software_manuals/command_reference/system#system-claimbw) — Claim undelegated bandwidth.
* [System Listbw](/software_manuals/command_reference/system#system-listbw) — List delegated bandwidth.
* [System Bidname](/software_manuals/command_reference/system#system-bidname) — Name bidding.
* [System Bidnameinfo](/software_manuals/command_reference/system#system-bidnameinfo) — Get bidname info.
* [System Setproxylvl](/software_manuals/command_reference/system#system-setproxylvl) — Set an account proxy level.
* [System Regproxy](/software_manuals/command_reference/system#system-regproxy) — Register an account as a proxy (for voting).
* [System Unregproxy](/software_manuals/command_reference/system#system-unregproxy) — Unregister an account as a proxy (for voting).
* [System Stake](/software_manuals/command_reference/system#system-stake) — Stake assets to gain resources.
* [System Canceldelay](/software_manuals/command_reference/system#system-canceldelay) — Cancel a delayed transaction.

## System Newaccount

### Description

Create a new account on the blockchain with initial resources.

### Positional Parameters

* `(string) creator`— The name of the account creating the new account (required).
* `(string) name`— The name of the new account (required).
* `(string) OwnerKey`— The owner public key or permission level for the new account (required).
* `(string) ActiveKey`— The active public key or permission level for the new account.

### Options

* `--stake` *TEXT* — The amount of tokens delegated for the account
* `--transfer`— Transfer voting power and right to unstake tokens to receiver.
* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'creator\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos system newaccount [OPTIONS] <creator> <name> <OwnerKey> [<ActiveKey>]
```

### Examples

'alice' creates 'bob' and transfers him *50* tokens irrevocably.

```bash
$ cleos system newaccount --stake=50.0000,CYBER --transfer alice bob XXX...XXX
```

## System Regproducer

### Description

Register a new producer.

### Positional Parameters

* `(string) account` — The account to register as a producer (required).
* `(string) producer_key` — The producer's public key (required).

### Options

* `--min-own-stake`— A min value the producer guarantees to stake.
* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'account\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos system regproducer [OPTIONS] <account> <producer_key>
```

## System Unregprod

### Description

Unregister an existing producer.

### Positional Parameters

* `(string) account` — An account to unregister from producers (required).

### Options

* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'account\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos system unregprod [OPTIONS] <account>
```

## System Voteproducer Proxy

### Description

This subcommand can be used to vote your stake through a proxy.

### Positional Parameters

* `(string) voter` — The voting account (required).
* `(string) proxy` — The proxy accoun (required).
* `(string) quantity` — An asset quantity that the voter delegates to the proxy to vote for the producer (required).

### Options

* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'voter\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos system voteproducer proxy [OPTIONS] <voter> <proxy> <quantity>
```

## System Voteproducer Prods

### Description

This subcommand can be used to vote for a producer.

### Positional Parameters

* `(string) voter`— A voting account (required).
* `(string) producer`— An account to vote for (required).
* `(string) quantity`— An asset quantity  that the voter votes for the producer (required).

### Options

* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'voter\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos system voteproducer prods [OPTIONS] <voter> <producer> <quantity>
```

## System Listproducers

### Description

This subcommand can be used to obtain a list of producers.

### Positional Parameters

No parameters required for this subcommand.

### Options

* `--json`, `-j`— Output in JSON format.
* `-l`, `--limit` *UINT* — The maximum number of rows to return.
* `-L`, `--lower` *TEXT* — Lower bound value of key, defaults to first.

### Command

```bash
$ cleos system listproducers [OPTIONS]
```

## System Delegatebw

### Description

This subcommand can be used to delegate bandwidth.

### Positional Parameters

* `(string) from` — The account to delegate bandwidth from (required).
* `(string) receiver` — The account to receive the delegated bandwidth (required).
* `(string) stake_quantity` — The amount of tokens to stake (required).

### Options

* `--transfer`— Transfer voting power and right to unstake tokens to receiver.
* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'from\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos system delegatebw [OPTIONS] <from> <receiver> <stake_quantity>
```

### Examples

'alice' delegates *10* tokens to 'bob'

```bash
cleos system delegatebw alice bob "10.0000 CYBER"
```

## System Undelegatebw

### Description

This subcommand can be used to undelegate bandwidth.

### Positional Parameters

* `(string) from` — The account undelegating bandwidth (required).
* `(string) receiver` — The account to undelegate bandwidth from (required).
* `(string) unstake_quantity` — The amount of tokens to undelegate (required).

### Options

* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'from\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos system undelegatebw [OPTIONS] <from> <receiver> <unstake_quantity>
```

## System Claimbw

### Description

This subcommand can be used to claim undelegated bandwidth.\
This operation can only be performed 30 days after completion of `undelegatebw` (see [Sake Usage Guide](https://docs.cyberway.io/validators/stake_usage_guide#undelegatebw)).

### Positional Parameters

* `(string) from` — An account claims undelegated stake (required).
* `(string) receiver` — An account returning stake (required).
* `(string) token_code` — An asset symbol claimed (required).

### Options

No options required for this subcommand.

### Command

```bash
$ cleos system claimbw <from> <receiver> <token_code>
```

### Examples

'alice' credits the amount of staked tokens returned from 'bob' to a stake.

```bash
$ cleos system claimbw alice bob "CYBER"
```

## System Listbw

### Description

This subcommand can be used to list delegated bandwidth.

### Positional Parameters

* `(string) account` — The account delegated bandwidth (required).

### Options

* `--json`, `-j` — Output in JSON format.

### Command

```bash
$ cleos system listbw [OPTIONS] <account>
```

### Examples

'alice' receives a list of users to whom she delegated bandwidth (staked tokens).

```bash
$ cleos system listbw alice
```

## System Bidname

### Description

Name bidding subcommand.

### Positional Parameters

* `(string) bidder` — The bidding account (required).
* `(string) newname` — The name which the bid is done for (required).
* `(string) bid` — The amount of system tokens to bid (it is asset structure) (required).

### Options

* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'bidder\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos system bidname [OPTIONS] <bidder> <newname> <bid>
```

### Examples

'accountname1' bids *100* tokens to buy 'alice' name at an auction.

```bash
$ cleos system bidname accountname1 alice "100.0000 CYBER"
```

## System Bidnameinfo

### Description

This subcommand can be used to get bidname info.

### Positional Parameters

* `(string) newname` — The name to lookup to lookup (required).

### Options

* `--json`, `-j` — Output in JSON format.

### Command

```bash
$ cleos system [OPTIONS] <newname>
```

### Examples

```bash
$ cleos system bidnameinfo alice
```

## System Setproxylvl

### Description

This subcommand can be used to set an account proxy level.

### Positional Parameters

* `(string) account` — An account whose proxy level will be set (required).
* `(uint) level` — A proxy level to set (required).

### Options

* `--symbol` — A symbol of an asset used in the system.
* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'account\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos system setproxylvl [OPTIONS] <account> <level>
```

## System Regproxy

### Description

This subcommand can be used to register an account as a proxy (for voting).

### Positional Parameters

* `(string) proxy` — A proxy account to register (required).

### Options

* `--symbol` *TEXT* — A token symbol used by producers.
* `--level` *UINT* — A proxy level (must be greater than 0, but less than MAX\_LEVEL. Default MAX\_LEVEL value is *1* ).
* `--fee` *UINT* — A part of the fee proxies get for a block producing (takes an ineteger value from *0* to *10000* inclusive (*10000* means *100,00* %).
* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'proxy\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos system regproxy [OPTIONS] <proxy>
```

### Examples

'alice' registers as a proxy having level=1 and fee=50(%).

```bash
$ cleos system regproxy --symbol=4,CYBER --level=1 --fee=5000 alice
```

## System Unregproxy

### Description

Unregister an account as a proxy (for voting).

### Positional Parameters

* `(string) proxy` — The proxy account to unregister (required).

### Options

* `--symbol` *TEXT* — A token symbol used by producers.
* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'proxy\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos system unregproxy [OPTIONS] <proxy>
```

### Examples

'alice' stops registering as a proxy account.

```bash
$ cleos system unregproxy --symbol=4,CYBER alice
```

## System Stake

### Description

This subcommand can be used to stake assets to gain resources.

### Positional Parameters

* `(string) account` — An account who stakes assets (required).
* `(string) quantity` — Assets quantity to stake (required).

### Options

* `--beneficiary` *TEXT* — An account gaining resources.

### Command

```bash
$ cleos system stake [OPTIONS] <account> <quantity>
```

### Examples

```bash
 cleos system stake alice "100.0000 CYBER" --beneficiary=bob
```

## System Canceldelay

### Description

This subcommand can be used to cancel a delayed transaction.

### Positional Parameters

* `(string) canceling_account` — Account from authorization on the original delayed transaction (required).
* `(string) canceling_permission` — Permission from authorization on the original delayed transaction (required).
* `(string) trx_id` — The transaction id of the original delayed transaction (required).

### Options

* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'canceling\_account\@canceling\_permission').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

### Command

```bash
$ cleos system canceldelay [OPTIONS] <canceling_account> <canceling_permission> <trx_id>
```


# Transfer

## Description

The subcommand can be used to transfer tokens from account to account.

## Positional Parameters

* `(string) sender` — The account sending tokens (required).
* `(string) recipient` — The account receiving tokens (required).
* `(string) amount` — The amount of tokens to send (required).
* `(string) memo` — The memo for the transfer.

## Options

* `--contract`, `-c` *TEXT* — The contract which controls the token.
* `--pay-ram-to-open` — Pay ram to open recipient's token balance row.
* `-x`, `--expiration` *TEXT* — Set the time (in seconds) before a transaction expires, defaults to *30* s.
* `-f`, `--force-unique` — Force the transaction to be unique. This will consume extra bandwidth and remove any protections against accidently issuing the same transaction multiple times.
* `-s`, `--skip-sign` — Specify if unlocked wallet keys should be used to sign transaction.
* `-j`, `--json` — Print result as JSON.
* `-d`, `--dont-broadcast` — Do not broadcast transaction to the network (just print to `stdout`).
* `--return-packed` — Used in conjunction with `--dont-broadcast` to get the packed transaction.
* `-r`, `--ref-block` *TEXT* — Set the reference block num or block id used for TAPOS (Transaction as Proof-of-Stake).
* `-p`, `--permission` *TEXT* — An account and permission level to authorize, as in 'account\@permission' (defaults to 'sender\@active').
* `--max-cpu-usage-ms` *UINT* — Set an upper limit on the milliseconds of CPU usage budget, for the execution of the transaction (defaults to *0* which means no limit).
* `--max-net-usage` *UINT* — Set an upper limit on the net usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-ram-usage` *UINT* — Set an upper limit on the ram usage budget (in bytes) for the transaction (defaults to *0* which means no limit).
* `--max-storage-usage` — Set an upper limit on the storage usage budget, (in bytes) for the transaction (defaults to *0* which means no limit).
* `--delay-sec` *UINT* — Set the `delay_sec` seconds, defaults to *0* s.
* `--bandwidth-provider` *TEXT* — Set an account which provide own bandwidth for transaction.
* `--dont-declare-names` — Do not add `declarenames` action for resolved account names.

## Command

```bash
$ cleos transfer [OPTIONS] <sender> <recipient> <amount> [<memo>]
```

## Examples

'alice' transfers *100* CYBER to 'bob'.

```bash
$ cleos transfer alice bob "100.0000 CYBER" "use for voting only"
```


# Version

## Description

Retrieve version information. Retrieve version information of the client.

## Positional Parameters

None.

## Options

None.

## Usage

Retrieve version information.

```bash
$ cleos version
```

Retrieve version information of the client

```bash
$ cleos version client
```


# Wallet

**Description**\
The subcommands can be used to interact with local wallet.

**Subcommands**

* [Wallet Create](/software_manuals/command_reference/wallet#wallet-create) — Create a new wallet locally.
* [Wallet Open](/software_manuals/command_reference/wallet#wallet-open) — Open an existing wallet.
* [Wallet Lock](/software_manuals/command_reference/wallet#wallet-lock) — Lock wallet.
* [Wallet Lock All](/software_manuals/command_reference/wallet#wallet-lock-all) — Lock all unlocked wallets.
* [Wallet Unlock](/software_manuals/command_reference/wallet#wallet-unlock) — Unlock wallet.
* [Wallet Import](/software_manuals/command_reference/wallet#wallet-import) — Import private key into wallet.
* [Wallet Remove Key](/software_manuals/command_reference/wallet#wallet-remove-key) — Remove key from wallet.
* [Wallet Create Key](/software_manuals/command_reference/wallet#wallet-create-key) — Create private key within wallet.
* [Wallet List](/software_manuals/command_reference/wallet#wallet-list) — List opened wallets.
* [Wallet Keys](/software_manuals/command_reference/wallet#wallet-keys) — List of public keys from all unlocked wallets.
* [Wallet Private Keys](/software_manuals/command_reference/wallet#wallet-private-keys) — List of private keys from an unlocked wallet in WIF or PVT\_R1 format.

## Wallet Create

### Description

This subcommand creates a wallet with the specified name. If no name is given, the wallet will be created with the name 'default'.

### Positional Parameters

None.

### Options

* `-n`, `--name` *TEXT* — The name of the new wallet.
* `-f`, `--file` *TEXT* — Name of file to write wallet password output to (must be set, unless `--to-console` is passed).
* `--to-console` — Print password to console.

### Command

```bash
$ cleos wallet create [OPTIONS]
```

### Examples

```bash
$ cleos wallet create --name=walletname1 --to-console
```

## Wallet Open

### Description

This subcommand can be used to open an existing wallet.

### Positional Parameters

None.

### Options

* `-n`, `--name` *TEXT* — The name of the wallet to open.

### Command

```bash
$ cleos wallet open [OPTIONS]
```

### Examples

*Example 1*

```bash
$ cleos wallet open
```

*Example 2*

```bash
$ cleos wallet open --name=walletname1
```

*Output*

```
Opened: walletname1
```

## Wallet Lock

### Description

This subcommand can be used to lock wallet.

### Positional Parameters

None.

### Options

* `-n`, `--name` *TEXT* — The name of the wallet to lock.

### Command

```bash
$ cleos wallet lock [OPTIONS]
```

### Examples

*Example 1*

```bash
$ cleos wallet lock
```

*Example 2*

```bash
$ cleos wallet lock --name=walletname1
```

*Output*

```
Locked: walletname1
```

## Wallet Lock All

### Description

This subcommand can be used to lock all unlocked wallets.

### Positional Parameters

None.

### Options

None.

### Command

```bash
$ cleos wallet lock_all
```

*Output*

```
Locked All Wallets
```

## Wallet Unlock

### Description

This subcommand can be used to unlock wallet.

### Positional Parameters

None.

### Options

* `-n`, `--name` *TEXT* — The name of the wallet to unlock.
* `--password` *TEXT* — The password returned by [wallet create](/software_manuals/command_reference/wallet#wallet-create).

### Command

```bash
$ cleos wallet unlock [OPTIONS]
```

### Examples

To unlock a wallet, specify the password provided when it was created.

```bash
$ cleos wallet unlock --name=walletname1 --password=XXXXXXXX
```

*Output*

```
Unlocked: walletname1
```

## Wallet Import

### Description

This subcommand can be used to import private key into wallet.

### Positional Parameters

None.

### Options

* `-n,--name` *TEXT* — The name of the wallet to import key into.
* `--private-key` *TEXT* — Private key in WIF format to import.

### Command

```bash
$ cleos wallet import [OPTIONS]
```

### Examples

```bash
$ cleos wallet import --name=walletname1 --private-key=3Rft...Uh6
```

## Wallet Remove Key

### Description

This subcommand can be used to remove key from wallet.

### Positional Parameters

* `(string) key` — Public key in WIF format to remove (required).

### Options

* `-n`, `--name` *TEXT* — The name of the wallet to remove key from.
* `--password` *TEXT* — The password returned by [wallet create](/software_manuals/command_reference/wallet#wallet-create).

### Command

```bash
$ cleos wallet remove_key <key> [OPTIONS]
```

### Examples

```bash
$ cleos wallet remove_key GLS8PE...rS3T --name=walletname1 --password=XXXXXXXX
```

## Wallet Create Key

### Description

This subcommand can be used to creates a key pair within the wallet so that you don't need to manually import it like you would with cleos create key. By default, this will create a key with the type "favored" by the wallet, which is a "K1" key. This subcommand also lets you create a key in "R1" format.

### Positional Parameters

* `(string) key_type` — "K1" or "R1" key type to create. "K1" generates privileged key. Defaults to "K1".

### Options

* `-n`, `--name` *TEXT* — The name of the wallet to create key into.

### Command

```bash
$ cleos wallet create_key [OPTIONS]
```

### Examples

```bash
$ cleos wallet create_key K1 --name-walletname1
```

```
Created new private key with a public key of: "GLS8PE...6tR, X6P...5EfG"
```

## Wallet List

### Description

The subcommand can be used to list opened wallets ("\*" means "unlocked").

### Positional Parameters

None.

### Options

None.

### Command

```bash
$ cleos wallet list
```

*Output*

```
Wallets:
[
  "default *",
  "walletname1 *"
]
```

or when there are no wallets:

```
Wallets:
[
]
```

## Wallet Keys

### Description

The subcommand can be used to list of public keys from all unlocked wallets. These are the keys that could be used to sign transactions.

### Positional Parameters

None.

### Options

None.

### Command

```bash
$ cleos wallet keys
```

*Output*

```
[[
    "GLS6MR...qcVpscN",
    "PbwdL6...FSSwsST3"
  ]
]
```

### Examples

```bash
$ cleos wallet
```

## Wallet Private Keys

### Description

The subcommand can be used to list of private keys from an unlocked wallet in WIF or PVT\_R1 format.\
It is possible to query for the public and private key pairs of an individual wallet. The wallet must already be unlocked and you must give the password again.

### Positional Parameters

None.

### Options

* `-n`, `--name` *TEXT* — The name of the wallet to list keys from.
* `--password` *TEXT* — The password returned by wallet create.

### Command

```bash
$ cleos wallet private_keys [OPTIONS]
```

### Examples

```bash
$ cleos wallet private_keys --name-walletname1 --password=XXXXXXXX
```


# Explorer Command Reference

This Command Reference includes information about CYBER/GOLOS token operations that are available in CyberwayIO Explorer from the menus. The sequence of actions is given by specific examples.

* [How To Check Your Balance](/software_manuals/explorer_command_reference/check_balance)
* [How To Find Out Account ID](/software_manuals/explorer_command_reference/user_id)
* [How To Convert *Golos* To *Golos Power* And Vice Versa](/software_manuals/explorer_command_reference/convert_golos)
* [How To Stake Tokens *CYBER*](/software_manuals/explorer_command_reference/convert_cyber)
* [How To Transfer Funds From One Account To Another](/software_manuals/explorer_command_reference/transfer)
* [How To Transfer Funds From Pending to Liquid](/software_manuals/explorer_command_reference/claim)
* [How To Bay Stake](/software_manuals/explorer_command_reference/bay_stake)
* [How To Withdraw Stake](/software_manuals/explorer_command_reference/withdraw)
* [How To Vote For A Validator](/software_manuals/explorer_command_reference/delegatevote)
* [How To Revoke Your Vote For A Validator](/software_manuals/explorer_command_reference/recallvote)
* [How To Bay Vesting Using Explorer](/software_manuals/explorer_command_reference/bay_vesting)
* [How To Vote For A Witness](/software_manuals/explorer_command_reference/witnessvote)
* [How To Revoke Your Vote For A Witness](/software_manuals/explorer_command_reference/unvotewitness)


# How To Check Your Balance

## Goal

Check your token balance.

## Steps

The operation can be performed in two ways - using the site `golos.io` and using explorer `cyberway.io`.

### Way 1: Check your balance using the site golos.io

#### Step 1.1

Go to the page `https://golos.io/<account name>`. Let the account name is *golos*.

#### Step 1.2

Open *wallet* tab. The types of tokens available on account balance will be shown in the left menu.

![](/files/-MCHUpQuul8iNhZBdGlj)

The fields at the top of menu indicate actions that can be performed by your account.

*Golos* and *CYBER* fields are types of tokens that are on your account balance.

*Golos Power* and *CYBER STAKE* fields are number of staked tokens of *Golos* and *CYBER* respectively.

*Awaiting* field is number and type of tokens in the state of illiquid.

### Way 2: Check your balance using explorer cyberway.io

#### Step 2.1

Go to the page `https://explorer.cyberway.io/`and specify account name. Please note that different names may be assigned to accounts depending on dApps. Let it i *andreypf*.

![](/files/-MCHUpQx4gVPI14TTpaw)

#### Step 2.2

In window that opens, all information about this account will be displayed, including balance.

![](/files/-MCHUpQy104JCLV-Zigs)

You can see the following information:

* `CYBER` Tokens: 804.0000
* `GOLOS` Tokens: 0.188
* `GOLOS` Tokens in the state of illiquid: 0.754

Also, you can see status of the steak:\
`Own` field shows amount of tokens that are available for conversion to`CYBER`. This field is updated after each account action.

Please note that the explorer does not show `Golos Power` balance, since this type of token is specific and applicable only to dApp Golos. Therefore, explorer it is not available.


# How To Find Out Account ID

## Goal

Define account ID (not account name) for GOLOS dApp.

## Steps

### Step 1

Go to the page `https://golos.io/<account name>`. Let the account name is *anazarov*.

### Step 2

Open the tab `Settings` and then click `Account`.

![](/files/-MCHUpnT7rcSOLEqZwI7)

The field `User ID` contains ID to search for.\
Please note that the user ID of the same account will be different in each application.


# How To Convert Golos To Golos Power And Vice Versa

## Goal

Convert the tokens *Golos* to *Golos Power* and vice versa.

## Steps

### Step 1

Go to the page `https://golos.io/<account name>` and open *wallet* tab. Let the account name is *anazarov*.

### Step 2

Fields at top of the left menu indicate actions that can be performed by the account. Choose the action *convert*.

![](/files/-MCHUpQdnDpo4XLWo-0B)

In opened window, you can take the conversion action you need.

### Step 3

To convert the tokens *Golos* to *Golos Power* you need to click *Golos* and *Golos -> Golos Power*.\
To convert the tokens *Golos Power* to *Golos* you need to click *Golos* and *Golos Power -> Golos*.

You have to set amount of tokens *Golos* with an accuracy of three characters after the point.\
Operation cannot be performed if there are not enough funds on the account balance. In this case, the message "Insufficient funds" appears.

### Step 4

Click *Convert* to run the operation.


# How To Stake Tokens CYBER

## Goal

Stake/unstake the tokens *CYBER*.

## Steps

### Step 1

Go to the page `https://golos.io/<account name>` and open *wallet* tab. Let the account name is *anazarov*.

### Step 2

Fields at top of the left menu indicate actions that can be performed by the account. Choose the action *convert*.

![](/files/-MCHUpSvBiULF4553vHw)

In opened window, you can take the conversion action you need.

### Step 3

To stake the tokens *CYBER* you need to click *CYBER* and *CYBER -> STAKED*.\
To unstake the tokens *CYBER* you need to click *CYBER* and *STAKED -> CYBER*..

Amount of tokens *CYBER* is indicated with an accuracy of four characters after the point.\
Operation cannot be performed if there are not enough funds on the account balance. In this case, the message "Insufficient funds" appears.

### Step 4

Click *Convert* to run the operation.


# How To Transfer Funds From One Account To Another

### Goal

Transfer tokens from your balance to another.\
You can also use this operation to transfer funds to an exchange.

## Steps

The operation can be performed through the contract `cyber.token`.

### Step 1

Go to the page `https://explorer.cyberway.io/account/cyber.token/contract` and specify account name. Let it be *zxcat*.

![](/files/-MCHUpKaIoQrPpkD7hUB)

Also keep ID of the account you are setting. In our case, this is `xhdtonx5zvnd`.

### Step 2

In menu that opens, select action `transfer` and fill in the fields.

![](/files/-MCHUpKeExSLMiSLtE0v)

**Fields:**

* `from` - the identifier of your account.
* `to` - the recipient's account. If you are unsure of the recipient account ID, you need to get it directly from the recipient user.
* `quantity` - the number of funds transferred, taking into account the required accuracy. For *GOLOS* tokens, you must specify three numbers after the point, for *CYBER* - four.
* `Memo` - field is optional to leave a comment.
* `authorization` - the same identifier of your account.

### Step 3

Click `Build transaction`.

### Step 4

Check transaction.

![](/files/-MCHUpKf8HOkOPx9FTli)

Make sure the transaction contains correct information.

### Step 5

Subscribe with your private key and click `Sign transation` to send it on blockchain.


# How To Transfer Funds From Pending to Liquid

### Goal

Transfer tokens from pending to liquid.

## Steps

The operation can be performed through the contract `cyber.token`.

### Step 1

Go to the page `https://explorer.cyberway.io/account/cyber.token/contract` and specify account name. Let it is *zxcat*.

### Step 2

Open an account balance and determine amount of tokens that need to be made liquid.

![](/files/-MCHUpkztyvHvxB7QXOn)

The field `paiments` contains amount of "pending" tokens that is 0.764 GOLOS. This amount is to be transfered to liquid.

### Step 3

![](/files/-MCHUpKaIoQrPpkD7hUB)

Keep ID of your account. In our case, this is `xhdtonx5zvnd`.

### Step 4

In menu that opens, select action `claim` and fill in the fields.

![](/files/-MCHUpkztyvHvxB7QXOn)

**Fields:**

* `owner` - the identifier of your account.
* `quantity` - the number of funds transferred, taking into account the required accuracy. For *GOLOS* tokens, you must specify three numbers after the point, for *CYBER* - four.
* `authorization` - the same identifier of your account.

### Step 5

Click `Build transaction`.

### Step 6

Check transaction.

![](/files/-MCHUpl3QnLqefQKTts0)

Make sure the transaction contains correct information.

### Step 7

Subscribe with your private key and click `Sign transation` to send it on blockchain.

### Step 8

Return to page with account balance again and make sure that the `payment` field has become empty, and amount of liquid tokens has increased by the number of funds transferred.


# How To Bay Stake

## Goal

Transfer tokens *CYBER* to stake.

## Steps

The operation can be performed through the contract `cyber.token`.

### Step 1

Go to the page `https://explorer.cyberway.io/account/<account ID>` and specify ID of your account. Let it is *shwojevqcywn*. See balance of this account.

![](/files/-MCHUpZ33dt9OX_VwhF5)

The field `Own`contains total amount of staked tokens of this account. In addition, there are another 804,0000 CYBER tokens on balance of this account. This amount can be spent on purchase of stake.

### Step 2

Go to the page `https://explorer.cyberway.io/account/cyber.token/contract`.

### Step 3

Choose the tab `transfer` and fill in fields.

![](/files/-MCHUpZ5wy5vHOm-Zf6y)

**Fields:**

* `from` - the identifier of your account.
* `to`- recipient, the contract `cyber.token`.
* `quantity` - the number of funds transferred, taking into account the required accuracy. For *CYBER* tokens, you must specify four numbers after the point.
* `memo` - field is left blank (or your account)if the stake is bought for itself. If the staked tokens are transferred to another account, you have to specify ID of account-recipient. Tokens will be transferred to steak of that account.
* `authorization` - the same identifier of your account.

### Step 4

Click `Build transaction`.

### Step 5

Check transaction.\
Make sure the transaction contains correct information.

### Step 6

Subscribe with your private key and click `Sign transation` to send it on blockchain.


# How To Withdraw Stake

## Goal

Withdraw tokens *CYBER* from stake and make them liquid.

## Steps

The operation can be performed through the contract `cyber.stake`.

### Step 1

Go to the page `https://explorer.cyberway.io/account/<account ID>` and specify ID of your account. Let it is *shwojevqcywn*. See balance of this account.

![](/files/-MCHUpZ33dt9OX_VwhF5)

The field `Own`contains total amount of staked tokens of this account. Note, only a part of this amount can be withdrawn because a piece of the steak is blocked due to using resources. You should also check whether the staked tokens have been transfered to perform an operation (i.e., transferred to proxy account for voting).

### Step 2

Go to the page `https://explorer.cyberway.io/account/cyber.stake/contract`.

### Step 3

Choose the tab `withdrawn` and fill in fields.

![](/files/-MCHUpbiQxNyMUpWerBO)

**Fields:**

* `account` - the identifier of your account.
* `quantity` - the number of funds transferred, taking into account the required accuracy. For *CYBER* tokens, you must specify four numbers after the point.
* `authorization` - the same identifier of your account.

### Step 4

Click `Build transaction`.

### Step 5

Check transaction.\
Make sure the transaction contains correct information.

### Step 6

Subscribe with your private key and click `Sign transation` to send it on blockchain.\
Operation is performed instantly.


# How To Vote For A Validator

### Goal

Delegate a part of staked tokens to a validator or to proxy account for voting.

## Steps

The operation can be performed through the contract `cyber.stake`.

### Step 1

Go to the page `https://explorer.cyberway.io/account/cyber.stake/contract`.

### Step 2

In menu that opens, select action `delegatevote` and fill in the fields.

![](/files/-MCMG9Qu-xE0fnMkfI6P)

**Fields:**

* `grantor_name` - the identifier of your account.
* `recipient_name` — the identifier of a validator or proxy account.
* `quantity` - an amount of staked tokens transferred, taking into account the required accuracy. For *CYBER* tokens, you must specify four numbers after the point.
* `authorization` - the same identifier of your account.

### Step 3

Click `Build transaction`.

### Step 4

Review transaction.

![](/files/-MCMG9QvMB5jjb9wLBTH)

Make sure the transaction contains correct information.

### Step 5

Subscribe with your private key and click `Sign transation` to send it on blockchain.


# How To Revoke Your Vote For A Validator

### Goal

Recall the right to use a delegated stake when voting for validators. The steak can be withdrawn partially or completely.\
The operation can be performed in two ways: automatically or manually.

## Way 1: Automatic

### Step 1.1

Go to the page `https://explorer.cyberway.io/account/<account name>`. Let the account name is `zzzzzzzzzzzz`.

### Step 1.2

Review the field `Grants`. This field will display information about staked tokens delegated to accounts (validators or proxies).

![](/files/-MCMGB1V3O-cv95g3xAp)

Click `Recall`.

### Step 1.3

Fill in the fields in window that appears.

![](/files/-MCMGB1WMbrNQ1H0eHPp)

Fill in the field in window that appears - sign with your active key.

## Way 2: Manual

The operation can be performed through the contract `cyber.stake`.

### Step 2.1

Go to the page `https://explorer.cyberway.io/account/cyber.stake/contract`.

### Step 2.2

In menu that opens, select action `recallvote` and fill in the fields.

![](/files/-MCMGB1YH_BtZ1YeFtqz)

Fields:

* `grantor_name` - the identifier of account that withdraws the right to use the stake.
* `recipient_name` - the identifier of a validator or proxy account from which the right to use the stake is withdrawn.
* `token_code` - the type of token (just specify *CYBER*).
* `pct` - share of stake. The value is in percent (5000 corresponds to 50%, 10000 corresponds to 100%).
* `authorization` - the same identifier of your account.

### Step 2.3

Click `Build transaction`.

### Step 2.4

Review transaction. Make sure the transaction contains correct information.

### Step 2.5

Subscribe with your private key and click `Sign transation` to send it on blockchain.

Note, funds will not be returned immediately, but after a certain time.


# How To Bay Vesting Using Explorer

### Goal

Transfer tokens *GOLOS* to *Golos Power* using Cyberway Explorer.

## Steps

The operation can be performed through the contract `cyber.token`.

### Step 1

Go to the page `https://golos.io/<@account name>/wallet` and review your token *GOLOS* and *Golos Power* balances.

![](/files/-MCHUpQuul8iNhZBdGlj)

The field *Golos* displays number of tokens that you can spend to purchase *Golos Power*.

### Step 2

Go to the page `https://explorer.cyberway.io/account/cyber.token/contract`. In menu that opens, select action `transfer` and fill in the fields.

![](/files/-MCMG8xxRW5rSPcxc5eD)

**Fields:**

* `from` - the identifier of your account.
* `to` - the account of recipient. This is *golos.vesting*.
* `quantity` - the number of tokens, taking into account the required accuracy. For *GOLOS* tokens, you must specify three numbers after the point.
* `Memo` - the identifier of your account if you buy tokens for yourself.
* `authorization` - the same identifier of your account.

### Step 3

Click `Build transaction`.

### Step 4

Check transaction. Make sure the transaction contains correct information.

### Step 5

Subscribe with your private key and click `Sign transation` to send it on blockchain.

### Step 6

Open the page `https://golos.io/<@account name>/wallet` and check the field *Golos Power* value. It should be increased by the purchase amount in accordance with current exchange rate.


# How To Vote For A Witness

### Goal

Transfer a part of tokens *Golos Power* to vote for a witness candidate.

## Steps

The operation can be performed through the contract `gls.ctrl`.

### Step 1

Go to the page `https://golos.io/<@account name>/wallet` and review your token balance.

![](/files/-MCHUpQuul8iNhZBdGlj)

The field *Golos Power* displays number of tokens a part of which you can spend on voting for witness.

### Step 2

Go to the page `https://explorer.cyberway.io/account/gls.ctrl/contract`.

### Step 3

In menu that opens, select action `votewitness` and fill in the fields.

![](/files/-MCMG9HX7wNFI-D6dyr-)

**Fields:**

* `voter` - account ID that is voting for the witness candidate.
* `witness` - account ID of the witness candidate for whom the vote is cast.
* `authorization` - the same account ID that is voting.

### Step 4

Click `Build transaction`.

### Step 5

Review transaction. Make sure the transaction contains correct information.

### Step 6

Subscribe with your private key and click `Sign transation` to send it on blockchain.


# How To Revoke Your Vote For A Witness

### Goal

Withdraw a previously cast vote for a witness candidate whose activity is suspended.

## Steps

The operation can be performed through the contract `gls.ctrl`.

### Step 1

Go to the page `https://explorer.cyberway.io/account/gls.ctrl/contract`.

### Step 2

In menu that opens, select action `unvotewitn` and fill in the fields.

![](/files/-MCMG95-hbxW2QCxTu4f)

**Fields:**

* `voter` - account ID that that intends to withdraw vote which was previously cast for the witness candidate.
* `witness` - account ID of the witness candidate for whom the vote is withdrawn.
* `authorization` - the same account ID that intends to withdraw vote.

### Step 3

Click `Build transaction`.

### Step 4

Review transaction. Make sure the transaction contains correct information.

### Step 5

Subscribe with your private key and click `Sign transation` to send it on blockchain.


# DEVPORTAL

* [System Contracts](/devportal/system_contracts)
* [Application Contracts](/devportal/application_contracts) &#x20;
* [Guide to Creating and Deploying an Application on CyberWay](/devportal/create_application) &#x20;
* [The cyberway\_wallet designed for the Bittrex market](/devportal/cyberway_wallet_for_bittrex) &#x20;
* [The Event Model](/devportal/event_engine) &#x20;


# System Contracts

* [BIOS](/devportal/system_contracts/cyber.bios_contract)
* [Domain names](/devportal/system_contracts/cyber.domain_contract)
* [Govern](/devportal/system_contracts/cyber.govern_contract)
* [Multi-Signature](/devportal/system_contracts/cyber.multi-signature_contract)
* [Stake](/devportal/system_contracts/cyber.stake_contract)
* [Tokens](/devportal/system_contracts/cyber.token_contract)


# BIOS

## Purpose of the cyber.bios smart contract

The `cyber.bios` smart contract is used as a link between operations, executed both directly in smart contracts and the node core.

The actions supported:

* [newaccount](/devportal/system_contracts/cyber.bios_contract#newaccount)
* [setprods](/devportal/system_contracts/cyber.bios_contract#setprods)
* [setparams](/devportal/system_contracts/cyber.bios_contract#setparams)
* [reqauth](/devportal/system_contracts/cyber.bios_contract#reqauth), [setabi](/devportal/system_contracts/cyber.bios_contract#setabi)
* [setcode](/devportal/system_contracts/cyber.bios_contract#setcode)
* [onblock](/devportal/system_contracts/cyber.bios_contract#onblock)
* [checkwin](/devportal/system_contracts/cyber.bios_contract#checkwin)
* [bidname](/devportal/system_contracts/cyber.bios_contract#bidname)
* [bidrefund](/devportal/system_contracts/cyber.bios_contract#bidrefund)
* [canceldelay](/devportal/system_contracts/cyber.bios_contract#canceldelay)
* [updateauth](/devportal/system_contracts/cyber.bios_contract#updateauth)
* [deleteauth](/devportal/system_contracts/cyber.bios_contract#deleteauth)
* [linkauth](/devportal/system_contracts/cyber.bios_contract#linkauth)
* [unlinkauth](/devportal/system_contracts/cyber.bios_contract#unlinkauth)

## newaccount

The `newaccount` action is used when creating new accounts in the system.

```cpp
void bios::newaccount(
    name creator,
    name name,
    authority owner,
    authority active
)
```

**Parameters:**

* `creator` — new account creator.
* `name` — the account name that is created in the system.
* `owner` — structure of type `authority` containing `owner public key` for the new account.
* `active` — structure of type `authority` containing `active public key` for the new account.

**Restrictions:**

* The name created (not redeemed at auction) must contain no more than 12 characters. Also, it must not contain the dot symbol.
* The name purchased at auction or created through the system account can be expanded by adding characters to the right after the dot symbol (for example, an owner of the name `cyber` can expanded it to the name `cyber.anyname`). &#x20;

A transaction containing `newaccount` action must be signed by the new account creator.

## setprods

The action `setprods` is used when creating a block production schedule. This schedule contains a list of validators in accordance with their rating. This action is not accessible to a user and is called by the system. This action takes the following form:

```cpp
[[eosio::action]] void setprods(eosio::producer_key schedule )
```

The `schedule` parameter is a list of validator keys.

The `cyber` account signature is required to execute a transaction containing the `setprods` action (`cyber` is account of `cyber.bios` smart contract).

## setparams

The `setparams` action is used to configure system parameters. This action is not accessible to a user and is called by the system. This action takes the following form:

```cpp
[[eosio::action]] void setparams( eosio::blockchain_parameters params )
```

The `params` parameter is a structure containing settable system parameters.

The `cyber` account signature is required to execute a transaction containing the `setparams` action.

## reqauth

The `reqauth` action is used to verify the user's signature in a transaction. This action takes the following form:

```cpp
[[eosio::action]] void reqauth( name from )
```

The `from` parameter is the account whose signature is verified.

The `from` account signature is required to execute a transaction containing the `reqauth` operation.

## setabi

The `setabi` action is used to upload ABI-description to an account. This action takes the following form:

```cpp
[[eosio::action]] void setabi( 
    name account,
    std::vector<char> abi
)
```

**Parameters:**

* `account` — the account to which ABI-description will be downloaded.
* `abi` — an array of bytes containing ABI-description.

## setcode

The `setcode` action is used to upload smart contract code to an account. The signature of this action is:

```cpp
[[eosio::action]] void setcode( 
    name account,
    uint8_t vmtype,
    uint8_t vmversion,
    std::vector<char> code
)
```

**Parameters:**

* `account` — the account to which smart contract code will be downloaded.
* `vmtype` — type of contract (type of virtual machine). In this release, the parameter is set to «0».
* `vmversion` — version of contract (version of virtual machine). In this release, the parameter is set to «0».
* `code` — an array of bytes containing smart contract code.

## onblock

The `onblock` action is inaccessible to a user and is called by the system each time after creation of a new block. Inside `onblock`, the `cyber.govern` smart contract code is called. This action takes the following form:

```cpp
void bios::onblock(block_header header)
```

The `header` parameter is a block header.

## checkwin

Action `checkwin` is used to register a name owner (a winner) at auction. This action has no parameters and is called implicitly.

```cpp
void bios::checkwin()
```

## bidname

The bidname action allows a user to bid on a specific name at the names auction. This action takes the following form:

```cpp
void bios::bidname( 
    name bidder,
    name newname,
    eosio::asset bid
)
```

**Parameters:**

* `bidder` — an account which bids at the action.&#x20;
* `newname` — betting name (a name on which the bid is done).
* `bid` — a bet on the name (a structure value specified the bid). Bets are accepted only in system tokens (CYBER).

The `bidder` account will be announced as an owner (a winner) of `newname`, if:

* the `bid` is the highest in the name newname;
* the `bid` remains the highest after 24 hours.

  In this case, the bid is not returned to the bidder. If the `bid` is beaten within 24 hours, it will be returned back to the `bidder` (in this release, the bid is not automatically refunded;  a call of `bidrefund` is required to refund it). &#x20;

## bidrefund

The `bidrefund` action is used to refund a non-winning (not the highest) bid to an auction participant

```cpp
void bios::bidrefund( name bidder )
```

The `bidder` parameter is an auction participant to whom the bid is returned.

The bid is automatically refunded to `bidder` if the `bidder` does not become a winner. The bidder should create a transaction with the bidrefund operation to refund the bid. One calling `bidrefund` is enough to return all of non-winning bids in case the bidder put several bids on different names and neither of these bids (or part of them) were non-winning.

## canceldelay

The `canceldelay` action cancels a deferred transaction.

```cpp
void canceldelay(
    permission_level canceling_auth,
    eosio::checksum256 trx_id
)
```

**Parameters:**

* `canceling_auth` — value containing an account of the transaction creator and its permission (permission name takes the value `active`).
* `trx_id` — a deferred transaction identifier.

The `canceling_auth` account signature is required to execute a transaction containing the `canceldelay` operation.

## updateauth

The `updateauth` action is used to add or change authorization for an account. This action takes the following form:

```cpp
void updateauth( 
    name  account,
    name  permission,
    name  parent,
    authority auth
)
```

**Parameters:**

* `account` — an account name whose authorization changes.
* `permission` — a permission name (for example: owner, active, posting, etc.) to be changed.
* `parent` — a name of parent permission (for example: `owner` is the parent permission to `active`; `active` is the parent permission to `posting`. Child permissions cannot exceed parental permissions). In most cases, this parameter is set to \`active'. &#x20;
* `auth` — structure of the form `authority`, the new values of which should match the `permission`. &#x20;

The `account` signature is required to execute a transaction containing the `updateauth` operation.

## deleteauth

The action `deleteauth` is used to delete authorization of an account. This action takes the following form:

```cpp
void deleteauth(
    name account,
    name permission
)
```

**Parameters:**

* `account` — account name whose authorization is being deleted.&#x20;
* `permission` — permission name that is deleted. &#x20;

The `account` signature is required to execute a transaction containing the `deleteauth` operation.

## linkauth

The `linkauth` action allows the `permission` to execute some action in a specific contract.

```cpp
void linkauth( 
    name account,
    name code,
    name type,
    name requirement
)
```

**Parameters:**

* `account` — account name for which permission is changed.
* `code` — an account name of the contract in which some action will be executed.
* `type` — type of permission. Any action can be performed in the contract if this parameter is empty, otherwise only one operation specified in the parameter can be performed (parameter value matches the name of the action).&#x20;
* `requirement` — name of `permission`, which is allowed to perform the operation. This parameter cannot be empty.&#x20;

The parameters `account` and`requirement` specify `permission_level`.\
The parameters `code` and`type` specify the contract account and action, respectively.

> **Notes:**\
> Any set of `account`, `code`, and `type` parameters must correspond to only one `requirement` value. This means that one account cannot have two or more different permissions related to the same contract's account and action.
>
> If the same `account`,`code` and `type` values are passed to the action again, but with a different `requirement`, its previous value will be replaced by the last passed.

The `account` signature is required to execute a transaction containing the `linkauth` operation.

## unlinkauth

The `unlinkauth` action removes the name of `permission` provided by the `linkauth` action in a specific contract

```cpp
void unlinkauth(
    name account,
    name code,
    name type
)
```

**Parameters:**

* `account` — a name of the account whose permission is removed.
* `code` — an account name of the contract in which some action was allowed to execute.&#x20;
* `type` — type of permission..

The `account` signature is required to execute the transaction containing the `unlinkauth` operation.


# Domain names

## Purpose of the cyber.domain smart contract development

The `cyber.domain` smart contract is designed to create and handle domain names, create or delete a link of domain names to accounts, change domain name owners, as well as to handle a purchase of domain names at auction.

The `cyber.domain` smart contract includes the following actions:

* actions used to acquire a domain name at auction: [checkwin](/devportal/system_contracts/cyber.domain_contract#checkwin), [biddomain](/devportal/system_contracts/cyber.domain_contract#biddomain), [biddmrefund](/devportal/system_contracts/cyber.domain_contract#biddmrefund) and [newdomain](/devportal/system_contracts/cyber.domain_contract#newdomain).
* internal domain actions: [passdomain](/devportal/system_contracts/cyber.domain_contract#passdomain), [linkdomain](/devportal/system_contracts/cyber.domain_contract#linkdomain), [unlinkdomain](/devportal/system_contracts/cyber.domain_contract#unlinkdomain) and [newusername](/devportal/system_contracts/cyber.domain_contract#newusername). Although a code of these actions is in the blockchain core, they are called up via smart contract. &#x20;
* the action [declarenames](/devportal/system_contracts/cyber.domain_contract#declarenames) to declare the names used in transactions. &#x20;

## Requirements for domain names

Domain names in CyberWay are formed in accordance with rules and procedures of the Domain Name System (DNS). The following requirements are imposed on the structure of domain names:

* a total number of characters in domain name should not exceed 253 pcs.
* a domain name consists of individual *parts*, separated by the symbol «dot».
* the «dot» characters should not stand side by side in any domain name.
* a number of characters in a separate *part* of domain name should not exceed 63 pcs.
* the valid characters in the domain name are alphanumeric, plus «hyphen».
* the capital letters in the domain name are unacceptable.
* a symbol «hyphen» should not be at the beginning or end of any domain name *part*.
* the further right *part* of domain name must contain at least one alphabetic character. A presence of numeric characters only is not allowed.

## Requirements for user names

The following requirements are imposed on a user name structure:

* a total number of characters in a user name should not exceed 32 pcs. &#x20;
* a user name can consist of individual *parts* separated by the symbol «dot». &#x20;
* two «dot» symbols near each other are not allowed. &#x20;
* the valid characters in a user name should be alphanumeric, a symbol «hyphen» could be used as well. &#x20;
* the capital letters in a user name are unacceptable. &#x20;
* a symbol «hyphen» should not be at the beginning or end of any user name *part*. &#x20;

## Domain name auction in the smart contract

The actions `checkwin`, `biddomain`, `biddmrefund` and `newdomain` are used to purchase a domain name at auction. The procedure for buying a domain name at the auction is the same as the procedure of buying an account name. The following rules apply to the procedure:

* the bids for the purchase of any domain name are accepted at auction at any time. &#x20;
* the largest bid is used to determine only one domain name that can be purchased at the moment.
* a domain name is considered to be purchased at auction if the following conditions are met:
  * at least a day has passed after betting on the current domain name;
  * at least one day has passed since previous redemption of any domain name.
* upon completion of auction, a token transfer of the winner is not returned. The winner can take advantage of the following opportunities:
  * to create her/his own domain name using the operation `newdomain` and become its owner.
  * to create subdomain names from it by adding the «dot» symbol and а name to the domain name on the left (for example, an owner of the domain `golos.io` can create subdomains such as `api.golos.io`, `ws.golos.io` and etc). In this case the only direct inheritance of domain names is allowed. It means that if the owner has created a domain for the second level, a domain for the third level can’t be created.

> **Note:**\
> The *account names* are formed by adding parts **to the right** (for example, `cyber.msig`, `cyber.domain` can be formed from `cyber`).

### checkwin

The `checkwin` action is used to register a domain name owner (a winner) at auction. This action does not require a special call and is called automatically when either `biddomain` or `biddmrefund` is performing.

The `checkwin` action has the following form:

```cpp
[[eosio::action]] void checkwin();
```

This action has no input parameters and can be performed by any account.

### biddomain

The `biddomain` action allows an account to bid at the auction. The action has the following form:

```cpp
[[eosio::action]] void biddomain(
    name bidder,
    domain_name name,
    asset bid
);
```

**Parameters:**

* `bidder` — an account name which bids at the action. &#x20;
* `name` — a domain name (a string value in accordance with the requirements) on which the bid is done. &#x20;
* `bid` — a bid (in system tokens, `asset` structure). &#x20;

To perform this action the `cyber.domain` contract account should have the rights of the `bidder` account to call `transfer` action in `cyber.token` contract. If a bid with a bigger value appears at the auction, the previous bid is returned to the `bidder` account. The refunds are made automatically by internal calling `biddmrefund` from `biddomain`.

### biddmrefund

The action `biddmrefund` is used to return a bid which was made at the auction to purchase a domain name if a higher bid is made for the same domain name. The action has the following form:

```cpp
[[eosio::action]] void biddmrefund(
    name bidder,
    domain_name name
);
```

**Parameters:**

* `bidder` —  the account name to which the funds are returned from the auction.  &#x20;
* `name` — the domain name for which the bid was made. &#x20;

In case of exceptional situations (a network failure or an error in the node's operation), the `biddmrefund` action can be called apart from calling `biddomain` (non-standard calling `biddmrefund`).

### newdomain

The `newdomain` action is used to create a new domain name. The action has the following form:

```cpp
[[eosio::action]] void newdomain(
    eosio::name creator,
    domain_name name
);
```

**Parameters:**

* `creator` — account name that creates a domain name. &#x20;
* `name` — domain name being created. &#x20;

The `newdomain` action can be used:

* to create domain name by the system account `cyber.domain` (without an auction). &#x20;
* to create domain name by a winner of the domain name auction. &#x20;
* to create a sub-domain name by the owner of a direct parent domain. &#x20;

The smart contract account `cyber.domain` must be privileged or have a permission to transfer funds from `cyber.names` (in case of a refund). Upon completion of this action, the `creator` account becomes the owner of the created domain name.

## Username operations

### newusername

The `newusername` action is used to create a user name. The `newusername` declaration has the following form:

```cpp
[[eosio::action]] void newusername(
    name creator,
    name owner,
    username name
);
```

**Parameters:**

* `creator` — an account name in scope of which the user name is created. &#x20;
* `owner`— an account name that is to be the domain name owner. &#x20;
* `name` — a string representation of the user name to be created.  &#x20;

The transaction containing the operation `newusername` must be signed by `creator` account.

## Domain operations

### passdomain

The `passdomain` action is used to transfer a domain name from one account to another one (to change the domain name owner). The `passdomain` declaration has the following form:

```cpp
[[eosio::action]] void passdomain(
    name from,
    name to,
    domain_name name
);
```

**Parameters:**

* `from` — an account from which a domain name is transferred and which owns it. &#x20;
* `to` — an account to which the domain name is transferred and which will be a new domain name owner. &#x20;
* `name` — a string representation of the domain name to be transferred. &#x20;

The transaction requires a signature from the account `from` that is the domain name owner.

### linkdomain

The `linkdomain` action is used to link a domain name to account name. After linking, the account can be found by domain name instead of account name. The `linkdomain` declaration has the following form:

```cpp
[[eosio::action]] void linkdomain(
    name owner,
    name to,
    domain_name name
);
```

**Parameters:**

* `owner` — an account that is a domain name owner. &#x20;
* `to` — an account account to which the domain name is linked. &#x20;
* `name` — a string representation of the domain name to be linked. &#x20;

### unlinkdomain

The `unlinkdomain` action is used to remove domain name link from account name (unlinking a domain name from the account name). The `unlinkdomain` declaration has the following form:

```cpp
[[eosio::action]] void unlinkdomain(
    name owner,
    domain_name name
);
```

**Parameters:**

* `owner` — an account that is a domain name owner. &#x20;
* `name` — a string representation of the domain name to be unlinked. &#x20;

After performing `unlinkdomain`, the linked domain name will not point to the account.

### Examples of using the linkdomain, unlinkdomain and newusername

Let an account on which the contract is installed has a hard-to-remembered name `ajhgsd23qw`. To eliminate this drawback, this account buys the `hello` domain name and links it to its contract using`linkdomain`. It is easier for users to remember such domain as `@hello` and send transfers to this name. In contrast to sending transfers to the account name `ajhgsd23qw` the domain name `@hello` will be converted to `ajhgsd23qw` and the `declarenames` action will be added to the transaction indicating the used domain names.

To stop using the domain name `@hello` the account has to call the `unlinkdomain` action. After that, the domain name `@hello` will not be converted to `ajhgsd23qw` and sending a transfer to it will be impossible.

The `ajhgsd23qw` account in its environment can create usernames. For example, thic account can take the name `admin` for owan use, and can assign the short name `t` for the contract`cyber.token`. In this case, the name `admin@@ajhgsd23qw` (note the double `@@`) will be resolved in the name `ajhgsd23qw`, and `t@@ajhgsd23qw` in `cyber.token`. When adding a domain name, it is possible to use `admin@hello` and `t@hello` respectively.

## Declarations of the names used in transactions

It is not enough for one domain name to define a user name. The matter is, the user name is linked to both the owner account and the domain account (usually, it is a smart contract) and has a structure of the form `name@domain`. The domain part defines a scope. The accounts with the same name can exist in different scopes. There are several variants that support `username` data and allow a textual representation of a user name to match an account name.

### declarenames

The `declarenames` action is used to submit a list of structures with information about the domain names (or user names) used in transactions and their respective accounts. The action has the following form:

```cpp
[[eosio::action]] void declarenames(
    vector<name_info> domains
);
```

**Parameter:**

* `domains` — an array of descriptions, each description of which is a structure in form of `name_info`. &#x20;

The `declarenames` action can be called by any account.

### The name\_info struct declaration

The `name_info` structure is used to check the presence of all elements at the time of executing the procedure, as well as the existence of linking a domain name with the specified account. The `name_info` structure declaration has the following form:

```cpp
struct name_info {
    domain_name domain;
    name account;
    vector<username> users;
};
```

**Parameters:**

* `domain` — a domain name. &#x20;
* `account` — an account name matching to the domain name. &#x20;
* `users` — a list of domain name users. &#x20;

The input to the `declarenames` declaration is an array of structures. This array should not be empty.

There are no matches for user names because a user name, unlike domain name, does not change its account for the entire time.

The `domains` array should satisfy the following requirements:

* the list should not contain two structures with the same domain name (field `.domain`), except for empty values (“ ”).   &#x20;
* the field `.account` must not contain an empty value. &#x20;

### Notes

* This implementation does not verify that the accounts specified in `declarenames` exist in other actions. The implementation of validation is difficult because the actual validation process requires a lot of resources to read the ABI file format and deserialize the action. A lack of such control causes a certain risk. That is a sender may add more information to the transaction, so the superfluous part of it will not be checked. As a result, it will have to pay extra for overused `bandwidth` resources. &#x20;
* This implementation does not contain information about positions of the used domain or user names. &#x20;

### Example 1

A transaction may contain an action with several account names as arguments, for example:\
`someaction(name 1, name 2, name 3, name 4, name 5)`.\
If a user sends an action like `someaction(acc1, one@golos, two@golos, acc1, three@golos)` and it converts to (`someaction(acc1, acc1, acc1, acc1, acc3)` ), then `declarenames` will contain only used user names or domain names. At the same time, it is impossible to determine the positions where user names were used, for example:

```
        declarenames([{
            domain:"golos",
            account:N(acc1),
            users:["one","two","three"]
        }])
```

### Example 2

Implemented support for the names like `username@@account` ( a presence of the symbols «@@» in the name means that the right side is not a domain, but the account name). For example, if a transaction converts view names `alice@@token`, `bob@@token`, `admin@@golos.io`, then the `declareames` declaration will contain the following arguments:

```
        declarenames([
            {domain:"", account:N(golos.io), users:["admin"]},
            {domain:"", account:N(token), users:["alice","bob"]}
        ])
```

In the above case, the `users` in `declarenames` indicate the usernames used, and in the `account` - the scope where these users are registered. Although, the final accounts into which names are resolved are not specified, an explorer (or some other application) can always identify required account via using the pair `username` +`scope`.

## Long domain names

When an account is created it is assigned a base32-encoded 8-byte identification name, which is a 12.5-character string. 60 bits are allocated for 12 characters. The remaining 4 bits are reserved for an additional symbol from the set {1, 2, 3, 4, a, b, c, d, e, f, g, h, i, j}.

A user can also assign her/his domain name to an account. The length of each part of the domain name should not exceed 63 characters. The number of domain names assigned to an account can be more than one. Since a fee is charged for storing a domain name, the number of domain names is limited and depends on the user funds.

A domain name can be purchased at auction, and can also be created by the lower-level domain owner.

Adding a domain name to an account allows a user to form domain transactions, the transactions with a link to the domain. Such transaction specify smart contract to be called and operations it performs. Domain name is not an identifier and can be transferred from one account to another.


# Govern

## Purpose of the cyber.govern smart contract development

The `cyber.govern` system smart contract contains the logic for selecting active validators and distributing remuneration for block production in accordance with the DPoS provisions.

The actions supported:

* [onblock](/devportal/system_contracts/cyber.govern_contract#onblock)
* [setshift](/devportal/system_contracts/cyber.govern_contract#setshift)

The events supported:

* [burnreward](/devportal/system_contracts/cyber.govern_contract#burnreward)

## Terminology used

**Cycle** - the time spent on one queue in a schedule (if the schedule contains N vaditors, then N blocks per 1 cycle must be produced).

**Round** - the time it takes to complete four cycles (the time for which *4×N* blocks must be produced, where *N* is number of schedule validators).

## onblock

The `onblock` action is a system operation and is not accessible to an external user. It is called by the `cyber.bios` smart contract. The operation contains the logic of block production, including the logic of token issuance and the appointment of validators. This action has the following form:

```
[[eosio::action]] void onblock(name producer);
```

`producer` parameter is a name of validator that succeed producing the next block.

The `cyber.bios` smart contract activates the `onblock` action after each block produced by validators. Calling `onblock` requires authorization of the `cyber.govern` smart contract account.

## setshift

This action allows validators to set a rate of change in their number. When assigning a new list of validators, their number will be changed to value specified in shift if the last change (or `setshift` call) was later than schedule\_resize\_min\_delay (14 days).

```cpp
[[eosio::action]] void setshift(int8_t shift)
```

`shift` parameter sets the rate of change in a number of validators. Valid values ​​limited by contract are (-1, 0, +1).

To perform the action, authorization of a `cyber.prods` account is required.

## burnreward

The `burnreward` event reports on burning an award allocated to a validator. A validator is not rewarded if no one block was produced by him during one round. The highlighted reward to validators is marked on their special account at the beginning of the round. When the validator produces a block, he marks these funds as requested and at the beginning of the next round they are transferred to a validator account. If the validator skips block production, then this award is burned.

```cpp
[[eosio::event]] void burnrevard(
    name      account,
    int64_t   amount
)
```

**Parameters:**

* `account` — validator account whose funds are burned.
* `amount` — amount of funds burned.

## Main regulations concerning the validators

### Validator status

* The status of a validator candidate can be obtained by any user who has signed up, switched to a zero proxy level and has his own stake in the amount of at least 50,000 CYBER as well as a server (node) that meets the requirements specified in [manual](https://cyberway.gitbook.io/en/validators/quick_reference).
* The validators are selected from the candidates by users via voting (read more about [voting process](https://cyberway.gitbook.io/en/validators/voting_for_validators)).
* The validators are divided into two groups according to the voting results — the main validators who received the biggest number of votes and reserved candidates.

### Active validators

* Block production-wise, a schedule of active validators is automatically compiled, which includes all the main validators and one reserve candidate.
* The selection of a reserve candidate for the schedule of active validators takes place according to the following rules. The priority of the candidate is calculated in accordance with the established formula, taking into account the number of votes cast for him and the time interval since his last appearance in the schedule of active validators.
* Active validators produce blocks alternately according to the schedule.
* The schedule of active validators is updated periodically every 4×A blocks, where A is the current number of active validators.
* The number of active validators changes upwards from 21 to 101 inclusive.&#x20;
* The number of active validators increases by one if two conditions are met:
  * at least 14 days have passed since the last increase in the number of active validators;
  * the number of votes cast for the main validators was less than 90 % of the total number of votes cast for all candidates. &#x20;

### Validator rewards

* The validator is rewarded for blocks produced by him in accordance with the provisions of DPoS and taking into account the annual issue of tokens. Funds generated from the annual issue of tokens are distributed in the following fractions:
  * 10 % goes to reward pool for validators for block production;
  * 20 % goes to reward pool for workers;
  * 70 % goes to the stake pool that is distributed between validators and users that voted for them. &#x20;
* Validator rewards are distributed in the following proportions:
  * 10 % from the validators pool goes to a validator, as well as commissions that he/she sets, which are taken from the stake pool; &#x20;
  * the rest of the stake pool is distributed between the proxy and generic accounts that voted for this specific validator. &#x20;

### Requirements and actions applied to a validator

* Validators must produce blocks in accordance with sequence specified in the schedule. If the schedule contains N vaditors, then N blocks must be produced per one cycle.
* Validator is not rewarded if no one block was produced by him during one round. The highlighted reward to validators is marked on their special account at the beginning of a round. When a validator produces block, he marks these funds as requested and at the beginning of the next round they are transferred to the validator account. If the validator skips block production, then this award is burned (this is reported using `burnreward` event).
* If a validator skips 100 rounds (no any block produced during 4×100 cycles) in a row, his key will be reset and a ban on changing the key for one day will be set.
* If 4 series are being skipped by a validator in a row of 100 rounds (no any block produced during 4×4×100 cycles), the validator will be automatically denounced by setting *proxy\_level* to the maximum value and it will be forbidden to return to activity within 7 days.
* If a validator does not demonstrate any activity within 30 days, then any user can suspend the validator using `suspendcand` action.


# Multi-Signature

## Purpose of the cyber.msig smart contract

The `cyber.msig` system smart contract is used to both sign and send multi-signature transactions to the blockchain, as well as to offer the transaction to another user for signing.

The actions supported:

* [propose](/devportal/system_contracts/cyber.multi-signature_contract#propose)
* [approve](/devportal/system_contracts/cyber.multi-signature_contract#approve)
* [unapprove](/devportal/system_contracts/cyber.multi-signature_contract#unapprove)
* [cancel](/devportal/system_contracts/cyber.multi-signature_contract#cancel)
* [schedule](/devportal/system_contracts/cyber.multi-signature_contract#schedule)
* [exec](/devportal/system_contracts/cyber.multi-signature_contract#exec)
* [invalidate](/devportal/system_contracts/cyber.multi-signature_contract#invalidate)

## Terminology used

**Multi-signature transaction** — a transaction for the performance of which it is necessary to obtain permission (signature) from one or more accounts (actors) whose names are indicated in a separate list during its formation. The transaction can include one or more operations. The transaction is sent to the blockchain only after obtaining the number of permissions (signatures) necessary for its execution.

**Multi-signature transaction actor** — the name of the account which you need to obtain permission from to perform a multi-signature transaction. An actor can be an individual user or a company account. Only users entrusted to it specified during its registration in the system with a certain permission level can give permission on behalf of the company.

**Transaction Permission** — the signature of the actor which has the form of a structure containing two fields — the name of the account and the required level of permission.

**Permission level** — significance of the signature (authorization) which is assigned to an account during registration. Authorization has the form of a structure containing fields that uniquely identify the signature belonging to a particular account, taking into account its weight and the key being used for signing.

```cpp
struct authority {
   uint32_t threshold = 0;
   std::vector<key_weight> keys;
   std::vector<permission_level_weight> accounts;
   std::vector<wait_weight> waits;
}
```

Depending on the permission level set in the transaction, the number of signatures required to complete the transaction may vary. For example, permission on behalf of a company representative permission with the required `threshold=3` is considered to be obtained if the signature is affixed either with one account with the same threshold value, or with two accounts with values of «2» and «1», or three with «1».

## Actions

### propose

The `propose` action is used to create a multi-signature transaction offer (proposed transaction), which requires permission from third-party accounts.

```cpp
void multisig::propose(
   name proposer,
   name proposal_name,
   std::vector<permission_level> requested,
   transaction trx,
   binary_extension<std::string> description
)
```

**Parameters:**

* `proposer` — name of account, author of a multi-signature transaction.
* `proposal_name` — the unique name assigned to the multi-signature transaction when it is created. This parameter, in conjunction with the proposer parameter, uniquely identifies a multi-signature transaction.
* `requested` — the unique name assigned to the multi-signature transaction when it is created. This parameter, in conjunction with the proposer parameter, uniquely identifies a multi-signature transaction.
* `trx` — proposed transaction.
* `description` — a field to describe a proposal. &#x20;

For calling the propose action the authorization of proposer user is obligatory.

**For example:**\
The `alice`, `bob`, and `carol` accounts created a common multisig account, for which transactions on behalf of which 2 signatures from 3 are sufficient. To work with this account, `bob` and `alice` decided to use separate keys, adding them to the `msig` permission. Now, to send a transaction to the network, `alice` can offer it for signing, indicating all three participants (with the required permissions) in the requested list:

```cpp
cyber.msig::propose(
   alice,
   sendtofund,
   [alice@msig, bob@msig, carol@active],
   {actions:[{account:token, name:transfer, authorization:[multisig@active], …}], …}
)
```

> **Side note**\
> After the multi-subscription transaction is completed, its name `proposal_name` can be reused for other transactions (by the `proposer` account). However, this `proposal_name` cannot be reused unless permission was not obtained to execute a multi-subscription transaction.

### approve

The `approve` action is used to send permission from an account in the requested list to execute a multi-subscription transaction.

```cpp
void multisig::approve(
   name proposer,
   name proposal_name,
   permission_level level,
   const eosio::binary_extension<eosio::checksum256>& proposal_hash
)
```

**Parameters:**

* `proposer` — name of account, author of a multi-signature transaction..
* `proposal_name` —  The unique name assigned to the multi-signature transaction when it is created. This parameter, in conjunction with the proposer parameter, uniquely identifies a multi-signature transaction.
* `level` — permission by which the account gives its consent to the implementation of the transaction proposed for signing.
* `proposal_hash` — optional parameter, «hash amount» of the multi-signature transaction. The parameter is used to control the occurrence of changes in a multi-signature transaction since the call to propose.  Level permission is not issued in the event of a «hash amounts» mismatch specified by proposal\_hash and obtained for an incoming transaction. &#x20;

Authorization of the account specified in the level parameter is required to call the approve action.

**For example:**\
In order to approve the transaction proposed by `alice`, member accounts must approve with the permission specified in propose and sign the transaction with a signature that satisfies this permission. For greater security, the `proposal_hash` parameter can be used:

```
cyber.msig::approve(alice, sendtofund, alice@msig, hash)
cyber.msig::approve(alice, sendtofund, bob@msig)
cyber.msig::approve(alice, sendtofund, carol@active)
```

### unapprove

The `unapprove` action is used by an account in the requested list to revoke permission previously granted by this account to execute a multi-signature transaction in case of a change in decision.

```cpp
void multisig::unapprove(
   name proposer,
   name proposal_name,
   permission_level level
)
```

**Parameters:**

* `proposer` — name of account, author of a multi-signature transaction.
* `proposal_name` —  the unique name assigned to the multi-signature transaction when it is created. This parameter, in conjunction with the proposer parameter, uniquely identifies a multi-signature transaction.
* `level` — revoked permission

To call `unapprove` action, authorization of the account specified in the level parameter is required.

**For example:**\
To withdraw approval, `alice` should unapprove with the permission specified in propose and sign the transaction with a signature that satisfies this permission:

```cpp
cyber.msig::unapprove(alice, sendtofund, alice@msig)
```

### cancel

The `cancel` action is used to cancel a multi-signature transaction offer.

```cpp
void multisig::cancel(
   name proposer,
   name proposal_name,
   name canceler
)
```

**Parameters:**

* `proposer` — name of account, author of a multi-signature transaction.
* `proposal_name` —  the unique name assigned to the multi-signature transaction when it is created. This parameter, in conjunction with the proposer parameter, uniquely identifies a multi-signature transaction.
* `canceler` — the name of the account that cancels its execution. &#x20;

A certain amount of time is allotted for a multi-signature transaction. If after this time the transaction does not complete, it can be canceled by any user. Only author is authorized to cancel a multi-subscription transaction before the time allotted for its execution expires, for example, after making an adjustment to it. In this case, the canceler parameter will match the proposer parameter.

To call the cancel operation, the authorization of the account specified in the canceler parameter is required.

**For example:**\
At the moment, the transaction has 2 necessary signatures, but `alice` has made a decision not to send it to the network (see examples above). She can cancel the transaction as the creator of the proposed transaction:

```cpp
cyber.msig::cancel(alice, sendtofund, alice)
```

Any user can cancel an expired transaction, thereby restoring STORAGE himself:

```cpp
cyber.msig::cancel(alice, sendtofund, anybody)
```

### schedule

The `schedule` action is intended to record a fact of reaching a consensus. The transaction will need to be executed using `exec` after a delay. Proposal signers can withdraw their signature while waiting. In this case, proposed transaction can not be executed if it does not have enough permissions to perform all operations.

```cpp
void multisig::schedule(
   name proposer,
   name proposal_name,
   name actor
)
```

**Parameters:**

* `proposer` — account, author of a multi-signature transaction.
* `proposal_name` — unique name assigned to multi-signature transaction when it is created.
* `actor` — account whose signature is required to execute multi-signature transaction.

This action allows users to cancel a proposal previously scheduled for execution, that is, users can manage the proposal during a delay period after reaching a consensus.

### exec

The `exec` action is called to execute a multi-signature transaction.

```cpp
void multisig::exec(
   name proposer,
   name proposal_name,
   name executer
)
```

**Parameters:**

* `proposer` — name of account, author of a multi-signature transaction.
* `proposal_name` —  the unique name assigned to the multi-signature transaction when it is created. This parameter, in conjunction with the proposer parameter, uniquely identifies a multi-signature transaction.
* `executer` — the name of the account performing the multi-signature transaction. An executor account can be either an actor or any other user who provides payment for the resources used. A transaction is executed if it contains the required number of permissions. &#x20;

To invoke the `exec` action, authorization of the account specified in the executer parameter is required.

**For example:**\
If the transaction was not canceled in the previous example, then it has the required 2 of 3 permissions, and can be executed by calling the `exec`:

```cpp
cyber.msig::exec(alice, sendtofund, bob)
```

### invalidate

The `invalidate` action is used to revoke all permissions previously issued by the account for performing multi-signature transactions. The action applies to all proposed transactions that are at the voting stage.

```cpp
void multisig::invalidate(name account)
```

**Parameter:**

* `account` — the name of the account whose previously issued permissions to perform multi-signature transactions must be invalidated. &#x20;

Calling invalidate action will invalidate all permissions issued by an account named account for ongoing multi-signature transactions. Invalidate does not apply to permissions of already completed transactions, as well as to permissions that will be issued by this account after calling invalidate.

The proposed transaction can still be sent to the network if it contains the necessary number of remaining permissions, taking into account the canceled one.

To invoke an invalidate action, authorization of an account named account is required.

**For example:**\
`carol` learned that her key was stolen. It's time to cancel all proposed transactions (and change the key):

```cpp
cyber.msig::invalidate(carol)
```


# Stake

The `cyber.stake` system smart contract provides voting methods for validators, which allow users to use their votes, as well as resources on balance sheets, most effectively. `Cyber.stake` also provides the user with the ability to authorize another user to vote.

## Terminology used

**Agent** — is a potentially active user who has a balance in the `cyber.stake` smart contract.

**Votes for a validator** — a certain number of staked tokens given to the validator as votes during a voting (one token equals to one vote).

**Delegator** — a user who delegates part of his stake (RAM, CPU, NET, Storage resources) or an authorization to vote to another user during the voting process.

**Proxy account** — a user empowered with a specific voting authorization during the voting process. Any user can declare himself a proxy account in order to receive votes from other users and use these votes at his own discretion during the voting for validators. In that case the user must set the proxy account level by calling `setproxylvl`.

A user who does not participate in the voting for validators regardless of reason, can authorize the proxy account to vote instead of him. A proxy account can also empower another proxy account in order to vote on his behalf.

**Proxy account level** — a conditional division of users into categories. Each user category is assigned a specific proxy account level. The highest level of proxy account is zero, which is assigned only to validators. The first and further levels in ascending order are assigned to users who have declared themselves proxy accounts. The number of proxy accounts of the same level is also not limited. The last level of proxy account is assigned to the ordinary user. A proxy account can only be configured at only one of the following levels (**please note: in the current release, the number of proxy account levels is limited to three**):

* A validator is considered as a zero-level proxy account.
* First level proxy account — a user who has declared himself a proxy account, empowered with the votes of ordinary users at his disposal during the voting process.
* The second level proxy account is an ordinary user. The ordinary user does not have to worry about what level of proxy he/she needs to set. The user is automatically assigned to the lowest-rated proxy level. &#x20;

The proxy accounts’ separation by levels was introduced in order to avoid the isolation when transferring the voting right from one user to another (for example, user A can transfer his vote to user B, and user B can transmit the vote received to user C. If the latter transfers the received votes back to user A, it will lead to the abruption of transmissions. The concept of proxy account levels was introduced to exclude the appearance of isolation during the transfer of votes. Transfer of voting rights is open only to a lower level proxy account.

**Stake** — a share of bandwidth resources (RAM, NET, CPU, and Storage) allocated to a user. The user can manage the share of resources allocated to him both independently and entrust its use to another user (delegate the share of resources).

**Staked tokens** — the tokens allocated for a stake acquisition that can’t be used for anything else in this state. The user can stake active tokens listed on his/her balance or deposit them. Also, the user can perform the reverse operation — withdraw tokens from the staked state to active.

## cyber.stake smart contract actions

The actions supported:

* [create](/devportal/system_contracts/cyber.stake_contract#create)
* [enable](/devportal/system_contracts/cyber.stake_contract#enable)
* [open](/devportal/system_contracts/cyber.stake_contract#open)
* [delegatevote](/devportal/system_contracts/cyber.stake_contract#delegatevote)
* [setgrntterms](/devportal/system_contracts/cyber.stake_contract#setgrntterms)
* [recallvote](/devportal/system_contracts/cyber.stake_contract#recallvote)
* [withdraw](/devportal/system_contracts/cyber.stake_contract#withdraw)
* [setproxylvl](/devportal/system_contracts/cyber.stake_contract#setproxylvl)
* [setproxyfee](/devportal/system_contracts/cyber.stake_contract#setproxyfee)
* [setminstaked](/devportal/system_contracts/cyber.stake_contract#setminstaked)
* [setkey](/devportal/system_contracts/cyber.stake_contract#setkey)
* [updatefunds](/devportal/system_contracts/cyber.stake_contract#updatefunds)
* [reward](/devportal/system_contracts/cyber.stake_contract#reward)
* [pick](/devportal/system_contracts/cyber.stake_contract#pick)
* [delegateuse](/devportal/system_contracts/cyber.stake_contract#delegateuse)
* [recalluse](/devportal/system_contracts/cyber.stake_contract#recalluse)
* [claim](/devportal/system_contracts/cyber.stake_contract#claim)
* [suspendcand](/devportal/system_contracts/cyber.stake_contract#suspendcand)
* [setautorcmode](/devportal/system_contracts/cyber.stake_contract#setautorcmode)
* [setautorc](/devportal/system_contracts/cyber.stake_contract#setautorc)
* [setinfo](/devportal/system_contracts/cyber.stake_contract#setinfo)

The inline functions supported:

* [get\_votes\_sum](/devportal/system_contracts/cyber.stake_contract#get_votes_sum)
* [get\_top](/devportal/system_contracts/cyber.stake_contract#get_top)

## create

The create action is used to create a stake for a separate type (symbol) of tokens. After creating the stake, tokens of this type can be transferred by users to the state of the stake.

```cpp
void create(
   symbol token_symbol,
   std::vector<uint8_t> max_proxies,
   int64_t depriving_window,
   int64_t min_own_staked_for_election
)
```

**Parameters:**

* `token_symbol` — symbol of the token for which the stake is being created.
* `max_proxies` — maximum allowed proxy account values. The zero element of the vector sets the maximum number of users who can be trusted in the voting if the proxy account level is the first. The first element of the vector sets the maximum number of parts into which the stake can be divided if the level of the proxy account is second. If there are fourth or more levels in the proxy system, the vector will contain three or more elements.
* `depriving_window` — the length of the period (in seconds) during which funds withdrawn back to the delegate cannot be used by him. Funds can be recalled by `recallvote` operation call. Withdrawn funds during this period cannot be taken into account when calculating the share of resources.
* `min_own_staked_for_election` — the minimum number of tokens staked which the user must have in his/her repository to be a candidate for validators. &#x20;

Generic users can vote for one validator either transfer the authorization for voting to only one proxy account.

A proxy account can simultaneously vote for several validators. The maximum number of validators for which the proxy account can vote is 30.

Calling create requires the rights of the creator of the `token_symbol` token. The token creator, by calling create, allows other users to translate tokens of this type into the state of the stake. When creating a stake for a system token, you must have system rights.

## enable

The `enable` action allows to deduce a certain type of token from use for a while. This action sets the enable flag to true.

```cpp
void enable(symbol token_symbol)
```

The `token_symbol` parameter is the symbol of the token affected by the enable flag set to true.

This action is used in testing to disable the use of tokens of a certain symbol. During testing, the enable flag is set to false, that is, the resource limit for a certain type of token is disabled. At the end of testing, the flag should be set back to true. If `token_symbol` is a system one, then when the enable flag is set on the node, the restriction on the use of resources by stake is enabled.

The rights of the `token_symbol` token creator are required to call this action.

## open

The `open` action is used to create a balance for a user.

```cpp
void open(
   name owner,
   symbol_code token_code,
   std::optional<name> ram_payer = std::nullopt
)
```

**Parameters:**

* `owner` — username for which balance is being created.
* `token_code` — symbol of the token that will be listed on the balance.
* `ram_payer` — name of the account paying for opening the balance. If the parameter accepts the default value `std::nullopt`, then the owner himself pays for opening the balance. &#x20;

A transaction, containing the `open` action should be signed by the user who pays for opening a balance. Owner rights are being requested by default.

## delegatevote

The `delegatevote` action is used to delegate to another account the right to dispose of staked tokens (in whole or in part) when voting for validators.

```cpp
void delegatevote(
   name grantor_name,
   name recipient_name,
   asset quantity
)
```

**Parameters:**

* `grantor_name` — an account who delegates the right to dispose of a steak. This is either an ordinary user or a proxy account whose proxy level higher than that of a recipient.
* `recipient_name` — name of the proxy account that is trusted with the voting right.
* `quantity` — number of staked tokens that the proxy `recipient_name` can use when voting. The parameter must be greater than zero. &#x20;

If a user for some reason can not vote for validators, he/she can use the services of a proxy account. In this case this user has to delegate to this proxy a certain number of staked tokens. These tokens (stake) can be used only when voting for validators.

Depending on the settings of the stake, the right to vote on the use of stake tokens can be transferred further (by calling `delegatevote`) to the ёrecipient\_nameё recipient, whose `proxy_level` proxy level is lower than that of the sender `grantor_name`.

> **Note:** Since in the current release the number of levels of proxy accounts is limited to three (zero is a validator, the first is directly a proxy account, the second is an ordinary user), voice transfer from one proxy account to another is not possible. Having received a vote from an ordinary user, a proxy account can use it only when voting for validators.

The stake is divided into several parts. The number of shares depends on the settings of the stake during the create action and is limited by the value of max\_proxies. this value is equal to one for an ordinary user. Therefore the user can vote for one validator only.

A transaction, containing the `delegatevote` action should be signed by the `grantor_name` account.

## recallvote

The `recallvote` action is used to withdraw the right to use a delegated stake when voting for validators. The steak value is set as a percentage and can be withdrawn either partially or completely.

```cpp
void recallvote(
   name grantor_name,
   name recipient_name,
   symbol_code token_code,
   int16_t pct
)
```

**Parameters:**

* `grantor_name` — name of the account that withdraws the right to use the stake.
* `recipient_name` — name of the account from which the right to use the stake is withdrawn.
* `token_code` — staked token symbol.
* `pct` — share of stake (in percent), the right to use of which is revoked. &#x20;

The recalled share of the stake can be used by the `grantor_name` account immediately after the `recallvote` operation is completed.

A transaction, containing the `recallvote` action should be signed by the `grantor_name` account.

## setgrntterms

The `setgrntterms` action is used to distribute additionally allocated staked tokens between validators when voting. These tokens are distributed in accordance with the specified proportions..

```cpp
void setgrntterms(
   name grantor_name,
   name recipient_name,
   symbol_code token_code,
   int16_t pct,
   int16_t break_fee,
   int64_t break_min_own_staked
)
```

**Parameters:**

* `grantor_name` — name of the account that delegates the extra share of stake.
* `recipient_name` — name of the proxy account, recipient of the extra share of staked tokens.
* `token_code` — staked token symbol.
* `pct` — share (in percent) of additional votes received, which will be given for the `recipient_name` candidate.
* `break_fee` — the parameter that controls the change in the fee set by the candidate. The value of this parameter is the percentage of commission charged by the `grantor_name` account for the `recipient_name` candidate. If the candidate during the voting process sets the value of fee greater than `break_fee`, the recall operation will be automatically called to recall the votes of this candidate.
* `break_min_own_staked` — the parameter that controls the availability of secured tokens in the `recipient_name` candidate. The value of this parameter is set by the `grantor_name` account. By default, this change is set to the current `min_own_staked` value. If the candidate reduces `min_own_staked` (in order to withdraw funds to a liquid state), the next time the balance of the `grantor_name` account is updated, the recall operation will be automatically called to revoke the allocated tokens from this candidate. &#x20;

When recalling, the condition is checked so that the candidate has funds in the amount of at least `min_own_staked`.

A proxy account can vote simultaneously for several candidates for validators, distributing votes between them in a certain proportion. The proxy account can receive an additional number of votes (staked tokens) and use them until the end of voting process. These additional votes will automatically be given to those candidates for whom the proxy account voted before receiving these votes. Additional votes will be distributed among the candidates taking into account previous proportion .

## withdraw

The `withdraw` action is used to withdraw staked tokens and make them liquid.

```cpp
void withdraw(
   name account,
   asset quantity
)
```

**Parameters:**

* `account` — name of the account withdrawing staked tokens.
* `quantity` — number of tokens withdrawn. This value shpild be positive. &#x20;

When the `withdraw` action is calling, the `cyber.stake` smart contract sends a notification to token creator, which makes the final decision on the withdrawal of tokens. The withdrawal of tokens is performed immediately without any delay.

In case of withdrawal the system tokens, decision to withdraw these tokens is made by the `cyber.bios` smart contract. The operation is performed if the remainder of the user’s stake covers the costs of the resources used by him taking into account the funds being withdrawn.

A transaction, containing the `withdraw` action should be signed by the `account`.

## setproxylvl

The `setproxylvl` action sets the proxy account level for a user.

```cpp
void setproxylvl(
   name account,
   symbol_code token_code,
   uint8_t level
)
```

**Parameters:**

* `account` — name of the account for which a proxy account level is set.
* `token_code` — number of staked tokens available to the user.
* `level` — level being set. &#x20;

If a user intends to be a candidate for validators, he/she should set the proxy level to zero. If a user intends to register as a proxy account, he/she should set the proxy level to one (in the current release).

A transaction, containing the `setproxylvl` action should be signed by the `account`.

## setproxyfee

The `setproxyfee` action sets a size of the commission for an agent (a candidate for validators) that users voted for.

```cpp
void setproxyfee(
   name account,
   symbol_code token_code,
   int16_t fee
)
```

**Parameters:**

* `account` — name of the agent that users have voted for.
* `token_code` — symbol of tokens constituting a reward to the agent.
* `fee` — amount of commission deductions to be taken from the amount of reward that the agent receives. This parameter is calculated at the time of reward payment. The parameter takes values from «0» to «10000» inclusive («0» corresponds to «0 %», «10000» corresponds to «100 %»). &#x20;

A fee is deducted from the received reward amount allocated to the agent and transferred to the agent account. The rest of the reward is distributed among all users who voted for this agent.

## setminstaked

The `setminstaked` action sets the minimum possible size of a steak allocated for voting by an agent (a candidate for validators).

```cpp
void setminstaked(
   name account,
   symbol_code token_code,
   int64_t min_own_staked
)
```

**Parameters:**

* `account` — name of the agent.
* `token_code` — symbol of staked tokens.
* `min_own_staked` — minimum possible steak, which is allocated for voting by the agent himself. This value should be positive. &#x20;

If the candidate for validators sets the value `min_own_staked` less than `min_own_staked_for_election` one during a voting, then the votes cast for him are automatically canceled.

## setkey

The `setkey` action sets the public key for a validator, which will be used for signing blocks.

```cpp
void setkey(
   name account,
   symbol_code token_code,
   public_key signing_key
)
```

**Parameters:**

* `account` — name of the validator to which the public key is being set.
* `token_code` — symbol of staked tokens.
* `signing_key` — the public key (i.e. validator signature).

## updatefunds

The `updatefunds` action is used to update a user’s stake.

```cpp
void updatefunds(
   name account,
   symbol_code token_code
)
```

**Parameters:**

* `account` — name of the account for which the steak size is being updated.
* `token_code` — symbol of staked tokens. &#x20;

The size of one user's stake may vary. The `updatefunds` action sets the actual value for a user’s stake. This operation simplifies the procedure for calculating user rewards, including share determination for a user. The `updatefunds` action can also be used during other actions, such as revoking tokens or voting. That is, when performing active operations that require updating a stake.

The `updatefunds` action can be called by any user. Authorization is not required.

## reward

The `reward` action is used to pay rewards to users by crediting the corresponding amounts to their balances.

```cpp
void reward(
   std::vector<std::pair<name, int64_t> > rewards,
   symbol sym
)
```

**Parameters:**

* `rewards` — a vector containing account names and the payouts associated to them.
* `sym` — symbol of tokens in which the reward is being paid. &#x20;

A transaction, containing the `reward` action should be signed by the `sym` token creator.

## pick

The `pick` action updates the entire list of validators, including candidates for validators, and notifies the `cyber.stake` contract about changes in the list, as well as about appearance of a new validator selected from the candidates at a certain time.

```cpp
void pick(
   symbol_code token_code,
   std::vector<name> accounts
)
```

**Parameters:**

* `token_code` — number of tokens held by a candidate, notification of which is sent.
* `accounts` — vector of accounts that are current validators, as well as candidates for validators. &#x20;

Selection of validators from the candidates for validators is carried out in the `cyber.govern` smart contract. The first `n-1` validators from the list (`n` is total number of validators) are selected in accordance with the number of votes cast for them, taking into account the weight of each vote. The last validator from this list is pseudo-random. This validator is selected according to a formula that takes into account the time elapsed since the last validator selection and the number of votes cast for this candidate.

Those candidates who did not become validators, but are listed next to the first `n-1` validators, get the opportunity to appear among these validators after a certain time. Candidate priorities are calculated using `get_top` method in the `cyber.govern` smart contract. This method determines the selected candidates who received the most votes and the reserve candidates. The method takes into account the length of stay in the status of a candidate (since when did the candidate remain among the non-elected). Each of the candidates is located in the list of the priority field in accordance with the priority calculated for it.

The `pick` operation is called by the `cyber.govern` smart contract and updates the priority field, moving all candidates in the queue to positions according to their calculated priority, and notifies `cyber.stake` of changes in the candidate list at the current time.

A transaction, containing the `pick` action should be signed by the `token_code` token creator

## delegateuse

The `delegateuse` action is used to delegate resources (RAM, NET, CPU, Storage) to another user, which can be used at user’s discretion (unlike this operation, `delegatevote` delegates resources that can be used only for voting).

```cpp
void delegateuse(
   name grantor_name,
   name recipient_name,
   asset quantity
)
```

**Parameters:**

* `grantor_name` — name of the account, who is a delegator of a stake.
* `recipient_name` — name of the account, who is a recipient of a stake.
* `quantity` — amount of delegated stake. This parameter should be positive. &#x20;

Stake resources such as RAM, NET, CPU, and Storage cannot be delegated in parts as they appear on the system. Therefore, the delegation of stake funds is carried out in value terms. The cost of resources consumed by the delegator is calculated in accordance with current prices and compared with his steak existing.

The delegated steak is not taken into account when votes for the delegator are calculated, but is taken into account in the calculation of votes for the recipient of these funds.

When the `delegateuse` action is calling, the `cyber.stake` smart contract sends a notification to the token creator, who makes the final decision on the stake delegation.

In case of delegating the system tokens, decision to delegate these tokens is made by the `cyber.bios` smart contract. The operation is performed if the remainder of the delegator’s stake covers the costs of the resources used by him taking into account the funds being delegated.

## recalluse

The `recalluse` action is used to revoke the delegated portion of a stake.

```cpp
void recalluse(
   name grantor_name,
   name recipient_name,
   asset quantity
)
```

**Parameters:**

* `grantor_name` — name of the account revoking the delegated portion of the stake.
* `recipient_name` — name of the account whose delegated portion of the stake is being revoked.
* `quantity` — amount of revoked stake. This parameter should be positive. &#x20;

As soon as the delegated part of the steak is withdrawn from the recipient, it immediately goes into a «frozen» state. The duration of the «frozen» state is determined by the `depriving_window` parameter when the create operation is called. The delegator can use the returned portion of the stake only after this period.

In case, after delegating the funds, only half of these funds are requested back, and then the remaining part is requested, then after the second `recalluse` call, the returned funds can only be used after the `depriving_window` time has passed.

## claim

The claim action is used to obtain permission to use revoked delegated funds.

```cpp
void claim(
   name grantor_name,
   name recipient_name,
   symbol_code token_code
)
```

**Parameters:**

* `grantor_name` — name of the account that revokes the delegated portion of the stake
* `recipient_name` — name of the account whose delegated portion of the stake is being revoked.
* `token_code` — revoked part of the stake. Value should be positive. &#x20;

After the expiration of the «frozen» state, the withdrawn funds may not be used by the delegator immediately, but only after obtaining the appropriate permission. The claim call requests permission from the cyber.stake smart contract to use funds withdrawn from the «frozen» state.

The operation is tied to resource recovery time. Funds are immediately returned in full.

The delegator can again return the withdrawn funds (or part of the funds) back to the recipient\_name account. The funds for redelegation will be debited from the «frozen» funds.

To perform the action, authorization of the funds delegator is required.

## suspendcand

The `suspendcand` action allows a user to set maximum proxy level (lowest) for a validator if this validator has not been active for a long time (30 days).

```cpp
void suspendcand(
   name account,
   symbol_code token_code
)
```

**Parameters:**

* `account` — account of a validator whose activity is checked.
* `token_code` — a symbol of staked tokens of the validator.

Transaction including the action can be signed by any user. However, it will be executed only if specified validator does really not fulfill his obligations.

## setautorcmode

The `setautorcmode` action allows a token issuer (excluding CYBER tokens) to enable/disable automatic reset of votes. This action is paired with `setautorc`. When the mode is on, the votes will not be reset automatically until a voter sets parameters with the action `setautorc`.

```cpp
void setautorcmode(
   symbol_code token_code,
   bool enabled
)
```

**Parameters:**

* `token_code` — a token code of an issuer.
* `enabled` — `true` enables auto recall mode (reset of votes).

Automatic reset of votes for a validator is cancelled if he reduces a percentage of deductions or obligation by minimum number of a stake.

To perform the action, authorization of the token issuer is required.

## setautorc

Using the action `setautorc`, a user indicates conditions under which his vote for validator should be reset. This action is paired with `setautorcmode`.

```cpp
void setautorc(
   name account,
   symbol_code token_code,
   bool break_fee_enabled,
   bool break_min_stake_enabled
)
```

**Parameters:**

* `account` — account of a validator.
* `token_code` — a symbol of staked tokens held by the validator.
* `break_fee_enabled` — `true` controls change in fee set by the validator.
* `break_min_stake_enabled` — `true` controls availability of staked tokens of the validator.

Parameters `break_fee` and `break_min_own_staked` are set using [setgrntterms](/devportal/system_contracts/cyber.stake_contract#setgrntterms). To perform the action, authorization of the validator is required.

## setinfo

The `setinfo` action allows a validator to provide a link to his page and to announce any info about himself on-chain.

```cpp
void setinfo(
   name account,
   symbol_code token_code,
   string url,
   binary_extension<string> info
)
```

**Parameters:**

* `account` — account of the validator.
* `token_code` — symbol of staked tokens.
* `url` — a link to validator's page (the url string is limited to 2048 characters).
* `info` — additional information about the validator (the info string is limited to 2048 characters).

To perform the action, authorization of the validator is required.

## get\_votes\_sum

The `get_votes_sum` inline function returns the total number of votes available to validator candidates who received the most votes by validator candidates who received the most votes.

```cpp
static inline int64_t get_votes_sum(
   symbol_code token_code,
   size_t limit = 0
)
```

**Parameters:**

* `token_code` — symbol of staked tokens by which votes were determined.
* `limit` — the requested number of first candidates from the priority list for which the total number of votes is determined. The first on the list are the candidates who received the most votes. By default, the parameter takes a null value.If `limit` is null, then this action returns total number of votes of all candidates from the `priority` list.

## get\_top

The `get_top` inline function returns a list of the most rated candidates, compiled according to a certain principle.

```cpp
static inline std::vector<elected_t> get_top(
   symbol_code token_code,
   uint16_t elected_num,
   uint16_t reserve_num,
   bool strict = true
)
```

**Parameters:**

* `token_code` — symbol of tokens tokens by which the votes were defined.
* `elected_num` — the requested number of candidates who received the largest number of votes among those elected as validators.
* `reserve_num` — the requested number of reserve candidates who were not included in the list of eligible candidates. The list of reserve candidates includes those candidates who received the most votes among remaining candidates, taking into account the time when each of the candidates did not appear in the list of validators.
* `strict` — `true` ignores the votes of candidates who do not have a public key. Default is `true`. &#x20;

  The `get_top` function returns a list of candidates made up of the requested number of `elected_num` elected to validators and the number of `reserve_num` backups added to it taking into account the strict parameter.


# Tokens

## Purpose of the cyber.token smart contract development

The system smart contract `cyber.token` provides token management functions, generates new tokens and stores information about created tokens and provides an ability to conduct mutual settlements between accounts as well.

The actions supported:

* [create](/devportal/system_contracts/cyber.token_contract#the-create-action)
* [issue](/devportal/system_contracts/cyber.token_contract#the-issue-action)
* [retire](/devportal/system_contracts/cyber.token_contract#the-retire-action)
* [transfer](/devportal/system_contracts/cyber.token_contract#the-transfer-action)
* [bulktransfer](/devportal/system_contracts/cyber.token_contract#the-bulktransfer-action)
* [payment](/devportal/system_contracts/cyber.token_contract#the-payment-action)
* [bulkpayment](/devportal/system_contracts/cyber.token_contract#the-bulkpayment-action)
* [claim](/devportal/system_contracts/cyber.token_contract#the-claim-action)
* [open](/devportal/system_contracts/cyber.token_contract#the-open-action)
* [close](/devportal/system_contracts/cyber.token_contract#the-close-action)&#x20;

## The create action

The `create` action is applied to create a token to supply it into the system. This action has the following form:

```cpp
[[eosio::action]] void create(
    name   issuer,
    asset  maximum_supply
);
```

**Parameters:**

* `issuer` — account name which creates the token to supply it into the system.
* `maximum_supply` — a structure value containing the fields: &#x20;
  * maximum number of tokens supplied; &#x20;
  * token symbol (data type that uniquely identifies the token). This is a structure value containing fields: &#x20;
    * token name, consisting of a set of capital letters;   &#x20;
    * field that specifies a token cost accuracy in the form of decimal places number. &#x20;

The `issuer` account is authorized to supply and withdraw tokens from circulation in the system. The `create` action can be executed by the `token` smart contract only. In order to perform this action, the signature of the validators is required. Use of the `bandwidth` resources (RAM) is charged to the `issuer` account.

## The issue action

The `issue` action is applied to put a token into circulation in the system.\
This action has the following form:

```cpp
[[eosio::action]] void issue(
    name to,  
    asset quantity,  
    string memo
);
```

**Parameters:**

* `to` — recipient account to balance of which the tokens are transferred. &#x20;
* `quantity` — number of the supplied tokens. This is a structure value containing fields:  &#x20;
  * number of the supplied tokens in the system; &#x20;
  * a token symbol. This is a structure value containing fields:
    * the token name, consisting of a set of capital letters;   &#x20;
    * the field that specifies a token cost accuracy in the form of decimal places number. &#x20;
* `memo` — memo text that clarifies a meaning (necessity) of the token emission in the system. The text volume should not exceed 384 symbols including blanks. &#x20;

When the `create` action is performed, the token symbol and the account name `issuer` are put into the table. When executing the `issue` action, the token character is taken from the resulting `quantity` value. The account `issuer` can be determined via using this symbol and table data. The number of supplied tokens should not exceed `maximum_supply` value specified in the `create` action. Use of the `bandwidth` resources (RAM) is charged to the `issuer` account.

To perform the `create` action, the `issuer` account authorization is required.

## The retire action

The `retire` action is used to withdraw a certain number of tokens from the system. This action has the following form:

```cpp
[[eosio::action]] void retire(
    asset quantity,
    string memo
);
```

**Parameters:**

* `quantity` — number of withdrawn tokens.   &#x20;
* `memo` — a memo text clarifying a purpose of withdrawing tokens from circulation. &#x20;

Use of the `bandwidth` resources (RAM) is charged to the `issuer` account. The number of tokens withdrawn from circulation is also removed from `issuer` account balance, so this account can not withdraw tokens more than he/she has them on own balance.

To perform this action, the `issuer` account authorization is required.

## The transfer action

The `transfer` action is used to transfer tokens from one account to another. This action has the following form:

```cpp
[[eosio::action]] void transfer(
    name from,
    name to,
    asset quantity,
    string  memo
);
```

**Parameters:**

* `from` — sender account from balance of which the tokens are withdrawn. &#x20;
* `to` — recipient account to balance of which the tokens are transferred. &#x20;
* `quantity` — number of tokens to be transferred. This value should be greater than zero. &#x20;
* `memo` — a memo text that clarifies a meaning of the token transfer.  &#x20;

The action is performed with sending a notification to smart contracts of the sender and recipient of tokens. Sending the notification is an internal action and looks similar to the `transfer` action . The difference is the «sending a notification» action is not performed on `cyber.token`, but on smart contracts of sender and recipient of the notification (for example, if the vesting smart contract receives a notification, it automatically charges tokens on the `vesting` balance).

To perform the `transfer` action, the `from` account authorization is required.

Use of the `bandwidth` (RAM) resources is charged either to sending account or to receiving account, depending on who signed the transaction. If the `open` action was previously performed, none of them should pay `bandwidth`, since the record already created in database is used.

> **Note:**\
> If sender account pays for used resources (RAM) for a recipient account, then there is the possibility of spending the entire share of memory allocated to the recipient account. To avoid such cases when performing the action `transfer`, additional actions have been implemented in `cyber.token`. These are `open` and `close`. Functional purposes of these actions are the creation and deletion of an entry in the database before and after (not during) performing `transfer` respectively.

## The bulktransfer action

The action `bulktransfer` is used to transfer tokens from one account's balance to the balances of several accounts (for example, for paying rewards for a post). This action has the following form:

```cpp
[[eosio::action]] void bulktransfer(
    name from,
    vector<recipient> recipients
)
```

**Parameters:**

* `from` — sender account from balance of which the tokens are withdrawn. &#x20;
* `recipients` — array (list) of token recipients. Each array element is a structure containing fields: &#x20;
  * `to` — recipient account to balance of which the tokens are transferred;
  * `quantity` — number of tokens to be transferred to account `to`. This value should be greater than zero;&#x20;
  * `memo` — a memo text that clarifies a meaning of the token transfer. The text volume should not exceed 384 symbols including blanks. &#x20;

The restrictions imposed on the `bulktransfer` action:

* transfer of various types tokens is not allowed; &#x20;
* transfer of tokens to itself is not allowed, that is, the list of `recipients` should not contain the account name `from`. &#x20;

It is allowed in the `recipients` list to specify the same account name `to` more than once. The action is performed with sending a notification to smart contracts of the sender and recipient of tokens in the same way as `transfer`.

To perform `bulktransfer`, it is required a signature of the account `from`.

## The payment action

The `payment` action like the `transfer` action is used to transfer funds from one account to another. This action has the following form:

```cpp
[[eosio::action]] void payment(
    name  from,
    name  to,
    const asset& quantity,
    const string& memo
)
```

**Parameters:**

* `from` — sender account from balance of which the tokens are withdrawn. &#x20;
* `to` — account name which is a recipient token. &#x20;
* `quantity` — number of tokens to be transferred to account name `to`. This value should be greater than zero. &#x20;
* `memo` — a memo text that clarifies a meaning of the token transfer. The text volume should not exceed 384 symbols including blanks.

Unlike `transfer`, when performing `payment` action, notifications are not sent and funds are transferred not to the recipient account balance , but to the payment-intermediary balance. To withdraw funds from the `payment` balance, the recipient account `to` should additionally perform the action `claim`.

The action `payment` is a more secure option to transfer tokens. To perform `payment`, it is required a signature of the account `from`.

## The bulkpayment action

The action `bulktransfer` is used to transfer tokens from one account's balance to several accounts (for example, for paying rewards to curators and beneficiaries for a post). The `bulkpayment` action has the following form:

```cpp
[[eosio::action]] void bulkpayment(
    name from,
    vector<recipient> recipients
)
```

**Parameters:**

* `from` — sender account from balance of which the tokens are withdrawn. &#x20;
* `recipients` — array (list) of token recipients. Each array element is a structure containing fields: &#x20;
  * `to` — account name which is a recipient token;
  * `quantity` — number of tokens to be transferred to account name `to`. This value should be greater than zero;&#x20;
  * `memo` — a memo text that clarifies a meaning of the token transfer. The text volume should not exceed 384 symbols including blanks. &#x20;

The restrictions imposed on the `bulkpayment` action:

* transfer of various types tokens is not allowed;
* transfer of tokens to itself is not allowed, that is, the list of `recipients` should not contain the account name `from`. &#x20;

  Unlike `bulktransfer`, when performing `bulkpayment` action, notifications are not sent and funds are transferred not to the recipient accounts balances , but to the payment (intermediary) balance. To withdraw funds from the `payment` balance, each of the recipient accounts should additionally perform the action `claim`. &#x20;

The action `bulkpayment` is a more secure option to transfer tokens. To perform `bulkpayment`, it is required a signature of the account `from`.

## The claim action

The `claim` action is used to transfer funds from the `payment` balance to an account balance. This action has the following form:

```cpp
[[eosio::action]] void claim(
    name owner,
    asset quantity
)
```

**Parameters:**

* `owner` — account name to whose balance the funds are transferred. &#x20;
* `quantity` — requested number of tokens to be transfered. This number must not exceed the number of tokens that are on the `payment` balance and which are owned by the `owner` account. &#x20;

Performing the `claim` action requires a signature of the `owner` account.

## The open action

The `open` action is used to create a record in database. This entry must contain an account name which should pay for the memory used, as well as a symbol for which this entry is created. The `open` action has the following form:

```cpp
[[eosio::action]] void open(
    name owner,
    symbol symbol,
    name ram_payer
);
```

**Parameters:**

* `owner` — account name to which the memory is allocated. &#x20;
* `symbol` — symbol for which the entry is being created. &#x20;
* `ram_payer` — account name that pays for the used memory. &#x20;

Performing the `open` action requires a signature of the `ram_payer` account.

## The close action

The `close` action is an opposite of `open` and is used to free allocated memory in database. The `close` action has the following form:

```cpp
[[eosio::action]] void close(
    name owner,
    symbol symbol
);
```

**Parameters:**

* `owner` — account name to which the memory was allocated. &#x20;
* `symbol` — a symbol for which the entry is deleted. &#x20;

To perform this action, it is necessary to have two zero balances of the account `owner`:

* zero token balance (determined by the symbol);
* zero payment balance.

### Obtaining statistical information about system tokens

To obtain statistical information on tokens, two tables, `currency_stats` and `account`, are used in the `cyber.token` smart contract.

The `currency_stats` table has the following form:

```cpp
struct [[eosio::table]] currency_stats {
    asset supply;
    asset max_supply;
    name issuer;
};
```

**Parameters:**

* `supply` — number of a certain type tokens that have been supplied in the system. &#x20;
* `max_supply` — maximum possible number of this type tokens in circulation. &#x20;
* `issuer` — account name which has supplied this type tokens in the system. &#x20;

Primary key for table `currency_stats` is a character value in the `asset`. This value is used to determine the token. having information about a token it is easily to obtain its `supply` value — the number of tokens released into circulation, as well as the account name `issuer`.

The `account` table has the following form:

```cpp
struct [[eosio::table]] account {
    asset balance;
    asset payments;
};
```

A scope of the table is determined by the account name.


# Application Contracts

**Golos Contracts:**

* [Charge](https://github.com/cyberway/cyberway.documentation/tree/010af7feb0acef4a36322dd8e23754335e2c6290/devportal/application_contracts/golos.charge_contract.md)
* [Control](/devportal/application_contracts/golos_contracts/golos.ctrl_contract)
* [Emission](/devportal/application_contracts/golos_contracts/golos.emit_contract)
* [Publication](/devportal/application_contracts/golos_contracts/golos.publication_contract)
* [Referral program](/devportal/application_contracts/golos_contracts/golos.referral_contract)
* [Social](/devportal/application_contracts/golos_contracts/golos.social_contract)
* [Vesting](/devportal/application_contracts/golos_contracts/golos.vesting_contract)
* [Memo-keys](https://github.com/cyberway/cyberway.documentation/tree/010af7feb0acef4a36322dd8e23754335e2c6290/devportal/application_contracts/golos_contracts/golos.memo_contract.md)
* [The Determining Rewards for a Post](/devportal/application_contracts/golos_contracts/rewards_definition)


# Golos Contracts

* [Charge](/devportal/application_contracts/golos_contracts/golos.charge_contract)
* [Control](/devportal/application_contracts/golos_contracts/golos.ctrl_contract)
* [Emission](/devportal/application_contracts/golos_contracts/golos.emit_contract)
* [Publication](/devportal/application_contracts/golos_contracts/golos.publication_contract)
* [Referral program](/devportal/application_contracts/golos_contracts/golos.referral_contract)
* [Social](/devportal/application_contracts/golos_contracts/golos.social_contract)
* [Vesting](/devportal/application_contracts/golos_contracts/golos.vesting_contract)
* [Memo-keys](https://github.com/cyberway/cyberway.documentation/tree/010af7feb0acef4a36322dd8e23754335e2c6290/devportal/application_contracts/golos_contracts/golos.memo_contract.md)
* [The Determining Rewards for a Post](/devportal/application_contracts/golos_contracts/rewards_definition)


# Charge

## The purpose of golos.charge smart contract

The `golos.charge` smart contract performs an applied function — it allows to limit user activity in creating posts, comments, and also in voting for posts. There is no direct user interaction with the `golos.charge` smart contact, recourse to actions occurs through `golos.publication` smart contract.

## The operating principle of golos.charge smart contract

The mechanism regulating user activity in the system is implemented on the basis of batteries. The battery-based solution provides ability to keep track of both individual user operations and user's overall activity. The number of batteries allocated to a user can be one or more, each of which can be configured to account for one of the operations performed by this user for a certain time interval (for example, comments are recorded by one battery, sending votes in the form of «upvote» is another). When operation is executed, a part of the associated battery resource (charge) is consumed, taking into account the cost of this operation. Then this resource is restored in whole or in part. Amount of the restored resource is calculated according to the formula specified in the battery settings. Operation wil be blocked if the updated value of the spent resource exceeds the boundary value.

For each user operation being performed, a portion of the battery resource is consumed, taking into account the cost of this operation. When the battery reaches the limit value, the operation is blocked. Battery charge is fully restored after a time. The battery charge is fully restored after a time in accordance with selected algorithm, which is specified in the `setrestorer` operation.

Access to batteries is possible through call of special actions. The `golos.charge` smart contract implements the inline functions [get\_stored](/devportal/application_contracts/golos_contracts/golos.charge_contract#get_stored) and [get\_current\_value](/devportal/application_contracts/golos_contracts/golos.charge_contract#get_current_value) as well as the actions [use](/devportal/application_contracts/golos_contracts/golos.charge_contract#use), [useandstore](/devportal/application_contracts/golos_contracts/golos.charge_contract#useandstore), [removestored](/devportal/application_contracts/golos_contracts/golos.charge_contract#removestored), [setrestorer](/devportal/application_contracts/golos_contracts/golos.charge_contract#setrestorer), [usenotifygt](/devportal/application_contracts/golos_contracts/golos.charge_contract#usenotifygt-and-usenotifylt) and [usenotifylt](/devportal/application_contracts/golos_contracts/golos.charge_contract#usenotifygt-and-usenotifylt).

One of the required parameters used in these actions is `token_code`, which identifies a specific token. The account that calls any of these actions must have the token creater rights in accordance with the authorization requirements.

Each battery is identified by the token code (`token_code`) and the battery identifier directly (`charge_id`).

Each type of token can be linked to more than one battery. The specific battery of a specific token is set by the `charge_id` parameter. A battery is a value that increases with the rise of it’s use and decreases with it’s expiry, i.e restoration.

## use

The `use` action is used to control the battery charge (resources) when the user performs any kind of actions.\
The action `use` has the form:

```cpp
[[eosio::action]] void use(
    name user,
    symbol_code token_code,
    uint8_t charge_id,
    int64_t price,
    int64_t cutoff,
    int64_t vesting_price
);
```

**Parameters:**

* `user` — account name, used battery resource. &#x20;
* `token_code` — the code of the token linked to the battery. &#x20;
* `charge_id` — battery ID. This value, in conjunction with the `token_code` value, provides battery identification. &#x20;
* `price` — amount of battery charge that the `user` consumes when the action is performed. &#x20;
* `cutoff` — the threshold value of the battery charge, upon which the action is terminated. &#x20;
* `vesting_price` — the amount of funds (in vesting) that the `user` must pay  in case of insufficient battery charge to complete an operation. That is, if the battery charge exceeds the `cutoff` threshold before the operation completes. *(**Note:** this parameter is currently not used and should be equal to `0`)*.   &#x20;

Any of the smart contracts can turn to the battery, but not directly, but through an action call. In case the battery charge does not meet the `cutoff` value conditions, the smart battery contract issues a corresponding message with a lock on the execution of the transaction, including the action that caused the access to the battery.

In order for the user to be able to pay for the missing battery charge (to complete the operation), it is necessary to provide the following:

* `golos.charge` must have access to user’s staked vesting; &#x20;
* `golos.charge` must have authority to «burn» the appropriate amount of the vesting; &#x20;
* on user's balance must be the required amount of vesting in unlocked state. &#x20;

  *(**Note:**  this functionality is currently blocked)*

## useandstore

*(**Note:** this action is currently disabled and has no effect)*\
The `useandstore` action as well as `use` is used to account for battery charge when the user performs any actions. Unlike `use`, the `useandstore` action saves the values of the battery resources used in the tables inside the `golos.charge` smart contract and remains readable by other smart contracts.

The `useandstore` action has the following form:

```cpp
[[eosio::action]] void useandstore(
    name user,
    symbol_code token_code,
    uint8_t charge_id,
    int64_t stamp_id,
    int64_t price
);
```

**Parameters:**

* `user` — account name, used battery resource. &#x20;
* `token_code` — the code of the token linked to the battery. &#x20;
* `charge_id` — battery ID. This value, in conjunction with the `token_code`, provides battery identification. &#x20;
* `stamp_id` — identifier of the stored value of the battery `charge_id` used by the `user` account. The value is stored in the table of this battery reserved for the `user` account. &#x20;
* `price` — the amount of funds (in conventional units of the battery), accrued to the `user` account for the used part of the battery resource.

## removestored

*(**Note:** this action is currently disabled and has no effect)*\
The `removestored` action is used to delete previously saved data on the use of battery resources in `golos.charge`. The key to finding deleted data is the set of values for the `charge_id`, `token_code`, and `stamp_id` parameters. The `removestored` action can be called from any smart contract.

The action `removestored` is:

```cpp
[[eosio::action]] void removestored(
    name user,
    symbol_code token_code,
    uint8_t charge_id,
    int64_t stamp_id
);
```

**Parameters:**

* `user` — account name, used battery resource. &#x20;
* `token_code` — the code of the token linked to the battery. &#x20;
* `charge_id` — battery ID. This value, in conjunction with the `token_code` value, provides battery identification. &#x20;
* `stamp_id` — the identifier of the value of the `charge_id` battery resource used by the `user` account, which is removed from the table of this battery. &#x20;

## setrestorer

The `setrestorer` action is used to set the function by which the battery charge is restored.\
The `setrestorer` action operation has the form:

```cpp
[[eosio::action]] void setrestorer(
    symbol_code token_code,
    uint8_t charge_id,
    std::string func_str, 
    int64_t max_prev,
    int64_t max_vesting,
    int64_t max_elapsed
);
```

**Parameters:**

* `token_code` — token code, which is linked to the battery. &#x20;
* `charge_id` — battery ID. This value, in conjunction with the `token_code` value, provides battery identification. &#x20;
* `func_str` — a mathematical expression that defines the function of battery charge restoration. &#x20;
* `max_prev` — the maximum value of the previous battery charge. This value is taken into account when restoring the charge. &#x20;
* `max_vesting` — the maximum value of the vesting, which can be used by the function as an argument in the process of restoring battery charge. &#x20;
* `max_elapsed` — the maximum period of time since the last call to the battery. &#x20;

The `func_str` value parameter is calculated by a defined function with three variables, namely:

* `p` — sets the previous value of the battery charge. &#x20;
* `v` — sets the value of the user's visitor. *(**Note:** this parametr is currently not used and should not be specified in the function).*&#x20;
* `t` — sets the time period since the last setrestorer call. &#x20;

For example, if a string is passed as the `func_str` parameter\
`sqrt(v / 500000) × (t / 150)` ,\
then the battery, identified by `token_code` and `charge_id` parameters, will be restored according to this function. If the user has an amount of funds equal to 500,000 (in vesting) during the period of 150 sec, the value of `func_str` will be the following:\
`func_str = sqrt(500000 / 500000) × (150 / 150) = 1`\
That means during 150 sec time the value of the battery will increase by one.

## usenotifygt and usenotifylt

These actions are internal and unavailable to a user.

The `usenotifygt` name means «use battery resources and notify `publication` smart contract if battery consumption is greater than specified threshold value».\
The `usenotifylt` name means «use battery resources and notify `publication` smart contract if the battery charge is less than specified threshold value».

Both operations are used to monitor users activity and notify the smart contract passed as a parameter (for example, `golos.publication`) about exceeding the permissible level of activity of these users. The `usenotifygt` action differs from `usenotifylt` by specified condition under which notification is sent.

The `usenotifygt` action has the form:

```cpp
void usenotifygt(
    name user,
    symbol_code token_code,
    uint8_t charge_id,
    int64_t price_arg,
    int64_t id,
    name code,
    name action_name,
    int64_t cutoff
)
```

**Parameters:**

* `user` — battery owner account name. &#x20;
* `token_code` — code of the token that is bound to the `charge_id` battery. &#x20;
* `charge_id` — battery identifier. This value, together with `token_code`, uniquely identify a battery. &#x20;
* `price_arg` — amount of battery charge that the `user` consumes when the action is performed. &#x20;
* `id` — internal identifier of the contract `code`. This parameter is in notification along with the user name and the new battery value. &#x20;
* `code` — contract code to which a notification is sent about the spent resources . &#x20;
* `action_name` — action that issues the notification in the contract `code`. &#x20;
* `cutoff` — threshold value of battery charge, upon reaching which a notification is sent about user's over-activity. &#x20;

The action `usenotifylt` has a similar structure and parameters.

A user can publish several posts for a certain period and at the same time exceed the battery charge limit assigned to the user (user's over-activity). For posts published in the excess of battery charge, amount of reward will be reduced. In order for smart contract `golos.publication` had information about such posts, the actions `usenotifygt` and `usenotifylt` are used.

Before publishing a post, the smart contract `golos.publication` sends the action`usenotifygt` (or `usenotifylt`) to another smart contract `code` to use battery resources of `user` account by that smart contract. Smart contract `code` informs `golos.publication` about the current battery charge. After receiving the appropriate notification, the `golos.publication` smart contract logic calculates the post reward.

## get\_stored

The `get_stored` inline function is used to determine the battery charge of a user at a particular point in time.

The `get_stored` inline function has the form:

```cpp
int64_t get_stored(
    name code,
    name user,
    symbol_code token_code,
    uint8_t charge_id,
    uint64_t stamp_id) {
    …
}
```

**Parameters:**

* `code` — account name hosting the charge contract. &#x20;
* `user` — account name, the battery charge of which is about to be determined. &#x20;
* `token_code` — code of the token, which is linked to the battery. &#x20;
* `charge_id` — battery identifier. This value, together with the `token_code`, provides battery identification. &#x20;
* `stamp_id` — identifier of the stored value of the `charge_id` battery resource used by the user account, which is required to be obtained from the battery table. &#x20;

The value of battery charge is stored in the battery table when the `useandstore` is executed. Subsequently, to get the value from this table, call `get_stored`. Calling `get_stored` does not require additional authorization.

Data on stored values ​​of battery resources are available for obtaining from any smart contract. The `get_stored` function does not process data, but only gets the saved values ​​from the `golos.charge` smart contract tables.

The interaction of `golos.charge` with any of the smart contracts provides ability to keep track user's activities in these smart contracts. One battery can interact simultaneously with the actions of several smart contracts.

## get\_current\_value

The inline function `get_current_value` determines the battery charge of a specific user.\
The `get_stored` inline function has the form:

```cpp
int64_t get_current_value( 
    name code, 
    name user, 
    symbol_code token_code, 
    uint8_t charge_id = 0);
```

**Parameters:**

* `code` — account name hosting the charge contract. &#x20;
* `user` — account name, the battery charge of which is about to be determined. &#x20;
* `token_code` — code of the token, which is linked to the battery. &#x20;
* `charge_id` — battery identifier. This value, together with the `token_code`, provides battery identification. &#x20;


# Control

## Overview

The Control (or `golos.ctrl`) smart contract implements logic for election of witnesses, including the following:

* a registering procedure for an account as a candidate for a witness;
* a voting procedure for election of a witness;
* determining a list of the most rated witnesses.

The `golos.ctrl` smart contract contains settings that apply to the Golos application as a whole. These settings can be used to the change parameters of any subsystems (for example, emission distribution between pools). Other Golos application smart contracts can access the `golos.ctrl` smart contract and get these settings, percentage ratios of the funds distributed by pools, limits on battery resources. Also, the smart contracts can obtain a list of the most rated witnesses with corresponding authority values. This makes it possible to verify the authenticity of actions certified by witnesses.

## Parameters set in the Control smart contract

The `golos.ctrl` smart contract contains a kit of the parameters. To configure the contract, it needs to apply the action `setparams` action. The list of available parameters used by the contract is as follows:

```cpp
ctrl_param, types: [
    symbol_code ctrl_token,
    name multisig_acc,
    uint16_t max_witnesses,
    struct multisig_perms {
        uint16_t super_majority,
        uint16_t majority,
        uint16_t minority
    }, 
    uint16_t max_witness_votes,
    struct update_auth {
        uint32_t period
    }
]
```

**Parameters:**

* `ctrl_token` — a token symbol that uniquely identifies a specific token: &#x20;
  * token name. It should consist of a set of capital letters; &#x20;
  * token rate. The token cost accuracy is set as a number of decimal digits. &#x20;
* `multisig_acc` — an account name that controls a multisignature authorisation.&#x20;
* `max_witnesses` — a maximum number of witnesses that can take a decision (for example, sign transactions) on behalf of the application. The `multisig_acc` parameter contains a list of such witnesses. &#x20;
* `multisig_perms` — a required number of signatures from the most rated witnesses that have a permission to perform actions on behalf of the application. To change a parameter value it requires an appropriate level of permission. Different parameters require a different level of permission that is connected to their importance. There are three permission levels: &#x20;
  * `super_majority` — a high level of permission. To get such level it needs to pick up at least «two-thirds plus one» votes of the most rated witnesses (if this parameter is "0", it takes default value — "2/3+1"); &#x20;
  * `majority` — an average level of permission. To get such level it needs to pick up at least «half plus one» votes of the most rated witnesses (if this parameter is "0", it takes default value — "1/2+1"); &#x20;
  * `minor_majority` — a low level of permission. To get such level it needs to pick up at least «one-third plus one» votes of the the most rated witnesses (if this parameter is "0", it takes default value — "1/3+1").&#x20;
* `max_witness_votes` — a maximum number of witnesses for which a user can vote. &#x20;
* `update_auth` — a parameter that specifies frequency of updating the authorization for the `multisig_acc` account: &#x20;
  * `period` — an update period (in seconds). Re-authorization change for account is not performed if specified period has not passed since the last update. &#x20;

## Actions supported by the golos.ctrl smart contract

* [setparams](/devportal/application_contracts/golos_contracts/golos.ctrl_contract#setparams)
* [validateprms](/devportal/application_contracts/golos_contracts/golos.ctrl_contract#validateprms)
* [regwitness](/devportal/application_contracts/golos_contracts/golos.ctrl_contract#regwitness)
* [unregwitness](/devportal/application_contracts/golos_contracts/golos.ctrl_contract#unregwitness)
* [stopwitness](/devportal/application_contracts/golos_contracts/golos.ctrl_contract#stopwitness)
* [startwitness](/devportal/application_contracts/golos_contracts/golos.ctrl_contract#startwitness)
* [votewitness](/devportal/application_contracts/golos_contracts/golos.ctrl_contract#votewitness)
* [unvotewitn](/devportal/application_contracts/golos_contracts/golos.ctrl_contract#unvotewitn)
* [changevest](/devportal/application_contracts/golos_contracts/golos.ctrl_contract#changevest)
* [ban](/devportal/application_contracts/golos_contracts/golos.ctrl_contract#ban)
* [unban](/devportal/application_contracts/golos_contracts/golos.ctrl_contract#unban)

## setparams

The `setparams` action is used to configure the `golos.ctrl` smart contract parameters. The action has the following form:

```cpp
void control::setparams(vector<ctrl_param> params)
```

**Parameters**

* `params` — a value in the form of a structure containing fields with the setting parameters.&#x20;

## validateprms

The `validateprms` action checks parameters for validity and controls if there are errors or not. The `validateprms` action is called by the smart contract. It has the following form:

```cpp
void control::validateprms(vector<ctrl_param> params)
```

**Parameters**

* `params` — a value in the form of a structure containing the parameters to be checked.

## regwitness

The `regwitness` action is used to register candidates for witnesses. The action has the following form:

```cpp
void control::regwitness(
    name witness,
    string url
)
```

**Parameters:**

* `witness` — a name of a candidate for witnesses. &#x20;
* `url` — a website address from where information about the candidate can be obtained, including the reasons for her/his desire to become a witness. The address string must not exceed 256 characters. &#x20;

Performing the `regwitness` action requires a signature of the witness candidate.

## unregwitness

The `unregwitness` action is used to withdraw a user's candidacy from among the registered candidates to the witnesses. The action has the following form:

```cpp
void control::unregwitness(name witness)
```

**Parameters**

* `witness` — the user name to be removed from the list of witnesses registered as candidates. &#x20;

The `unregwitness` action can be called either by the candidate (in case of a withdrawal) or by a witness who found a discrepancy of the witness capabilities to desirable witness requirements, and mismatched data published on the web site with her/his relevant data.

Conditions for performing the `unregwitness` action:

* no votes for this witness candidate. Votes of all users who voted for this witness candidate should be removed; &#x20;
* the transaction must be signed by the `witness` candidate himself.

## stopwitness

The `stopwitness` action is used to temporarily suspend active actions of a witness (or a witness candidate). The action has the following form:

```
void stopwitness(name witness)
```

**Parameters**

* `witness` — account name of a witness (or a witness candidate) whose activity is temporarily suspended.

Conditions for performing the `stopwitness` action:

* the `witness` account should be active;
* a transaction must be signed by the `witness` account.

The `witness` account activity can be continued in case it has performed the `startwitness` action.

## startwitness

The `startwitness` action is used to resume suspended witness activity (or a witness candidate activity). The action has the following form:

```cpp
void startwitness(name witness)
```

**Parameters**

* `witness` — account name of a witness (or a witness candidate), whose activity is resumed.

Conditions for performing the `startfitness` action:

* the `witness` account activity should be suspended, that is, the operation `stopwitness` should be performed previously;
* a transaction must be signed by the `witness` account.

## votewitness

The `votewitness` action is used to vote for a witness candidate. The action has the following form:

```cpp
void control::votewitness(
    name voter,
    name witness
)
```

**Parameters:**

* `voter` — an account name that is voting for the witness candidate. &#x20;
* `witness` — a name of the witness candidate for whom the vote is cast. &#x20;

Doing the `votewitness` action requires signing the `voter` account.

**Restrictions:**

* the `witness` candidate name must first be registered through a call to `regwitness`; &#x20;
* total number of votes cast by the `voter` account for all candidates should not exceed the `max_witness_votes` parameter value;
* it is not allowed to vote for a witness candidate whose activity is suspended (after the candidate has completed the `stopwitness` action).

## unvotewitn

The action `unvotewitn` is used to withdraw a previously cast vote for a witness candidate.

The action has the following form:

```cpp
void control::unvotewitn(
    name voter,
    name witness
)
```

**Parameters:**

* `voter` —  an account name that intends to withdraw her/his vote which was previously cast for the witness candidate. &#x20;
* `witness` — the witness candidate name from whom the vote is withdrawn. &#x20;

It is allowed to withdraw a vote cast for a witness candidate whose activity is suspended (after the candidate has completed the `stopwitness` action).

Doing the `unvotewitn` action requires signing the `voter` account.

## changevest

The `changevest` is an internal and unavailable to the user action. It is used by `golos.vesting` smart contract to notify the `golos.ctrl` smart contract about a change of the vesting amount on the user's balance. The `changevest` action has the following form:

```cpp
void control::changevest(
    name who,
    asset diff
)
```

**Parameters:**

* `who` — an account name whose vesting amount has been changed. &#x20;
* `diff` — a relative change of vesting amount. &#x20;

The `changevest` action is called automatically each time in case the vesting amount is changed on a user's balance. The `golos.vesting` smart contract informs the `golos.ctrl` smart contract about this change. Because changing the vesting amount on the user's balance changes the weight of this user's vote, the witness rating that the user voted for will also be changed. The `golos.ctrl` smart contract corrects the rating of each witness based on received information about the change. The data of the smart contract table is not modified.

In case a list of the most rated witnesses is changed, `multisig_acc` authorization will automatically be changed too.

## ban

The `ban` action bans a user from publishing and curating any posts. Any account can be banned if the content of its publication or comment poses a direct threat to the life of the application or the blockchain as a whole (for example, a statement in a harsh negative form that could affect the reputation of application, campaigning or calling users, etc.).

```cpp
void ban(name account)
```

**Parameters:**

* `account` — the account to be banned.

The action requires authorization of the account on which dApp is deployed.

## unban

The `unban` action cancels the ban for a user to publish and curate posts.

```cpp
void unban(name account)
```

**Parameters:**

* `account` — the account to be unbanned.

The action requires authorization of the account on which dApp is deployed.


# Emission

## Purpose of golos.emit smart contract

The smart contract `golos.emit` ensures the generation of new tokens and their distribution among reward pools in accordance with settings the parameters of the smart contract.

## Overview

Tokens in the smart contract `golos.emit` are emitted according to the algorithm specified in the parameter settings. New tokens are distributed between smart contract reward pools, such as `golos.vesting`, `golos.publication`, `golos.ctrl` in accordance with the settings of the `golos.emit` smart contract parameters. Funds from the vesting pool are accrued to the owners of vesting, from the publication pool — to the authors and curators of posts.

## Parameters set in golos.emit smart-contract

The setting parameters have the following forms:

```cpp
emit_param, types:[
    struct inflation_rate {
        uint16_t start,
        uint16_t stop,
        uint32_t narrowing
    },
    struct reward_pools {
        name name,
        uint16_t percent
    },
    struct emit_token {
        symbol symbol
    },
    struct emit_interval {
        uint16_t value
    },
]
```

**Parameters to be set:**

* `inflation_rate` — inflation parameters that determine the number of new tokens emitted for a certain period of time. Tokens that are already in circulation are not taken into account when calculating this indicator. The`inflation_rate` value is a structure containing the fields:
  * `start` — initial inflation rate;
  * `stop` — minimum inflation rate;
  * `narrowing` — the rate of decrease in the current percentage of inflation (shows the number of seconds during which the `start` parameter value decreases by 0.01%).
* `reward_pools` — reward pool vector. For each pool, the parameter value has the form of a structure containing fields:
  * name — reward pool name;
  * percent —  the share (percentage) of new tokens that is transferred to the `name` pool. This value is set to an accuracy of 0.01 percent. This parameter takes the values from 0 to 10000. The value 10000 corresponds 100 %.
* `emit_token` — the type of token that is being issued:
  * symbol — token symbol.
* `emit_interval` — emission interval parameter:
  * value — new tokens emission interval (in seconds). &#x20;

New issued tokens are distributed among several pools. Award pools in which new tokens are distributed are determined by the witnesses. One of the reward pools must have zero percent. Remaining undistributed part of the tokens is transferred to this pool.

When inflation is reduced to its minimum `stop` parameter, tokens continue to be emitted, but remain unchanged.

> **Restrictions:**\
> The total percentage of all tokens distributed in pools must be no more than 100 (or 10 000 tokens). For example, 25 (pool of vesting) + 25 (pool of publications) + 49 (some other pool) + 0 (control pool) = 99 (%).

## Actions supported by the golos.emit smart contract

* [setparams](/devportal/application_contracts/golos_contracts/golos.emit_contract#setparams)
* [validateprms](/devportal/application_contracts/golos_contracts/golos.emit_contract#validateprms)
* [start](/devportal/application_contracts/golos_contracts/golos.emit_contract#start)
* [stop](/devportal/application_contracts/golos_contracts/golos.emit_contract#stop)
* [emit](/devportal/application_contracts/golos_contracts/golos.emit_contract#emit)

## setparams

The `setparams` action is used to set the parameters of the smart contract (to configure the smart contract). The action has the following form:

```cpp
void emission::setparams(vector<emit_param> params)
```

`params` — a list of parameters to be set.

## validateprms

The `validateprms` action is internal and called by the smart contract `golos.emit`. The action is used to check the parameters for validity, controls the presence of errors in them. The action has the following form:

```cpp
void emission::validateprms(vector<emit_param> params)
```

`params` — a list of parameters to be check.

## start

The `start` action is used to start the emission process of tokens of a certain type in accordance with the selected algorithm.\
The action has the following form:

```cpp
void emission::start()
```

To perform this action it is required the authorization of `golos.emit` smart contract.

The start time of emission is determined by the moment of the first call start. Before calling the `start` action, it is required to configure the smart contract parameters, as well as the reward pools.

## stop

The `stop` action is used to temporarily or completely stop the token emission process, due to various reasons, including the need to change the parameters of the smart contract (for example, to reconfigure reward pools). The action has the following form:

```cpp
void emission::stop()
```

To perform this action it is required the authorization of `golos.emit` smart contract.

## emit

The `emit` action is internal and its call is not available to a user. It is used to emit tokens in the amount determined by the selected algorithm. The action has the following form:

```cpp
void emission::emit()
```

The `emit` action is called periodically at regular intervals. Each call determines the amount of funds to accrue for each reward pool.\
Below is the diagram showing the emit of tokens by the `golos.emit` smart contract. This diagram also shows the moments of calling the actions `start`,`stop` and `emit`.

![Fig.1 — Diagram of emitting the tokens by the smart contract](/files/-LoZvuNlSq7uT0unl2Df)

Vertical axis shows the annual percentage of a certain type of tokens produced in relation to their total number of this type. Horizontally time is displayed. The blue line conventionally shows the annual inflation of tokens of this type. The red line conditionally indicates the percentage of tokens emitted by the smart contract relative to the total number of tokens of this type.

Designations on the diagram in fig.1:

* n1 is the minimum inflation rate, set by the `stop` parameter.
* n2 is the initial rate of inflation, set by the `start` parameter.
* t1 and t4 are the start times of the `start` action.
* t3 and t8 are the start times of the `stop` action.
* t2, t5, t6 and t7 are the instants of the launch time of the `emit` action. &#x20;

The diagram shows that the release of tokens began after the first start of the `start` action. Tokens emission stopped after the `stop` calls. When the threshold value n1 was reached, tokens emission remained at the minimum acceptable level. After the `emit` calls, the amount of tokens emission is displayed, which should be distributed among the award pools of smart contracts.


# Publication

## The list of actions implemented in the golos.publication smart contract

* contract setting: [setlimit](/devportal/application_contracts/golos_contracts/golos.publication_contract#setlimit), [setrules](/devportal/application_contracts/golos_contracts/golos.publication_contract#setrules) and [setparams](/devportal/application_contracts/golos_contracts/golos.publication_contract#setparams);
* message actions: [createmssg](/devportal/application_contracts/golos_contracts/golos.publication_contract#createmssg), [updatemssg](/devportal/application_contracts/golos_contracts/golos.publication_contract#updatemssg), [deletemssg](/devportal/application_contracts/golos_contracts/golos.publication_contract#deletemssg), [reblog](/devportal/application_contracts/golos_contracts/golos.publication_contract#reblog), [erasereblog](/devportal/application_contracts/golos_contracts/golos.publication_contract#erasereblog), [setcurprcnt](/devportal/application_contracts/golos_contracts/golos.publication_contract#setcurprcnt) and [setmaxpayout](/devportal/application_contracts/golos_contracts/golos.publication_contract#setmaxpayout);
* voting: [upvote](/devportal/application_contracts/golos_contracts/golos.publication_contract#upvote), [downvote](/devportal/application_contracts/golos_contracts/golos.publication_contract#downvote) and [unvote](/devportal/application_contracts/golos_contracts/golos.publication_contract#unvote);
* system actions: [closemssgs](/devportal/application_contracts/golos_contracts/golos.publication_contract#closemssgs), [calcrwrdwt](/devportal/application_contracts/golos_contracts/golos.publication_contract#calcrwrdwt), [paymssgrwrd](/devportal/application_contracts/golos_contracts/golos.publication_contract#paymssgrwrd) and [deletevotes](/devportal/application_contracts/golos_contracts/golos.publication_contract#deletevotes). &#x20;

In addition, this contract contains logic for determining the [payments to authors, curators and beneficiaries of posts](https://cyberway.gitbook.io/en/devportal/application_contracts/golos_contracts/rewards_definition).

### Data types used

**percentage**\
16-bit value with declaration types `int16_t` or `uint16_t` and accuracy to hundredths of a percent. The percentage is between -10000 and 10000 (for example: -10000 = -100 %, 0 = 0 %, 10000 = 100 %, 1234 = 12,34 %).\
Negative percentage values are specified by the type `int16_t`.

**mssgid**\
Message identifier, structure containing fields:

* `author` — message author;
* `permlink` — unique name of message within a particular author's publications. &#x20;

  ```cpp
  struct mssgid {
  name author;
  std::string permlink;
  }
  ```

**beneficiary**\
Beneficiary, structure containing fields:

* `account` — beneficiary account;
* `weight` — *percentage*, a share of payment to a beneficiary. It is a part of an author reward amount. &#x20;

  ```cpp
  struct beneficiary {
  name account;
  uint16_t weight;
  };
  ```

## setlimit

The `setlimit` action is used to set rules that restrict user operations. The mechanism for restricting user operations is based on interaction of two smart contracts — precisely `golos.publication` and `golos.charge`. Each action of the `golos.publication` smart contract is linked to a certain battery of the `golos.charge` smart contract. In the `setlimit` parameters, it needs to specify an action (for example, `createmssg` or `upvote`) and a battery to be linked to it.

The `setlimit` action has the following form:

```cpp
setlimit(
    std::string act,
    symbol_code token_code,
    uint8_t    charge_id,
    int64_t    price,
    int64_t    cutoff,
    int64_t    vesting_price,
    int64_t    min_vesting
);
```

**Parameters:**

* `act` — a name of action. The contract supports the values `post`, `comment`, `vote` and `post bandwidth`.&#x20;
* `token_code` —  token code (character string that uniquely identifies a token). &#x20;
* `charge_id` — battery ID. The action specified as `act` is limited to the charge of this battery. Multiple actions can be linked to a single battery. For voting actions such as `upvote`, `downvote` and `unvote`, the battery ID value should be set to zero.   &#x20;
* `price` — a price (in arbitrary units) of the consumed battery recourse with the `charge_id` identifier for the `act` action. The battery recourse is reduced after each performed action and recovered with time.  &#x20;
* `cutoff` — lower threshold value of the battery recourse at which the `act` action is blocked. &#x20;
* `vesting_price` — amount of vesting, that the user must pay for performing the `act` action, in case of exhaustion of the battery recourse (reaching lower threshold value). The `act` action will be executed if the user allows to withdraw the specified amount of vesting from her/his balance. For payment it is necessary that on the user balance there was a necessary sum of vesting in unblocked state. *(**Note:** this parameter is currently disabled and should be equal to «0»)*.&#x20;
* `min_vesting` — minimum value of vesting that a user needs to have on her/his balance to perform the `act` action. *(**Note:** this parameter is currently disabled and should be equal to «0»)*. &#x20;

The interaction of smart publishing contracts and batteries allows a witness to flexibly configure restrictions on user actions (for example, such actions as voting for posts, publication of post and leaving comments can be correlated with the resources of three separate batteries. In this case, user activity will be limited for each of these actions. Also, all these actions can be linked to only one battery, that is, be limited by resources of the same battery). For each action performed by the user, she/he is charged a value corresponding to cost of the consumed battery recourse. When the `golos.charge` smart contract reaches the threshold value of used battery recourse, user's actions are blocked until necessary resource appears in the battery again.

## setrules

The `setrules` action is used for setting rules that apply in application for distribution of rewards between authors and curators of posts.\
The `setrules` action has the following form:

```cpp
void setrules(
    funcparams  mainfunc,
    funcparams  curationfunc,
    funcparams  timepenalty,
    int64_t     maxtokenprop,
    symbol      tokensymbol
);
```

**Parameters:**

* `mainfunc` — a function that calculates a total amount of rewards for an author and post curators in accordance with accepted algorithm (for example, a linear algorithm or a square root algorithm). The algorithm used in the function is selected by witnesses voting. The function contains two parameters: mathematical expression (the algorithm itself) by which the reward is calculated, and maximum allowable value of argument for this function. When setting parameter values for `setrules`, they are checked for correctness (including for monotonous behavior and for non-negative value). &#x20;
* `curationfunc` — a function that calculates a fee for each of the curators in accordance with accepted algorithm (similar to calculation for `mainfunc`). &#x20;
* `timepenalty` — a function that calculates a weight of vote, taking into account the time of voting and the penalty time duration. &#x20;
* `maxtokenprop` — the maximum share of the reward paid to an author in tokens (balance in vesting). &#x20;
* `tokensymbol` — a token type (within the Golos application, only Golos tokens are used). &#x20;

A transaction containing the `setrules` action must be signed by most leaders.

## createmssg

The `createmssg` action is used to create a message as a response to a previously received (parent) message. The `createmssg` action has the following form:

```cpp
void createmssg(
    mssgid        message_id,
    mssgid        parent_id,
    std::vector<structures::beneficiary> beneficiaries,
    int16_t       tokenprop,
    bool          vestpayment,
    std::string   headermssg,
    std::string   bodymssg,
    std::string   languagemssg,
    std::vector<structures::tag> tags,
    std::string   jsonmetadata,
    std::optional<uint16_t> curators_prcnt,
    std::optional<asset> max_payout
);
```

**Parameters:**

* `message_id` — identifier of the message. &#x20;
* `parent_id` — identifier of the parent message. To create a post, the field `parent_id.author` should be empty. &#x20;
* `beneficiaries` — list of beneficiaries. The list may be empty. &#x20;
* `tokenprop` — a share of reward paid in liquid tokens (the balance is paid in vesting). This value cannot exceed the `maxtokenprop` value  specified in `set_rules`. &#x20;
* `vestpayment` — `true`, if a user gives permission to pay in vestings in case of battery resource exhaustion (the message is sent regardless of battery resource). Default value is `false`. *(**Note:** this parameter is currently disabled and should be equal to «false»)*.&#x20;
* `headermssg` — title of the message. &#x20;
* `bodymssg` — body of the message. &#x20;
* `languagemssg` — language of the message. &#x20;
* `tags` — a list of tags. &#x20;
* `jsonmetadata` — metadata in the JSON format. &#x20;
* `curators_prcnt` — a share (in percent) of reward deducted to curators from total amount of rewards for the created message. The parameter value is set by the message author within the range of values set by leaders. This parameter is optional. If is not specified it takes default value — the value of [min\_curators\_prcnt](/devportal/application_contracts/golos_contracts/golos.publication_contract#setparams);
* `max_payout` — maximum possible reward amount for the message being paid out of the pool to which this message is linked. This amount is set by the author. It can be used to create messages without payouts. The parameter is optional and defaults to `asset::max_amount`. &#x20;

The `parent_id` parameter identifies the parent message to which a response is created via `createmssg`.

To perform the `createmssg` action it is required that the transaction should be signed by the author of the message.

The key that is used to search for a message is bound to the `account` and `permlink` parameters.

## updatemssg

The `updatemsg` action is used to update a message previously sent by user.\
The `updatemssg` action has the following form:

```cpp
void updatemssg(
    mssgid       message_id,
    std::string  headermssg,
    std::string  bodymssg, 
    std::string  languagemssg,
    std::vector<structures::tag> tags,
    std::string  jsonmetadata
);
```

**Parameters:**

* `message_id` — identifier of the message being updated. The parameter contains the fields: `author` — author name of the message being updated, `permlink` — unique name of the message within publications of this author. &#x20;
* `headermssg` — title of the message. &#x20;
* `bodymssg` — body of the message. &#x20;
* `languagemssg` — language of the message. &#x20;
* `tags` — tag that is assigned to the message. &#x20;
* `jsonmetadata` — metadata in the JSON format. &#x20;

To perform the `updatemssg` action it is required that the transaction should be signed by the author of the message.

## deletemssg

The `deletemssg` action is used to delete a message previously sent by user.\
The `deletemssg` action has the following form:

```cpp
void deletemssg(mssgid   message_id);
```

**Parameter:**

* `message_id` — identifier of the message to be deleted. The parameter contains the fields: `author` — author of the message to be deleted, `permlink` — unique name of the message within publications of this author. &#x20;

The message cannot be deleted in the following cases:

* the message has a comment; &#x20;
* total weight of all votes cast for this message is greater than zero. The weight of the user's vote depends on amount of vesting she/he uses. A message cannot be deleted if the total weight of all votes has a positive value. &#x20;

To perform the `deletemssg` action it is required that the transaction should be signed by the author of the message.

## upvote

The `upvote` action is used to cast a vote in the «upvote» form when voting for a message.\
The `upvote` action has the following form:

```cpp
void upvote(
    name      voter,
    mssgid    message_id,
    uint16_t  weight
);
```

**Parameters:**

* `voter` — voting account name. &#x20;
* `message_id` — identifier of the message. &#x20;
* `weight` — the vote weight of the account name `voter`, *percentage*. &#x20;

To perform the `upvote` action it is required that the transaction should be signed by the account name `voter`.

## downvote

The `downvote` action is used to cast a vote in the «downvote» form when voting for a message.\
The `downvote` action has the following form:

```cpp
void downvote(
    name      voter,
    mssgid    message_id,
    uint16_t  weight
);
```

**Parameters:**

* `voter` — voting account name. &#x20;
* `message_id` — identifier of the message.  &#x20;
* `weight` — the vote weight of the account name `voter`, *percentage* (the weight value must be positive).   &#x20;

To perform the `downvote` action it is required that the transaction should be signed by the account name `voter`.

## unvote

The `unvote` action is used to revoke user's own vote that was previously cast for the post.\
The `unvote` action has the following form:

```cpp
void unvote(
    name     voter,
    mssgid   message_id
);
```

**Parameters:**

* `voter` — account name that revokes her/his own vote previously cast for the message. &#x20;
* `message_id` — identifier of the message. &#x20;

To perform the `unvote` action it is required that the transaction should be signed by the account name `voter`.

## closemssgs

The `closemssgs` is a system action and used to «close» messages that have reached the time of payment.\
The `closemssgs` action has the following form:

```
void close_messages(name payer)
```

**Parameter:**

* `payer` — account name paying for data storage. &#x20;

## reblog

The `reblog` action is used to place a post adopted from another author under this smart contract, as well as to add rebloger's own title and text to the post as a note.

The `reblog` action has the following form:

```
void reblog(
    name rebloger,
    mssgid message_id,
    std::string headermssg,
    std::string bodymssg
)
```

**Parameters:**

* `rebloger` — account name of the reblogger.  &#x20;
* `message_id` — identifier of the post-original. &#x20;
* `headermssg` —  title of the note to be added. This field can be empty. &#x20;
* `bodymssg` — body of the note to be added. This field can be empty if the field `headermssg` is empty too. &#x20;

Restrictions that are imposed on the `reblog` action:

* It is not allowed to perform `reblog` of own post, that is, the author of which is the account`rebloger`.
* If a title of the note `headermssg` is specified, then its body `bodymssg` must be present too (reblogging without a header, as well as without a header and body is allowed).
* The title length of the added note should not exceed 256 characters.

To perform the `reblog` action it is required that the transaction should be signed by the account name `rebloger`.

## erasereblog

The `erasereblog` action is used to remove a previously posted reblog. The `erasereblog` action has the following form:

```cpp
void erasereblog(
    name rebloger,
    mssgid message_id
)
```

**Parameters:**

* `rebloger` — account name removing the reblog.
* `message_id` — identifier of the post-original. &#x20;

A transaction containing the `erasereblog` action should be signed by the `rebloger` account.

## setcurprcnt

The `setcurprcnt` action is used by author of a post to set or change previously specified amount (in percent) of reward, allocated to the curators.

The `setcurprcnt` action has the following form:

```
void set_curators_prcnt(
    mssgid message_id,
    uint16_t curators_prcnt
)
```

**Parameters:**

* `message_id` — identifier of the post.
* `curators_prcnt`— a share (*percentage*) of reward deducted to curators from total amount of rewards for the post. &#x20;

After the start of voting for a post, any change in the share of payment to curators is unacceptable.

To perform the `setcurprcnt` action it is required that the transaction should be signed by the post author `message_id.author`.

## setmaxpayout

The `setmaxpayout` action is used by author of a message to set or change maximum possible payment to curators for the message.

The `setmaxpayout` action has the following form:

```cpp
void setmaxpayout(
    mssgid message_id,
    asset max_payout
);
```

**Parameters:**

* `message_id`— identifier of the message for which amount the payment to curators is setting. The parameter contains the fields: `author` — author of the message, `permlink` — unique name of the message within publications of this author. &#x20;
* `max_payout`— maximum possible reward amount for the message being paid out of the pool to which this message is linked. This amount is set by the author in the form of funds (tokens) that are in this pool. &#x20;

The following restrictions apply to changing the `max_payout` parameter:

* the parameter can only be changed for open messages. &#x20;
* the parameter can only be changed for messages that do not have votes. &#x20;
* the parameter can only be decreased in relation to its previous value. It must be positive. Retaining old value of the parameter is unacceptable. &#x20;

To perform the `setmaxpayout` action it is required that the transaction should be signed by the author of message.

## calcrwrdwt

The `calcrwrdwt` action is internal and unavailable to the user. It is used to calculate a post weight based on number of publications made by its author for a certain time.

The action has the following form:

```
void calcrwrdwt(
    name account,
    int64_t mssg_id,
    int64_t post_charge
)
```

**Parameters:**

* `account`— account name that is the post author. &#x20;
* `mssg_id`— internal identifier of the post. &#x20;
* `post_charge`— current battery life. It is used to limit user activity in posting. Battery charge decreases with increasing number of posting by the author for a certain time. The amount paid for posts is also reduced.

To perform the `calcrwrdwt` action it is required that the transaction should be signed by the `golos.publication` smart contract account.

## paymssgrwrd

The `paymssgrwrd` action is internal and unavailable to the user. It is used to pay rewards for a «closed» message to curators, beneficiaries and author. The action has the following form:

```
void paymssgrwrd(mssgid message_id)
```

**Parameter:**

* `message_id` — identifier of the message for which awards are paid. &#x20;

Reward may be partially paid when calling `paymssgrwrd`. In this case, repeated calls of `paymssgrwrd` are allowed.

This action can be performed by any account.

## deletevotes

The `deletevotes` is an inner action. It is used to free up memory occupied by voting records for messages for which rewards have been paid. The action has the following form:

```cpp
void deletevotes(int64_t message_id, name author)
```

**Parameters:**

* `message_id` — internal message identifier.
* `author` — post author. &#x20;

When calling `deletevotes`, the votes may be removed only partially not to completely. In this case, repeated calls of `deletevotes` are allowed.

A transaction containing the `deletevotes` action must be signed by the `golos.publication` contract account.

## setparams

The `setparams` action is used to configure the parameters of `golos.publication` smart contract. The action has the following form:

```
void set_params(std::vector<posting_params> params)
```

**Parameter:**

* `params` — list of structures with variable contract parameters. &#x20;

### Other parameters which are used and set in the golos.publication smart contract

There are other parameters in the `golos.publication` smart contract that can be set by calling `set_params`:

* `cashout_window` — payout window options:
  * `window` — time interval after which a message reward is paid;
  * `upvote_lockout` — the time interval before «closing» a post.  During this interval the positive voice «upvote» is prohibited, but allowed the negative voice «downvote».
* `max_beneficiaries` — maximum possible number of beneficiaries.
* `max_comment_depth` — maximum allowable nesting level of comments (it shows the allowed nesting level of child comments relative to root one). &#x20;
* `social_acc` — account name of the `social` contact. &#x20;
* `referral_acc` — account name of the `referral` contact. &#x20;
* `curators_prcnt` — a share (in percent) of reward deducted to curators from total amount of rewards for a message. The parameter sets thresholds (`min_curators_prcnt` and `max_curators_prcnt`) within which the author can specify her/his own percentage value of curators fee.
* `bwprovider` — account of the `bandwidth` resource provider as well as  the permission used (type `permission_level`).
* `min_abs_rshares` — minimum absolute value of `rshares` for voting operations. Votes with a lower value are rejected.


# Referral program

## Purpose of the golos.referral smart contract

The `golos.referral` smart contract contains the logic of a referral program that rewards users who invite their friends or third parties to register in the `Golos` application via social networks (for example, by viewing third-party publications or posting their own posts about the blockchain). The logic of the referral program defines one user as a referrer with respect to another (referral). The smart contract contains algorithm for calculating the reward for a post, as well as algorithm for the completion of the referral program, including the completion at the initiative of the referral user through the redemption of his account.

## Parameters set in the golos.referral smart contract

The parameters of the smart contract are set by the witnesses (leaders) of the community.

```cpp
referral_param, types:[
    struct breakout_parametrs {
        asset min_breakout,
        asset max_breakout
    },
    expire_parametrs (uint64_t max_expire),
    percent_parametrs (uint16_t max_percent)
]
```

**Parameters:**

* `breakout_parametrs` — value in the structure form (containing fields):
  * `min_breakout` — the minimum allowable number of tokens required for the purchase of a referral account and, accordingly, the termination of the referral program;
  * `max_breakout` — the maximum allowable number of tokens required for the redemption of the referral account and, accordingly, the termination of the referral program.
* `expire_parametrs`— the maximum allowable time of the referral program.
* `percent_parametrs` — maximum allowable percentage of deduction to the referrer during the duration of the referral program.

## Actions used in golos.referral smart contract

The `golos.referral` smart contract supports the following actions: [setparams](/devportal/application_contracts/golos_contracts/golos.referral_contract#setparams), [validateprms](/devportal/application_contracts/golos_contracts/golos.referral_contract#validateprms), [addreferral](/devportal/application_contracts/golos_contracts/golos.referral_contract#addreferral) and [closeoldref](/devportal/application_contracts/golos_contracts/golos.referral_contract#closeoldref).

## setparams

The `setparams` action is used to set (configure) the parameters of a smart contract. The action has the form:

```cpp
void referral::setparams(std::vector<referral_params> params)
```

The parameter `params` is a value in the form of a structure which contains the fields: `breakout_parametrs`, `expire_parametrs`, `percent_parametrs`.

## validateprms

The `validateprms` action is called by the smart contract and is used to check the parameters for validity and controls the presence of errors in them.

```cpp
void referral::validateprms(std::vector<referral_params> params)
```

## addreferral

The `addreferral` action is used to create a referral account for the invited user. As a referrer, it can be specified a user who directly invited another user, as well as a third-party account. Referrer for the created referral account receives a share in the form of a percentage of the author's fees for referral publications.

This action comes in the following the form:

```cpp
void referral::addreferral(
    name referrer,
    name referral,
    uint16_t percent,
    uint64_t expire,
    asset breakout
)
```

**Parameters:**

* `referrer` — referrer account name.
* `referral` — referral account name. &#x20;
* `percent` — the percentage of payment to the referrer withdrawn from the referral income. The parameter takes a value from zero to the maximum allowed by the witnesses. &#x20;
* `expire` — time (in seconds) of the referral program. The value must not exceed the maximum allowed time set by witnesses. &#x20;
* `breakout` — the number of tokens which is necessary to purchase a referral account. &#x20;

To perform the `addreferral` action, the smart contract account authorization is required. To create a referral program record on a website, the witnesses (leaders) grant rights to this website, which becomes responsible for attracting users.

## closeoldref

The `closeoldref` action is a service internal function and is used to release obsolete entries from the table of active referral programs of the smart contract. It serves for removing referral programs data which actions are completed.

The action has the following form:

```cpp
void referral::closeoldref()
```

To perform the `closeoldref` action, the smart contract account authorization is required. The call is made automatically.


# Social

## Purpose of golos.social smart contract

The `golos.social` smart contract provides users the following features:

* creating and editing user profiles (metadata).
* pin-list establishment that allows its owner to receive information about the publications of users that he/she is interested in.
* the establishment of a so-called «black» list allowing to block communication between the owner of this list and any unwanted users. &#x20;

## Terminology used in the description of golos.social smart contract

**User profile** — user metadata stored in the client application database in the form of a structure characterizing the user. The user profile is created and edited by the user. The `golos.social` smart contract is not responsible for the storing of user metadata, but only controls whether the user has the right to change or delete metadata.

**A user’s pin list** — a database item containing a list of account names that a given user is interested in. The user’s pin list is created and edited by the user. It can be used in the client application to create subscriptions, including informing the given user (subscriber) about the appearance of a new post whose author’s name is contained in the pin list.

**«Black» list** — a database item containing a list of account names that this user characterizes as unwanted. The «black» list is created and edited by the user. Using the «black» list allows the user to block comments and votes of accounts whose names are contained in this list. The `golos.publication` smart contract verifies the absence of the account name in this list when performing `createmssg` action.

## Actions supported by golos.social smart contract

The `golos.social` smart contract supports the following actions: [pin](/devportal/application_contracts/golos_contracts/golos.social_contract#pin), [unpin](/devportal/application_contracts/golos_contracts/golos.social_contract#unpin), [block](/devportal/application_contracts/golos_contracts/golos.social_contract#block), [unblock](/devportal/application_contracts/golos_contracts/golos.social_contract#unblock), [updatemeta](/devportal/application_contracts/golos_contracts/golos.social_contract#updatemeta) and [deletemeta](/devportal/application_contracts/golos_contracts/golos.social_contract#deletemeta).

## accountmeta type

The `accountmeta` type is intented to describe the user profile and comes in the following structure:

```cpp
struct accountmeta {
  optional<std::string> type;               //  Type

    optional<std::string> app;              // Mother application

    optional<std::string> email;            // User’s e-mail address
    optional<std::string> phone;            // User’s phone number
    optional<std::string> facebook;         // User’s facebook account
    optional<std::string> instagram;        // User’s instagram account
    optional<std::string> telegram;         // User’s telegram account
    optional<std::string> vk;               // User’s vk account
    optional<std::string> whatsapp;         // User’s whatsapp account
    optional<std::string> wechat;           // User’s wechat account
    optional<std::string> website;          // Personal website url

    optional<std::string> first_name;       // User first name
    optional<std::string> last_name;        // User surname
    optional<std::string> name;             // Account name
    optional<std::string> birth_date;       // Date of birth
    optional<std::string> gender;           // Gender
    optional<std::string> location;         // Province of residence
    optional<std::string> city;             // City of residence

    optional<std::string> about;            // About a user
    optional<std::string> occupation;       // Occupation
    optional<std::string> i_can;            // User capability
    optional<std::string> looking_for;      // User purpose 
    optional<std::string> business_category; // Business category

    optional<std::string> background_image; // Background image
    optional<std::string> cover_image;      // Cover image
    optional<std::string> profile_image;    // Profile (avatar) picture 
    optional<std::string> user_image;       // User image
    optional<std::string> ico_address;      // Ico-address

    optional<std::string> target_date;      // Accomplish due date
    optional<std::string> target_plan;      // User target 
    optional<std::string> target_point_a;   // Intermediate target A
    optional<std::string> target_point_b;   // Intermediate target B
}
```

The `accountmeta` type is used as a parameter in the `updatemeta` action.

## pinblock table

The `pinblock` table is a database item and contains information about the relationship of one user to another. The data from the table is used to create a pin-list and a list of blocked users.

The `pinblock` table contains the following fields:

* `(name) SERVICE.scope` — the account name (the first name taken from a pair), which puts a user name of interest into one of the lists — the pin-list or the list of blocked users;
* `(name) account` — the account name that was added to one of the lists — the pin-list or the list of blocked accounts;
* `(bool) pinning` — «true» means that the account name has been added to the pin list;
* `(bool) blocking` — «true» means that the account name has been added to the list of blocked accounts. &#x20;

> **Please note:**\
> Both `pinning` and `blocking` fields cannot be set to «true».\
> The record is removing from the table if the `pinning` and `blocking` fields are «false».

## pin

The `pin` action is used to add an account name of interest to a pin-list. This action can only be performed by the pin-list owner. The `pin` action has the following form:

```cpp
void pin(
    name pinner,
    name pinning
);
```

**Parameters:**

* `pinner` —  account name which is the pin-list owner and adds the name specified in the `pinning` field to the pin-list.
* `pinning` — the account name that is being added to the pin-list. &#x20;

The rights to run the `pin` action belong to `pinner` account.

The `pin` action is introducing the following restrictions:

* a user is not allowed to add own name to the pin-list, that is, the `pinning` field must not contain the `pinner` field value.
* it is not allowed to add account name to the pin-list if pin-list already contains this name.
* it is not allowed to add account name to the pin-list if this name has been blocked by the `pinner` account, that is, this name is in the list of blocked accounts. &#x20;

## unpin

The `unpin` action is used to remove an account name from a pin-list. The `unpin` action is as follows:

```cpp
void unpin(
    name pinner,
    name pinning
);
```

**Parameters:**

* `pinner` — the account name that removes a name specified in the `pinning` field from the pin-list.
* `pinning` — the account name that is about to be removed from the pin-list. &#x20;

The rights to run the `pin` action belong to `pinner` account.

The `unpin` action is introducing the following restrictions:

* it is not allowed to remove the account name which is the pin-list owner, that is, the `pinning` field must never be equal to `pinner` filed.
* it is not allowed to remove an account name that is not present in the pin-list. &#x20;

## block

The `block` action is used to add an account name of interest to «black» list. This action can only be performed by the «black» list owner.\
The `block` action has the following form:

```cpp
void block(
    name blocker,
    name blocking
);
```

**Parameters:**

* `blocker` —  account name which is the «black» list owner and adds the name specified in the `blocking` field to the «black» list.
* `blocking` — the account name that is being added to the «black» list. &#x20;

The rights to run the `block` action belong to `blocker` account.

The `block` action is introducing the following restrictions:

* a user is not allowed to block him/herself, that is, the `blocking` field must not be equal to `blocker` field value.
* it is not allowed to add account name to the black-list if black-list already contains this name. &#x20;

## unblock

The `unblock` action is used to remove an account name from a «black» list.\
The `unblock` action has the following form:

```cpp
void unblock(
    name blocker,
    name blocking
);
```

**Parameters:**

* `blocker` — the account name that removes a name specified in the `blocking` field, from the «black» list.
* `blocking` — the account name that is about to be removed from the «black» list. &#x20;

The rights to run the `unblock` action belong to `blocker` account.

The `unblock` action is introducing the following restrictions:

* it is not allowed to remove the account name which is the «black» list owner, that is, the `blocking` field must never be equal to `blocker` field;
* it is not allowed to remove an account name that is not present in the «black» list. &#x20;

## updatemeta

The `updatemeta` action is used to fill, update, or delete account profile field values.\
The `updatemeta` action has the following form:

```cpp
void updatemeta(
    name account,
    accountmeta meta
);
```

**Parameters:**

* `account` — name of the account whose profile is being edited.
* `meta` — a value of type of the `accountmeta` structure. &#x20;

The rights to run the `updatemeta` action belong to the account that is specified in the `account` field. The updatemeta action does not interact with the database. It only checks the rights of the user who changes her/his profile. Updating user metadata within the database should be implemented in the client application.

## deletemeta

The `deletemeta` action is used for deleting an account profile.\
The `delelemeta` action has the following form:

```cpp
void deletemeta(name account);
```

The parameter `account` is a name of the account whose profile is being deleted.

The rights to run `deletemeta` action belong to the account that is deleting her/his profille. The `deletemeta` action does not interact with the database. It only checks the rights of the user who is about to delete her/his profile.\
Removal of user metadata from the database should be implemented in the client application.


# Vesting

## Purpose of golos.vesting smart contract

The `golos.vesting` smart contract provides binding of the vesting to a token created by the `cyber.token` smart contract.

## Overview

The `golos.vesting` smart contract supports the following operations:

* creation/«burning» of the vesting by a user;
* delegation of funds in the form of the vesting to another user;
* accrual of the vesting to authors and curators from the reward pool;
* replenishment of the pool with funds received from the `golos.emit` smart contract. &#x20;

**Creating (buying) vesting**\
The user can store her/his funds in the form of tokens and in the form of vesting. The user can exchange part of tokens for vesting at the `golos.vesting` smart contract at the current price.\
In the smart contract, there is a table in the table that stores data on the availability of funds in the form of vesting on the balance sheet of each user. When purchasing the vesting, the transfer of funds (transaction) is performed directly in tokens. The user transfers a certain number of tokens from her/his balance to the `golos.vesting` balance. The user's balance is received amount of vesting at the current price as soon as the transaction is completed.

**Vesting withdrawal**\
The user can withdraw the existing vesting on her/his balance into tokens at the current rate. The transfer of funds (transaction) occurs directly in tokens. The amount of vesting is removed from the user's balance. Amendments to a certain amount of ongoing tests. Depending on the settings of the smart contract.

**Delegation of funds in the form of vesting**\
User (delegator) can delegate a part of vesting to another user. Direct transfer of funds between balances does not occur. In the `golos.vesting` table, an appropriate entry is made that only the recipient can use the delegated part of vesting. Data on the distribution of funds in the table are adjusted.

**Return of delegated funds** Upon expiration of the delegation term, the right to use delegated vesting is revoked from the recipient of the vesting. The delegated part of vesting goes into a «frozen» state (blocked). The delegator can use this part of vesting only after it is unlocked.\
Data about rights between users to use the vesting is modified in the `golos.vesting` table. If the operation to return the delegated vesting is created before the end of delegation, the delegator can not use the returned vesting before the delegated period deadline.

## Parameters set in golos.vesting smart contract

Smart contract parameters are set using the `setparams` call. Each `vesting_param` parameter is a «variant» type containing a structure of one of the following types:

```cpp
name: vesting_param,
    types: [
        struct vesting_withdraw,
        struct vesting_amount,
        struct vesting_delegation
]
```

When calling the `setparams` action for the first time, all three types of parameters are transitioned to the smart contract. When performing repeated calls (to change the settings) not all the parameters are allowed to be transferred.

**vesting\_withdraw**\
The `vesting_withdraw` parameter is used to set intervals to convert vesting into tokens. It is the structure:

```cpp
struct vesting_withdraw : parameter {
    uint32_t intervals;
    uint32_t interval_seconds;
}
```

* `intervals` — number of intervals. The value to be set must be greater than zero. &#x20;
* `interval_seconds` — the duration of the interval (measured in seconds, in the first release the duration of the interval will be one week). The value to be set must be greater than zero. &#x20;

**vesting\_amount**\
The `vesting_amount` parameter is used to set minimum number of vesting to be converted. It is the structure:

```cpp
struct vesting_amount : parameter {
    uint64_t min_amount;
};
```

* `min_amount` — minimum allowable (threshold) amount of vesting, below which it is not converted to tokens. &#x20;

**vesting\_delegation**\
The `vesting_delegation` parameter is used to set the delegation parameters. The value is a structure of the following form:

```cpp
struct vesting_delegation : parameter {
    uint64_t min_amount;
    uint64_t min_remainder;
    uint32_t return_time;
    uint32_t min_time;
}
```

* `min_amount` — the minimum allowable amount of vesting for delegation / return delegated. Specifying the number of vesting below this value is not allowed. &#x20;
* `min_remainder` — minimum balance delegated. It is not allowed to delegate less than this value. As a result of the return of the delegated, the balance must be at least this value, or it must be zero. &#x20;
* `return_time` — the time it takes to return the delegated funds (in seconds). The time is counted from the moment of withdrawing funds from the account to which they have been delegated, until the moment they are receipted on the delegators’ balance. &#x20;
* `min_time` — minimum delegation time (in seconds). The withdrawal of delegated funds is possible not earlier than this value. &#x20;

### Actions used in golos.vesting smart-contract

The `golos.vesting` smart contract contains the following actions: [setparams](/devportal/application_contracts/golos_contracts/golos.vesting_contract#setparams), [validateprms](/devportal/application_contracts/golos_contracts/golos.vesting_contract#validateprms), [create](/devportal/application_contracts/golos_contracts/golos.vesting_contract#create), [retire](/devportal/application_contracts/golos_contracts/golos.vesting_contract#retire), [unlocklimit](/devportal/application_contracts/golos_contracts/golos.vesting_contract#unlocklimit), [withdraw](/devportal/application_contracts/golos_contracts/golos.vesting_contract#withdraw), [stopwithdraw](/devportal/application_contracts/golos_contracts/golos.vesting_contract#stopwithdraw), [delegate](/devportal/application_contracts/golos_contracts/golos.vesting_contract#delegate), [undelegate](/devportal/application_contracts/golos_contracts/golos.vesting_contract#undelegate), [timeoutrdel](/devportal/application_contracts/golos_contracts/golos.vesting_contract#timeoutrdel-timeoutconv-and-timeout), [timeoutconv](/devportal/application_contracts/golos_contracts/golos.vesting_contract#timeoutrdel-timeoutconv-and-timeout), [timeout](/devportal/application_contracts/golos_contracts/golos.vesting_contract#timeoutrdel-timeoutconv-and-timeout), [open](/devportal/application_contracts/golos_contracts/golos.vesting_contract#open), [close](/devportal/application_contracts/golos_contracts/golos.vesting_contract#close) and [paydelegator](/devportal/application_contracts/golos_contracts/golos.vesting_contract#paydelegator).

## setparams

The `setparams` action is used to configure the `golos.vesting` smart contract. The signature of this action is:

```cpp
void vesting::setparams(
    symbol symbol,
    std::vector<vesting_param> params
)
```

**Parameters:**

* `symbol` — identifier of the vesting for which the settings are made (there can be several types of vesting in the smart contract. For each type, a separate table is created containing the data on the distribution of this type of vesting).
* `params` — array vector comprising of several parameters. Each parameter is bound to one of the characters of vesting and is a structure [vesting\_param](/devportal/application_contracts/golos_contracts/golos.vesting_contract#parameters-set-in-golosvesting-smart-contract) . &#x20;

> **Please note:**\
> The order of the parameters in *params* is important: the parameters must be transmitted in the same order as described in the variant, and not all parameters are allowed to be passed. This *setparams* rule is valid in all the contracts.

## validateprms

The `validateprms` action checks all the parameters for validity and, respectively, controls the appearance of errors in them. The signature of this action is:

```cpp
void vesting::validateprms(
    symbol symbol,
    std::vector<vesting_param> params
)
```

**Parameters:**

* `symbol` — vesting identificator.
* `params` — array of several parameters.

## create

The `create` action is used to create and launch tokens in the vesting form. This action looks as:

```cpp
void vesting::create(
    symbol symbol,
    name notify_acc
)
```

**Parameters:**

* `symbol` — identifier of the created vesting, symbol of the associated token located in the `golos.token` smart contract.
* `notify_acc` — the name of the account (`golos.ctrl` smart contract) to which notifications will be sent when the balance changes. Each identifier of the corresponding account corresponds to a `notify_acc` account, which is a smart management contract. Each time the balance changes, the weights of the «leaders» change; for this, a smart management contract receives a notification.

  The successful completion of `create` action requires a two-step authentication:
* the right of account, which is the creator of the token with the same name as the vesting; &#x20;
* presence of the signature of the token creator's account.

  Additionally, the presence of a previously created vesting with the same symbol is checked. Re-creation of the same name of vesting is unacceptable.

## retire

The `retire` action is used for taking the «burnt» vesting out of circulation. The signature of this action is:

```cpp
void vesting::retire(
    asset quantity,
    name user
)
```

**Parameters:**

* `quantity` — the number and type of vesting to be «burnt». The parameter comes in the form of a structure containing fields:
  * the quantity of vesting tokens to be «burnt»;
  * type (symbol) of the vesting.
* `user` — user, performing the action.

  The character of the token and its creator are determined by the type of the `asset` value. The amount (i.e. `quantity`) of vesting withdrawn from the system must be greater than zero, but not greater than the amount on the user's balance sheet, as well as the amount that is in the unlocked state.

  The `retire` and `create` actions are similar to the actions of `golos.token` smart contract. The difference is that the vesting is the token for shares and is not used as a cryptocurrency.

  To perform this operation, the rights of the account that issued this vesting are required. Only publisher can initiate withdrawal from the turnover of token tokens.

## unlocklimit

The `unlocklimit` action is used to limit the «burnt» by the smart contract part of the vesting from the account balance. The user can allow the smart contract to withdraw (i.e.«burn») a certain part of the vesting from its balance sheet (for example, when «burning» the vesting for purchasing bandwidth resources). The user-selected part of the vesting for «burning» must be previously unlocked.\
The signature of this action is:

```cpp
void vesting::unlock_limit(
    name owner,
    asset quantity
)
```

**Parameters:**

* `owner` — the account name that unlocks and gives permission to «burn» vesting from its balance.
* `quantity` — specific vesting amount, safeguarded for «burning» and being in unlocked state. The specified quantity must be greater than zero or equal to zero. Zero number means no burning will be performed.

  To perform this action it is required the signature of the account `owner`.

## withdraw

The withdraw action is used to convert the vesting into tokens. The signature of this action is:

```cpp
void vesting::withdraw(
    name from,
    name to,
    asset quantity
)
```

**Parameters:**

* `from` — the account name that started the withdrawal process. In the process of withdrawing from the balance of this account, the amount of funds withdrawn in vesting.
* `to` — the account name on whose balance the amount of token funds is transferred.
* `quantity` — amount of funds allocated for withdrawal (i.e. conversion). &#x20;

To perform this action it is required the signature of the account `from`.

Conversion can be performed both between different accounts, and between the same account (the names of `from` and `to` match). Conversion is performed not once, but for a certain number of steps. The duration of one step is set by the action `setparams` (by default, it is set to one week, and the duration of the entire process (all steps) of conversion — 13 weeks). Converting vesting into tokens is performed in equal shares. Conversion by different parts is not allowed.

If the action `convert` is called again, the results of the previous conversion are canceled and new shares and a new balance are set in accordance with the current rate of vesting and token. In the process of conversion, internal actions are periodically called to verify the start of the payment of the next share and the execution of the current payment.

The conversion may imply the following restrictions:

* only undelegated part of the funds can be converted. It means that:
  * the vesting previously credited to the balance from the delegation operation cannot be involved in the conversion, since these funds must be returned upon completion of the delegation;
  * when vesting is marked as turned into the process of delegation, it cannot be converted until it is actually returned.
* the minimum allowed value to convert the vesting is `min_amount`; when it’s not met, the vesting is never converted into tokens.

## stopwithdraw

The `stopwithdraw` action is used for cancelling the «in progress» process of converting vesting to tokens.The signature of this action is:

```cpp
void vesting::stopwithdraw(
    name owner,
    symbol symbol
)
```

**Parameters:**

* `owner` — the account name that launched the conversion process.
* `symbol` — a type of vesting for which the conversion process is canceled (conversion can be performed for each type of vesting separately and therefore a separate `stopwithdraw` call can cancel only one separate process). &#x20;

To perform this action it is required the signature of the account `owner`. As soon as `stopwithdraw` starts, payments for conversion are immediately terminated.

## delegate

The `delegate` is used to delegate funds in the form of vesting. The signature of this action is:

```cpp
void vesting::delegate(
    name from,
    name to,
    asset quantity,
    uint16_t interest_rate,
    uint8_t payout_strategy
)
```

**Parameters:**

* `from` — the account name that launched the process of delegating the vesting. Specified amount of this account’s vesting will be marked as delegated.
* `to` — the account name to which funds are delegated. The balance of this account will be credited with the amount of funds in vesting. This amount of funds is absolutely refundable and will be returned to the `from` account upon completion of the delegation.
* `quantity` — amount of funds allocated for delegation.
* `interest_rate` — the percentage of payment to the account `from` that is deducted from curator fee of the account `to`.
* `payout_strategy` — identifier of delegation strategy (delegation options):&#x20;
  * `to_delegator` — delegation, in which reward from curation (curator fee) are charged to the account `from`;&#x20;
  * `to_delegated_vesting` — delegation, in which reward from curation (curator fee) is added to delegated funds (with compound interest). &#x20;

The `interest_rate`parameter accepts one of two values: «0» — `to_delegator` or «1» — `to_delegated_vesting`.

To perform this action it is required the signature of the account `from`.

It may imply the following restrictions:

* account names in the `from` and `to` parameters must be different (if the user has two or more accounts, then delegation between them is allowed);
* the amount of funds allocated for delegation must not be less than the minimum value set in the parameters of the smart contract when calling `setparams`;
* `interest_rate` interest payment should not exceed the maximum delegation payment value set in the smart contract parameters when calling `setparams`;
* when the `delegate` action is called again for the same `from` and `to` pair, with the same vesting symbol, it is not allowed:
  * change the delegation strategy;
  * change interest payment `interest_rate`.
* tokens allocated for the conversion of vesting remain blocked and cannot be allocated for delegation.

## undelegate

The `undelegate` action is used for partial or full refund of the delegated funds. The signature of this action is:

```cpp
void vesting::undelegate(
    name from,
    name to,
    asset quantity
)
```

**Parameters:**

* `from` — the account name that started the process of vesting delegation.
* `to` — the account name to which funds were delegated.
* `quantity` — the amount of funds received from the delegation. Value must be greater than zero. &#x20;

The `undelegate` action requires meeting of the following rules:

* transaction must be signed by `from` account.
* the presence of the actual body (object) of delegation, that is, the fact of the previous delegation between the sender and the recipient. Account balance `to` must contain funds delegated by account `from`.
* the amount of funds allocated for delegation must be specified in a relative value (how much it will decrease relative to the previous one). At the same time, the balance of funds delegated by the account `from` to the account `to`, should not be less than `delegation.min_remainder`.
* funds cannot be returned before the date set on the account when delegating.
* the amount of funds returned to the account’s balance must not exceed the amount of the funds delegated to them. &#x20;

Funds to the account’s balance are not returned immediately, but only after the end of the set period (by default, this period is seven days). This period can be changed and set in the parameters of the smart contract when calling `setparams`.

## timeoutrdel, timeoutconv and timeout

The `timeoutrdel`, `timeoutconv` and `timeout` actions are internal operations-related and are called by the smart contract to check the following data:

* the moment of converting funds from vesting to tokens;
* the time of return of the delegated amount. &#x20;

The signatures of these actions are:

```cpp
void vesting::timeoutrdel()
void vesting::timeoutconv()
void vesting::timeout()
```

Calling of these operations is not available to the user.

## open

The `open` action is used to create a record in the database to store the user's balance. The user can open the record both for himself and for another account. The signature of this action is:

```cpp
void vesting::open(
    name owner,
    symbol symbol,
    name ram_payer
)
```

**Parameters:**

* `owner` — account name (signature owner).
* `symbol` — parameter that uniquely identifies the vesting type.
* `ram_payer` — account name that signs the transaction and pays for the use of RAM. &#x20;

Transaction must be signed by `ram_payer` account.

## close

The `close` action is used for memory brush up occupied by a record. The signature of this action is:

```cpp
void vesting::close(
    name owner,
    symbol symbol
)
```

**Parameters:**

* `owner` — account name, record owner.
* `symbol` — parameter that uniquely identifies the vesting type. &#x20;

Transaction must be signed by the `owner` account.

To perform the action, it is required that the balance of all vesting, including the delegated one, equals to zero.

## paydelegator

The `paydelegator` system action is called by `golos.publication` smart contract. The publication smart contract cannot imply any changes to the tables of the `golos.vesting` smart contract. Therefore, when closing a post, the publication smart contract calls the `paydelegator` and through it makes payments to the witnesses.

The signature of this action is:

```cpp
void vesting::paydelegator(
    name voter,
    asset reward,
    name delegator,
    uint8_t payout_strategy
)
```

**Parameters:**

* `voter` — curator name whose curatorial fees were paid to delegates.
* `reward` — reward amount.
* `delegator` — account name, recipient of the reward.
* `payout_strategy` — identifier of delegation strategy. Accepts one of two values — «0» or «1». («0» — reward in tokens; «1» — reward in vesting).


# Memo-keys

## Purpose of the golos.memo smart contract

The `golos.memo` smart contract provides a storage for the memo-keys of the users. These keys can be used in client application to encrypt the private messaging between users. At the moment, the contract does not allow to add or remove memo keys, but only provides storage of memo keys that are imported from the genesis, for possible usage in the future.

## Actions used in golos.memo smart contract

The `golos.memo` smart contract does not support any actions.


# Determining Rewards for a Post

After a message is published, users (including curators, beneficiaries and author of this post) may be interested in voting process for this message, as well as predicted rewards for it. Users are given the opportunity to get up-to-date information about the voting process and predicted payments for the message on Golos application website.

The `golos.publication` smart contract implements logic to calculate all the necessary payments for the post and put the actual calculation results on the website. This logic is based on processing of actual data taken from messages that are received from Event Engine. The calculation results are modified after each received message from Event Engine in real time and depend mainly on such parameters as a size of the reward pool, a number of current publications, as well as «weight» of each voting user.

This section provides methods that can be applied in applications to determine the (predicted) amounts of rewards in real time mode, while is voting for a post. The list of determined rewards is as follows:

* total amount of rewards for the post; &#x20;
* total amount of fees for curators; &#x20;
* amount of fee for each of curators; &#x20;
* total amount of rewards for beneficiaries; &#x20;
* amount of reward for each of beneficiaries; &#x20;
* amount of reward for author of the post. &#x20;

## The data used in the methods of calculating rewards for a post

Voting for a post occurs after its creation and before it is closed. Amount of reward for the created post mainly depends on results of voting for this post and amount of funds in a rewards pool. The rewards pool for the post is selected with taking the time this post was created.

Each vote is registered in the `golos.publication` smart contract as an event. Information about this event is sent to Event Engine. Then this information is sent to Golos application.

Each application can apply its own method of calculating the rewards for a post and display all results in real time mode. However, it is recommended that the following events received from Event Engine were applied in their methods. These are: `rewardweight`, `poststate`, `poolstate` and `votestate`.

## rewardweight

The `rewardweight` event structure contains data about a paid share of reward for a post.

```cpp
struct reward_weight_event {
    mssgid message_id;
    uint16_t rewardweight;
};
```

**Parameters:**

* `message_id` — identifier of the post. &#x20;
* `rewardweight` — the paid share (in percent) of reward for the post taking into account the imposed fine. &#x20;

The activity of each author is limited, that is, the author can publish only a certain number of posts within a specified time interval. If the author’s activity does not exceed the limit, this author is not charged a penalty and the parameter `rewardweight` takes the value of 100 %. Otherwise, for each extra publication, the author will be dynamically charged a fine in the amount of from 0 to 100 %. Accordingly, the value of `rewardweight` for each extra publication will be reduced by the amount of the fine.

The `rewardweight` event is dispatched only in case of a penalty, at 100 % reward it is not dispatched.

## poststate

The `poststate` event structure contains data about current state of a post.

```cpp
struct post_event {
    mssgid message_id;
    base_t netshares;
    base_t voteshares;
    base_t sumcuratorsw;
    base_t sharesfn;
};
```

**Parameters:**

* `message_id` — identifier of the message. &#x20;
* `netshares` — amount of funds, which will be taken from the rewards pool as a total fee for the post (this parameter is calculated as a sum of positive `voteshares` values of all votes). &#x20;
* `voteshares` — a share of reward for the post is related to a separate vote. The separate vote value is calculated as multiplying a number of vesting by a weight of voting account. This parameter can take both positive and negative values. The sign «-» is assigned to «downvote» vote while the sign «+» is assigned to «upvote» one.
* `sumcuratorsw` — total weight of all curators votes at the current time.
* `sharesfn` — value calculated by the reward function (`mainfunc`) applied to the `netshares` message.

## poolstate

The `poolstate` event structure contains data about current rewards pool.

```cpp
struct pool_event {
    uint64_t created;
    counter_t msgs;
    eosio::asset funds;
    wide_t rshares;
    wide_t rsharesfn;
};
```

**Parameters:**

* `created` — the pool creation time (a pool selected by this time). &#x20;
* `msgs` — a number of messages awaiting rewards from the pool `created`. &#x20;
* `funds` — a number of tokens in the rewards pool. &#x20;
* `rshares` — total `rshares` value of all posts in the pool. &#x20;
* `rsharesfn` — total `sharesfn` value of all posts in the pool. &#x20;

## votestate

The `votestate` event structure contains data about current post voting results.

```cpp
struct vote_event {
    name voter;
    mssgid message_id;
    int16_t weight;
    base_t curatorsw;
    base_t rshares;
};
```

**Parameters:**

* `voter` — account name (a user) who votes for the message. &#x20;
* `message_id` — identifier of the message. &#x20;
* `weight` — a vote weight (in percent) of the account `voter`.   &#x20;
* `curatorsw` — a «weight» of the curator. &#x20;
* `rshares` — parameter used in calculating rewards for a post. The parameter is calculated as multiplication of voting account's vesting by a vote weight in percentages (`rshares = eff_vesting * weight / 10000`). This parameter can take both positive and negative values.The vote of «downvote» corresponds to a negative value. &#x20;

## Calculating a total reward for a post

To calculate the predicted amount of reward for a post in real time, it is recommended to use the formula

```
payout = reward_weight × funds × (sharesfn / rsharesfn)       (1)
```

**Components of the formula:**

* `payout` — resulting total amount of reward for the post at the time of receiving data from Event Engine. &#x20;
* `reward_weight = rewardweight::reward_weight` — a weight of reward for a post. &#x20;
* `funds = poolstate::state.funds` — total number of tokens in the reward pool. &#x20;
* `sharesfn = poststate::sharesfn` — a share of tokens that allocated in the rewards pool to be used for reward for the post (this parameter depends on a weight of the post). &#x20;
* `rsharesfn = poolstate::state::rsharesfn` — number of tokens that allocated in the rewards pool to be be spent on reward for all posts (parameter depends on total weight of all posts).&#x20;

Component `reward_weight` shows the share of author's fee for the publication, taking into account possible penalty imposed on this publication. By default, the number of publications per day should not exceed four. For exceeding this amount the author is charged a penalty. By default, the `reward_weight` value is calculated using the formula

```
 reward_weight = min{100 %, (400 %)² / postbw_charge²}      (1.1)
```

The `postbw_charge` component is the battery charge. Each use of the battery changes the charge by 100 %. The charge is restored completely, if within twenty-four hours from the previous posting no new post is created.

To calculate `payout` with using the formula (1), it is necessary to use data obtained from Event Engine only at the same time point.

## Сalculating the amount of fees to curators for a post

Total amount of fee to curators is a part of the funds as a percentage of the total reward for a post. An author can specify the percentage value `curators_prcnt` independently during the post creation. If the author does not specify this parameter, the `min_curators_prcnt` value is taken from the `pstngparams` table as this parameter. This value means minimum possible share allocated to curators from total rewards for the post.

To determine the amount of fee to curators it is recommended to use the formula

```
curation_payout = curators_prcnt × payout        (2)
```

**Components of the formula:**

* `curation_payout` — resulting total amount of fee to curators for the post at the time of receiving data from Event Engine, &#x20;
* `curators_prcnt` — share (in percent), deducted to curators, of the total reward for the post; &#x20;
* `payout` — total amount of reward for the post, calculated by the formula (1). &#x20;

Calculated by the formula (2) the total fee amount is distributed between all curators in accordance with the rules accepted in application. Below is recommended method of determining a fee amount for each of the curators.

To determine the `curator_rewardⱼ` fee allocated to individual curator `j` it is recommended to use this formula

```
curator_rewardⱼ = curation_payout × (curatorswⱼ / weights_sum)     (3)
```

**Components of the formula:**

* `curation_payout` — total amount of fee to curators for the post, calculated by the formula (2). &#x20;
* `curatorswⱼ = votestate::curatorswⱼ` — a weight of a positive vote `j` of the «upvote» type. &#x20;
* `weights_sum = poststate::weights_sum` — total weight of all positive votes of the «upvote» type. &#x20;
* `(curatorswⱼ / weights_sum)` — a share allocated to `j-th` curator of the total fee of all curators.&#x20;

The calculation of the fee amount via the formula (3) should be performed for each curator. Needed data about the curator are contained in the `vote_event` structure..

After calculating all the fees amount for all the curators may form a residual (unclaimed) amount. This amount may be formed due to fines during the voting (for example, for early voting). Such fine is not taken into account in the sum value of `sumcuratorsw`, but it does affect the value of `curatorsw` of a separate vote. The residual amount in the form of «surrender» will be returned back to the rewards pool for posts. This residual amount `unclaimed_rewards` is calculated by the formula

```
unclaimed_rewards = curation_payout - ∑(curator_rewardⱼ)       (4)
```

**Components of the formula:**

* `curation_payout` — total amount of fee to curators for the post, calculated by the formula (2).&#x20;
* `∑(curator_rewardⱼ)` — total fee amount of all curators, calculated by the formula (3).  &#x20;

## Сalculating the rewards to beneficiaries for a post

The part of funds allocated to author in the form of reward for a post is distributed between the beneficiaries and the author. The share of total reward allocated to beneficiaries, as well as the number of beneficiaries, are determined by the author at the time of posting. The rules according to which the reward is distributed among the beneficiaries are set and accepted for each application individually. Below is recommended method of determining the reward amount for each of the beneficiaries.

To determine the amount of reward to `j-th` beneficiary, it is recommended to apply the formula

```
ben_rewardⱼ = (payout - curation_payout) × weightⱼ       (5)
```

**Components of the formula:**

* `ben_rewardⱼ` — amount of reward to `j-th` beneficiary.
* `payout` — total amount of reward for the post, calculated by the formula (1). &#x20;
* `curation_payout` — total amount of fee to curators for the post, calculated by the formula (2).&#x20;
* `(payout - curation_payout)` — total amount of rewards allocated to beneficiaries and author. &#x20;
* `weightⱼ` — a weight of reward allocated to `j-th` beneficiary. This percentage value is set by the author at the time of posting. &#x20;

The award amount should be determined by the formula (5) for each beneficiary. Needed data about beneficiaries can be taken from the field `beneficiaries` of the table `message`. There is an array containing names and percentage deductions.

The total amount of payments `ben_payout_sum` allocated to beneficiaries is calculated by the formula

```
ben_payout_sum = ∑(ben_rewardⱼ)                         (6)
```

## Сalculating the reward to author for a post

To determine the amount of reward to author of the post it is recommended to use the formula

```
       author_reward = payout - curation_payout - ben_payout_sum
```

**Components of the formula:**

* `author_reward` — amount of reward to author of the post.
* `payout` — total amount of reward for the post, calculated by the formula (1). &#x20;
* `curation_payout` — total amount of fee to curators for the post, calculated by the formula (2). &#x20;
* `ben_payout_sum` — total amount of payments to beneficiaries, calculated by the formula (6). &#x20;

## Calculating total amount of rewards for a post in tokens and vestings

One part of reward for a post is paid in vesting, and another one is in tokens. Their percentage ratio is set at the time of posting. After calculating the amount of reward for a post by the formula (1), it is possible to determine the number of liquid tokens, as well as the vestings that make up this reward.

To calculate the number of liquid tokens `token_payout` in real time mode, it is recommended to use the formula

```
        token_payout = payout × tokenprop
```

**Components of the formula:**

* `payout` — total amount of reward for the post, calculated by the formula (1). &#x20;
* `tokenprop = post::tokenprop` — percentage of tokens in rewards. &#x20;

Number of vesting in the `vesting_payout` reward is

```
        vesting_payout = payout - token_payout
```

## Conclusion

The presented methods for calculating rewards for a post in real time mode are intended for their using in the Golos application. Although these methods are recommendatory, they can also be applied in other applications.


# Guide to Creating and Deploying an Application on CyberWay

This guide is intended to target the developers of smart contracts on CyberWay platform, as well as those who are interested in development using blockchain.\
The guide provides step-by-step instructions for creating and establishing a decentralized application on smart contracts for CyberWay blockchain. The guide also contains several instructions for implementing the most important software components including the smart contracts. A part of the instructions is inherited from the [EOS](https://developers.eos.io/eosio-home/docs/) blockchain documentation.

The body of the manual may be adjusted within the process of development of CyberWay platform.

**Contents:**

* [1 Preliminary Work](/devportal/create_application/overview) &#x20;
* [2 Creating a Simple Contract](/devportal/create_application/hello_users) &#x20;
* [3 Creating Tokens](/devportal/create_application/create_tokens) &#x20;
* [4 Understanding ABI Files](/devportal/create_application/abi_file) &#x20;
* [5 Data Persistence](/devportal/create_application/data_persistence) &#x20;
* [6 Secondary Indexes](/devportal/create_application/secondary_indexes) &#x20;
* [7 Adding Inline Actions](/devportal/create_application/adding_inline_actions) &#x20;
* [8 Inline Action to External Contract](/devportal/create_application/inline_action_to_external_contract) &#x20;
* [9 Conclusion](/devportal/create_application/conclusion) &#x20;


# 1 Preliminary Work

## Stages of building and deploying an application on CyberWay

* Preliminary organizational work. &#x20;
* Software development: &#x20;
  * development of contracts that implement the logic of the application algorithms; &#x20;
  * deployment of contracts on the blockchain node; &#x20;
  * contract testing. &#x20;

## Hardware and software requirements

It is recommended to build and debug contracts on a specific server where Testnet is installed. The server must meet the following characteristics (or above):

* RAM size (a min. of): 8 GB;
* disk space (a min. of): 20 GB.

The following software must also be installed on the server:

* an operating system:
  * Ubuntu (version recommended: 16.04 or 18.04);&#x20;
  * MacOS Darwin 10.12 (or later versions);
  * Centos 7;
  * Fedora 25 (or later versions);
  * Mint 18;
* a Nodeos utility version 15.0 (or later versions);
* a cleos utility version 15.0 (or later versions);
* a keosd utility version 15.0 (or later versions);
* a graphene library;
* a docker;
* a docker compose;
* a compiler: eosio-cpp;
* an ABI-generator: eosio-abigen.

Upon development and debugging the contracts can be loaded into the MainNet.

**Please note:**

> The required disk space for node running Mainnet will be determined later.

## Knowledge needed to develop applications for CyberWay

* Some basic knowledge of blockchain technology;
* An ability to create an account;
* An ability to operate a wallet;
* An ability to compile different programs written in C++.

## Preliminary organizational work

Before development it is necessary to determine the principles (rules) of the application. CyberWay provides resources and service software components which allow you to create all the contracts necessary for the implementation of application logic of different complexity.

The application contracts can be developed both from scratch as well as using previously developed contracts (for example, based on the contracts of [Golos application](https://cyberway.gitbook.io/en/devportal/golos_contracts)).

However, first, it is advisable to do the following:

* Identify the tasks that the new application will solve. Outline the rules within which these tasks could be solved.
* Develop an entire methodology for technical support of the application, including ways to involve technical experts in the development of the applications.
* Build thoroughly structural (for instance, block) schemes of the algorithms for successful performance of the application according to its rules. Determine a set of contracts that is required for implementation of the algorithms.
* Prepare a server (blockchain node) that will be linked to your application. Ensure that the Testnet software is already installed on the server and the developers has a wallet as well as private and public keys. Otherwise, it is necessary to:
  * Install the latest testnet version on the server, following the instructions of the [Testnet Installation Guide](https://cyberway.gitbook.io/en/validators/testnet_installation); &#x20;
  * Create a user wallet following our [guidelines for creating a wallet](https://cyberway.gitbook.io/en/devportal/create_development_wallet). &#x20;


# 2 Creating a Simple Contract

When creating a contract you may note that most of the actions are typical. The differences lay in the implementation of the functions performed by the contract, which are implemented directly in the body of the contract. In this section instructions are given for creating a contract whose main function is to issue a greeting that comes in the form of «Hello, user».

## 2.1 Create a directory for contracts

Create a directory CONTRACTS\_DIR, download the Contract Development Toolkit components necessary for compiling contracts in it.

```
cd CONTRACTS_DIR
git clone --recursive https://github.com/cyberway/cyberway.cdt --branch <branch name> --single-branch
cd cyberway.cdt
./build.sh
sudo ./install.sh
```

## 2.2 Create the hello.cpp file

```
cd CONTRACTS_DIR
mkdir hello
cd hello
touch hello.cpp
```

Put «Hello, user» text message into hello.cpp file.

```cpp
#include <eosiolib/eosio.hpp>

using namespace eosio;

class [[eosio::contract("hello")]] hello : public contract {
  public:
      using contract::contract;

      [[eosio::action]]
      void hi( name user ) {
         print( "Hello, ", user);
      }
};

EOSIO_DISPATCH( hello, (hi))
```

This action receives a parameter named «user» and displays a «Hello, user» message as a result. EOSIO\_DISPATCH acts as a macro-operation to handle this action.

## 2.3 Compile hello.cpp

```
eosio-cpp -o hello.wasm hello.cpp --abigen
```

## 2.4 Set (unfold) contract

During the installation of the contract an account of this contract is created, as well as a public key of the account.

```
cleos wallet keys
cleos create account cyber hello <public key> -p cyber@active
```

A guide for creating a wallet as well as creating a development key can be found on the CyberWay [website](https://cyberway.gitbook.io/en/devportal/create_development_wallet).

## 2.5 Set the absolute path to the created contract

Specify the absolute path `<contracts dir path>` to the contracts’ directory in the following command:

```
cleos set contract hello CONTRACTS_DIR/hello -p hello@active
```

## 2.6 Check whether contract is running properly

To verify the operation of the contract you can call an action using user’s name, for example, try sending a greeting to the user «Bob» using the following command:

```
cleos push action hello hi '["bob"]' -p hello@active
```

The operation is considered as successful if the following information is displayed on the monitor:

```
executed transaction: ... 
#    hello.code <= hello.code::hi               {"user":"bob"}
>> Hello, bob
```

To expand the functions of the contract it is necessary to expand the logic of the hello.cpp file. It’s the logic of the file file\_name.cpp that determines the functionality of the contract being created.


# 3 Creating Tokens

In CyberWay everybody can create his/her own type of tokens (In EOS this right applies to validators only). The tokens of the application should be deployed on a separate account from `cyber.token`. When creating tokens a developer can use a reference implementation of the `cyber.token` contract as a base by loading its contents into developer’s workspace.

## 3.1 Download contract source files

Enter the directory created for the contracts and load a copy of the remote repository with the contract source files into it.

```
cd CONTRACTS_DIR
git clone https://github.com/cyberway/cyberway.contracts --branch <branch name> --single-branch
```

The cyberway.contracts repository contains several contracts, but the `cyber.token` contract is required to create tokens.

```
cd cyberway.contracts/cyber.token
```

## 3.2 Create an account for the contract

Before you deploy a token-contract, you need to create an account of this contract by executing the following command line:

```
cleos create account olga olga.token <public key>
```

Command line parameters:\
olga — an account name for the contract being created;\
olga.token — a name of the token contract downloaded from the `cyberway.contracts` repository with the source files.

As an example a contract account has been created with the `olga.token` name.

## 3.3 Compile a contract

```
eosio-cpp -I include -o olga.token.wasm src/olga.token.cpp --abigen
```

The contract is compiled into a web assembler file wasm format. The presence of the `--abigen` option indicates that the `abi/olga.token.abi` file will also be generated.

## 3.4 Install Token contract

```
cleos set contract olga.token CONTRACTS_DIR/cyberway.contracts/olga.token --abi abi/olga.token.abi -p olga.token@active
```

Parameter:\
`olga.token@active` — a name that will be used to authorize the request.

The token contract will be considered successfully installed if the resulting output of the command being executed contains information of the form:

```
executed transaction:  ... 
#         eosio <= eosio::setcode               {"account":"olga.token","vmtype":0,"vmversion":0,"code":"<code>
#         eosio <= eosio::setabi                {"account":"olga.token","abi":"<code>
warning: transaction executed locally, but may not be confirmed by the network yet         ]
```

## 3.5 Create a Token

To create a new token use the action `create`. The argument is the type of the token `symbol_name`, which contains two values — the maximum value of the sentence and the symbol of the token. The call to this action has the form:

```
cleos push action olga.token create '{"issuer":"olga", "maximum_supply":"1000000000.0000 SYS"}' -p olga.token@active
```

The `-p olga.token@active` option authorizes the `olga.token` contract to perform this action.

Creating a token is considered successful if the following information appears on the monitor:

```
executed transaction: <info>
#   olga.token <= olga.token::create          {"issuer":"olga","maximum_supply":"1000000000.0000 SYS"}
```

As a result, a new token SYS will be created, which has an accuracy of four decimal digits. The maximum allowable number of tokens in circulation should be limited to the value of 1,000,000,000. To create this token, a permission of the contract `olga.token` is required. The name `olga.token@active` will be used when authorizing the request.

## 3.6 Releasing a Token

The author of a token can issue tokens to an already existing account, for example, to an account with the name «alice» by executing:

```
cleos push action olga.token issue '[ "alice", "100.0000 SYS", "memo" ]' -p olga@active
```

The following information should appear as a result of the command execution:

```
executed transaction:  ... 
#   olga.token <= olga.token::issue           {"to":"user","quantity":"100.0000 SYS","memo":"memo"}
>> issue
#   olga.token <= olga.token::transfer        {"from":"olga","to":"alice","quantity":"100.0000 SYS","memo":"memo"}
>> transfer
#         olga<= olga.token::transfer        {"from":"olga","to":"alice","quantity":"100.0000 SYS","memo":"memo"}
#          user <= olga.token::transfer        {"from":"olga","to":"alice","quantity":"100.0000 SYS","memo":"memo"}
```

The output contains one `issue` action and three `transfer` actions. At `issue` run time, three internal calls are additionally generated notifying the sender and receiver of tokens.

## 3.7 Token transfer

Some tokens can be transferred from the balance of one account to the balance of another account. For example, to transfer an amount of 25 tokens from the «alice» account balance to «bob» account balance you need to use the following command line:

```
cleos push action olga.token transfer '[ "alice", "bob", "25.0000 SYS", "m" ]' -p alice@active
```

To perform this action you need permission from the «alice» sender account — the `-p alice@active` option is available.

The transfer of tokens is considered as successfully completed if upon its completion the following information appears in the command window:

```
executed transaction:  ... 
#   olga.token <= olga.token::transfer        {"from":"alice","to":"bob","quantity":"25.0000 SYS","memo":"Here you go bob!"}
>> transfer
#          user <= olga.token::transfer        {"from":"alice","to":"bob","quantity":"25.0000 SYS","memo":"Here you go bob!"}
#        tester <= olga.token::transfer        {"from":"alice","to":"bob","quantity":"25.0000 SYS","memo":"Here you go bob!"}
```

To control the token transfer, you can use the `get_currency_balance` call to get the balance data of the sender and the receiver accounts by executing:

```
cleos get currency balance olga.token alice SYS
cleos get currency balance olga.token bob SYS
```




---

[Next Page](/llms-full.txt/1)